nesdev.com
http://forums.nesdev.com/

Sprite DMA/DMC and irq_and_dma / RC Pro AM II
http://forums.nesdev.com/viewtopic.php?f=3&t=17620
Page 1 of 1

Author:  Zepper [ Thu Aug 02, 2018 7:13 pm ]
Post subject:  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.

Author:  zeroone [ Mon Aug 06, 2018 8:31 am ]
Post subject:  Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

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.


That is inconsistent with the wiki:

Quote:
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.


The check should happen on the first dot of the prerender scanline.

Author:  lidnariq [ Mon Aug 06, 2018 10:12 am ]
Post subject:  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.

Author:  zeroone [ Mon Aug 06, 2018 10:38 am ]
Post subject:  Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

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.


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?

Author:  tepples [ Mon Aug 06, 2018 10:44 am ]
Post subject:  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.

Author:  lidnariq [ Mon Aug 06, 2018 12:12 pm ]
Post subject:  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.

Author:  zeroone [ Mon Aug 06, 2018 2:26 pm ]
Post subject:  Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

lidnariq wrote:
but I'm surprised there's any way for the exact time the copy happens to matter.


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)?

Author:  Zepper [ Mon Aug 06, 2018 2:47 pm ]
Post subject:  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).

Author:  lidnariq [ Mon Aug 06, 2018 3:10 pm ]
Post subject:  Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

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)?
But it can't?

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"

Author:  Quietust [ Mon Aug 06, 2018 5:56 pm ]
Post subject:  Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

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.

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.

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).

Author:  zeroone [ Tue Aug 07, 2018 6:45 am ]
Post subject:  Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

lidnariq wrote:
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)?
But it can't?

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"


@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.

Author:  zeroone [ Tue Aug 07, 2018 9:17 am ]
Post subject:  Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

lidnariq wrote:
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)?
But it can't?

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"


Is this because OAM consists of DRAM that is refreshed during the pre-render scanline (and the other rendering scanlines)?

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.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/