Super Mario Bros on the Genesis

Announce (tech) demos or games releases

Moderator: Mask of Destiny

Eke
Very interested
Posts: 856
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Mon Jul 05, 2010 6:59 am

Eke wrote: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.
ok, I found the issue: I took VDP init register values from other program that I know works on real hardware and figured that you need to set register 23 to $80 (VRAM fill operation) before setting the first VRAM write in CTRL port. I guess that this has something to do with Memory to V-RAM DMA being started even if it shouldn't (probably because code register MSB are not cleared on startup and the first write to CTRL port which is set to program a VRAM write would trigger the DMA before the second write ???). Well, we know that DMA from ROM can lock the machine if not done properly so I think this is the issue.

I don't know, I also noticed that, contrary to most others, this program don't read the VDP status on startup. This might clear some internal settings as well and could do the trick also.

To resume, to get this ROM work on real hardware, the following patches are required:


$552: replace $06 by $04 (this clears the M3 latch bit)
$569: replace $00 by $80 (this prevents DMA from ROM to be accidentally triggered)
$2B2-$2B3: patch with $4E71
$2B4-$2B5: patch with $4E71
(this patches the checksum verification routine)


The problem now is that inputs seems not to be read properly: my controller does not respond and I can't leave the menu screen , it's probably something related to timings when programming the controller.

TascoDLX
Very interested
Posts: 256
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Mon Jul 05, 2010 9:18 am

Eke wrote:The problem now is that inputs seems not to be read properly: my controller does not respond and I can't leave the menu screen , it's probably something related to timings when programming the controller.
It's much more obvious than that. (hint: something is missing.)

For anyone still "testing", here's an unofficial hackpatch of mine in IPS form. It fixes that controller issue, everything Eke mentioned, and that pesky disappearing sprites problem (plus anything related).

bastien
Very interested
Posts: 208
Joined: Mon Jun 25, 2007 7:19 pm
Location: Besançon,France
Contact:

Post by bastien » Mon Jul 05, 2010 9:59 am

hi have tested this patch now the game launch ,
very good works :twisted:
but they are some graphical glithes but thanks you a lot for your work

Eke
Very interested
Posts: 856
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Mon Jul 05, 2010 11:09 am

TascoDLX wrote:
Eke wrote:The problem now is that inputs seems not to be read properly: my controller does not respond and I can't leave the menu screen , it's probably something related to timings when programming the controller.
It's much more obvious than that. (hint: something is missing.)

For anyone still "testing", here's an unofficial hackpatch of mine in IPS form. It fixes that controller issue, everything Eke mentioned, and that pesky disappearing sprites problem (plus anything related).
Indeed, it never initializes the CTRL ports (TH direction is not set properly ), this at least showed me I was not handling this properly on emulator.
Thanks for the patch !

TmEE co.(TM)
Very interested
Posts: 2373
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Mon Jul 05, 2010 11:25 am

that DMA triggering thing was something I once cracked my head on, and I found a workaround to it... Z80 must run and access ROM, then it won't cause a crash... :idea:

...and thanks for the patch TascoDLX :D
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

Eke
Very interested
Posts: 856
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Mon Jul 05, 2010 1:59 pm

TmEE co.(TM) wrote:that DMA triggering thing was something I once cracked my head on, and I found a workaround to it... Z80 must run and access ROM, then it won't cause a crash... :idea:
interesting... do you have any explanation why this fixes it ?

It does not seems it's related to the initialvalue of the code register as I first suspected since it also locks when starting from BIOS (which initialize VDP correctly). Weird, maybe it's just a bug when setting this specific VDP register...

TmEE co.(TM)
Very interested
Posts: 2373
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Mon Jul 05, 2010 3:01 pm

the crash happens perhasp because DMA grabs the bus form 68K before 68K finishes, and when Z80 runs it delays DMA somehow or something and thigns run.
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

Chilly Willy
Very interested
Posts: 2785
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jul 05, 2010 10:14 pm

The patch works, but it seems to leave the MD in 40 col mode instead of 32 col, so everything is "centered" around the left side of the screen with all the stuff to be scrolled in showing on the right. Also, sprites just appear part of the way in on the right where the edge would have been in 32 col mode.

Also, just having a mouse plugged into the second controller port is enough to make the controls ignored.

EDIT: Sometimes it will run in 256 wide mode, and sometimes it won't. When it runs in 256 wide mode, you get lots of graphical glitches... things appear to be positioned wrong. Look at evildragon's photo for an example of the glitches.

EDIT 2: It boots as 320 wide if I have the MegaMouse in controller port 2. ed said that holding the buttons down on the second controller when the game boots is what does it. Anyway, if you don't want graphical glitches, do one or the other. :D

Image

TascoDLX
Very interested
Posts: 256
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Tue Jul 06, 2010 5:03 am

It's probably the VRAM reads/writes. The code does a bit of read and writeback. I'm thinking that setting the address and reading immediately may fail occasionally. I'm not sure about writing immediately. Anyway, it might be enough to have a NOP before the first read or write.

I'm also thinking that the faster clock is why 320 mode doesn't have the glitches that 256 mode does. Faster reaction time, in a sense.

Chilly Willy
Very interested
Posts: 2785
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Jul 06, 2010 6:52 am

TascoDLX wrote:It's probably the VRAM reads/writes. The code does a bit of read and writeback. I'm thinking that setting the address and reading immediately may fail occasionally. I'm not sure about writing immediately. Anyway, it might be enough to have a NOP before the first read or write.

I'm also thinking that the faster clock is why 320 mode doesn't have the glitches that 256 mode does. Faster reaction time, in a sense.
That makes sense - I seem to remember a tech bulletin for the MD that said that vram reads after writes can fail if the VDP goes busy fetching/drawing the next line, and that you could have to wait as long as almost one horizontal line before reading becomes valid again... or something like that.

TascoDLX
Very interested
Posts: 256
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Tue Jul 06, 2010 7:20 am

OK, I gave it a shot: hackpatch v2. Let me know if it's better.

Eke
Very interested
Posts: 856
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Tue Jul 06, 2010 7:56 am

Strange, I remember seeing somewhere in the code a routine that sets H40 mode if some value is read at some RAM address on startup (why ?). Contrary to what emulators are doing, RAM is not initialized on power on, so it can return random value depending on the console model.

It's meant to be running in H32 mode by default though, as it runs fine on emulators.

Glitches are definitively due to VRAM read/writes timing after changing the address: there is a FIFO for writes but reads are buffered I think (a read is initiated when you setup the address & code through CTRL port, so when CPU reads the DATA port, the value of the buffer is immediately returned then a read is programmed at the next address to be ready for the next time CPU access the DATA port). If you read the port before the VRAM reads being actually done (there are most likely fixed slots on a line where it can be done), you get wrong data and so does the writeback...

LocalH
Very interested
Posts: 152
Joined: Tue Dec 19, 2006 5:04 pm

Post by LocalH » Tue Jul 06, 2010 8:35 am

Eke wrote:Strange, I remember seeing somewhere in the code a routine that sets H40 mode if some value is read at some RAM address on startup (why ?). Contrary to what emulators are doing, RAM is not initialized on power on, so it can return random value depending on the console model.
That seems like it'd be the H40 "down+B on port 2" code, second part (first part of course sets that flag if the conditions are met)
It's meant to be running in H32 mode by default though, as it runs fine on emulators.
Obviously, yes, it's meant to "work" in both modes (I quantify the word "work" with the aforementioned sprite pop-on behavior - other than that, the screen is properly displayed and scrolled in H40). Kinda interesting to set Fusion to a widescreen resolution (here, 1440x900), set it to fill the screen, then run in H40 mode. Other than the sprite pop-on, it's a fairly unique experience to any other version of SMB.

Eke
Very interested
Posts: 856
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Tue Jul 06, 2010 8:57 am

My bad, I didn't noticed there was a cheat code added by the author to switch into experimental h40 mode.

Yes, it's definitively that: random RAM initialization on power-on sometime makes the game think the "cheat" flag has been set. The game should properly zeroes the work RAM during the startup phase.

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Tue Jul 06, 2010 12:55 pm

I've noticed reports of the game not letting Mario slide. With my 3-in-1 adapter and a Saturn gamepad he slides just fine.

Post Reply