It is currently Sat Dec 16, 2017 8:12 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: sprite evaluation issues
PostPosted: Fri Jul 07, 2017 3:56 pm 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
Hi, i have some problems with sprite evaluation. It never was fine in my emulator so here i go with my first question:

the wiki states:

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


Can somebody explain me this?? Why reading from $2004 will return $FF? i Tought that reding from $2004 returned from the OAM (not the secondary one).

Anyway as you can see i'm confused and sometimes my english is in a fault.

_________________
ANes


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 4:26 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19348
Location: NE Indiana, USA (NTSC)
When rendering is in progress, reading $2004 returns what in OAM the PPU itself is looking at. And during x=1 through 64, that's secondary OAM.


Top
 Profile  
 
PostPosted: Fri Jul 07, 2017 4:30 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
tepples wrote:
When rendering is in progress, reading $2004 returns what in OAM the PPU itself is looking at. And during x=1 through 64, that's secondary OAM.

And when rendering is disabled, reading $2004 returns OAM[spriteaddr]. Is this correct?


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 11:38 am 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
I really don't get it, please help, what does this mean?

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

_________________
ANes


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 11:40 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
Anes wrote:
I really don't get it, please help, what does this mean?

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

It means that it reads $FF and then writes it to secondary OAM. Why it reads $FF makes no difference to emulator authors.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 11:46 am 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
Thanks Quietust, i'll be posting more questions sure.

_________________
ANes


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 11:51 am 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
The Wiki states:
Quote:
Cycles 65-256: Sprite evaluation
On odd cycles, data is read from (primary) OAM
On even cycles, data is written to secondary OAM (unless secondary OAM is full, 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.


Does it take 2 cycles reading Y coordinate and THEN copying it in SECONDARY OAM?

So, if it's IN RANGE does it take 6 CYCLES more to copy remaining data?

_________________
ANes


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 12:24 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
Anes wrote:
Does it take 2 cycles reading Y coordinate and THEN copying it in SECONDARY OAM?
So, if it's IN RANGE does it take 6 CYCLES more to copy remaining data?


If the sprite is in range, it takes a total of 8 cycles, otherwise it takes only 2 cycles.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 12:27 pm 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
thanks!!

_________________
ANes


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 2:16 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
Plz?
Quote:
And when rendering is disabled, reading $2004 returns OAM[spriteaddr]. Is this correct?


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 2:57 pm 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
Please answer to Zepper!! :D

Now i have a doubt here:

The Wiki states:

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


When reading the next 3 entries of OAM is it done in odd cycles so it takes 6 cycles??

_________________
ANes


Top
 Profile  
 
PostPosted: Sat Jul 08, 2017 5:49 pm 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
Well all Blargg's test passed, but the timing throws me #2 "cleared too early at the end of vblank".

Should i care for that?

_________________
ANes


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: MLX 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