Hi Hi -- recently went back to putzing around on my emu after a long break. There are quite a few questions whose answers still escape me. Any help with any of them would be appreciated. ^^
1) Regarding reading $2007 during rendering -- I'm assuming you'll get the read buffer returned... but will the read buffer be re-filled with appropriate data? I'd assume not since the PPU is busy spending all of its time fetching bytes for rendering (or at least if it is eventually re-filled.. it won't be until rendering is complete). Also, I'd assume that reading $2007 at this time would muck up the PPU address and affect rendering, yes?
2) Similar question for $2007 writes during rendering. Do they go anywhere? Or are they lost? PPU address still changes, I'd assume.
3) Does $2003 have any significance other than interacting with $2004 and that weird sprite 0,1 quirk (see question #4)? Does $2003 have any impact on $4014? I've seen games write $01 to $2003, then DMA (or write $00 to $2003, write to $2004 incrementing $2003, then DMA) -- but the DMA still seems to start at OAM[0] instead of OAM[1]. Does $2003 affect rendering in any way (aside from the sprite 0,1 quirk)? Most importantly, can $2003 be changed during rendering?
4) More of a confirmation than a question -- but I've read that sprite data for sprites 0 and 1 are taken from %xxxxx000 (sprite 0) and %xxxxx100 (sprite 1), where xxxxx is the high 5 bits of $2003. A post on the boards says that information is in the wiki, but I didn't see it anywhere. Is my understanding correct?
5) Can $2004 be written to during rendering? I'd assume not since it can't even be properly read. Ditto for $4014 -- I'd assume that if you DMA during rendering, you'd still lose the 513 cycles, but OAM would not be changed (the writes would be lost). Is there any time where writing to $2004 won't increment $2003?
6) More of a confirmation: Regarding MMC5 ExRAM when $5104=00 or 01. ExRAM can only be written to via $5C00-5FFF during rendering? Writes during VBlank (or when PPU is off) are lost?
7) NMI seems to take a full PPU cycle to trip (or longer?), right? NMI occurs the cycle AFTER (or 2 cycles after?) $2002.7 goes high (assuming they're enabled). And when $2000.7 rises when $2002.7 is high, an NMI is fired at least a full PPU cycle later (leaving the CPU enough time to run one more instruction before being interrupted). Is that right?
8) Special MMC1 variants, specifically SUROM, need to be set to 8k CHR swap mode or have both CHR reg bits set properly or "bad things" will happen (PRG will be swapping on its own during rendering). I'd assume that this is caused by different CHR regs being used to select the PRG page at different times -- presumably by A12?
For example, say MMC1 reg1 is $00 and reg2 is $11 -- and assuming "normal" pattern table setup (BG uses left, all sprites use right pattern table). Would this mean that the first 256k would be swapped in during all of rendering except for when sprite tiles are being fetched (when it would quickly toggle between the first and second 256k 8 times)?
9) Last but certainly not least (in fact this is the most important question of all) -- I was having lots of 1-off errors in some test ROMs with my previous emu. I think my problem was due to a lack of clear understanding of WHEN (within the cycle) the writes actually take place.
For instance.. if the PPU is shut off via a $2001 write on PPU cycle 5 in a scanline... would the PPU be shut off before or after the 6th pixel is rendered?
Is it different for reads than it is for writes? If I read $2002 on the EXACT PPU cycle in which sprite 0 hits -- will I read that bit set? or will it not be read back as set until the next cycle?
That's all of them I think. Like I said any help at all would be greatly appreciated. Thanks in advance ^^
1) Regarding reading $2007 during rendering -- I'm assuming you'll get the read buffer returned... but will the read buffer be re-filled with appropriate data? I'd assume not since the PPU is busy spending all of its time fetching bytes for rendering (or at least if it is eventually re-filled.. it won't be until rendering is complete). Also, I'd assume that reading $2007 at this time would muck up the PPU address and affect rendering, yes?
2) Similar question for $2007 writes during rendering. Do they go anywhere? Or are they lost? PPU address still changes, I'd assume.
3) Does $2003 have any significance other than interacting with $2004 and that weird sprite 0,1 quirk (see question #4)? Does $2003 have any impact on $4014? I've seen games write $01 to $2003, then DMA (or write $00 to $2003, write to $2004 incrementing $2003, then DMA) -- but the DMA still seems to start at OAM[0] instead of OAM[1]. Does $2003 affect rendering in any way (aside from the sprite 0,1 quirk)? Most importantly, can $2003 be changed during rendering?
4) More of a confirmation than a question -- but I've read that sprite data for sprites 0 and 1 are taken from %xxxxx000 (sprite 0) and %xxxxx100 (sprite 1), where xxxxx is the high 5 bits of $2003. A post on the boards says that information is in the wiki, but I didn't see it anywhere. Is my understanding correct?
5) Can $2004 be written to during rendering? I'd assume not since it can't even be properly read. Ditto for $4014 -- I'd assume that if you DMA during rendering, you'd still lose the 513 cycles, but OAM would not be changed (the writes would be lost). Is there any time where writing to $2004 won't increment $2003?
6) More of a confirmation: Regarding MMC5 ExRAM when $5104=00 or 01. ExRAM can only be written to via $5C00-5FFF during rendering? Writes during VBlank (or when PPU is off) are lost?
7) NMI seems to take a full PPU cycle to trip (or longer?), right? NMI occurs the cycle AFTER (or 2 cycles after?) $2002.7 goes high (assuming they're enabled). And when $2000.7 rises when $2002.7 is high, an NMI is fired at least a full PPU cycle later (leaving the CPU enough time to run one more instruction before being interrupted). Is that right?
8) Special MMC1 variants, specifically SUROM, need to be set to 8k CHR swap mode or have both CHR reg bits set properly or "bad things" will happen (PRG will be swapping on its own during rendering). I'd assume that this is caused by different CHR regs being used to select the PRG page at different times -- presumably by A12?
For example, say MMC1 reg1 is $00 and reg2 is $11 -- and assuming "normal" pattern table setup (BG uses left, all sprites use right pattern table). Would this mean that the first 256k would be swapped in during all of rendering except for when sprite tiles are being fetched (when it would quickly toggle between the first and second 256k 8 times)?
9) Last but certainly not least (in fact this is the most important question of all) -- I was having lots of 1-off errors in some test ROMs with my previous emu. I think my problem was due to a lack of clear understanding of WHEN (within the cycle) the writes actually take place.
For instance.. if the PPU is shut off via a $2001 write on PPU cycle 5 in a scanline... would the PPU be shut off before or after the 6th pixel is rendered?
Is it different for reads than it is for writes? If I read $2002 on the EXACT PPU cycle in which sprite 0 hits -- will I read that bit set? or will it not be read back as set until the next cycle?
That's all of them I think. Like I said any help at all would be greatly appreciated. Thanks in advance ^^