SpritesMind.Net

I saw an announcement at another forum that a Genesis port of Super Mario Bros has been released (original post here).

I haven't tested it myself yet, but there's a youtube video here, and it's looks pretty cool.

Very impressive. I knew that automatic code translation was used for NES>GB and ZX/MSX>some russian computers porting in the past, but didn't expected that someone will ever try it these days, to port something to SMD.

Yeah. Some NES games have also been ported to the PCE, but it's a lot more similar to the NES. It's the first project of this kind that I've seen for the Genesis.

Of course it helps that a commented disassembly for SMB is available and that SMB was an NROM game (no CHR-RAM, and only 8kB of CHR-ROM)

It would be cool to see an attempt to translate arbitrary NROM games, but the analyzer that determines what is code and what is data would be the project from hell Just doing some sort of code coverage analysis based on the assumption that all code is executed in-place shouldn't be too complicated. But you'd also have to deal with code being copied to RAM, and perhaps being modified at runtime. Plus the scenarios where games might've used the same set of bytes both as code and data in some places to save space.

Woow it realy kind-of rocks. Has maybe a rather limited usefulness as it is, but cool technology demo (code translator).

Oddly enough, game is kind-of buggy now - I have no idea as of why. I have some savestates where game starts up in some level aafter losing life, and controls doesn't work anymore (time goes, music plays, nothing else works); an other similar strangities.

I fould this bug by entering the warp zone in the underground and then tube "3". Then the night level begins and everything rocks. And then I die and game does it as well (when it restarts in oviously visualy other level for some reason).

I guess bugs come from flags being different in some cases.... ?

This is cool none the less

mic_ wrote:Yeah. Some NES games have also been ported to the PCE, but it's a lot more similar to the NES. It's the first project of this kind that I've seen for the Genesis.

The cpu core. But the rest is just as different on the PCE as it is on the Genesis, from the NES. At least Genesis has 8x8 tile/sprite cells, and that can be used for tiles or sprites.

Of course it helps that a commented disassembly for SMB is available and that SMB was an NROM game (no CHR-RAM, and only 8kB of CHR-ROM)

Yeah, not tile or sprite updating via chr-ram (which is huge pain in the ass as now you have to trap all kinds of vram addresses and re-appropriate data being sent. Converting the NES planar format on the fly is a pain too, not to mention the PPU takes single byte updates for vram). There's just soo much more behavior you have to emulate depending how the games goes about its business. Not fun. SMB is one of the easiest games to do/handle.

It would be cool to see an attempt to translate arbitrary NROM games, but the analyzer that determines what is code and what is data would be the project from hell Just doing some sort of code coverage analysis based on the assumption that all code is executed in-place shouldn't be too complicated. But you'd also have to deal with code being copied to RAM, and perhaps being modified at runtime. Plus the scenarios where games might've used the same set of bytes both as code and data in some places to save space.

You had access to an open source NES emulator, you could do a log system were a clean memory map gets updates for opcodes and for data. Play completely through a game, then you have a near perfect map as to where all code is VS data.

You had access to an open source NES emulator, you could do a log system were a clean memory map gets updates for opcodes and for data. Play completely through a game, then you have a near perfect map as to where all code is VS data.

Yeah, that's what I was thinking too. You could do other useful stuff with that approach as well - like resolving all indirect memory accesses. And it might be easier to handle cycle-timed scrolling and whatnot, since the emulator could include PPU state info in the log.
But playing through each game to completion isn't exactly automatic

incredible work funny few times ago, i was looking at the super mario source thinking about a genesis port :p

great to hear that my "md developer studio" was helpful

Yes, this is indeed great, I don't think it has ever been done before so congrats for that !

I've hard time figuring why it does not work on real hardware though. So far, I found 2~3 odd things the program is doing:

(1) it sets the M3 latch bit (bit 1) in register 0 which apparently locks the HV counter (see thisthread). Since the program uses vertical counter to wait for VBLANK, it might be locked-out because of this.

(2) it sometime attempts to write at $00001F (cartridge ROM), seems like an address register is not being initialized properly.

(3) during initialization, it does a lot of VRAM reads followed by VRAM writes, while changing the VDP address manually (using CTRL port) between DATA port access. While it works on emulator, I'm not sure if real hardware can handle that and if it does not require some waits between setting a new VDP address and reading/writing the DATA port.


I've patched (1) and (2) in the ROM (requires patching the checksum routine also) but the game still refuses to boot on real hardware. It does starts and have the time to set some VDP registers though because I can see the BIOS licensing screen being distorded when it switches into H32 mode.

(3) during initialization, it does a lot of VRAM reads followed by VRAM writes, while changing the VDP address manually (using CTRL port) between DATA port access. While it works on emulator, I'm not sure if real hardware can handle that and if it does not require some waits between setting a new VDP address and reading/writing the DATA port.

Wouldn't that just give corrupt graphics instead of halt the code from going any further? I didn't know there was a required delay. Shouldn't the VDP itself assert the delay if it was needed?

yes, it would indeed seems weird it gets indefinitively locked just for that but you never know
it could be anything anyway, it's quite hard to track down

I was just wondering why all of the previous SMB adaptations to the MD obviously weren't the same game. I wonder how long it will be now before we see a full "All Stars" style adaptation. While it probably wouldn't be a fair comparison it would be interesting to see.

Pascal wrote:incredible work funny few times ago, i was looking at the super mario source thinking about a genesis port :p

great to hear that my "md developer studio" was helpful

Heh, as was I at one point. I would have been doing it manually, however, and instead of emulating the PPU and I/O, I would have pre-converted tiles and rewritten the graphics, sound, and input routines to use MD-native ones.

World 36 needs special-casing (no surprise there, as NES/Famicom cart SMB and FDS SMB have different world 36, since it's caused by reading out-of-band data). Other than a small issue with the sprite limit that shows up on a few levels (most notably, 5-4 and 6-4 near the powerup blocks, as well as X-4 levels with Bowser throwing hammers), this thing is pretty damn accurate. Cheep-cheeps on 2-3/7-3 seem to have a slight oscillation on their vertical speed (instead of smoothly flying like on the original), and occasionally (and randomly), on the same levels there are a few miscolored tiles (given the rotating coin palette instead of the proper one). Other than that, it's pretty full featured, all other known glitches and tricks work that I've tried (hatstomping, jumping from a powerup midair). I can't reliably walljump so I haven't tested that, nor have I tested the phenomenon where if you can stomp a paratroopa twice in midair, it will float in mid air, and when it starts moving again it'll walk on air.

Just tried the SMB1 "port" : awesome ! I particulary like the YM2612 "touch" =)
Congratulations to all people which contribued to this project

I recorded a full warpless run the other night, it's 42:44 long and so I'm uploading it in 5 segments on YouTube. Here's the first one, second one uploading now, third through fifth will upload after that, then I'll add annotations later today.