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

Amusingly the device that replaced my classic Palm was an Axim X3, which if I hadn't sold it to buy a server in 2005 would probably have already had your rePalm build installed on it.

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

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)

As ram, you could read the data on the cartridge, modify it, and thus fake bidirectional comms?

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.

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.

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)

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 still want to play all of the Splatter House titles, though. I didn't find out about those until I was older, but I've watched plenty of walkthroughs of the various iterations, and it looks like the perfect amount of strategy, gore, and need for proper timing to master.

"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?

If you don't have an RLE tool handy, you can force Pucrunch to act as an RLE-only compressor by using the -r 0 switch which disables the LZ compression feature.

But... I'd love to know how often assets were compressed on "normal" carts without special chips.

Decompressing assets on the fly during gameplay action seems like it would be quite a challenge for the SNES' CPU.

My understanding is that images on title screens and cinematics were often compressed. Anime/comic art styles lend themselves really well to RLE compression because you have lots of consecutive pixels of the same color. And, obviously, these can be fairly static images that don't need to be updated 60 times a second.

Definitely an outlier, but: the title screen of Secret of Mana was actually a JPG that took around a minute (!!) to decompress. The music and scrolling text are cleverly designed to mask this: https://manaredux.com/lore/how-was-the-incredible-title-scre...

Likewise, text needs to be decompressed once immediately before it's displayed, so games will usually compress that - it's quick enough to decompress a few hundred bytes while the text box loads.

The only thing that I've seen that's usually stored uncompressed is sprite animation data - particularly for player characters with lots of different animations. There's not enough VRAM to load all of it at once, so it needs to be streamed in, and in that case the CPU often just doesn't have the muscle.

Made me ponder a bit.

Generally for a modern polygonal game, you are using skeletal animation for the characters. A character consists of a polygon mesh and anywhere from dozens to hundreds of bones.

Animations consist of keyframes. Each keyframe represents just a handful of bytes for each bone (the XYZ coordinates for each end of the bone, and the rotational angle, or something like that). The animators create as many keyframes as they want, maybe 10-20 per second max. So a 5-second emote animation might contain something like 8 32-bit floats * 100 bones * 10 frames per second * 5 seconds = ~120 kilobytes of uncompressed data.

That's all you need to specify an animation. The rest is calculated on the fly at runtime and rendered to the screen at 60fps or whatever the current frame rate is. The graphics engine interpolates bone positions between your keyframes, and the player model mesh is deformed by the bones. Also, those skeletal animations can be shared between all player models.

The alternative to skeletal animation is fully prebaked animations. This involves minimal interpolation and calculation at runtime. It is more memory intensive because you are calculating the position of every point on the mesh ahead of time, and then storing that data on disk. This is generally how a very complex and non-interactive animation (think: cutscenes, etc) would be animated and stored on disk. Note, this is still far less storage-intensive than storing rendered video, and you still maintain a great deal of flexibility at runtime - you can change the camera location, rendering passes, resolution, etc. That's why you don't see a lot of prerendered video cutscenes these days.

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.

[1]: https://youtu.be/tfAnxaWiSeE?list=PL2e4mYbwSTbbiX2uwspn0xiYb...

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

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.

I know that Wolf3D on the SNES uses Mode 7. Not for the walls or sprites, but for the entire screen. The graphics are rendered into a background tiles with a resolution of like 175x100 or something, then scaled up with Mode7 to fill the 224x192 screen. (those aren't the exact numbers, but you get the idea)

Normally the SNES mosaic feature just the top-left pixel of a 2x2 square into that entire square. But the trick makes a different set of pixels get doubled horizontally on the next scanline.

It requires a different arrangement of pixels than the normal way of drawing tiles. A tile containing these pixels:

01234567

becomes this when viewed on two scanlines:

00224466

11335577

Actually performing these scroll writes does not require any CPU intervention because you use the SNES's HDMA feature to do those scroll writes.

User "93143" on Nesdev describes the Mosaic trick in this post: https://forums.nesdev.org/viewtopic.php?p=205633#p205633, other discussion here: https://forums.nesdev.org/viewtopic.php?t=20393&start=135

---

So now that you've done this, you need half as much video memory as before, which effectively doubles your bandwidth for rendering and transfers.

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!

The NES was a little unusual in that it basically had no video ram. The PPU (the graphics chip) rendered sprites and background tiles straight off of the cartridge at 60fps as if the cartridge was an extension of the CPU's address space.

So there are almost no limits to what you could do with expansion hardware, other than the fact that everything would have to ultimately be rendered thru the NES' limited color palette. You could make a cart that provides an interface to let a monster PC with multiple 4090s treating the cartridges' tile data as a "dumb" framebuffer and run Cyberpunk 2077 through an NES... although, again, in 4-bit color hahaha.

In contrast, for the Genesis and SNES, you need to copy graphics data from cartidge to VRAM. Then it gets rendered. This was presumably done because ROM of the area was not fast enough to feed the graphics chips of the 16-bit systems, thus the need for local VRAM as sort of a cache.

So on a SNES you'd have to do some more work, you'd have to DMA a whole screen's worth of data from the custom cart into VRAM 60 times per second, which I think exceeds the data rates the SNES can achieve.

My understanding may be wrong, somebody correct me

The trick is that the Game Boy display is smaller than the SNES display, so it doesn't have to transfer a complete frame, and so it can be completed within the vertical blanking interval.

Apparently the timing is so close that it's not possible to transfer palette information alongside the video, just black-and-white, which is why there was never a Super Game Boy Color.

Unusual for home consoles, but it was pretty standard for arcade boards. This is why systems like the NeoGeo and the CPS-1/2/3 could handle massive amounts of sprites and animation that home systems couldn't replicate until the Dreamcast.

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

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.

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?

It was easily defeated for consumers though (but probably not for game producers/editors)...

Back then we all had a "backup device" for our SNES: a device you'd plug into the SNES and which had a floppy drive. So we'd "backup" all our games on very cheap 3"1/2 floppies. All that was needed for the system to work was to have one original cartdridge, which you'd plug into the copier, and the device would reuse that cartdridge's CIC chip.

https://en.wikipedia.org/wiki/Game_backup_device

OK, I will use that excuse if someone asks me why I am so bad at it.

I imagine this would add to much cost or complexity to the console, making it simpler to just bundle the chips in a single cart anyway.

It would also cause a lot of confusion, where clueless older relatives would buy games for kids, not realize that an accessory was required (or have no idea if the kid actually had that accessory), and then the game wouldn't run.

We see this sort of problem happen a lot with computers of the 8-bit era as well, where add-on modules would fix a lot of the issues with the base system... then be supported by almost no software for these exact reasons.

The SegaCD-32x problem. The Genesis sold tens of millions of units, the SegaCD only ones of millions of units, and the 32x under a million units.

There were a couple 32x games that required the 32x and a SegaCD. Being that the SegaCD and 32x didn't have 100% overlap, those games had a smaller TAM than even solely 32x games.

I feel bad for the studios that decided (or were told) to make those games. There was just no way they were going to make a game that would sell well on an uncommon configuration of a dead-end console/accessory.

I can see how this would create some confusion when buying games (which may be a deal-breaker for nintendo), but I also see more potential in this approach since these carts would be "seeded" by Nintendo's own high volume and highly sought after games, thus getting much more traction than the big console accessories of the competition, which cost around (not 100% sure) 150$. Also, as another poster noted, the n64 had the expansion pak (not too far from the idea of an enhancement cart) introduced a few years into it's life which would end up being bundled with a few games and get fairly wide support on many newer releases, tough most of the games opted for optional support to unlock extra features.

The SA-1 chip was especially impressive, featuring a 65C816 CPU running at 10.74 MHz (4x faster than the main SNES CPU), 2KB of SRAM, and an integrated CIC. 34 games used it, including Super Mario RPG. I'd be curious to know more about how developers took advantage of that extra horsepower. Were there certain game genres or features it enabled?

It's wild that the Super 3D Noah's Ark unlicensed game didn't have its own CIC chip and required plugging an official cartridge on top to pass the copy protection check. Goes to show the lengths publishers had to go to bypass Nintendo's strict licensing. I wonder how many other unlicensed carts used similar CIC workarounds.

The list of SNES games by ROM size is a great resource. Would be fascinating to analyze that data and look for correlations between ROM size and other factors like review scores, sales, use of enhancement chips, etc. Could provide some interesting insights into SNES game development.

Super 3D Noah's Ark is the only game that seems to have survived to modern times, but I remember there were quite a few more. Nintendo wasn't happy about the religious-themed games but knew it would be extremely bad press to go after the developers, so they strong-armed the major retailers instead. I used to see the games developed by Wisdom Tree in Christmas stores, book stores, and small regional retailers.

In non-western countries, there were pirated games that used the same "piggyback" technique to avoid the CIC, but this was less common since PCBs were pretty expensive to manufacture in smallish quantities at the time. Console game piracy didn't _really_ take off until CDs became the dominant format. Arcade game piracy actually had a pretty robust underground market, though.

It's that some consoles like the (S)NES were extremely popular, sold in the millions. And some games sold in similar numbers. Or were expected to. Or custom IC was (expected to be) used in a # of games. Or some of these publishers were just awash with cash + crazy high expectations for their products. Or some combination of the above.

Iirc for custom ICs, you're usually talking about production runs in the many-thousands. Say, 10k+.

But in the above example: if $60 provides a $10/sale budget, 10k sales gives you a $100k budget to work with. 100k sales -> a cool 1M budget.

Numbers add up quickly if it's mass-produced and 'everyone' buys one.

For reference a typical Nintendo Switch game will sell for AUD $79 on release.

Wasn't this true even on other Nintendo consoles? Gameboy and Gameboy Color cartridges did similar if not even more outlandish things, like the GameBoy Camera

Even the Nintendo DS could do it, though I'm not sure it was used outside of flashcarts like the SuperCard that included an additional CPU.

And the N64 technically supported cart enhancements though only a small handful of japanese games used it (Morita Shogi 64 had a modem and rj11 adapter in the cart… and RCEs so you can use it as a homebrew vector).

Once cart were replaced with optical drives there was no way to have anything but data shipped with the game, so enhancements was limited to whatever the console designer had specced expansion slots or even just controller ports for.

Then again, as hardware became more complex an expensive, the ROI on bespoke chips got lower and lower. SETA released 3 single-game chips, there’s no way that’s justifiable nowadays.

Yeah, it's custom and tuned, but that's a lot of fun packed with at the time 'good graphics' in the size of a single low quality jpeg of today.

Irrespective of the abundance of storage we now enjoy, and even though I could rationally understand the reasons, this will always make me raise an eyebrow or sigh.

The amount of technology and number and size of assets in a game now is just insane, it is in no way at all comparable to the garage projects for 8bit consoles.

Remember, games used to have to be ported - they were so locked into their particular platform/hardware that porting a game was essentially a total rewrite every single time. Nowadays we can write once, run on every single platform with just hooks into platform specific libs swapped out.

Modern day developers aren't stupid; we're just all used to our current environments, but I would bet that if we all needed to, we could just as easily jump back in to writing everything in asm and custom tailoring it for a particular CPU/hardware. But then modern games would be impossible to actually get finished.

> Modern day developers aren't stupid; we're just all used to our current environments, but I would bet that if we all needed to, we could just as easily jump back in to writing everything in asm and custom tailoring it for a particular CPU/hardware.

Some people could jump back in, but not all.

But that's actually progress! You needed to be a wizard to get anything done on eg an Atari 2600 at all. Nowadays, game development is accessible to more and more people.

For many of us it's an engineer's mindset. We appreciate games for their art and gameplay, and we also appreciate them for their engineering.

So it's a little sad to see that one aspect of game engineering become relatively extinct, even if it's the certainly the correct tradeoff given today's constraints.

I am! But even then, imho sizes should correlate to the detail (graphics / sound), complexity & vastness of virtual worlds embodied in a game.

Not the ease with which developers can fill up the available space.

Yes these are related. But some kind of 1:1 correspondence was lost ages ago.

Optimizing for size, to squeeze out every last byte possible: who still does this in 2024?

The ratio has been shifting all this time. There wasn't a one time shift that happened once.

> Optimizing for size, to squeeze out every last byte possible: who still does this in 2024?

You can still find that in the demoscene. A few years ago https://en.wikipedia.org/wiki/.kkrieger made a big splash. (Well, it's actually been 20 years. How time flies. But they still make small demos and games today.)

I understand that 3D textures are large files, but surely there is some hideous bloat occurring to cause the explosion in size.

And outside of games, the same bloat occurs, so it’s not just textures. “Let’s ship an entire browser rendering engine with our app” hasn’t exactly helped.