I do really like how cartridges on the old systems were essentially equivalent to a PCI Expansion Card in a PC. It was directly connected to the Bus and could do essentially anything. Sadly, that practice ended after the GameBoy Advance, and everything since the Nintendo DS has been purely data storage.
This leads to crazy modern enhancements like a Raytracing chip[1], or the MSU1 enhancement chip that is AFAIK not available as an actual physical chip, but only in software emulators. But it would be theoretically possible to manufacture, so you could have an actual physical SNES Cartridge of Road Blaster[2].
On the article itself, I noticed that his list has "Street Fighter Zero 2" as a USA ROM - that should be incorrect, since Street Fighter Zero is what Street Fighter Alpha was called in Japan. So Zero 2 should just be the Japanese version of Alpha 2. (Also, thanks for linking to the MVG video that debunks the myth that the delay before each round is caused by decompression)
There is also this entirely crazy "NES reverse emulation"[1] Here someone replaces the cartridge with a modern computer and then... weird things start happening. Such as using a NES to present effectively a powerpoint presentation about humor.
I did that with PalmOS - a card that you insert into the original Pilot (16MHz 68k) and it takes over, runs PalmOS5 on a 200MHz ARM chip, using the pilot as a display and touch panel. Also did it using memory stick IO protocol too (Ctrl+F for "MSIO")
That's not entirely true. A few DS carts at least had IR receivers (e.g. Pokemon HeartGold). I think Learn with Pokémon: Typing Adventure adds Bluetooth through the card as well. So there was some limited capability to add features, not quite as exciting as extra CPUs but it's not like any GBA did anything super exciting there either.
Not that it was an official licensed product, but for what it's worth, there was a DS flashcart that bundled a significantly faster CPU than the DS's own - the SuperCard DSTWO [1]. The extra CPU (Ingenic Jz4740, MIPS) was primarily used for GBA emulation on DS/DSi systems without the need for a GBA slot passthrough flashcart, as was otherwise required - though there was a quite successful homebrew scene around it at the time as well, up to and including stuff like a (proof of concept) port of a PS1 emulator [2].
It was a surprisingly impressive device! The only downsides, as I recall, were the increased battery drain and the fact that the DS Slot-1 bus was only fast enough to allow streaming video output from the cartridge to the system's displays at ~45FPS, irrespective of the rate that the emulator was actually running at internally.
There are some that use the GBA slot for expansion too. The DS browser uses it for a memory expansion, and there's a Guitar Hero game that uses it for some extra buttons. When you boot the console with one inserted in Manual Mode it calls it a "DS Option Pak", and there's a lot more than i thought https://nintendo.fandom.com/wiki/DS_Option_Pak
It's like the difference between slotting ROM into DDR5 slot[1] vs SATA port. You can still add features by means of fake disk I/O, but that isn't the same as directly interfacing with the CPU bus.
1: perhaps more perfect analogy will be socketing ROM as its own chiplet if that ever made sense
Guitar Hero ("On Tour" ) for the DS added additional controler buttons to allow you to hold it like a guitar Hero guitar and use their buttons in the game. Was a really cool approach.
There was at least one Game Boy cart with fun features: Aprilia had a GBC cart[0] that had an interface cable for diagnostics on one of their scooters:
Now I am curious to know how some games could have an IR transmsmitter inside the cartridge like Pokemon Soulsilver, did they plan this specific usecase or a whole channel for limited cartridge expansion components ?
That's actually a pretty good question. The NTR-031 IR cartridges were used for a few games, and there was also one for Motion Sensors and a TV Antenna.
From what I can see, it looks like even though they can't extend the functionality directly, they do still interface with the system in some way. Perhaps they are more like a device connected to a serial port would be? So far less capable than the full extension cart, but still possible to communicate with through a standardized protocol? (The DS Cartridge slot has 8 data pins rather than the full address/data bus, but seems to have a protocol: http://problemkaputt.de/gbatek.htm#dscartridgeprotocol)
(Though if someone with more knowledge can correct me, please do so. I thought that DS/3DS/Switch are pure flash chips, but was wrong at least about the DS)
The interface to the gaming system might be strictly data, but you've got power supplied to the cartridge; you can put whatever hardware you can fit inside that cartridge still
Widely believed to be because Mike Bison was a little too on-the-nose for a heavyweight boxer and the shuffle was the easiest way to make a last minute change.
Someone already mentioned Mike Bison, but FWIW, in the fighting game community - which includes people from Japan and outside of Japan - those characters are generally called "Boxer", "Claw", and "Dictator" specifically because of the localization changes, to give them unambiguous names.
At least Sagat kept his name, though "Tiger bullshit" would've been a great moniker, and no, I'm not salty about losing to his projectile once too many.
Another detail not mentioned here is that even carts which didn't contain enhancement chips had different levels of performance - the SNES CPU nominally ran at 3.58mhz, but it would only actually run at that speed with a "FastROM" cart inserted. Nintendo also offered publishers a "SlowROM" cart format, which was cheaper, but would downclock the CPU to just 2.68mhz.
There is a community of modders developing patches to turn SlowROM games into FastROM games to alleviate slowdown. I read somewhere that some SlowROM games appear to have been developed for FastROM in the first place, but were converted to SlowROM at the last minute due to penny-pinching demands by the publisher.
Out Of This World is a case of SlowROM/FastROM where the dev was not allowed to use FastROM. Iirc they claimed it saved a whopping 50 cents a cartridge to use slowrom in that case.
The thing that blows my mind about the SNES is that even its onboard RAM can't be accessed at the nominal 3.58MHz clock; the system slows down for that.
Always confused me why the SNES was so paltry with its speed when the competitor TurboGrafx-16 usually ran at 7MHz, and also had a 6502-family CPU that required similar memory timing. But the TurboGrafx flopped (in the west) and the SNES was a hit world-wide, so I guess they did something right.
> But the TurboGrafx flopped (in the west) and the SNES was a hit world-wide, so I guess they did something right.
Still have all my old consoles including the Turbo Graphics 16 and SNES. It was all about the software. Mind you this was during a time when games were $50 each which today is something like $100. If you wanted to sample a game you hoped a friend had it so you could borrow or the local video store had it to rent. If not it was a crap shoot and game review magazines were a staple.
TG16 had nothing to compete. I only remember the popular side-scrollers like Bonks Adventure or Splatter House. The rest were "weird" games no one was interested in. We had about 7 or 8 games before we gave up on it. I had I think one other friend who had one who also gave up on it with just a few titles.
SNES had 3 background layers and color math/transparency, TurboGrafx 16 was stuck with one background layer. SNES also had much better sound capabilities.
I'd say TurboGrafx's biggest advantage was that they had a full handheld version of the system available very early on. The Turbo Express crushed the Game Gear and Lynx in terms of power. (The Game Boy still beat all its more-powerful competitors because of its far lower battery consumption)
Technical specifications rarely have to do with whether or not a console succeeds, as long as they don't affect MSRP too much. Price and game library are typically the most important aspects. Or ease of piracy in some territories.
Always wondered if that was just an arbitrary licensing distinction made up by nintendo or there were actual differences between carts data reading speeds. At the end of the day, all SNES carts sported mask roms.
At various points it was very hard to get ROM made due to shortages. It may have been an attempted solution to that, can’t get fast but you could have slow.
The ROM chips were literally lower specced / worse tolerances, and thus cheaper. FastROM chips were guaranteed (by the manufacturers) to yield stable results in under 120ns, versus 200 for SlowROM.
Ostensibly the reason is that the ROM chips have to run in lockstep with the CPU clock, so the CPU may need to be downclocked if cheaper ROM chips can't keep up with it, but I don't know what the actual cost difference would have been at the time, if any. Maybe all of the chips were capable of 3.58mhz and Nintendo was just gouging.
No that's something else, LoROM and HiROM differ in how the ROM data is mapped into memory, while FastROM and SlowROM differ in the bus speed. You can have Lo/Slow, Lo/Fast, Hi/Slow or Hi/Fast carts.
I hope developers still love to blog details with article mode like this, rather than vlogging it on YouTube. A lot of detail packed into a few kilobytes only.
"Super Mario World" is still the masterpiece game ever. It has amazing characters, sprites, and stages packed into only 360 KB.
The file sizes given by the site are wrong. Super Mario World is 512KB, or 508KB if you discard the padding at the end. Only compressing it to ZIP format gives you a file size around 360KB.
It's still quite impressive to fit such a lengthy and fun game into 508KB without any procedural generation, just tight assembly and clever use of bitmaps. This is programming art.
Super Mario World is great, but I stand by Donkey Kong Country 2 being the best game on the system. To me, it just nails every single aspect of platforming, with awesome music, tight controls, and appealing graphics.
Terranigma is right up there as well for me; Super Mario World is probably number 3 in my book.
> hope developers still love to blog details with article mode like this, rather than vlogging it on YouTube.
I think the driving force behind this for many is it's much harder to steal video content. With text bits can scrape it change a few words and reuse it on an SEO ad site.
I've definitely noticed as a blogger many sites are so brazen stealing content that they'll even hotlink to my images, so I can find their copying in my server logs. Very annoying.
Isn't it more of "Pitfall!" has a set of 255 levels that are procedurally generated and the author spent a ton of time searching for the best seed that would generate the levels we know today.
It isn't as if you could have a map editor and adjust the levels or the order of the levels, though you could run the generation procedure to find new levels to your liking.
Take a look at Solaris. Another huge game with 48 sectors and probably the best graphics seen on the 2600, all in a 16k cartridge.
Quite a feat considering how horrifyingly difficult programming the 2600 was. Even the SDK was fairly barebones, basically a VT100 connected to a PDP-11 running RT8 and a 6502 assembler
I wonder what you could do with modern tech, exploiting that ability of having "enhancement chips" in the cartridge.
The SuperFX is mentioned to have it's own framebuffer and copy the whole thing over to VRAM.
Does that mean, it would technically be possible to put some ridiculously overpowered SoC into an cartridge, and use that to render modern graphics (at SNES resolutions), copying the resulting frames back into the SNES VRAM?
but apparently the NES is a lot more limited, in that it wasn't really designed to accept enhancement chips. still absolutely amazing that he can run emulated SNES games on real NES hardware!
but the SNES actually had that ability to accept enhancement chips - as seen in the SuperFX and others... I feel that should allow for doing drastically more!
> The author of DOOM for SNES, Randy Linden, did not have access to any documentation about the GSU chip or even DOOM source code. He reverse engineered all of it
Technically this is impressive, but why was it necessary?
Randy Linden, the port's sole programmer, initiated the port of Doom for the Super NES on his own initially, as he was fascinated by the game.
Since Doom's source code was not yet released at the time, Linden referred to the Unofficial Doom Specs as a means of understanding the game's lump layout in detail. The resources were extracted from the IWAD, with some (notably sprites such as the player's sprites and the original status bar face sprites) unused due to technical limitations.
According to an interview, due to lack of development systems for the Super FX, Linden wrote a set of tools consisting of an assembler, linker, debugger, dubbed the ACCESS, on his own Amiga before beginning development of the port proper. For the hardware kit, he utilized a hacked Star Fox cartridge and a pair of modified Super NES controllers plugged into the console and connected to the Amiga's parallel port. A serial protocol was used to further link the two devices.
After developing a full prototype, he later showcased it to his employer, Sculptured Software, which helped him finish the development. In the interview, Linden expressed a wish that he could have added the missing levels; however, the game, already the largest possible size for a Super FX 2 game at 16 megabits (approximately 2 megabytes), only has roughly 16 bytes of free space. Linden also added support for the Super Scope light gun device, the Super NES mouse, and the XBAND modem for multiplayer. Fellow programmer John Coffey, himself a fan of the Doom series, made modifications to the levels, but some of those modifications were rejected by id Software.
I was lucky enough to work with Randy for quite a few years at Microsoft.
Incredible developer. He also made the Bleem! PlayStation emulator.
Funny enough none of his coworkers ever bothered to look him up online until after we all stopped working together at which point we all learned we'd been working with programming royalty.
A similar thing happened with the Wolfenstein 3D port as well, where John Carmack gave Rebecca Heineman kudos for learning Japanese to read the patents to get the technical documentation, always cool history around these things, some more in my post about it here:
https://eludevisibility.org/super-noahs-ark-3d-source-code
I can't speak to this case, but dev kits and SDK/documentation are often two separate SKUs and the latter has a higher price. If I remember the Crash Bandicoot guys found a hardware bug with memory card saving because they rolled their own code rather than using the SDK they didn't have.
Where do the byte counts for the various games come from? The games came on ROM chips that were, as ROM chip are wont to, sized to powers-of-two. For instance, Super Mario World was shipped on a 512kb ROM - where does 346,330 bytes come from? Are these compressed sizes?
The numbers are estimates based on zipped size. But it is a bad idea. I should write a program to extract each zip, and count zero bytes padding at the end of the file.
Too late for today, I will write that tomorrow and update the article.
It looks like they're compressed sizes. If I gzip SMW.SMC, I get a 347 KB file. It's very misleading.
There are other issues in there. The writer makes it sound like MVG was the one who discovered that the pause in SFA2 was from loading audio data, when it was already known LONG before his video. https://forums.nesdev.org/viewtopic.php?p=70474#p70474
He also seems very confused about the RTC. It's obviously so that the clock keeps going even when the console is off and the cartridge is unplugged, like in the GBC/GBA Pokemon games, but he says something about how it might be because of the NTSC clock drifting? ??? What?
> Even Super Mario World[10] got the treatment (I can't remember slowdowns but I was only twelve can then).
Yoshi’s Island 4 has a slowdown in some circumstances (have Yoshi, get Starman and hit P-Switch), as does another level I can’t recall, exactly… it has a bunch of Monty Moles that explode all at once. I think it’s on Chocolate Island. I think there might be a third with two Sumo Bros. and an Amazing Flying Hammer Bro. onscreen.
Something I've never been able to wrap my head around is how ROMs are dumped for emulators from cartridges? Dumping instructions and assets makes total sense to me, and packaging that up in a data file that can be interpreted by an emulator too, but how does an emulator model the hardware of every 'expansion' chip in a cartridge? How is that dumped from an original cartridge?
Expansion chips aren't ROMs; they need to be emulated as well.
The situation was IMHO a bit worse with the SNESs precedessor, the NES.
There were quite a few expansion chips--called mappers--even though their general function was expanding the NES's memory space instead of adding additional processors or capabiliies - and they were in most games because without them the NES is limited to 32KB of PRG ROM and I think 4KB or 8KB of CHR (graphic) ROM. Most games after the year the NES came out had them.
These all had to be reverse engineered along with the console itself - fortunately much simpler than reverse engineering an add-on CPU or accelerator though. Some are common and in many games (MMC1, MMC3) and others are pretty much for a specific game only (MMC2 is for Punch-Out only).
They're not dumped. The emulator implementation recreates the expansion chip functionality in software. There are only so many expansion chips, so its not intractable.
Readit News
This leads to crazy modern enhancements like a Raytracing chip[1], or the MSU1 enhancement chip that is AFAIK not available as an actual physical chip, but only in software emulators. But it would be theoretically possible to manufacture, so you could have an actual physical SNES Cartridge of Road Blaster[2].
On the article itself, I noticed that his list has "Street Fighter Zero 2" as a USA ROM - that should be incorrect, since Street Fighter Zero is what Street Fighter Alpha was called in Japan. So Zero 2 should just be the Japanese version of Alpha 2. (Also, thanks for linking to the MVG video that debunks the myth that the delay before each round is caused by decompression)
[1] https://www.youtube.com/watch?v=2jee4tlakqo
[2] https://www.youtube.com/watch?v=BvIXUOr4yxU
1: https://www.youtube.com/watch?v=ar9WRwCiSr0
https://dmitry.gr/?r=05.Projects&proj=27.%20rePalm
Not that it was an official licensed product, but for what it's worth, there was a DS flashcart that bundled a significantly faster CPU than the DS's own - the SuperCard DSTWO [1]. The extra CPU (Ingenic Jz4740, MIPS) was primarily used for GBA emulation on DS/DSi systems without the need for a GBA slot passthrough flashcart, as was otherwise required - though there was a quite successful homebrew scene around it at the time as well, up to and including stuff like a (proof of concept) port of a PS1 emulator [2].
It was a surprisingly impressive device! The only downsides, as I recall, were the increased battery drain and the fact that the DS Slot-1 bus was only fast enough to allow streaming video output from the cartridge to the system's displays at ~45FPS, irrespective of the rate that the emulator was actually running at internally.
[1] https://wiki.gbatemp.net/wiki/SuperCard_DSTWO [2] https://gbatemp.net/threads/how-to-play-ps1-games-on-your-ds...
1: perhaps more perfect analogy will be socketing ROM as its own chiplet if that ever made sense
https://en.m.wikipedia.org/wiki/Guitar_Hero:_On_Tour#Gamepla...
Edit: a better picture of it in action, https://en.m.wikipedia.org/wiki/File:Guitar-hero-on-tour-ds-...
[0]: https://youtu.be/bknfVpctoSY?si=_neVHq_fkJRfDH5I
From what I can see, it looks like even though they can't extend the functionality directly, they do still interface with the system in some way. Perhaps they are more like a device connected to a serial port would be? So far less capable than the full extension cart, but still possible to communicate with through a standardized protocol? (The DS Cartridge slot has 8 data pins rather than the full address/data bus, but seems to have a protocol: http://problemkaputt.de/gbatek.htm#dscartridgeprotocol)
So, I need to correct myself, they nerfed it first with the DS, before then switching to being pure flash chips with the 3DS when they switched to XtraROM (which has potential lifespan issues: https://gbatemp.net/threads/nintendo-switch-3ds-cartridge-li...) - and that seems to not allow much custom functionality: https://www.3dbrew.org/wiki/Gamecards#Protocol
(Though if someone with more knowledge can correct me, please do so. I thought that DS/3DS/Switch are pure flash chips, but was wrong at least about the DS)
At least Sagat kept his name, though "Tiger bullshit" would've been a great moniker, and no, I'm not salty about losing to his projectile once too many.
Between this and the SA-1 fixes for Gradius III and Super R-Type, we live in a golden age of improving SNES games :)
There is a community of modders developing patches to turn SlowROM games into FastROM games to alleviate slowdown. I read somewhere that some SlowROM games appear to have been developed for FastROM in the first place, but were converted to SlowROM at the last minute due to penny-pinching demands by the publisher.
Always confused me why the SNES was so paltry with its speed when the competitor TurboGrafx-16 usually ran at 7MHz, and also had a 6502-family CPU that required similar memory timing. But the TurboGrafx flopped (in the west) and the SNES was a hit world-wide, so I guess they did something right.
Still have all my old consoles including the Turbo Graphics 16 and SNES. It was all about the software. Mind you this was during a time when games were $50 each which today is something like $100. If you wanted to sample a game you hoped a friend had it so you could borrow or the local video store had it to rent. If not it was a crap shoot and game review magazines were a staple.
TG16 had nothing to compete. I only remember the popular side-scrollers like Bonks Adventure or Splatter House. The rest were "weird" games no one was interested in. We had about 7 or 8 games before we gave up on it. I had I think one other friend who had one who also gave up on it with just a few titles.
I'd say TurboGrafx's biggest advantage was that they had a full handheld version of the system available very early on. The Turbo Express crushed the Game Gear and Lynx in terms of power. (The Game Boy still beat all its more-powerful competitors because of its far lower battery consumption)
> Different address ranges are accessed at different speeds, and the speed of the ROM at banks $80-$FF may be changed with register $420D.
https://snes.nesdev.org/wiki/Memory_map
"Super Mario World" is still the masterpiece game ever. It has amazing characters, sprites, and stages packed into only 360 KB.
Probably would get better number by extracting each zip and look how much zero padding is at the end of the file. WDYT?
https://games.greggman.com/game/programming_m_c__kids/
Terranigma is right up there as well for me; Super Mario World is probably number 3 in my book.
I think the driving force behind this for many is it's much harder to steal video content. With text bits can scrape it change a few words and reuse it on an SEO ad site.
It isn't as if you could have a map editor and adjust the levels or the order of the levels, though you could run the generation procedure to find new levels to your liking.
Still an amazing game. In 4k it is astonishing.
Quite a feat considering how horrifyingly difficult programming the 2600 was. Even the SDK was fairly barebones, basically a VT100 connected to a PDP-11 running RT8 and a 6502 assembler
The SuperFX is mentioned to have it's own framebuffer and copy the whole thing over to VRAM.
Does that mean, it would technically be possible to put some ridiculously overpowered SoC into an cartridge, and use that to render modern graphics (at SNES resolutions), copying the resulting frames back into the SNES VRAM?
What are the limitations there?
but apparently the NES is a lot more limited, in that it wasn't really designed to accept enhancement chips. still absolutely amazing that he can run emulated SNES games on real NES hardware!
but the SNES actually had that ability to accept enhancement chips - as seen in the SuperFX and others... I feel that should allow for doing drastically more!
Technically this is impressive, but why was it necessary?
Randy Linden, the port's sole programmer, initiated the port of Doom for the Super NES on his own initially, as he was fascinated by the game.
Since Doom's source code was not yet released at the time, Linden referred to the Unofficial Doom Specs as a means of understanding the game's lump layout in detail. The resources were extracted from the IWAD, with some (notably sprites such as the player's sprites and the original status bar face sprites) unused due to technical limitations.
According to an interview, due to lack of development systems for the Super FX, Linden wrote a set of tools consisting of an assembler, linker, debugger, dubbed the ACCESS, on his own Amiga before beginning development of the port proper. For the hardware kit, he utilized a hacked Star Fox cartridge and a pair of modified Super NES controllers plugged into the console and connected to the Amiga's parallel port. A serial protocol was used to further link the two devices.
After developing a full prototype, he later showcased it to his employer, Sculptured Software, which helped him finish the development. In the interview, Linden expressed a wish that he could have added the missing levels; however, the game, already the largest possible size for a Super FX 2 game at 16 megabits (approximately 2 megabytes), only has roughly 16 bytes of free space. Linden also added support for the Super Scope light gun device, the Super NES mouse, and the XBAND modem for multiplayer. Fellow programmer John Coffey, himself a fan of the Doom series, made modifications to the levels, but some of those modifications were rejected by id Software.
Incredible developer. He also made the Bleem! PlayStation emulator.
Funny enough none of his coworkers ever bothered to look him up online until after we all stopped working together at which point we all learned we'd been working with programming royalty.
Too late for today, I will write that tomorrow and update the article.
There are other issues in there. The writer makes it sound like MVG was the one who discovered that the pause in SFA2 was from loading audio data, when it was already known LONG before his video. https://forums.nesdev.org/viewtopic.php?p=70474#p70474
He also seems very confused about the RTC. It's obviously so that the clock keeps going even when the console is off and the cartridge is unplugged, like in the GBC/GBA Pokemon games, but he says something about how it might be because of the NTSC clock drifting? ??? What?
Yoshi’s Island 4 has a slowdown in some circumstances (have Yoshi, get Starman and hit P-Switch), as does another level I can’t recall, exactly… it has a bunch of Monty Moles that explode all at once. I think it’s on Chocolate Island. I think there might be a third with two Sumo Bros. and an Amazing Flying Hammer Bro. onscreen.
The situation was IMHO a bit worse with the SNESs precedessor, the NES.
There were quite a few expansion chips--called mappers--even though their general function was expanding the NES's memory space instead of adding additional processors or capabiliies - and they were in most games because without them the NES is limited to 32KB of PRG ROM and I think 4KB or 8KB of CHR (graphic) ROM. Most games after the year the NES came out had them.
These all had to be reverse engineered along with the console itself - fortunately much simpler than reverse engineering an add-on CPU or accelerator though. Some are common and in many games (MMC1, MMC3) and others are pretty much for a specific game only (MMC2 is for Punch-Out only).