Remember how Super Mario RPG was really expensive when it came out? Thats why. Quite a few other games used this chip, but it seems to be all Japan only except for Kirby Super Star and Kirby's Dream Land 3, neither of which were particularly exceptional games.
I am sure that's enough to cover the cost of an ARM6.
From the perspective of a software guy, this sounds very impressive. Can some hardware guy chime in and tell us just how impressive it is to recognize a CPU from looking at a binary dump?
Also for every ISA there are some instructions that are very common, for example x86 has very-recognizable NOPs (0x90).
Having said that, seeing it is ARMv3 code specifically in one glance is pretty impressive.
You seem to have added some hyperbole. There was no mention of "in one glance".
Also, it's likely that he recognized that it was ARMvSomething (which is relatively easy) and then did some comparisons to narrow it down.
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.
I however think it is a prime example of great teamwork rather than open source.
Open source is a mean, not an end. We tend to forget that.
Open Source is both a means and an end. It can be a means to collaboration, but the ongoing sharing of knowledge is itself a virtue.
I prefer to read a book about why and how a software is made than to read the source code.
From Dr Decapitator's page:
"The data was extracted by laser-cutting the top two ROM bits from the actual CPU logic (so it would read all opcodes as OP(00) or LD(11) opcodes depending on whether lines were pulled high or low, and neither OP nor LD can branch address), then microprobing, 8 bits at a time, the ROM outputs from before the cut. The program counter was also monitored to ensure that the data read started at 0×000 and didn’t jump anywhere."
(http://decap.mameworld.info/2010/12/16/snes-dsp1b/)
You can read more about chip decapping here: http://guru.mameworld.info/decap/index.html And here: http://www.defcon.org/images/defcon-12/dc-12-presentations/G...
Yes, basically we bypassed the JP (jump) and RT (return) opcodes, so that the program counter always stepped by one. Externally clock the CPU to move to the next instruction, and keep logging the data lines prior to the OP/LD cuts.
For what it's worth, this is almost identical to the process initially used to hack satellite TV smartcards, except it seems that these devices had a lot less physical tamper protection (and can't be reprogrammed with a new ROM over-the-air).
I think this kind of console hack is a dying art - as process shrinks and most consoles move closer and closer to commodity hardware and off-the-shelf software, LLE and chip decapping become less and less appealing and software exploits are the name of the game.
Absolutely awesome, though - this is the kind of story I come to HN to read.
