It is currently Tue Dec 18, 2018 4:27 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
PostPosted: Thu Aug 02, 2018 7:13 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3155
Location: Brazil
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.


Top
 Profile  
 
PostPosted: Mon Aug 06, 2018 8:31 am 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Mon Aug 06, 2018 10:12 am 
Offline

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


Top
 Profile  
 
PostPosted: Mon Aug 06, 2018 10:38 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 823
Location: New York, NY
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?


Top
 Profile  
 
PostPosted: Mon Aug 06, 2018 10:44 am 
Offline

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


Top
 Profile  
 
PostPosted: Mon Aug 06, 2018 12:12 pm 
Offline

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


Top
 Profile  
 
PostPosted: Mon Aug 06, 2018 2:26 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 823
Location: New York, NY
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)?


Top
 Profile  
 
PostPosted: Mon Aug 06, 2018 2:47 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3155
Location: Brazil
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).


Top
 Profile  
 
PostPosted: Mon Aug 06, 2018 3:10 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7845
Location: Seattle
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"


Top
 Profile  
 
PostPosted: Mon Aug 06, 2018 5:56 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1441
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.


Top
 Profile  
 
PostPosted: Tue Aug 07, 2018 6:45 am 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Tue Aug 07, 2018 9:17 am 
Offline
User avatar

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group