namuol / boyziigame Goto Github PK

Most of the mooneye tests fail.

I suspect that many of them fail due to the lack of cycle-accuracy baked into our emulator. For instance, DMA operations occur in parallel with CPU operation, so a write that should happen a few cycles after an instruction is fetched will lead to the data being incorrect.

These fail because our CPU implementation performs all its reads within a single call to cpu.cycle(), and then keeps track of how many cycles it needs to wait before the next instruction is fetched and executed.

In order to fix these kinds of issues, we need to ensure that reads/writes actually occur on the appropriate cycle, such that the calls to e.g. ppu.cycle() will allow DMA to read/write values at the exact right cycle time.

There are many ways to achieve this, but if I understand the problem correctly, we may be able to solve this without major refactoring since the problem is isolated to bus access. This means we may be able to allow the bus to ultimately dictate timing for the various devices that communicate with it, essentially allowing the bus to say how many cycles should run for each device whenever reads/writes happen, and the rest would be indirectly driven by the CPU instructions.

Concretely, this would mean that special calls to e.g. bus.read() would actually advance devices on the bus four machine cycles (usually, I think). This may mean that we'd want to get rid of the cpu.cycle() function and instead have something like cpu.step() always advance to the next instruction, with all other devices being driven by the bus.

This sounds relatively simple but could be tricky to get right... probably worthy of a feature branch to try it out and see if we can get a few of these tests to pass.