On a related note -- when I see the minuscule filesize of the original Zelda game on emulators, I marvel at how little text/code/information could produce how much wonder, how far-reaching impact, and how many hours of enchantment for me.
https://en.wikipedia.org/wiki/The_Legend_of_Zelda_(video_gam...
Indeed, magic. How about the Commodore 64, there was a game (Eindeloos, Radarsoft, 1985) within 64kb that has a huge map. Someone recently (after 40 years!) extracted the map (500 screens) and the png alone is 800kb. See the story an zoom in and try finding the little heart in the map! https://adayinthelifeof.nl/2025/03/07/endless.html
Elite on the BBC Micro - which had 32kB of RAM, a huge chunk of which was required for the screen - managed to have eight galaxies with 256 distinct planets each.
Everything about them was procedurally generated, even the names, which required some clever code to ensure none of them used rude words.
> which had 32kB of RAM, a huge chunk of which was required for the screen
People assume 10KB, with the BBC Micro¹² version's version using a mix of modes 4 & 5 (320×256×1bbp and 160×256×2bbp respectively), but as well as the split screen trickery they tweaked the graphics hardware in more detail than that to create custom modes. There were only 248 scanlines and either 256 or 128 pixels per line, so the display took 7.75KB. As well as leaving more memory for the rest of the code, this reduced the amount being drawn, so helped keep the draw speed acceptable.
This left about 24KB⁴ for the rest of the code and its working data. Still a very impressive feat!
> - managed to have eight galaxies with 256 distinct planets each.
IIRC it was originally going to be larger than that, they toned it down a bit but not due to technical limitations (the galaxy generator code would not have needed to be any larger).
--------
[1] The Electron lacked support that allowed the split screen to work (one of the chips removed meant the required timing signal wasn't available), so it was all monochrome though still with the custom resolution and taking 7.75KB.
[2] The version enhanced for the Master series use a mix of mode 1 and mode 2 to enable more colours, 2bbp for the view of space and 4bbp³ for the dashboard. This still used the custom resolution, so took 15.5KB rather than 20KB. This was achieved by using the shadow RAM bank to host the screen display (some programs instead used this feature to implement double-buffering for smoother screen drawing), allowing the screen to take twice as much space while also freeing up memory to hold things that would have been loaded from disc when needed⁵ in the Micro version.
[3] Actually effectively 3bbp as the BBC hardware did 8 colours and flashing variants instead of 16 colours (which most other systems used to provide two shades of 8 colours, using the 4th bit as an intensity flag).
[4] less a few chunks here & there needed by code in system ROMs when doing things like reading extra data from the floppy
[5] There were two chunks of code, one for in-flight and one for while docked, that were swapped in as you entered or left a space station. On the Micro these were pulled from disk each time, on the Master they could both be in RAM. If playing from cassette you had a cut-down version of the game that didn't need this split.
that is a legitimate post by itself
Zelda 1 was 128 kB, for those wondering, and that's without any compression. Double that for the sequel.
> without any compression
Perhaps not compression as we see it today. But one could argue that tile based graphics and code based music is a form of compression. Old games used a myriad of cool tricks to get around their limitations.
- [deleted]
Modern coders will probably never experience the fun of rewriting the same thing endlessly only to discover how good some early version really was. Then some time after giving up someone else would make a similar thing go 20 times faster.
Modern coders will most likely never get to enjoy endless rewrites.
Zelda 1 has TONS of built-in compression, and it's own decompression routines.
I should have worded that better, I meant no UPX-style end-to-end compression like the OPs project used. NES games had to be much more judicious than that since there wasn't nearly enough RAM to decompress everything at once.
Yep. Each screen is just a list of prebuilt columns reused over and over. Then they used a form of crude RLE on the lists.
That honestly doesn't seem too bad. Zelda 1 is relatively large but it reuses a lot of assets and honestly probably doesn't have that much text. (More than a Mario but way less than a Dragon Warrior.)
AFAIR tho im not sure its even 128k, I think disk cards themselves are more like 110k and even then FDS Zelda had separate sides mostly for main menu and saves.
IOW might have been able to fit in 96Kb or less.
My favorite slight of hand was that all the dungeons and caves were part of a single rectangular map. Designers carved out a few specific designs, then other levels were clearly what worked with the remaining map screens available so it all fit in the space they had, with caves thrown in to take up single screen gaps.
And created them in somewhat recognizable shapes, e.g. eagle
What I think is really great about The Legend of Zelda is that Breath of the Wild is very clearly a more fully realized version of the same core vision that guided the design of the original game thirty years earlier.
Heck Chrono Trigger on the Super Nintendo is 4 MiB! A lot is possible if you have to fit your game in a tiny space.