Live data from Hacker News

Inside the Super Nintendo cartridges

fabiensanglard.net

261–270 of 275 posts

Re: Inside the Super Nintendo cartridges

#261

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 a…

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.

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:

[0]: https://youtu.be/bknfVpctoSY?si=_neVHq_fkJRfDH5I

Re: Inside the Super Nintendo cartridges

#262
post #38

Earlier quoted context omitted.

You are just getting old. People used to have the same reaction to games that filled up an entire CD (or even multiple).

> You are just getting old. 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?

> But some kind of 1:1 correspondence was lost ages ago.

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

Re: Inside the Super Nintendo cartridges

#263

Earlier quoted context omitted.

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

As a millennial who has done both embedded and web it doesn't make me sigh at all and usually I find people with that line of thought are just being elitist. 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/hardwa…

Mostly agreed:

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

Re: Inside the Super Nintendo cartridges

#264

It’s impressive that developers could afford to make custom ICs for only one or two games. I wouldn’t have thought the revenue would be enough to justify that.

My assumption was always that they went into the design of it assuming they would use the chips for more games. Then either the game didn't sell well or the SNES was at the end of its life or something happened to prevent them from using it again.

Re: Inside the Super Nintendo cartridges

#265

Earlier quoted context omitted.

It would result in a situation where nobody could depend on the expansion module, if they wanted their game to have the largest possible market. 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…

> It would result in a situation where nobody could depend on the expansion module, if they wanted their game to have the largest possible market. 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…

The difference here being that those enhancement carts would likely cost less then 20$ to manufacture and would either cost a little more then that when sold individually or cost a little bit above the price of a full game when sold bundled with a game.

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.

Re: Inside the Super Nintendo cartridges

#266

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 a…

Street fighter localization is wacky. Why would they swap the same names for different characters?

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.

Re: Inside the Super Nintendo cartridges

#267
post #254
post #197

Earlier quoted context omitted.

From what I've seen, on average, with many exceptions, most games will lightly compress most data. Tile graphics and layouts only need to be decompressed whenever a scene/level/map is loaded. Games aren't doing streaming audio or anything, so song data can be decompressed and uploaded to the sound processor before a level starts too. Likewise, text needs to be decompressed once immediately before it's displayed, so g…

I was actually just thinking last night about how something like Fortnite handled emotes. Skins and cosmetics I can understand, but they have 100 players and hundreds of emotes that any player can use at any time. Is it all really just streamed in on demand? Most common preloaded? Made me ponder a bit.

Maybe a little counter-intuitive, but Fortnite emotes (essentially, animations) takes up much less memory than skins.

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.

Re: Inside the Super Nintendo cartridges

#268

Since these carts pull out the CPU bus I would like to know if anyone ever did anything unusual with a classic gaming console. Like controlling motors for a robot or wiring in an FPGA to add functionality like Ethernet/USB, running a terminal emulator, trying to write an OS, etc.

Here's someone using the (officially unused) NES expansion port to send a Tweet from the console: https://www.trapzz.com/?page_id=292

Thanks! this is the weird stuff I like to see.

Re: Inside the Super Nintendo cartridges

#269

Earlier quoted context omitted.

Street fighter localization is wacky. Why would they swap the same names for different characters?

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.

Mike Bison

You know 12 year old me never caught that.

Re: Inside the Super Nintendo cartridges

#270
post #113

Earlier quoted context omitted.

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…

I'd say the Game Boy also won in terms of library of games, and the popular properties owned by Nintendo, such as Super Mario Bros., Metroid, The Legend of Zelda, among many others.

Yes but that was due to it's popularity, not the cause of it, there is quite a bit of network effect, but that only comes into play once you have the network.

The gameboy won because it was half the cost of any of it's competitors. while being more than half as good.

Post reply on HN