Is there any way to proper get accurate emulaton of "Reading 1 PPU clock before VBL should suppress setting" (i taked that from the blargg's test) having a NOT "cycle by cycle" cpu? i mean cycle info of instructions is well in my emulator. Is there difference between docs about the cycles of the opcodes? cos nesdev's 6502 docs seems to agree.
As long as your CPU keeps track of clocks, you can implement this. To implement it just check the time of a $2002 read and if it's one PPU clock before the VBL flag would be set, set an internal flag to suppress VBL being set for that frame.
thanks, now its fixed.
Other dumb question (maybe it should go in another topic) does spr dma takes 512 or 513 cpu cc?
if it needs 1 cycle to read and 1 cycle to write it would seem 512, but i have heard about 513.
yeah i know it could be said "why dont you change it to 513 and see what happens", the thing is im fighting with 3 or more cpu cycles and when i test both ways throw me different result, and diff. results change other things. and so on...
513 cycles, not counting the 4 cycles for the STA $4014 instruction.
Anes wrote:
does spr dma takes 512 or 513 cpu cc?
if it needs 1 cycle to read and 1 cycle to write it would seem 512, but i have heard about 513.
It takes 513. The extra cycle is apparently to wait for the CPU to finish the instruction properly before the DMA controller grabs the bus. These extra cycles are also why sample playback DMA takes four cycles instead of one.
thanks a lot