EMUya is my first cycle accurate emulator, as in it runs 3 pixels for each CPU clock precisely when it should in the CPU. As well as the PPU is implemented very precisely. However, surprisingly EMUya emulates the most inaccurately in comparison to my other emulators with regards to a couple MMC3 games & the scanline counter irq.
Specifically, the title screen on Kick Master wobbles a bit. The fact that the wobbling is different on every frame implies that they don't synchronize with the IRQ at all and that they instruction time it, or it could mean that each IRQ occurs at slightly different times due to the fact that IRQs can only occur in between 2 instructions, and not in the middle of a single instruction. However, the MMC3 IRQ does go off at regular intervals down the screen (haven't checked if its masked yet) - about once every 8 scanlines starting at scanline 4 IIRC. The wobbling goes away if I do the IRQ at dot 240 instead of 260 (but that messes up other games). That implies that there isn't enough time in between the IRQ trigger and when rendering starts for them to be able to execute instructions. Any ideas as to the cause? I was thinking because the difference is 20 dots or so (about the cycles of a IRQ), maybe my IRQ timing is off (however I pass all the tests).
Not sure if it helps or not, but it's at least relevant. In creating my own MMC3 in hardware I had similar issues until I got the CHR A12 filtering correct. IIRC, I found not allowing 2 scanline clocks within ~5CPU cycles to be accurate and remove 'wobbling' from all titles I tested.
I have the same problem with Kick Master.
infiniteneslives wrote:
Not sure if it helps or not, but it's at least relevant. In creating my own MMC3 in hardware I had similar issues until I got the CHR A12 filtering correct. IIRC, I found not allowing 2 scanline clocks within ~5CPU cycles to be accurate and remove 'wobbling' from all titles I tested.
I thought that might be the issue, so I hacked it to only occur on dot 260 to eliminate any possibilities there, still wobbles. =/
Well anyway. I'm going to spend a bunch of time looking at trace logs trying to figure out precisely what the code is trying to do, which should help me figure out what is wrong. I'll report back with my findings.
FCEUX jumps 30 dots on an IRQ.
It also looks their IRQ is delayed by 1 or 2 instructions.
Can you add some screenshots to the post? I don't quite understand the issue.
So, I'm not 100% sure why, but doing the MMC3 interrupt at dot 270 fixes all problems with every game I've tested thus far. The reason it works is It brings the timing in line with FCEUX. I'm still unsure why FCEUX has this additional delay in there.
I've never experienced the problem you have even tho my emulator generates IRQ at 260 pixel. So I think something wrong with CPU's IRQ processing or PPU's timings are not right. Does your emulator pass all blargg's cpu interrupt tests?
x0000 wrote:
I've never experienced the problem you have even tho my emulator generates IRQ at 260 pixel. So I think something wrong with CPU's IRQ processing or PPU's timings are not right. Does your emulator pass all blargg's cpu interrupt tests?
Last time I checked, yup. I'll check again.
I pass all CLI/instruction timing tests. I do not pass all of the VBL/NMI timing tests. However, I think the CLI tests would be the most important ones here in terms of what needs to be correct. So my question still stands on why does FCEUX have this additional delay that games expect.
I don't implement any kind of delay, aside from emulating the irq flag polling accurately. And this game does not shake or wobble at all.
beannaich wrote:
I don't implement any kind of delay, aside from emulating the irq flag polling accurately. And this game does not shake or wobble at all.
oh I agree, its probably a problem with my emulator somehow, just not sure exactly what, and why FCEUX has a 10 dot delay.
Zelex wrote:
oh I agree, its probably a problem with my emulator somehow, just not sure exactly what, and why FCEUX has a 10 dot delay.
Since when is FCEUX the gold standard for accuracy? I thought it was the "Speed at all costs" emulator.
Zelex wrote:
I pass all CLI/instruction timing tests. I do not pass all of the VBL/NMI timing tests. However, I think the CLI tests would be the most important ones here in terms of what needs to be correct. So my question still stands on why does FCEUX have this additional delay that games expect.
What about blargg's
MMC3 IRQ test? That's really what your having issues with...
When I dork around with my NMI timing I can get this issue to surface. I can even get it to pass blargg's timing tests and screw up on this game.
infiniteneslives wrote:
Zelex wrote:
I pass all CLI/instruction timing tests. I do not pass all of the VBL/NMI timing tests. However, I think the CLI tests would be the most important ones here in terms of what needs to be correct. So my question still stands on why does FCEUX have this additional delay that games expect.
What about blargg's
MMC3 IRQ test? That's really what your having issues with...
lol
doing it at dot 270, and I pass the MMC3 timing tests.
I pass everything except 5. (as I don't detect Rev A, and am unsure how to exactly)
beannaich wrote:
When I dork around with my NMI timing I can get this issue to surface. I can even get it to pass blargg's timing tests and screw up on this game.
Sounds like a good idea. I'll give it a shot and make sure my NMI timing is perfect.
Regarding detected the MMC3A vs MMC3B, I think you need to resort to CRC32 checks. There is no information in the iNES header which allows differentiation of the two
For actual games, I think you can just assume the new behavior (0 = 1 line per IRQ). Are there games that depend on the old behavior (0 = disable)?
As I said, I have the exact same problem, but with a twist: my emu passes in ALL test suites (MMC3, PPU INTs etc).
blargg's test suite (mmc3) only checks IRQs at cycle 259 (counting from zero) for the IRQ default setting (bg at PPU $0000 and SPR at $1000). The test should check for any other A12 raising at every 4th cycle.
I didn't any deep analysis for this game, but will do very soon.
EDIT: it's strange. If you clock the IRQ before the PPU, the title screen stabilizes, but obviously blargg' scanline test gives errors.