Sprite DMA/DMC and irq_and_dma / RC Pro AM II

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Sprite DMA/DMC and irq_and_dma / RC Pro AM II

Post by Zepper »

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.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

Post by zeroone »

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:
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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

Post by lidnariq »

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.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

Post by zeroone »

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?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

Post by tepples »

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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

Post by lidnariq »

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.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

Post by zeroone »

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)?
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

Post by Zepper »

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).
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

Post by lidnariq »

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"
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

Post by Quietust »

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).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

Post by zeroone »

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.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Sprite DMA/DMC and irq_and_dma / RC Pro AM II

Post by zeroone »

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.
Post Reply