Emulation of 68K bus access refresh delays

[ekeeke]

As verified on real hardware (cf. https://gendev.spritesmind.net/forum/viewtopic.php?f=2&t=2323), there are periodical refresh access slots on 68K bus which can delay access from 68K CPU:

• in cartridge slot area (0x000000-0x3FFFFF)
• in work RAM area (0xE00000-0xFFFFFF)

These delays are actually not emulated in Genesis Plus GX and are the cause of graphical issues or crashes in the following games (the code of these games is somehow bugged / unsafe and is causing some race conditions with hardware or concurrently running software that were by luck not occurring on real hardware because of the tight timings but are exposed in emulator as it is running the code a little bit faster than real hardware):

• Clue (graphics corruption in title screen) / Microcosm (FMV intro infinite loop with Model 1 US BIOS)
  => there is currently a hack implemented in Genesis Plus GX (see https://github.com/ekeeke/Genesis-Plus-GX/blob/master/core/vdp_ctrl.c#L827 and https://github.com/ekeeke/Genesis-Plus-GX/blob/master/core/vdp_ctrl.c#L2258) that indirectly slowdowns code execution in these games and avoid the occurrence of these issues

• Super Airwolf (graphical glitch during intro)
  => see Intro Glitch on Super Airwolf libretro/Genesis-Plus-GX#205

• Pac-Man 2 : The New Adventures (infinite loops during Pac-Jr minigame levels transitions)
  => see https://bitbucket.org/eke/genesis-plus-gx/issues/444/crashes-in-pacman-2-new-adventures-pac-jr

[Tippek]

Primitive fix for Super Airwolf and Pac-man 2:
https://github.com/ekeeke/Genesis-Plus-GX/blob/master/core/m68k/m68kcpu.c#L305
if((m68k.cycles-refresh_cycles)>=(128*7)) { m68k.cycles += 2*7; refresh_cycles = m68k.cycles; }
with unsigned int refresh_cycles

for Megadrive 2 * 7, but for SCD probably 2 * 4.
based on https://plutiedev.com/mirror/kabuto-hardware-notes#bus-system
+2 cycles every 128

[ekeeke]

Yes, that's more or less the same way I initially tried to implement it but unfortunately this is not enough to fix Clue graphics issues without the aforementioned hack.

The two other games only need CPU execution to be shifted a little every lines/frames but Clue requires very accurate timings as the race condition window is very tight: the bug occurs if the CPU is running too fast but also if it is too slow. I think it only works correctly if the fixed ROM delays are accurately emulated (i.e only in case of access to cartridge/expansion area within the refresh cycle window) and if RAM delays are also accurately emulated (this one is more complex from what I observed on real hw as it seems to be a variable delay, between 0 and 3 cycles, depending how CPU access to RAM is aligned with the RAM refresh slot).

[Tippek]

I did noticed CPU still very fast in GPGX even with this refresh delay. http://gendev.spritesmind.net/forum/viewtopic.php?f=8&p=37391#p37391 - this tests on my MD1 Japan, so I guess it also need refresh delay for RAM (I guess about 3 cycles every 120 cycles), but don't sure its helps, because GPGX CPU very fast as I did said.

Is it fix correct? https://github.com/ekeeke/Genesis-Plus-GX/blob/master/core/vdp_ctrl.c#L2258
because it's not equal x*7

[ekeeke]

Is it fix correct? https://github.com/ekeeke/Genesis-Plus-GX/blob/master/core/vdp_ctrl.c#L2258
because it's not equal x*7

This is part of the hack mentionned in initial post to get Clue/Microcosm games working: indeed, these 2 games appear to have a big VRAM update (done with CPU writes instead of DMA as it should have been) interrupted by VINT, which screws the code register by updating VDP registers and make all the further writes to VRAM invalid when the interrupted routine continues its processing. Adding 2 M-cycles (less than one cpu cycle) on every invalid access was the minimal value I found to work in order to get sufficient delay but it is indeed not accurate at all (and does not happen on real hardware), as said above, this is hack (that I would like to get ride of by implementing accurate refresh delays).

[Silanda]

FWIW, Tippek's fix seems to alleviate a hitherto unreported issue with graphic corruption before the bonus stages in the PAL version of Art of Fighting, so it might be another game affected by this. Interestingly, neither the US version or the PAL version run in NTSC mode exhibit the problem.

Running with the CPU speed at 125% also stops the glitching.

[ekeeke]

Basic emulation of periodic 68K cartridge/expansion bus refresh delay added in 47761b9

Implementation is a little different from Tippek's original proposition as it gave one-cycle error for many instructions when running this test ROM: https://gendev.spritesmind.net/forum/viewtopic.php?f=8&t=3321 but otherwise it's very similar.

This also gives very close results to real hardware when running Sik's 68K benchmark test ROM (real hardware shows 88AD / 88AE)

Those two test ROMs are attached below for future references.
test_inst_speed.zip
68kbench.zip

As expected, this fixes libretro#205

https://bitbucket.org/eke/genesis-plus-gx/issues/444/crashes-in-pacman-2-new-adventures-pac-jr was actually fixed by 405c545

FIFO access delay timing hacks (previously required by Microcosm and Clue to compensate lack of 68k bus refresh delays emulation) were reverted in c04a942

Without the hacks, Microcosm still boots fine and Clue also in most cases, although the latter can still occasionally display corrupted tiles depending on when or how START button is pressed to access title screen (from experiment, it seems that holding START until title screen appears is always fine but repetitively smashing the START button can cause graphical issues to occur). It seems that additional RAM refresh delays are required to be safe so I leave this issue opened until this is properly implemented.