Background
There are three categories for SNES coprocessors.
Discrete logic (MMCs)
In this category, we have chips with hard-coded logic to perform various utility functions.
- OBC1 (memory mapper)
- S-RTC (real-time clock)
- S-DD1 (memory mapper, decompressor)
- SPC7110 (memory mapper, decompressor, RTC, math unit)
In this field, only the decompression algorithms prove troubling. The S-DD1 decompression algorithm was reverse engineered by Andreas Naive; and the SPC7110 decompression algorithm was reverse engineered by neviksti.
Programmable coprocessors (CPUs)
In this category, games provide their own programming code inside of their program ROMs. As such, these coprocessors are very well documented.
- SuperFX
- SA-1 (Super Accelerator)
The difficulty in supporting these is simply the breadth of their functionality. They have a tendency to have dozens of ancillary functions.
Pre-programmed coprocessors (DSPs)
The final category of coprocessors turn out to be the most fascinating. These are coprocessors that have a pre-made program designed specifically for the games that use them.
These chips are often highly proprietary, and great lengths are taken to hide not only the ISA used, but also the program code itself.
- Cx4
- DSP-1
- DSP-1A
- DSP-1B
- DSP-2
- DSP-3
- DSP-4
- ST010
- ST011
- ST018
The most interesting characteristic of pre-programmed processors, is that it becomes possible to simulate them using high-level emulation. Rather than emulating each add and subtract operation, one can instead map "command 7" to "calculate the distance of two objects in 3D space."
This is a fascinating technique that creates very fast code. It is the primary reason that post-SNES consoles can be emulated at full speed on modern computers, in fact.
But the technique is not without its flaws. Timing cannot be accurately emulated, as you are no longer tracking the number of add and subtract operations needed to complete a calculation. In most cases, timing is simply ignored entirely: commands are treated as though they have executed immediately.
It also hides the inner workings of the processor: homebrew cannot take advantage of the underlying coprocessors to create their own programs to execute. This greatly limits the usefulness of these coprocessors.
This technique is also very hard: it is no small matter to perfectly simulate complex math equations simply by studying chip input and output values. Even after nearly a decade of research, only the DSP-1 and DSP-2 were really bit-perfect in their calculations. The DSP-3, ST011 and ST018 were almost entirely unemulated: none of them were sufficient to play the games that used them.
LLE Project
On September 10th, 2009; I started out on a project to emulate all of the pre-programmed processors using low-level emulation. As of March 6th, 2012, I have succeeded in that goal. But it would not have been possible without the help of so many individuals.
This article seeks to describe the effort that was involved, and those who helped make this possible.
Fundraising
Perhaps the most compelling reason why HLE was used on these DSPs was because the programs were protected from being extracted. Sometimes to very great lengths. And sometimes, as it turns out, hiding in plain sight.
In order to extract these programs from most of the DSPs, we had to decap the chips, scan them in with an electron microscope, and 'tweak' the processors to allow us to dump their protected program ROMs.
As you can imagine, this kind of work costs a substantial amount of money. Professional firms that do this can charge upwards of $100,000 per processor for this kind of work.
Thankfully, Lord Nightmare from the MAME/MESS project was in contact with a savant named Dr. Decapitator, with the necessary knowledge and hardware to make this possible. Even better, he was willing to do it just for the cost of the donor cartridges and supplies. This worked out to $250 per coprocessor.
In the end, we raised over $2,500 to make this possible.
DSP-1
- anonymous: $50
- panzeroceania: $50
- dfreer: $20
- ht1848: $53
- FitzRoy: $50
(Note: Dr. Decapitator graciously worked on all three DSP-1 revisions for one payment.)
DSP-2
- anonymous: $250
DSP-3
- tukuyomi: $100
- generalleoff: $95
- Themaister: $50
DSP-4
- byuu: $30
- caitsith2: $25
- Andrew Clunn: $80
- krick: $95
- Marcus Kühne: $25
ST010, ST011, ST018, Cx4
- Łukasz Krawczyk: $1,000
Cartridges
- Lord Nightmare: all but ST018
- Kakashi: 3x ST018
- byuu: 2x ST018
- d4s: 1x ST018
Cartridge Funds
- Danish: $100
- zidanax: $50
Without such a gracious outpouring of donations, this project would never have even been able to get off the ground.
DSP-1(A,B), DSP-2, DSP-3, DSP-4
These DSPs have commands to allow dumping the data ROMs (math tables and such); but are heavily protected against having their program ROMs read out. For these, Dr. Decapitator had to decap the chips, and read the ROM data directly off of the chips internally.
Upon looking at the markings on the die, we confirmed that these were all the same processor: the NEC uPD77C25. Thankfully, this processor has some documentation available.
I wrote an emulator for this core, and Cydrak spent some time fixing the bugs in my implementation.
An interesting aside: the DSP-1A turned out to be nothing more than a die shrink of the DSP-1. The program and data ROMs are identical in both revisions. The DSP-1B, however, fixes bugs that existed in the original DSP-1 program.
ST010, ST011
Interestingly, these turned out to be a souped up version of the NEC uPD77C25. The die identified this chip as the NEC uPD96050.
In addition to a lot more ROM and RAM, these chips ran much faster than their uPD77C25 counterparts. But what made these especially challenging was that this was a one-off custom chip made for Seta. NEC never released any public documentation on the ISA. When contacted, they refused to provide any.
Luckily, it was mostly backward-compatible with the uPD77C25. I was able to reverse engineer all of the new instructions added to this model.
Cx4
Upon decapping this DSP, we found a die marking of "HG51B169". This was an Hitachi DSP. This chip proved very challenging to read out electronically, and hope was looking grim for ever extracting the program ROM.
And then, Jonas Quinn made an amazing discovery: the program ROM was actually stored right there inside the game cartridge itself!
Unfortunately, the ISA was once again undocumented. And this time, we had absolutely nothing to work off of, except the previous HLE code for this chip. But that's all that was needed. segher got involved and reconstructed the entire instruction set just from looking at the binary data and HLE code!
Overload took that information, and found an exploit in the program code that allowed him to electronically dump the data ROM that was stored inside the DSP itself.
From here, it was relatively simple for me to emulate the chip.
ST018
The final processor turned out to be a nightmare as well. Once again, decapping and reading out the program was proving to be quite a challenge. Even worse, there was no die marking on this chip to identify it, so we had no idea what kind of ISA it used. We didn't evne know who manufactured the chip.
This time, however, we got really lucky. There are debug commands inside the program ROM that allow us to dump the program and data ROMs.
But running your own commands on a physical cartridge is no easy feat. Thankfully, blargg supplied me with just what was needed: a serial interface between the SNES and a PC.
With this interface, I was able to swap between a copier and an ST018 cart, upload code from my PC to dump the ROM, and send that data back to my PC to log.
So in this instance, I was actually the one to extract one of these DSP programs. Neat!
Yet once again, we were stuck looking at a binary blob. And this time, we had no real HLE code to go off of. Luckily, Cydrak recognized the ISA just from looking at the binary: it was an ARMv3 CPU!
So, one last time, I emulated this final processor. Cydrak came in and really saved the day with multiple critical CPU fixes, and LostTemplar helped in analyzing the program code.
Conclusion
It took multiple years, lots of money, and the help of a vast number of individuals; but we've finally pulled it off: every SNES DSP program has now been extracted and emulated fully.
I believe the most important point of all is the power of open source and community involvement. If I were to go at this solo, I would have never succeeded at all. But by fostering an open environment, and relying on others to overcome my weaknesses, we are all able to accomplish something truly amazing: due to this effort, every last SNES game ever commercially released is now fully emulated, and fully playable!
And this is why I am such a staunch supporter of open source development in the emulation community.
© 2004–2012 byuu - archive.is/evDty