Super Mario Bros on the Genesis
Moderator: Mask of Destiny
Super Mario Bros on the Genesis
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.
I haven't tested it myself yet, but there's a youtube video here, and it's looks pretty cool.
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.
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).
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).
_____________
www.dtech.lv
www.dtech.lv
-
- Very interested
- Posts: 2442
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
I guess bugs come from flags being different in some cases.... ?
This is cool none the less
This is cool none the less
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 256
- Joined: Tue Sep 11, 2007 9:10 pm
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.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.
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.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)
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.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.
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.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.
But playing through each game to completion isn't exactly automatic
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.
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.
-
- Very interested
- Posts: 256
- Joined: Tue Sep 11, 2007 9:10 pm
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?(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.
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.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
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.
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.