Super Mario Bros.

Some of you may remember that I expressed interest in wanting to do something like this in the past, but was unable to due to lack of time. Well, someone's done it. It doesn't work on hardware ATM (Tiido did test it), but other than that it's fucking brilliant (world 36 seems to crash the game, as seen in the YouTube video).

 

I wasn't aware he was registered here, so I figured I'd post about it.

 

I know. Intuitive in regards to button labeling, non-intuitive in terms of actual play. I was able to adjust fairly easily, however.

 

Yeah, except those "ports" suck BIG PENIS. Play control is shitty, collision detection is horrible, and not all secrets are present. This is a true port, made from a disassembly of the original NES code. So far, the only thing I've seen that doesn't work properly is world 36 (I.e., the minus world), and that makes complete sense, since it was a bug in the original that relied on reading out-of-bounds data (the FDS version of SMB1 also behaves differently, giving you -1, -2, and -3, which when beaten acts like 8-4 was beaten and returns to the title screen with the world select active). For world 36 to work on the Genesis port, it would have to be special-cased.

 

Noticed a few more small issues - as everyone has probably already noticed, the palette is way off, black is too gray and reds are a little purplish. Also, due to the way it seems he's assigning each 8x8 NES sprite to a single Genesis sprite, you run into the sprite limit quite a bit (see 6-4 near the powerup block, and also the later X-4 levels where Bowser throws hammers - if you shoot fireballs at him with lots of hammers on-screen, the fireballs are invisible, but still there - they do damage as expected).

 

NES has no overall sprite limit for the entire screen that I know of, MD does. That's where the issue comes into play, I believe. Let me do a bit of research and I'll get back to you on this.

Edit: Hm. I was wrong. NES OAM can hold data for up to 64 sprites. H32 mode can support 64 sprites. Have no idea if SMB reloads the OAM data midframe, most likely not (AFAIK, the only code that runs at a specific mid-frame point is the sprite 0 hit below the status bar). AFAIK, he's more or less emulating the PPU behavior, so I can't imagine that the status bar is taking up any sprites (except for the aforementioned sprite 0 hit).

 

Well, you're not 100% exactly right, but you're really close. The code is translated to 68k (mostly automatic, but a few small things had to be done manually), he does emulate the NES PPU and I/O, but he only simulates the APU interface, as sort of a "bridge" to his custom music engine (which uses data converted from the original NES data). Otherwise, the game data is stored exactly as found in the NES ROM. I'm sure his sound engine could be replaced with another one, or better instruments could be used with the existing data (it seems that rather than exactly simulating the 5 channels of the NES, he put the music on the 2612 and the sound effects on the PSG, because it doesn't seem like music notes drop out when sound effects hit, as would happen on the NES).