Hey look buddy, I'm an engineer. That means I solve problems. Not problems like "What is software," because that would fall within the purview of your conundrums of philosophy. I solve practical problems. For instance, how am I gonna stop some high-wattage thread-ripping monster of a CPU dead in its tracks? The answer: use code. And if that don't work? Use more code.
A new GBA emulator with a focus on hyperaccuracy? Hell yeah. I actually found out about this by checking the Emulation General Wiki's article on GBA accuracy tests, since a friend of mine is working on a Fire Emblem 8 hack and the community's guide to hacking on the decomp suggests using Nocash, which dates it. (Also, hi. I'm surprised I didn't already have an account here.)
Wow, GBAHawk participates in GBA tests on gametechwiki! https://emulation.gametechwiki.com/index.php/GBA_Tests Looks awesome. I didn't expect to see Mesen there, I thought it was just a NES emulator. CasualPokePlayer made some tests, wow! Good luck, Alyosha! I keep reading your posts
The basic problem was that while I had previously found that IRQ clocking is delayed during DMA, this is not the case for internal CPU cycles, which would seem to be obvious given that they still run while DMA is running but I still somehow got it wrong. I need to do some more testing before I commit the fix to make sure I don't break anything else and have all the edge cases correct, but the basic idea is there.
Unfortunately, even with this the original test still fails by 235 cycles. So now I need to basically repeat the entire process with the prefetcher enabled. But making progress though!
The final issue was with prefetcher behavior at ROM 0x20000 boundaries. I previously thought what happens is that the prefetcher stops and behaves as though it is full. But what actually happens is that the prefetcher continues to try and read from the boundary address, but always fails, thus the prefetcher address never advances. This distinction is important because if the prefetcher is one cycle away from finishing a read (even a failed attempt as here) it will hold the bus from other accesses to complete. This can occasionally add 1 cycle delays to whatever is trying to read ROM. Fixing this brought total count to the correct value. This is done in the current dev build.
I uploaded several tests to the repo that test this.
Now that this is done I'll put together an official release, after I do some regression testing.
There are still a bunch of smaller issues to deal with, but most of them are comparatively simple. The biggest remaining mystery is why that Snood run crashes on hardware.
Unless something comes up in console verification, I don't really have any motivation to endlessly test edge cases and weird interactions. Fixing Cirotemark was the capstone for me.
Yes, standard runs are needed and very appreciated here too
Me and the boys starting over our games of choice for the infinityieth time in a row because of just-found optimizations
The fight against Cirotemark is over and I am finally at the correct cycle count:
Congrats on beating it! I never thought anyone would be able to pass it :) However, there's still some missing scanlines when rendering the 3D pink train. Not sure if you try to be as accurate with the PPU as you are with the CPU, but well xD
Out of curiosity, did you do anything to purposefully make the test mode difficult, or did it just end up that way by virtue of all the complicated effects you used?
This test changes x-scroll mid-scanline, inside the red circles. It turns out that this test isn't quite right compared to hardware. Unfortunately, fixing this needs a significant overhaul of the pipeline code. I don't have the time at the moment to focus on a more complicated task such as this, so it will have to stay broken for now.
