Sprite DMA/DMC and irq_and_dma / RC Pro AM II
Moderator: Moderators
Sprite DMA/DMC and irq_and_dma / RC Pro AM II
Just to let you know that I've fixed the problems in my emulator with sprite DMA and DMC DMA, plus irq_and_dma tests.
About RC Pro AM-II, the copy of 8 bytes from &sprite[sprite_addr&0xF8] to &sprite[0] should occur around PPU cycle 115 of the pre-render scanline, instead of cycle zero. Tatakai no Banka works too.
About RC Pro AM-II, the copy of 8 bytes from &sprite[sprite_addr&0xF8] to &sprite[0] should occur around PPU cycle 115 of the pre-render scanline, instead of cycle zero. Tatakai no Banka works too.
Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II
That is inconsistent with the wiki:Zepper wrote:Just to let you know that I've fixed the problems in my emulator with sprite DMA and DMC DMA, plus irq_and_dma tests.
About RC Pro AM-II, the copy of 8 bytes from &sprite[sprite_addr&0xF8] to &sprite[0] should occur around PPU cycle 115 of the pre-render scanline, instead of cycle zero. Tatakai no Banka works too.
The check should happen on the first dot of the prerender scanline.If the sprite address (OAMADDR, $2003) is not zero at the beginning of the pre-render scanline, on the 2C02 an OAM hardware refresh bug will cause the first 8 bytes of OAM to be overwritten by the 8 bytes beginning at OAMADDR & $F8 before sprite evaluation begins.
Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II
I believe I'm the person who added that text to the wiki. We don't know the exact time the copy happens: my text was just meant that "no lines will display the original contents of OAM before it is corrupted", but I'm surprised there's any way for the exact time the copy happens to matter.
Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II
Can we work out the exact time using a test ROM? Also, how long does it take to copy the data? Or is the "copy" really some form of mirror that happens instantly?lidnariq wrote:I believe I'm the person who added that text to the wiki. We don't know the exact time the copy happens: my text was just meant that "no lines will display the original contents of OAM before it is corrupted", but I'm surprised there's any way for the exact time the copy happens to matter.
Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II
I'd assume instantaneous, based on what I know about the hardware implementation of OAM. Each word of OAM is 8 bytes.* The DRAM controller reads or writes an entire word at a time during one dot. So I assume it's writing out the word that it most recently read or wrote (and refreshed), but it's writing it out to the first word instead of the word where it was originally read.
* Minus the 6 bits corresponding to the 3 unused bits of attribute 2 of two OAM entries.
* Minus the 6 bits corresponding to the 3 unused bits of attribute 2 of two OAM entries.
Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II
Since the DRAM (32x66 bits) inside the 2C02 is 8 bits wide, I'm really not certain how the copy happens: all 8 bytes can't be simultaneous.
Looking at visual2c02, the only idea that occurs is that somehow two different spr_row signals are asserted in sequence (one being the one corresponding to the value OAM_ADDR was left at, the other being spr_row0) without a chance for pclk0 to pre-charge the analog multiplexers in-between.
It could possibly be the very first 8 cycles, I guess.
Looking at visual2c02, the only idea that occurs is that somehow two different spr_row signals are asserted in sequence (one being the one corresponding to the value OAM_ADDR was left at, the other being spr_row0) without a chance for pclk0 to pre-charge the analog multiplexers in-between.
It could possibly be the very first 8 cycles, I guess.
Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II
If the game were manipulating OAM just prior to the copy or just after the copy, wouldn't the exact time matter (like everything else)?lidnariq wrote:but I'm surprised there's any way for the exact time the copy happens to matter.
Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II
If I'm not mistaken, the text on the wiki takes the sprite evaluation occurring/starting at the pre-render scanline. Later, we've found that it does NOT occur. I had this problem in my emulator since version 5.20 (currently at 5.4x).
Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II
But it can't?zeroone wrote:If the game were manipulating OAM just prior to the copy or just after the copy, wouldn't the exact time matter (like everything else)?
Once OAM evaluation starts, the $2003/2004 interface is largely unusable by the CPU. And I'm pretty certain the erroneous copy is some part of OAM evaluation starting "incorrectly"
Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II
From what I understand, that's pretty much what causes it - asserting a row signal while the bus is not precharged can cause a bit to be overwritten with whatever value was left on the bus, especially if the value has decayed significantly. Not surprisingly, this is quite likely to happen when you write to $2003 (depending on CPU/PPU clock alignment) or when rendering starts, but it never happens with the auto-increment that happens when you write to $2004 or during normal rendering once it's started up.lidnariq wrote:Looking at visual2c02, the only idea that occurs is that somehow two different spr_row signals are asserted in sequence (one being the one corresponding to the value OAM_ADDR was left at, the other being spr_row0) without a chance for pclk0 to pre-charge the analog multiplexers in-between.
OAM corruption is actually quite easy to trigger in Visual 2C02 - it happens consistently if you write to $2003 while pclk0 is low (which happens with the default "test program" at halfcycle 274).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II
@Zepper Check if RC Pro AM II attempts to modify OAM during the pre-render scanline. Maybe RockNES permits OAM changes at times when OAM should be inaccessible. If you had to delay the copy until scanline cycle 115, then something else is wrong.lidnariq wrote:But it can't?zeroone wrote:If the game were manipulating OAM just prior to the copy or just after the copy, wouldn't the exact time matter (like everything else)?
Once OAM evaluation starts, the $2003/2004 interface is largely unusable by the CPU. And I'm pretty certain the erroneous copy is some part of OAM evaluation starting "incorrectly"
Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II
Is this because OAM consists of DRAM that is refreshed during the pre-render scanline (and the other rendering scanlines)?lidnariq wrote:But it can't?zeroone wrote:If the game were manipulating OAM just prior to the copy or just after the copy, wouldn't the exact time matter (like everything else)?
Once OAM evaluation starts, the $2003/2004 interface is largely unusable by the CPU. And I'm pretty certain the erroneous copy is some part of OAM evaluation starting "incorrectly"
I reviewed the logic in my own emulator and I can't find a specific check that disables OAM writes during rendering. However, I see that attempting to write to OAM during rendering appears to corrupt OAM. I haven't looked at this in quite a while though. I don't recall all the OAM insanity.