
Bsnes has emulated every SNES DSP - pkmays
http://byuu.org/articles/emulation/snes-coprocessors
======
feralchimp
Add one to the list of "people who should never pay for another beer in their
lifetime":

 _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._

~~~
plaes
I hate to state the obvious, but the quote you gave actually talks about 3
people.

~~~
feralchimp
FWIW, I meant Dr. Decapitator. But really, take your pick.

------
SoftwarePatent
"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!"

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?

~~~
wladimir
The instruction size is the first thing that is apparent. By looking at the
pattern you can distinguish between fixed-sized, or variable-sized
instructions, telling a lot about the architecture. ARM either has 16 bit
(thumb mode) or 32 bit (normal) fixed-size instructions.

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 ARM _v3_ code specifically in one glance is
pretty impressive.

~~~
rcfox
> 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.

------
kevingadd
It blows my mind that there's a SNES game out there that shipped with an ARMv3
core inside it. I wonder how much that ate into their margins?

~~~
jcromartie
These games were much more expensive than games today. Accounting for
inflation, SNES games originally cost about $100 in today's dollars.

I am sure that's enough to cover the cost of an ARM6.

~~~
tibbon
And yet for some reason gamers complain that games of 2012 are too expensive.
$60 of 2012USD really isn't that much compared to $50 of 1992USD. Add in the
fact that you can get some excellent an amazing games on mobile platforms now
for a dollar, and gaming is cheaper than ever.

~~~
codezero
Difference was that back then a game from start to end lasted a whole lot more
than 4-8 hours.

Yes I know lots of games now do as well, but lots of the most popular ones
don't.

~~~
tibbon
I wish there was a good data source on that, because it would be interesting
to see.

I'm not sure if the single player play time has really gone up or down to get
through the main story, but modern games seem to incorporate almost endless
numbers of side quests, self generating quests, achievement junky-only quests
(kill 10,000 of X) and also a lot of multiplayer functionality.

------
bri3d
I love how game consoles are always providing exciting hacks - from the
variety of CPUs and DSPs used in SNES cartridges to the brute-forced SHA
collision exploited to hack the PSP.

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.

------
shin_lao
Congratulations on this very difficult project.

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.

~~~
nitrogen
_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.

~~~
shin_lao
Open source does not imply proper documentation or easy knowledge extraction.

I prefer to read a book about why and how a software is made than to read the
source code.

~~~
nitrogen
No doubt books are very useful learning tools. However, depending on the code,
source code can be equally if not more useful. For example, years ago I
learned a lot about C by reading (and later writing) Linux kernel source code.

It's also true that code being open source doesn't mean the code is useful,
but a book being published doesn't mean the material is presented well,
either.

Maybe it's just my pro-open source bias, but it feels like you've got an axe
to grind against open source. If so, would you mind sharing why (maybe you
know something I don't)?

~~~
shin_lao
Absolutely no axe to grind I've contributed to open source projects and will
certainly continue to.

What I don't like is that people overstate the importance of open source and
think it's the solution to everything.

Open source is great for some projects, useless and even counterproductive for
others.

~~~
byuu
I can agree with that.

I'm sure you weren't implying me in particular, but to clarify, I certainly
don't think open source is the solution to everything.

I just find it particularly important in the field of emulation. This is much
like a science, with constant refinements to theories. Since we're running
against the clock to preserve these systems before they die, I assign much
more value to open source emulators than I do to other applications (for
instance, I'm happy to use the closed source nVidia driver on Linux.)

~~~
shin_lao
I think open source makes a lot of sense for research. I'm actually surprised
researchers don't publish that much source code.

------
mistercow
This is fascinating, but I'm not really clear on what role the electron
microscope played. Did it just allow them to see where they needed to modify
the chips to allow them to dump their ROM?

~~~
Leynos
That's correct. The data was also extracted using probes under a microsope in
this case.

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...](http://www.defcon.org/images/defcon-12/dc-12-presentations/Grand/dc-12-grand.ppt)

~~~
byuu
Oh, good. I was intentionally vague there, as I wasn't sure how much was
public knowledge.

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.

------
pkmays
Can any MAME/MESS hackers tell us if we'll be seeing accuracy improvements now
that this information is available. MESS is my console emulator of choice.

~~~
simcop2387
I wouldn't be too surprised if the details from all of this get pulled into
MAME/MESS. It will take some rewriting though as I believe BSNES is written
using a number of C++ features (I seem to recall it even needing some C++11
stuff from when I last played with the source). The CPU cores themselves I'd
imagine would be fairly easy to port over but I'm not sure how tied in
everything is for timing and everything else in there.

~~~
byuu
The main magic I do for RISC CPUs is allowing a write callback binding to the
registers (overloading operator=) This allows us to handle pipeline
invalidation on writes to the PC register, without having to special case the
hell out of every single instruction that can modify it.

~~~
simcop2387
Ah seems my memory was bad there. I must have had it confused with another
emulator, however that sounds while it wouldn't be trivial to rewrite those
sections it shouldn't be very difficult to do so either, just very very
tedious. I think other than that there could only be a licensing issue, and I
seem to recall that bsnes had a fairly liberal license that shouldn't run into
any problems. Though obviously you'll know better than me byuu :) In that case
it's all about time and who has it that'll determine when/if it'll happen

------
scw
I found this Wikipedia article helpful in explaining the roles of the DSPs in
the games that used them:
[http://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_c...](http://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_chips)

------
funkah
Great stuff! I found myself missing a bit of background, though, which you can
find here: <http://byuu.org/articles/emulation/decap>

