Sign in to follow this  
GilliganCoder

Super Mario source code

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Vampyre_Dark
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.


It has more to do with the simple fact that a 1.79 MHz CPU simply does not have the processing power to render complex scenes at 256x240, at 60 fps. (That works out to about 1/2 clock cycle per pixel.) Using a tile-based PPU meant that NES games could use more of their precious CPU cycles for game logic instead of video rendering. (Compare with the Atari 2600, which basically required that the game code spent most of it's time in rendering.)

The 8 sprite/scanline limit is a timing issue. The PPU can only fetch sprite tiles during the horizontal blanking period, when it is not actively fetching background tiles; the horizontal blanking period is just long enough to fetch 8 tiles.

As an aside, the SNES PPU is very similar to the NES PPU; the main difference is that it's RAM is clocked at 5.37 MHz instead of 2.68 MHz, and has a 16-bit data bus instead of 8-bit, allowing it to load 16 bytes/tile instead of 4.

Share this post


Link to post
Share on other sites
Quote:
Original post by 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.


Yeah, it's similar. In Japan, it's 70 years now after the date of publication, and in the US, it's 95 years after the date of publication (because SMB is owned by Nintendo, not Miyamoto).

So assuming, they don't republish it (which they have), nor get any sort of extention, the absolute earliest you're going to be able to do a legal remake is 48 years from now.

As for the leniency of other remakes? Well, those are all illegal, and Nintendo can at any point in time send a cease and desist on the project. While they probably won't for an unknown project, they have the option too, should they choose to change their minds.

Share this post


Link to post
Share on other sites
Quote:
Original post by Vampyre_Dark
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.


You have to consider that things like RAM were pretty expensive at the time, the cost of RAM was so much of a concern for Nintendo that they only included 2k of working ram in the NES itself. At 256x240 pixels, with 4 bits (see note) per pixel, and double-buffered you're looking at just under 64k of RAM solely as framebuffer memory. The NES also used SRAMs which were more expensive than DRAMs -- DRAMs require the NES to have refresh circuitry which would have added to the cost and power-consumption of the NES unit.

note: Sprites on the NES use 2bits per pixel, plus another 2 bits in the sprite attribute table to specify one of four 4-color palettes, giving an effective bpp of 4. Its technically a little more complicated since color 0 of each pallete was always transparant/background.

Anthony also makes some good points, though I'm not sure that I'd go as far as saying the the SNES PPU is all that similar. While the idea of tiles is preserved on the SNES, it has far more capabilities: A larger color palette, larger sprites, more sprites, more tile/object planes, 8 different video modes and 4 different resolutions.

Share this post


Link to post
Share on other sites
Quote:
Original post by ravyne2001
Quote:
Original post by Vampyre_Dark
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.


You have to consider that things like RAM were pretty expensive at the time, the cost of RAM was so much of a concern for Nintendo that they only included 2k of working ram in the NES itself. At 256x240 pixels, with 4 bits (see note) per pixel, and double-buffered you're looking at just under 64k of RAM solely as framebuffer memory. The NES also used SRAMs which were more expensive than DRAMs -- DRAMs require the NES to have refresh circuitry which would have added to the cost and power-consumption of the NES unit.

note: Sprites on the NES use 2bits per pixel, plus another 2 bits in the sprite attribute table to specify one of four 4-color palettes, giving an effective bpp of 4. Its technically a little more complicated since color 0 of each pallete was always transparant/background.

Anthony also makes some good points, though I'm not sure that I'd go as far as saying the the SNES PPU is all that similar. While the idea of tiles is preserved on the SNES, it has far more capabilities: A larger color palette, larger sprites, more sprites, more tile/object planes, 8 different video modes and 4 different resolutions.
Mario Paint at least demonstrated that it had full 'buffer' access?

Share this post


Link to post
Share on other sites
Actually, I don't believe so. According to Wikipedia and everything else I've read on the net, the SNES does not have a "proper" bitmapped display mode, all 8 video modes are variations on tile-based modes.

That said, there are some relatively simple ways to emulate a bitmapped mode in a tile-based system. The most obvious is to write a set of tiles into the tile-buffer, and then write into the coresponding tile RAM instead of into a nice, linear frame-buffer. I'm not sure how the tiles are laid out in memory, but I assume its linear, in which case you can imagine a single screen as a collection of 8x8 framebuffer "tiles". Calculating the correct pixel address is obviously somewhat complicated, but as far as I know this is the technique that game's that used the SuperFX and possibly DSP chips used to achieve their appearantly bitmapped displays. Its likely that the cartriges used memory mappers or other hardware to alleviate this pain. Cartriges that did use these add-on chips were essentially a complete system unto themselves -- they had their own Processors (SuperFX/DSP), ROM and RAM -- The SNES unit itself was often little more than an IO conduit in these games.

The SNES, unlike the NES, had its own pool of RAM for storing tile and sprite images; the NES PPU had a dedicated memory bus to CHR ROM on the cartridge (all NES carts contain 2 ROM chips: one for tile/sprite images, the other for the program and other data such as maps, text and music.) making this technique possible out-of-the-box. It would be possible on the NES with the proper hardware built into the cartrige.


Wikipedia has a ton of technical information on the SNES, NES and most other systems. I don't think there was a console with a proper bitmapped mode until the 32bit era.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this