Hi,
I'm trying to write (yet another) SNES emu. I'm no newb in emu development, but I would like a few recommendations regarding where to start (65816 ? SPC700 ? PPU ?) and some cool links at accurate docs if you have some, since it's seems to be lacking seriously.
Thanks in advance and keep the good work coming up !
Regards,
LTronic (from Potato Emulation)
Trying to write a SNES emulator..
Moderator: ZSNES Mods
-
Bahamut_ZERO_Clue
Here's some ideas for ya. Keep it simple. You may want to start with a debugging program and work it out from there that debugs the chips and other processing units. Most emulators start out this way and work in other things later. Besides you want to fully test your code and readouts will help greatly.
API wise... use DirectX and keep it minimal to DirectDraw, DirectSound, DirectInput, and (if neccessary) DirectPlay. You won't need 3D graphics and software video Interpolation methods for pixel blitting will work out very well along with some basic Scale2x methods and VSync. DirectDraw is hardware accelerated enough anyway.
SNESAmp if I remember has/had a very good sound engine based on the SPC700 but with some modifications for newer sound cards, CPUs, and SIMD instruction sets. I'm not sure if the developer still works on it either but last I heard it was pretty decent. It's a good alternative if you don't want to clone out SNEeSe, Snes9x, or ZSNES's engines or build a brand new one.
Lastly, work slowly and carefully. Never rush things ahead. A lot of documents that are available out on the web for the SNES's inner workings were either incorrect or incomplete. The guys here if I'm not mistaken have better and more accurate documents that some found around the web.
API wise... use DirectX and keep it minimal to DirectDraw, DirectSound, DirectInput, and (if neccessary) DirectPlay. You won't need 3D graphics and software video Interpolation methods for pixel blitting will work out very well along with some basic Scale2x methods and VSync. DirectDraw is hardware accelerated enough anyway.
SNESAmp if I remember has/had a very good sound engine based on the SPC700 but with some modifications for newer sound cards, CPUs, and SIMD instruction sets. I'm not sure if the developer still works on it either but last I heard it was pretty decent. It's a good alternative if you don't want to clone out SNEeSe, Snes9x, or ZSNES's engines or build a brand new one.
Lastly, work slowly and carefully. Never rush things ahead. A lot of documents that are available out on the web for the SNES's inner workings were either incorrect or incomplete. The guys here if I'm not mistaken have better and more accurate documents that some found around the web.
-
byuu
Re: Trying to write a SNES emulator..
Since you're writing this in Java for whatever reason, I can assume hardware accuracy isn't a top priority, correct? (and if it is, then I hope your target audience are Cray users)
In that case, I'd focus on writing a 65816 core. No harder than a 6502 core. If you throw in some really basic mode1 PPU support (tile rendering, scrolling regs, palette stuff), you should be able to get a lot of stuff running. Do yourself a favor and start out with a line-based renderer. You're just wasting your own time writing a tile-based renderer for a system like the SNES.
You can get away with faking the spc700 until you get some commercial games running.
You're also going to need NMI + IRQ interrupts for pretty much anything other than the most basic demos. And those a royal PITA to get right. I'd venture to say no SNES emulator ever released has had them 100% right (so far, at least).
If accuracy were a priority, though, I'd recommend coding a cycle-based 65816 core. It would make many timing intricacies much easier later on.
Oh, and good luck.
In that case, I'd focus on writing a 65816 core. No harder than a 6502 core. If you throw in some really basic mode1 PPU support (tile rendering, scrolling regs, palette stuff), you should be able to get a lot of stuff running. Do yourself a favor and start out with a line-based renderer. You're just wasting your own time writing a tile-based renderer for a system like the SNES.
You can get away with faking the spc700 until you get some commercial games running.
You're also going to need NMI + IRQ interrupts for pretty much anything other than the most basic demos. And those a royal PITA to get right. I'd venture to say no SNES emulator ever released has had them 100% right (so far, at least).
If accuracy were a priority, though, I'd recommend coding a cycle-based 65816 core. It would make many timing intricacies much easier later on.
Oh, and good luck.
Thanks for your advice.
I've been able to get many demos and commercial games running. A lot of games are not far from being playable.
Here is the current status :
65C816 emulation : Complete, a few bugs left IMHO
SPC700 emulation: 90 %
PPU emulation : 50-70 %
Sound DSP emulation : 0%
I have also an SPC700 "skipper" in my 65816 core in order to avoid check on 0x2140-2143 but I really want to get rid of it ASAP.
Right now we are facing major graphic corruption in many, many games, not talking about missing planes.
Obviously of emulation core is line-based as byuu suggested it.
I'm pretty confident in most 65816 opcodes and timing, but did not check IRQ/NMI a lot.
Any special tip for IRQ/NMI ?
I've been able to get many demos and commercial games running. A lot of games are not far from being playable.
Here is the current status :
65C816 emulation : Complete, a few bugs left IMHO
SPC700 emulation: 90 %
PPU emulation : 50-70 %
Sound DSP emulation : 0%
I have also an SPC700 "skipper" in my 65816 core in order to avoid check on 0x2140-2143 but I really want to get rid of it ASAP.
Right now we are facing major graphic corruption in many, many games, not talking about missing planes.
Obviously of emulation core is line-based as byuu suggested it.
I'm pretty confident in most 65816 opcodes and timing, but did not check IRQ/NMI a lot.
Any special tip for IRQ/NMI ?