I disagree that things hit a wall, but there are a lot of smaller unknowns:
- 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.
Thanks so much for this. This is precisely the sort of nitty-gritty I was wondering about. I appreciate your time and your efforts in the emulation scene a lot.
To be clear, the stuff I posted about isn't generally important for running games. Getting the whole commercial game library running is a goal that was more or less passed a long time ago (excluding stuff that depends on obscure peripherals anyway). The things in that list are obstacles to approaching the platonic ideal of perfect emulation and are sometimes problems for things like verifying tool assisted speedruns or catching bugs in homebrew development.
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.
That is outstanding work. I can practically smell a physical MegaDrive burning somewhere every time I watch video of Overdrive 2 running on real hardware. My deepest respect and thanks for the work you've done on BlastEm!
Maybe but that's true for all systems (the last 1% of unknown are always the hardest and longest to figure) and Genesis emulation quality /hardware knowledge are certainly not behind other systems nowadays
- 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.