BGB AND KIGB LINK CODE
some fun stuff meant to give people disassembling the code a headache (but that's outside the scope of this post) and eventually it will return with a success. (You could do something more interesting here to enforce absolute correctness of timings if you wanted.) Eventually it will reach a ret instruction at $3FFF and return to HRAM and do. If bus conflicts are emulated accurately, the CPU will read a bunch of $00 bytes from the OAM data stream.
If the value isn't $CD, a call to $3E04 is done. If it matches the actual value at that address, $CD, the test is marked as a failure. The protection works by initiating a OAM DMA from $3Fxx and then loading the data at address 3270. (Look at the page background from a shallow angle and you might see an easter egg.) Iirc, my check is more advanced than Furrtek's original check in Super Connard, since it jumps to inaccessible memory instead of just reading it and confirming the value. I added that in the dump I offer for download, for trolling purposes. Airaki doesn't actually have emulator detection originally. Thanks for your time, and your awesome tests, I will test the next one =D I wonder how the anti emulator protection works for "airaki" with this logic, since it's supposed to do a DMA and then jump to bank 0.
I'm guessing I don't have to lock all memory when there's a DMA, or maybe when a new instruction is fetch, it's supposed to bypass the DMA lock ?ĭarkMoe wrote:Wow, really ? I've been using BGB logic to lock everything, I will analyze it a little and fix it. If I adjust my OAM to take 4 more cycles (or 1 machine cycle), I get FF as the instruction (instead of E9), and since that's a restart to 0x38, the flow goes elsewhere and does nothing more. This is wrong, the expected value in the test is: E9 FF.
BGB AND KIGB LINK PC
When I reach PC = 0xFDFF, my DMA routine already finished and I read instruction as: E9 42, the 42 being the first byte on the OAM memory. My emulator, returns 0xFF for all the memory map (except high ram) when DMA is being done. So, I'm a little confused with it, the first test says it's expecting OAM to be locked for the argument parameter for instruction E9 (add sp,e), but not for the instruction reading phase (the E9 itself) Which fails on BGB, kigb, NefustoGB (my emu), but works perfect on higan (byuu always manage to emulate everything wow). I've been trying to fix edge case scenarios, so for starters, this test:
Fortunately, each day I manage to fix most of them, and today I think my compatibility ratio for commercial games is near 100%. Hi all, I've been trying to iron out some of the many bugs that my emulator still has.
0 kommentar(er)
