It is currently Mon Dec 11, 2017 8:30 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Wed Jul 22, 2015 3:34 am 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
Due my wrong (or old) implementation of sprite evaluation (thing i can note in Bee 52) i just need some help with sprite evaluation mechnism.

First the wiki says:

Code:
During each pixel clock (341 total per scanline), the PPU accesses OAM in the following pattern:
Cycles 1-64: Secondary OAM (32-byte buffer for current sprites on scanline) is initialized to $FF - attempting to read $2004 will return $FF. Internally, the clear operation is implemented by reading from the OAM and writing into the secondary OAM as usual, only a signal is active that makes the read always return $FF.


My doubt is in:

Code:
the clear operation is implemented by reading from the OAM and writing into the secondary OAM as usual, only a signal is active that makes the read always return $FF


As usual how?? What signal is active??

_________________
ANes


Top
 Profile  
 
PostPosted: Wed Jul 22, 2015 4:25 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
Hmm... Well, for my best, "signal" means "only reads work, write has no effect" during this period (cycles 1-64). Currently, a Famicom doesn't read $2004, as it never returns the contents of the sprite ram.


Top
 Profile  
 
PostPosted: Wed Jul 22, 2015 6:17 am 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
This wiki explanation it really confuses me more and more.

Code:
Cycles 65-256: Sprite evaluation
On odd cycles, data is read from (primary) OAM
On even cycles, data is written to secondary OAM (unless writes are inhibited, in which case it will read the value in secondary OAM instead)
1. Starting at n = 0, read a sprite's Y-coordinate (OAM[n][0], copying it to the next open slot in secondary OAM (unless 8 sprites have been found, in which case the write is ignored).
1a. If Y-coordinate is in range, copy remaining bytes of sprite data (OAM[n][1] thru OAM[n][3]) into secondary OAM.
2. Increment n
2a. If n has overflowed back to zero (all 64 sprites evaluated), go to 4
2b. If less than 8 sprites have been found, go to 1
2c. If exactly 8 sprites have been found, disable writes to secondary OAM. This causes sprites in back to drop out.
3. Starting at m = 0, evaluate OAM[n][m] as a Y-coordinate.
3a. If the value is in range, set the sprite overflow flag in $2002 and read the next 3 entries of OAM (incrementing 'm' after each byte and incrementing 'n' when 'm' overflows); if m = 3, increment n
3b. If the value is not in range, increment n and m (without carry). If n overflows to 0, go to 4; otherwise go to 3
The m increment is a hardware bug - if only n was incremented, the overflow flag would be set whenever more than 8 sprites were present on the same scanline, as expected.
4. Attempt (and fail) to copy OAM[n][0] into the next free slot in secondary OAM, and increment n (repeat until HBLANK is reached)


We have 256 - 65 cc = 192 cc to all this thing happen. It always get me confused.

_________________
ANes


Top
 Profile  
 
PostPosted: Wed Jul 22, 2015 6:52 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19326
Location: NE Indiana, USA (NTSC)
2 cycles per sprite plus 6 more per in-range sprite is guaranteed to be less than 192.


Top
 Profile  
 
PostPosted: Wed Jul 22, 2015 9:42 am 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
tepples wrote:
2 cycles per sprite plus 6 more per in-range sprite is guaranteed to be less than 192.


EDIT:

So much clear now, so it means that PRIMARY-> OAM[n][1], OAM[n][2] and OAM[n][3] are READ in ODD cycles and SECONDARY-> OAM[n][1], OAM[n][2] and OAM[n][3] are WRITTEN on EVEN cycles? I put it for claryfing things.

The other 2 cycles are for the OAM[n][0] evaluation??
I mean, i have an english missaunderstanding problem here with the Wiki when it says:

Code:
1. Starting at n = 0, read a sprite's Y-coordinate (OAM[n][0], copying it to the next open slot in secondary OAM (unless 8 sprites have been found, in which case the write is ignored).
   1a. If Y-coordinate is in range, copy remaining bytes of sprite data (OAM[n][1] thru OAM[n][3]) into secondary OAM.

Code:
"Copying it to the next open slot"

The "Y" copy can't be made to the SECONDARY buffer becouse it would be ready "to go" in a sprite unit. (Im confused about this)
AND are these the 2 cc you say for sprite Tepples??

_________________
ANes


Top
 Profile  
 
PostPosted: Wed Jul 22, 2015 9:25 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
1 cycle to fetch data from sprite RAM,
1 cycle to write data to secondary OAM.

In write mode, evaluate the Y value (+sprite zero hit).
If less than 8 sprites were found:
- if Y value is in range, write data & advance the pointer++;
else, skip the next 3 bytes (OAM+3).

Code:
         /* normal evaluation */
         else
         {
            //transfer data
            oam_secondary[oam_secondary_addr] = oam_read_buffer;
            if(oam_y_in_range)
            {
               oam_secondary_addr++;
               //transfer complete
               if( 0 == (oam_secondary_addr & 3) )
                  oam_y_in_range = 0;
            }
            else //skip the remaining bytes, move forward
               oam_addr += 3;
         }


Top
 Profile  
 
PostPosted: Thu Jul 23, 2015 1:15 am 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
OK, thanks for the help, im closer now to get more precise timing.

Blargg's Sprite Timing Test now throws me:

Code:
12)too late when 9th sprite # is way after 8th


I don't know what it means.

_________________
ANes


Top
 Profile  
 
PostPosted: Thu Jul 23, 2015 6:56 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
Probably $2002:$20 flag should be set earlier.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


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