Inside the Super Nintendo cartridges

Reverse engineering and technical tricks

• The SNES Doom port was largely a solo effort without official Super FX docs or source; the programmer relied on community specs, built custom tools on an Amiga, hacked a Star Fox cart as a dev kit, and squeezed the game into a near‑full 16 Mbit cart with only ~16 bytes free.
• A “mosaic trick” using the SNES mosaic + HDMA scrolling can hardware‑double pixels horizontally, halving video memory needs and effectively freeing bandwidth that could raise framerate.
• Other ports (e.g., Wolfenstein 3D) also involved reverse‑engineering and even reading foreign patents to obtain hardware details.

Cartridges as hardware expansions

• Many miss the era when carts acted like plug‑in expansion cards: adding co‑processors, decompression chips, RTCs, sensors, modems, or even entire GB hardware (Super Game Boy).
• Later systems (DS, 3DS, Switch) mostly reduced carts to storage, though DS carts and GBA/DS slots still hosted IR, motion sensors, TV tuners, RAM expansions, and unusual accessories (e.g., guitar controllers, medical devices).
• Unofficial flashcarts sometimes added faster CPUs, enabling on‑cart emulation but with bandwidth and heat limits.

ROM sizes, compression, and optimization

• Several comments correct the article’s quoted game sizes; many figures are compressed (ZIP/gzip) sizes, not raw ROM.
• Suggestions for estimating “effective” size include stripping padding, run‑length encoding, or counting non‑repetitive bytes via hexdump tools.
• There’s admiration for how much content fit in hundreds of kilobytes, using tight assembly, tile reuse, selective compression, and sometimes procedural generation (e.g., Pitfall’s level layout).
• Asset compression on SNES was common for title screens, cinematics, and text; streaming sprite animation data was often left uncompressed due to CPU limits.

Custom chips and economics

• Custom enhancement ICs seem surprising, but carts were expensive and consoles/games sold in the millions, so per‑unit margins could fund dedicated chips, sometimes used for only one or a few titles.
• Some suspect chips were designed assuming reuse that never fully materialized.
• A second “enhancement slot” was discussed; commenters argue it would fragment the market and confuse buyers, citing historical add‑on failures.

CPU speed, memory, and performance mods

• SNES CPU speed depends on cart type: “FastROM” lets it run at ~3.58 MHz, “SlowROM” downclocks to ~2.68 MHz due to ROM speed guarantees.
• Some games shipped as SlowROM for marginal cost savings; modders now patch them to FastROM to reduce slowdown.
• There’s debate over whether SlowROM was strictly hardware‑driven or also a pricing/licensing decision, but ROM timing specs did differ.
• SNES internal RAM itself isn’t fast enough for full‑speed access, highlighting conservative design compared to some contemporaries.

Modern size bloat and development trade‑offs

• Many contrast sub‑MB 16‑bit games with today’s tens‑of‑GB updates; some see this as wasteful bloat, others argue it reflects vastly larger asset counts and cross‑platform engines.
• Several note that ultra‑tight size optimization is now niche (e.g., demoscene), as storage is cheap and productivity matters more.

Blog posts vs videos and content theft

• Multiple commenters prefer detailed written retrospectives over video essays.
• Bloggers report widespread scraping and even hotlinking, and some speculate that difficulty of copying video pushes creators toward YouTube.

Emulation and expansion chips

• Expansion chips aren’t “dumped” like ROM; emulators reimplement their behavior in software, based on reverse engineering.
• NES and SNES had numerous mappers/enhancement chips; once cataloged, supporting them in emulators is manageable but was a long community effort.