48 replies to this topic

[GilliganCoder]

I have always wanted to find the original source code to the mario games to see how they implemented such functions as jumping and collision detection. SMB, SMB3, and SMW are the target games, and I'm assuming the algorithms improved from SMB3 to SMW, etc. Does anyone know where I could find the original source code, the disassembled source code, or the original assembly language code for any of these games? Any input is appreciated. Thanks.

[MrDaaark]

Nintendo didn't release the source code to these games.

[Evil Steve]

Simple answer is that you can't legally.

[GilliganCoder]

I know that Nintendo never released the code officially but it's probably past the copyright restrictions now after 20+ years... The RAM & ROM maps are already on the net so I figured maybe the source would be available somewhere.

[Evil Steve]

That's just a myth. Just because a game is old, doesn't mean it's legal to rip it. The ROMs of it on the Internet are still illegal. The only way you'd be able to see the source would be by disassembling it, but even then you'd be looking at assembly for whatever platform the game is on, and assembly code usually looks very little like the original source (Unless the game is written in assembly of course).

[BrasiLokau]

alternatively you can check this website: http://jnrdev.72dpiarmy.com/
Its a greate resource for making games like mario.

[Goober King]

Quote:

Original post by GilliganCoder I know that Nintendo never released the code officially but it's probably past the copyright restrictions now after 20+ years... The RAM & ROM maps are already on the net so I figured maybe the source would be available somewhere.

Hate to break it to you but its something like 75years After the Death of the creator that a copyright expires. So Mario has a long way to go, and if Micky mouse has anything to say about it, it will take even longer.

[Th0ughtCr1me]

As a side note, I am possitive I heard that Mario and most of the launch games for the FamiCom were coded in ASM. Later they used a Basic compliler.

[GilliganCoder]

Quote:

Original post by Th0ughtCr1me As a side note, I am possitive I heard that Mario and most of the launch games for the FamiCom were coded in ASM. Later they used a Basic compliler.

I believe the original NES games were coded in 8086 assembly or something close to it.

[Th0ughtCr1me]

It didn't use an 8086 so I think that's highly unlikly, but since it's ASM, one could disassemble and you would be looking at the original source (since they didn't use optimising assemblers at the time).

[MrDaaark]

Just speculation, but could the source code to super mario brothers really be that complex? It's just a tile map and some collision. The genius of the game was from the creativity, the art, the music, etc. Not the source. I assume there might have been some clever hacks to get around original NES hardware restrictions, but that's irrelevant now.

All the monsters follow very simple patterns. They just walk a few tiles back and forth and won't even give chase (except the ghosts). If they happen to have projectiles, they fire them at random, or in a set pattern.

If you touch a projectile or an enemy (everywhere except the top) you shrink back down to normal Mario, or you lose a life.

If you're not standing on a solid tile, you fall a few pixels. If there's no solid tiles under you in your current tile column, you're over a cliff and you fall to your doom.

The exception to that is jumping. Nothing complex in Mario's jumps. If Jump mode is on, you increase his height every update until you hit his peak, then jump mode is off, and you just fall normally.

[GilliganCoder]

Quote:

Original post by Th0ughtCr1me It didn't use an 8086 so I think that's highly unlikly, but since it's ASM, one could disassemble and you would be looking at the original source (since they didn't use optimising assemblers at the time).

Found it - 6502 processor. It's not so much the idea of emulating Mario but actually being able to see how they did it in the original games.

[Kaze]

Infinite Mario Bros
if your still intrested heres a open source mario clone,
(code link at bottom of page)

also its in java so it should be a bit easier to understand than NES assembly

[GilliganCoder]

well I ended up finding something like what I was looking for on the net. It's the disassembled assembly for the original mario bros w/ comments by a programmer. here's the link if anyone's interested:

http://www.romhack.org/old-site/docs/gamespec/nes/Smbre.zip

[Anthony Serrano]

Quote:

Original post by Vampyre_Dark Just speculation, but could the source code to super mario brothers really be that complex? It's just a tile map and some collision. The genius of the game was from the creativity, the art, the music, etc. Not the source. I assume there might have been some clever hacks to get around original NES hardware restrictions, but that's irrelevant now.

One would be surprised; they put a lot of effort into keeping data sizes down, because the first-generation titles (before they developed memory-mapping hardware) had to fit into 40 KB. (8 KB for tile images, and 32 KB for code and all other data.)

So, for example, Super Mario Brothers (and almost all Nintendo-made NES games) don't actually store tile maps anywhere. Instead, the levels are divided into "rooms" (one room is one screenfull of data) that can be repeated; each room then consists of a list of "objects" in that room along with parameters for controlling the drawing of those objects.

Similarly, in all likelihood they made use of all sorts of programming hacks (similar to Final Fantasy's manual stack manipulation) to try to keep within the very strict 29,859 clock cycle/frame limit or keep the code size down.

Quote:

Original post by GilliganCoder well I ended up finding something like what I was looking for on the net. It's the disassembled assembly for the original mario bros w/ comments by a programmer. here's the link if anyone's interested:

I do hope that you are very familiar with NES hardware and 6502 assembly (as well as the differences between 6502 and 65816), because otherwise, that code isn't going to help you very much. The comments certainly don't give you very much of an idea of what's going on, especially considering a lot of them are guesswork. It doesn't even have the entry point marked; the entry point, by the way, is at 008000.

Be prepared to spend a lot of time analyzing that code before you actually find what you want.

[MrDaaark]

Quote:

Original post by Anthony Serrano Quote: Original post by Vampyre_Dark Just speculation, but could the source code to super mario brothers really be that complex? It's just a tile map and some collision. The genius of the game was from the creativity, the art, the music, etc. Not the source. I assume there might have been some clever hacks to get around original NES hardware restrictions, but that's irrelevant now. One would be surprised; they put a lot of effort into keeping data sizes down, because the first-generation titles (before they developed memory-mapping hardware) had to fit into 40 KB. (8 KB for tile images, and 32 KB for code and all other data.) So, for example, Super Mario Brothers (and almost all Nintendo-made NES games) don't actually store tile maps anywhere. Instead, the levels are divided into "rooms" (one room is one screenfull of data) that can be repeated; each room then consists of a list of "objects" in that room along with parameters for controlling the drawing of those objects. Similarly, in all likelihood they made use of all sorts of programming hacks (similar to Final Fantasy's manual stack manipulation) to try to keep within the very strict 29,859 clock cycle/frame limit or keep the code size down.

This is what I was talking about by 'clever NES hardware hacks'. [lol] When I think of Super Mario 3, of think of that one issue on the second level in world one (the grassy hill level) where you can get to a spot where too many enemies are on screen at once, and some of them would start to flicker, and the game would slow to like 3 fps.

I never understood the sprite limit (or sprite limit per scan line) on these old consoles. Was there not direct access to blit them to vram?

When you eliminate all the NES stuff, Super Mario comes down to simple tile maps and bounding box collisions (maybe with per pixel, should the boxes intersect).

[apatriarca]

Quote:

Original post by Goober King Quote: Original post by GilliganCoder I know that Nintendo never released the code officially but it's probably past the copyright restrictions now after 20+ years... The RAM & ROM maps are already on the net so I figured maybe the source would be available somewhere. Hate to break it to you but its something like 75years After the Death of the creator that a copyright expires. So Mario has a long way to go, and if Micky mouse has anything to say about it, it will take even longer.

In Italy the copyright expires 70 years after the death of the last author. So it’s a lot more than 75 years. I think the law is similar in other countries.

[Ravyne]

Quote:

Original post by Vampyre_Dark This is what I was talking about by 'clever NES hardware hacks'. [lol] When I think of Super Mario 3, of think of that one issue on the second level in world one (the grassy hill level) where you can get to a spot where too many enemies are on screen at once, and some of them would start to flicker, and the game would slow to like 3 fps. I never understood the sprite limit (or sprite limit per scan line) on these old consoles. Was there not direct access to blit them to vram?

The sprite limit is a very strict limitation of the hardware. On the NES and other systems which used similar tile-based graphics units there is no frame-buffer memory at all: the very concept of writing a pixel is foreign, you only write tiles and objects (sprites). Each scan-line of the display is formed on the fly, sampling against the tile plane(s) and checking against objects on the scan-line for potential intersections. If a sprite was found to be intersecting, its image is super-imposed over the sampled tile images. The graphics unit literally has 8 slots from which to sample sprite objects and these slots are re-filled between each scan-line. The number 8 simply comes from the engineering considerations of the device, perhaps speed, perhaps cost, perhaps it was simply an arbitrary "target number" Nintendo laid down when shopping around for GPUs. This is the way that all tile-based graphics modes work. Even the infamous mode-7 of the SNES (F-Zero, Mario Cart) works on the same principle (with a few programming tricks thrown in.) Some systems, like the SNES or GBA added bitmap modes that had directly-accessible pixels in addition to tiled modes.


And now some advice for the OP -- Firstly, the mere possession of that source is illegal, you'd be best off deleting it from your hard-drive and your memory. Even setting aside the illegality of this resource you are in no way equipped to decipher it. Until a short while ago you didn't even know what processor the NES used, let alone how to read or write its assembly language, let along its own particular hardware system or its quirks. Some of the NES's opcodes aren't even officially documented (though NES homebrew information can shed some light there.) You would be far better off, both legally and practically speaking, to simply watch the game very closely and reverse-engineer this behavior through simple observation and trial-and-error.

Not long ago I created a simulated tile-based GPU and ported the first level of SMB as a proof-of-concept. Through simple observation I was able to deduce all of the movement and gameplay mechanics precisely in a single evening, and without racking my head trying to understand a disassembly listing for a processor I wasn't fluent with.

[MrDaaark]

Quote:

Original post by ravyne2001 Quote: Original post by Vampyre_Dark This is what I was talking about by 'clever NES hardware hacks'. [lol] When I think of Super Mario 3, of think of that one issue on the second level in world one (the grassy hill level) where you can get to a spot where too many enemies are on screen at once, and some of them would start to flicker, and the game would slow to like 3 fps. I never understood the sprite limit (or sprite limit per scan line) on these old consoles. Was there not direct access to blit them to vram? The sprite limit is a very strict limitation of the hardware. On the NES and other systems which used similar tile-based graphics units there is no frame-buffer memory at all: the very concept of writing a pixel is foreign, you only write tiles and objects (sprites). Each scan-line of the display is formed on the fly, sampling against the tile plane(s) and checking against objects on the scan-line for potential intersections. If a sprite was found to be intersecting, its image is super-imposed over the sampled tile images. The graphics unit literally has 8 slots from which to sample sprite objects and these slots are re-filled between each scan-line. The number 8 simply comes from the engineering considerations of the device, perhaps speed, perhaps cost, perhaps it was simply an arbitrary "target number" Nintendo laid down when shopping around for GPUs. This is the way that all tile-based graphics modes work. Even the infamous mode-7 of the SNES (F-Zero, Mario Cart) works on the same principle (with a few programming tricks thrown in.) Some systems, like the SNES or GBA added bitmap modes that had directly-accessible pixels in addition to tiled modes.

I have to wonder why that design decision was made. Was vram too expensive, or a foreign concept in this age? I assume a bit of vram for to hold the frame (not double buffered) would only take a few KB, especially with the restricted pallet.

Quote:

Original post by Wikipedia The PPU (Picture Processing Unit), more specifically known as Ricoh RP2C02 (NTSC version) / RP2C07 (PAL version), is the microprocessor in the Nintendo Entertainment System responsible for generating video signals from graphic data stored in memory. The chip is known for its effective use of memory, using very little memory to store graphical data. It was rather advanced for its time when the Famicom (first Japanese version of the Nintendo Entertainment System) was released, sporting full sprite support, movable backgrounds, and many colors on screen at the same time. To compete with other video game systems, like the technically superior Sega MegaDrive, Nintendo also extended the PPU's technical capabilities through the use of mappers, placed on the game cartridge. The mappers added more memory or could bank switch data into the PPU's address space, making it possible to create more advanced graphics, using more colors and bigger tile sets.

[Mike2343]

Quote:

Original post by GilliganCoder well I ended up finding something like what I was looking for on the net. It's the disassembled assembly for the original mario bros w/ comments by a programmer. here's the link if anyone's interested: http://www.romhack.org/old-site/docs/gamespec/nes/Smbre.zip

I'm pretty sure posting that link is against the forums rules. The site hosts illegal ROMs and stolen property.