Live data from Hacker News

A Comprehensive Super Mario Bros. Disassembly

gist.github.com

11–20 of 87 posts

Re: A Comprehensive Super Mario Bros. Disassembly

#11

This seems like a really impressive effort to make sense of all this! Would the original game have been written in assembly? And if so, would the source have looked similar to this? Having never touched assembly language (aside from learning some very basic cracking many years ago swapping JE for JNE in the serial check routine, haha), it seems like a true dark art to me, so I’m really curious to know!

> Would the original game have been written in assembly? And if so, would the source have looked similar to this?

Yes, and probably somewhat. The programmers were Japanese, so variable names would almost certainly be different, and the assembler this code was written for is actually for the CPU in the Super Famicom/SNES, so although I'm not sure when the assembler was written, it certainly wasn't around in 1984 when this game was being written. I think that the notation style is based on Nintendo's system development documentation, though.

The NES would actually be a good place to look at some assembly, at least to get a basic idea of how it works. There aren't many operations, they're pretty easy to understand. There are only a few registers, and no layers of historic cruft layered on top ofit. The same (well, very close) CPU was used in a lot of computers from the same era: https://en.wikipedia.org/wiki/MOS_Technology_6502#Computers_...

Re: A Comprehensive Super Mario Bros. Disassembly

#12
There's also a Legend of Zelda disassembly, but it's not as nice:

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

Re: A Comprehensive Super Mario Bros. Disassembly

#14
post #10

This seems like a really impressive effort to make sense of all this! Would the original game have been written in assembly? And if so, would the source have looked similar to this? Having never touched assembly language (aside from learning some very basic cracking many years ago swapping JE for JNE in the serial check routine, haha), it seems like a true dark art to me, so I’m really curious to know!

Yes, all old NES games were written in 6502 assembly (named after the NES's 6502 processor), and even most games into the Super Nintendo and Game Boy days were written using assembly language. The source would've looked very similar to this, although I can assume the original labels would've been in Japanese. The difficulty in creating a disassembly like this isn't converting the machine code back into assembly, whic…

Yes I believe on the Genesis most games were written in assembly as well. Sonic Spinball was written in a “high level language” (i.e. C) and so it only runs at 30 FPS instead of 60.

Re: A Comprehensive Super Mario Bros. Disassembly

#15
post #3

https://gist.github.com/1wErt3r/4048722#file-smbdis-asm-L601... I think this is where the real gems start. The biggest contribution that SMB had was the "physics engine", to retrofit a modern term. The friction, the jumping, the inertia. If you compare it with the primitive physics in Donkey Kong or Mario Brothers, you can really grasp the groundbreaking novelty that was SMB. You can change direction in mid-air, but…

I once read that the way SMB was able to pull off the physics engine on such limited hardware was that it used lookup tables for physics instead of actually calculating velocity. My assembly-fu is weak but it looks like your link is to the section that contains all the lookup tables. I think JumpMForceData for example is a series of offsets for each successive frame after you hit the jump button. https://gist.github.…

Lookup tables were indeed a common technique used by games in the past.

Re: A Comprehensive Super Mario Bros. Disassembly

#17

Earlier quoted context omitted.

I once read that the way SMB was able to pull off the physics engine on such limited hardware was that it used lookup tables for physics instead of actually calculating velocity. My assembly-fu is weak but it looks like your link is to the section that contains all the lookup tables. I think JumpMForceData for example is a series of offsets for each successive frame after you hit the jump button. https://gist.github.…

Lookup tables were indeed a common technique used by games in the past.

And present, too, right? It's not the same reason as it would have been in the 80s, but today in performance critical code it is not uncommon to reduce the number of conditionals for better CPU pipelining, and lookup tables are a very common tool for this.

Re: A Comprehensive Super Mario Bros. Disassembly

#19
Check out the section under "DemoActionData": this is where it stores (and plays) the demo you see when you don't push Start and Mario runs around on his own volition.

It just simulates player input and runs it through the regular game engine. (The alternative, playing a recorded video, would have been laughably data intensive.)

Re: A Comprehensive Super Mario Bros. Disassembly

#20
post #13

Looks like data for the various songs here: https://gist.github.com/1wErt3r/4048722#file-smbdis-asm-L160... I'd love to see the process of extracting actual audio from that.

The NES had a memory-mapped APU[1], so the game just sets sound registers to play the appropriate notes, and ticks down a timer until it's time to switch to the next note: https://gist.github.com/1wErt3r/4048722#file-smbdis-asm-L156...

[1] https://wiki.nesdev.com/w/index.php/APU

Post reply on HN