I was browsing the source code for some Super Nintendo Entertainment System (SNES) emulators recently. I learned some interesting things about compression hardware. I had previously uncovered one compression algorithm used in an SNES title but that was implemented in software.
SNES game cartridges — being all hardware — were at liberty to expand the hardware capabilities of the base system by adding new processors. The most well-known of these processors was the Super FX which allows for basic polygon graphical rendering, powering such games as Star Fox. It was by no means the only such add-on processor, though. Here is a Wikipedia page of all the enhancement chips used in assorted SNES games. A number of them mention compression and so I delved into the emulators to find the details:
- The Super FX is listed in Wikipedia vaguely as being able to decompress graphics. I see no reference to decompression in emulator source code.
- DSP-3 emulation source code makes reference to LZ-type compression as well as tree/symbol decoding. I’m not sure if the latter is a component of the former. Wikipedia lists the chip as supporting “Shannon-Fano bitstream decompression.”
- Similar to Super FX, the SA-1 chip is listed in Wikipedia as having some compression capabilities. Again, either that’s not true or none of the games that use the chip (notably Super Mario RPG) make use of the feature.
- The S-DD1 chip uses arithmetic and Golomb encoding for compressing graphics. Wikipedia refers to this as the ABS Lossless Entropy Algorithm. Googling for further details on that algorithm name yields no results, but I suspect it’s unrelated to anti-lock brakes. The algorithm is alleged to allow Star Ocean to smash 13 MB of graphics into a 4 MB cartridge ROM (largest size of an SNES cartridge).
- The SPC7110 can decompress data using a combination of arithmetic coding and Z-curve/Morton curve reordering.
No, I don’t plan to implement codecs for these schemes. But it’s always comforting to know that I could.
Not directly a compression scheme, but still a curious item is the MSU1 concept put forth by the bsnes emulator. This is a hypothetical coprocessor implemented by bsnes that gives an emulated cartridge access to a 4 GB address space. What to do with all this space? Allow for the playback of uncompressed PCM audio as well as uncompressed video at 240x144x256 colors @ 30 fps. According to the docs and the source code, the latter feature doesn’t appear to be implemented, though; only the raw PCM playback.
The sd2snes FPGA-based SNES cartridge has MSU1 support, taking it (just barely) out of the ‘hypothetical’ stage I suppose.
There are a couple of videos of it working (including video playback):
http://www.youtube.com/sd2snes
Since both the SuperFX and SA-1 are coprocessors, the former a DSP and the latter a 65c816-derivative… Is it not entirely possible that said decompression was implemented in software?
That said, it is also possible Wikipedia is wrong. This would not overly surprise me.
@James: De-virtualization! Good stuff. :-)
@Owen: I certainly entertained the possibility that Wikipedia was wrong. That’s why I wanted to find proof of compression via emulator source code.
I noticed that SA-1 is basically a faster SNES CPU. I wondered if it was used in the previous SNES compression algorithm I unearthed. But that game was a Zelda game and no Zelda game is listed as using SA-1. The software route is still a plausible theory, especially with a faster CPU.
Minor correction: the MSU-1 itself doesn’t actually do anything to let the SNES play back video. That’s actually something you could pull off with a normal SNES cart, if it had enough space to store the video. And MSU-1 gives you 4 gigs; plenty of space.
As far as I know, nobody’s actually written up an SNES ROM to play back video using the MSU-1 right now, though.
pikhq > Someone did:
http://www.youtube.com/watch?v=yULkopwR8oA (Real hardware Video playback via sd2snes + MSU1)
http://www.youtube.com/watch?v=EqXYPvhHMCo (Real hardware Mario Hack that uses MSU1)
I am surprised to see a post about MSU1 here.
You’ll find the SuperFX (aka. the Mario Chip) is extremely well documented in a couple of patents, notably 5724497 and 5357604.
Although both patents do reference using the SuperFX for compression, it doesn’t seem to have any hardware support for codecs specifically. It just notes that being clocked much faster than the 65816 in the SNES, the code would run faster.
I also wouldn’t call the SuperFX a DSP. It’s sort of a weird RISC design with a very early graphic pipeline.
As someone who was active in the SNES scene back in the day, I can state that the Zelda compression or the similar compression used by Nintendo on other games did not use hardware addons in the cart itself.
There is a library here
http://fusoya.eludevisibility.org/lc/index.html
that can decode a number of SNES compression algorithms including the one used in Zelda, an almost identical one used in Super Mario World and a bunch more.
Of note is that the docs for that library do mention 2 algorithms that are decompressed by the FX chip. Most likely that refers to algorithms implemented in software but using the FX chip as the CPU and not the main SNES CPU.
yoshi’s island not only uses the superfx2 for sprite scaling & polygons but according to nintendo, it,s also used to put 32megabits of data possible on 16megabit space,as shigaru myomoto dit said yoshi,s island is an 16mbit cart but thanks the superfx2 it,s possible to make it larger up to 32mbit,but it,s becomes useless when it is not decompressed, so obviousely the superx2 chip must decompress all that stuff.
that explains why they needed the superfx2 chip cuzz unlike the superfx1 chip, it has more memory acces and runs at 21mhz wich is fast enough for realtime decompression.
trough it,s still hard tobelive cuzz nintendo only advertized the fx chip as an 3d chip snd not as an decompression chip!!!