Live data from Hacker News

Inside the Super Nintendo cartridges

fabiensanglard.net

21–30 of 275 posts

Re: Inside the Super Nintendo cartridges

#21
> One of the exceptional characteristics of the Super Nintendo was the ability for game cartridges (cart) to pack more than instructions and assets into ROM chips

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

Re: Inside the Super Nintendo cartridges

#22
post #17
post #9

I'm wondering why the console CPU wasn't running at 4x the clock rate to begin with, if the cartridges could easily and cheaply include one so much better. I guess that's just how fast CPUs were improving back then. A CPU from just a few years prior was that obsolete. Crazy!

Unlike modern chips with cache hierarchies and the like, the 65816 is designed to run in lock step with the memory it’s accessing. A faster CPU would have necessitated faster RAM in the system and faster ROMs on the carts too. Games were expensive enough as it was, then.

N64 would be the first Nintendo home console to use a cache.

Then Nintendo DS was the first Nintendo handheld to use a cache.

Re: Inside the Super Nintendo cartridges

#23

I love any and all research on these systems. It completely blows my mind that something as complex and fun as Mario Kart was only 350KB in size. You can't even get a 'hello world' binary that small for most languages today. 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.

Well, we have to account for the fact that modern system simply don't require that much optimization and compression. Working with stricter limits meant that dev teams had to get creative and minimize file size, while nowadays a single game update can be around 20 GB.

Re: Inside the Super Nintendo cartridges

#24

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

Some Details on the Doom Wiki ( https://doomwiki.org/wiki/Super_NES ): 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 IW…

Also it was recently figured out that using the SNES's mosaic feature in an unconventional way could have nearly doubled the game's framerate.

Re: Inside the Super Nintendo cartridges

#25

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.

Re: Inside the Super Nintendo cartridges

#26
> 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.

Re: Inside the Super Nintendo cartridges

#27

I love any and all research on these systems. It completely blows my mind that something as complex and fun as Mario Kart was only 350KB in size. You can't even get a 'hello world' binary that small for most languages today. 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.

Well, we have to account for the fact that modern system simply don't require that much optimization and compression. Working with stricter limits meant that dev teams had to get creative and minimize file size, while nowadays a single game update can be around 20 GB.

> nowadays a single game update can be around 20 GB

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.

Re: Inside the Super Nintendo cartridges

#28
post #25

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.

Yea, after writing this I regretted using zip to estimate usage.

Probably would get better number by extracting each zip and look how much zero padding is at the end of the file. WDYT?

Re: Inside the Super Nintendo cartridges

#29
post #8

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.

Re: Inside the Super Nintendo cartridges

#30
post #25

Earlier quoted context omitted.

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.

Yea, after writing this I regretted using zip to estimate usage. Probably would get better number by extracting each zip and look how much zero padding is at the end of the file. WDYT?

I think applying RLE to the file might give a better estimate, because files have blank space throughout, not just at the end. Just tried it on Super Mario World and the estimated size was 479,154 (468K) bytes.

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.

Post reply on HN