S3KBR Transitions not working

[Coco976-arg]

I was playing Sonic 3 & Knuckles Battle Race, I noticed that the transitions from the battle and mini game menus are not working, please fit that, thank you

S3KBR.zip

[Clownacy]

This is just bizarre:

000B3ED6: sf.b    ($FFFFF62A).w
000B3EDA: move.w  #$8A00,(a6)
000B3EDE: movea.l ($FF6FF0).l,a4
000B3EE4: movea.l ($FF6FF4).l,a5
000B3EEA: move.l  a4,($FF6FF8).l
000B3EF0: move.l  a5,($FF6FFC).l
000B3EF6: bchg.b  #3,($FF6FEF).l
000B3EFE: moveq   #0,d0
000B3F00: move.b  ($FF6FEF).l,d0
000B3F06: move.l  $B3EC6(pc,d0.w),($FF6FF0).l
000B3F0E: move.l  $B3ECA(pc,d0.w),($FF6FF4).l
000B3F16: movem.l (sp)+,d0-a3
000B3F1A: move.l  #$40000010,d7
000B3F20: move.l  #$B3F28,($FFFFFFF8).w
000B3F28: move.l  d7,(a6)
000B3F2A: move.l  (a4)+,-4(a6)
000B3F2E: move.l  (a5)+,(a6)
000B3F30: rte     

This is part of the game's V-Int/H-Int logic. It reads from $FF6FF4 (which is 0x000000), sets $FF6FF4 (to a valid value), and then copies data (from 0x000000) to the VDP. It copies data on every scanline, causing the VDP to be flooded with invalid data from the start of the cartridge, resulting in the massive corruption seen in-game.

The problem is, this appears to be exactly what the code should be doing: $FF6FF4 is only written to by random memory clears and this code, meaning there's nothing that could set $FF6FF4 to a valid value without first reading from it to write nonsense to the VDP later.

My best guess is that somehow two V-Ints are occurring in a single frame, or the H-Ints do not occur until the next frame; either outcome would cause two V-Ints to occur before the first H-Int, allowing $FF6FF4 to be correctly initialised before the H-Ints proceed to use it to copy data to the VDP.

[Clownacy]

According to Regen, other emulators are fed this garbage data as well, but, somehow, they do not respond to it by corrupting VRAM.

[Clownacy]

Okay, I think I might know what's going on: the garbage data is all sent to the control port, which is normally harmless... unless it happens to accidentally trigger a DMA transfer, which it eventually does. With Regen's debugger, I can see that only 0x18 bytes of garbage data are copied before a second V-Int occurs and properly-initialises $FF6FF4, ending the bug. In my emulator, much more data is copied before the second V-Int has a chance to fix things. I am almost certain that the difference here is that Regen is correctly emulating DMA transfer times, while ClownMDEmu does not.

The code at $B3ED6 runs at the end of the V-Int handler, after all of the DMA transfers have been performed, which could be leaving it with very little time to run before the next V-Int. Because my emulator does not emulate these transfer times, the code is left with much more time to run, allowing it to copy far more garbage data to the VDP, eventually triggering a nonsensical DMA transfer and corrupting VRAM.

With that in mind, solving this would require emulating DMA transfer durations.

[Clownacy]

Somehow GitHub thinks 'Somehow does not fix #95 goddammit.' means that it somehow fixes #95 goddammit.

[Clownacy]

I moved it here; this issue relates to the emulator core, not its frontend.

[Coco976-arg]

ok

[Coco976-arg]

Now the transitions work but still showing up corrupted tiles