Most accurate SNES docs for emulation
Moderator: ZSNES Mods
Most accurate SNES docs for emulation
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?
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?
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
Re: Most accurate SNES docs for emulation
Yes.mozz wrote: (1) Is anomie still updating his docs with the recent findings?
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
Started.(2) Has byuusan started some docs to capture all the obscure timing details he's dug up on the SNES?
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.
A salary would be nice.(3) What would it take to get anomie and byuu together to produce one heavenly volume of SNES technical documentation goodness?
I didn't mean "write a book". =Pbyuusan wrote:A salary would be nice.
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.
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
I'd advise to built it in in a higher-level language first, and then optimize the compiled code if needed.mozz wrote:I'm currently working on an SPC core in assembly
Btw. ZSNES is currently ported from ASM to C/C++.
[/offtopic]
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
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.creaothceann wrote:I'd advise to built it in in a higher-level language first, and then optimize the compiled code if needed.mozz wrote:I'm currently working on an SPC core in assembly
Btw. ZSNES is currently ported from ASM to C/C++.
[/offtopic]
-
- Rookie
- Posts: 41
- Joined: Wed Oct 12, 2005 12:34 am
-
- Rookie
- Posts: 41
- Joined: Wed Oct 12, 2005 12:34 am
Lol, I'll settle for docs that distinguish between "we tested it thoroughly and it works like this" and "our current best guess is..."anomie wrote: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...mozz wrote:I know writing docs is a tedious, time-consuming task.
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.