nesdev.com

Do we now need to wire up a set of caps representing the CPU data bus, in the same way that the PPU's data bus for CPU communication has the _io_db lines that act as dynamic latches?

Thanks for letting me know about the typo - it's fixed.

Like tepples implied, the data bus' behavior is not part of the simulation (the RAM/VRAM isn't part of the simulation, for example, so these are emulated on a higher level), and their behavior is potentially incorrect.

As far as I can tell, it seems to be writing $00, not $FF ($FF is the bus' value in the first half of the clock, but this switches to $00 when the write is performed (which occurs when cpu_clk0 goes low) - this seems to be the same on the 2A03, though. Like you said, this should probably be $80 - the top 3 bits on $4017 reads are always meant to return open bus behavior. Note that I am far from being qualified to analyze this - so don't assume anything I just said is actually true. :)

That's ... weird.

During a write, the data bus should be stable for the entire time that the address bus is unchanging, i.e. both φ1 and φ0≈φ2≈M2

Unless maybe you're tickling problems with hold times ?

Thanks, that's good to know, and probably explains why I wasn't able to get the PPU writes working without a bit of a hack. The data bus is $FF for 6 master clocks and then switches to $00 for the last 6 clocks. But I just checked on the Visual 2A03 and it seems to keep the bus to $00 for the entire cycle in this case, like you said. This could be an issue with how the CPU/PPU are connected in the simulation, or some other bug in my code, I'll take a look when I get a chance.

I tried reading 0x2002 around the time when the nmi flag gets set (241.001). Below is the "read from address" cycle of LDA 0x2002... wasn't sure how to present the results, but maybe you guys'll understand.


I had expected the last case to also block the nmi, that's what the wiki says I think. Unsure how much clock alignment does here, but that can't be changed in visual nes as far as i know.


Edit:
Brief test of sprite overflow clearing (261.001):


With dot 1 barely in on this cycle, it still manages to clear sprite overflow and return a 0 in bit 5. That should mean that if dot 1 is where 340 or 0 is in that diagram, overflow will also be seen as cleared. Haven't tested any other timing, though.