Most accurate SNES docs for emulation

[mozz]

First, a big thank-you to the everyone who does the hard work of reverse-engineering obscure details about the SNES. Especially big thank-you to anomie, Overload, byuusan.

I very much want to make sure that the information you guys discover isn't lost. Much of it seems to be captured only in forum threads. I dream of having all the "most accurate" info about SNES emulation captured in one set of docs. I know anomie had made a good start on this, as he gave me a copy of his docs in late 2004.

Basically I am wondering 3 things:

(1) Is anomie still updating his docs with the recent findings?
(2) Has byuusan started some docs to capture all the obscure timing details he's dug up on the SNES?
(3) What would it take to get anomie and byuu together to produce one heavenly volume of SNES technical documentation goodness?

[Nach]

(1) Is anomie still updating his docs with the recent findings?

Yes.

[byuu]

(2) Has byuusan started some docs to capture all the obscure timing details he's dug up on the SNES?

Started.
I mostly just started on this so I could document the NMI / IRQ timing behavior, as it's very non-trivial and I want it documented somewhere before I forget how it works.

(3) What would it take to get anomie and byuu together to produce one heavenly volume of SNES technical documentation goodness?

A salary would be nice.

[anomie]

(3) What would it take to get anomie and byuu together to produce one heavenly volume of SNES technical documentation goodness?

A salary would be nice.

Seconded.

[mozz]

A salary would be nice.

I didn't mean "write a book". =P

I know writing docs is a tedious, time-consuming task. Its just that only a handful of people have the unique combination of knowledge and experience to write them. Most of the info gets posted to one forum or another, but its difficult for those of us with less hands-on experience to consolidate the info into docs. Misunderstandings or omissions are likely.

You and anomie and a handful of others have unique expertise in this area, and lots of little details in your heads. Years from now, working SNES hardware will be harder and harder to find, and many of the current SNES emulation devs may have drifted away to other areas. Higher quality documentation would make it easier for newcomers to join the SNES emu development scene.

Anyway, I just want to say that your efforts to create accurate docs are valued, and I hope you keep them up.

P.S. I would love to have a copy of any docs you are willing to share (email to mozzpack_AT_hotmail.com). I'm currently working on an SPC core in assembly, and the idea of creating a whole emulator eventually is on my mind.

[creaothceann]

I'm currently working on an SPC core in assembly

I'd advise to built it in in a higher-level language first, and then optimize the compiled code if needed.
Btw. ZSNES is currently ported from ASM to C/C++.

[/offtopic]

[mozz]

I'm currently working on an SPC core in assembly

I'd advise to built it in in a higher-level language first, and then optimize the compiled code if needed.
Btw. ZSNES is currently ported from ASM to C/C++.

[/offtopic]

Yea, I know. But I'm only doing this for fun--for me the fun is in prematurely-optimizing the assembly. Yes of course its an impractical way to do things, but I'll just try it for a while and see where it goes. My core is aimed at a niche that doesn't seem to be filled yet (accurate per-cycle timing, optimized for speed except for a few major optimizations for size). It will probably be 10-20x smaller (in code size) than a C core, and at least 5x smaller than most of the assembly cores out there.

[Bobbias2.0]

damn, that would be small, and fast, if you can get those specs, or even near them.

[anomie]

I know writing docs is a tedious, time-consuming task.

For me, it's more that i have to pay the bills. Which doesn't leave much time for the extensive testing and double-verification that writing a good doc requires...

[Bobbias2.0]

well, if someone else knows what is needed to know, they can proofread the doc, and help clear things up (because i know writing a doc requires more than just knowing the subject matter)

[mozz]

I know writing docs is a tedious, time-consuming task.

For me, it's more that i have to pay the bills. Which doesn't leave much time for the extensive testing and double-verification that writing a good doc requires...

Lol, I'll settle for docs that distinguish between "we tested it thoroughly and it works like this" and "our current best guess is..."

I'm not trying to rush you or anything. I mostly started this thread to find out what the state of people's docs was, and to cheer you guys on a bit (since I'd like to see comprehensive, higher-quality docs replace the mishmash of crap that people like me have access to now). The existence of better docs can only be a good thing, but obviously its up to you whether you want to work on them or not, or make them public or not.