Sprite evaluation timing clarification

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
wbrian
Posts: 10
Joined: Wed Feb 15, 2017 6:41 pm

Sprite evaluation timing clarification

Post by wbrian » Thu Apr 06, 2017 10:17 pm

I'm reading the wiki page on sprite timing here, and just wanted to clarify something quickly.
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)
Taking into consideration the note about odd/even cycles...
1a. If Y-coordinate is in range, copy remaining bytes of sprite data (OAM[n][1] thru OAM[n][3]) into secondary OAM.
Am I correct in interpreting this step as taking 6 PPU cycles, one for each read from primary oam and one for each write to secondary OAM?

More generally, all reads and all writes from primary OAM to secondary OAM occur on separate cycles during sprite evaluation?

User avatar
Quietust
Posts: 1488
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Sprite evaluation timing clarification

Post by Quietust » Fri Apr 07, 2017 5:05 am

wbrian wrote:
1a. If Y-coordinate is in range, copy remaining bytes of sprite data (OAM[n][1] thru OAM[n][3]) into secondary OAM.
Am I correct in interpreting this step as taking 6 PPU cycles, one for each read from primary oam and one for each write to secondary OAM?

More generally, all reads and all writes from primary OAM to secondary OAM occur on separate cycles during sprite evaluation?
Yes, to both questions.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

wbrian
Posts: 10
Joined: Wed Feb 15, 2017 6:41 pm

Re: Sprite evaluation timing clarification

Post by wbrian » Sun Apr 09, 2017 10:05 am

Much appreciated! One more thing I could use clarification on:
if eight in-range sprites have been found so far, the sprite evaluation logic continues to scan the primary OAM looking for one more in-range sprite to determine whether to set the sprite overflow flag.
Does this imply that once sprite overflow logic finds another sprite on the scanline, overflow evaluation stops and we continue to step 4 of sprite evaluation? For reference, step 4 is "Attempt (and fail) to copy OAM[n][0] into the next free slot in secondary OAM, and increment n (repeat until HBLANK is reached)."

Post Reply