4 ms·
There's also a Legend of Zelda disassembly, but it's not as nice: https://github.com/camthesaxman/zeldasource https://github.com/camthesaxman/zeldasource It's
by khedoros1 9y ago
There's also a Legend of Zelda disassembly, but it's not as nice:
https://github.com/camthesaxman/zeldasource https://github.com/camthesaxman/zeldasource
It's a much larger game, though.
I haven't checked, but I'm assuming that a lot of the giant chunks of statically-defined data are just graphics and audio (unlike many games, LoZ stored graphics interspersed with the program code and copied data over to an in-cartridge RAM chip, instead of storing the complete graphics data in a ROM chip.)
- derefr 9y ago> unlike many games, LoZ stored graphics interspersed with the program code and copied data over to an in-cartridge RAM chip, instead of storing the complete graphics data in a ROM chip This is because Zelda 1 was a port from the Famicom Disk System—no memory-mapped ROM chip to rely on, so you've got to load everything you're going to use to RAM. (Also like this: Metroid.) I believe this is why both LoZ's and Metroid's maps are built out of individual "screens" with a "pause to transition" effect between them: in the FDD version, the game would be reading the new map from disk, and there'd (sometimes, if the load took long enough) be a loading screen involved. (You can see the screen for LoZ here: http://tcrf.net/The_Legend_of_Zelda/Console_Differences#Loading_Screen http://tcrf.net/The_Legend_of_Zelda/Console_Differences#Load...)
- khedoros1 9y agoCool, I never dug in to see why they were that way, but those were both test cases when I built an NES emulator.