- Work RAM refresh timing seems to be a bit variable and the exact logic for the timing has been unclear
- The exact point when scroll values are latched from the internal scroll RAM when in full screen scroll mode is unknown
- Precise cause of a CPU lockup when configuring a 68K->VDP DMA and then performing a normal access instead is also unknown
- Certain details of sprite rendering that can show up in certain edge cases are also a bit unclear
- The function of some of the VDP debug registers is unknown
There's a lot more like that, but that hopefully gives you the gist. Nuked-MD-FPGA (and its C-based predecessor) will hopefully make a lot of those questions easier to answer since Verilog/C with a lot of unclear signal names is still a lot more easier to interpret than a die photo.
I looked but couldn't find much information on remaining games that still have emulation issues. This was about all I found: https://ares-emu.net/compatibility/21?status=3000
Last I looked into it, even Overdrive 2 was emulated pretty well...
> This was about all I found: https://ares-emu.net/compatibility/21?status=3000
IIRC this game shipped with broken EEPROM code so it's a bit unclear if this is actually emulated incorrectly. Ares is really in great shape these days
I do have a couple minor open compat bugs in BlastEm (my public issue tracker is sadly not up to date...), but I believe these are just normal bugs and not "we don't understand how this actually works" kind of things.
EDIT: > Last I looked into it, even Overdrive 2 was emulated pretty well...
Yes. In BlastEm there's a one-line glitch in one of the scenes I haven't managed to figure out. In Ares, there's a single effect that doesn't work (border dissolve after the "arcade" scene) and a 1-line glitch in the arcade scene. Both are only visible if you have overscan enabled.