It is currently Sat Apr 20, 2019 11:19 am

 All times are UTC - 7 hours

 Page 1 of 1 [ 5 posts ]
 Print view Previous topic | Next topic
Author Message
 Post subject: Sprite evaluation timingPosted: Tue Sep 11, 2018 9:03 am

Joined: Mon Aug 20, 2018 1:23 am
Posts: 4
I'm trying to figure out a good way of programming the PPU sprite evaluation state machine, but the nesdev page is a little unclear to me.
Quote:
n 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.

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 because it is full. This causes sprites in back to drop out.

Does 1 and 2 happen on the same cycle ?

Top

 Post subject: Re: Sprite evaluation timingPosted: Tue Sep 11, 2018 7:36 pm
 Formerly Fx3

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3182
Location: Brazil
I'm still rewriting my sprite evaluation logic, but I have a few notes. Hope it helps.

1. The sprite evaluation starts at PPU cycle 65. On odd cycles, data is read from primary OAM (sprite ram). On even cycles, the buffered data is written to the secondary OAM (32 bytes long).
2. Steps 1 and 2 refer to the normal evaluation. Step 3 is the weird evaluation, and step 4 is when less than 8 sprites are found in the current scanline.
3. 'n' scans through the primary OAM. If 'n'=64, then 'n' warps to 0. Go to step 4. It may be less than 8 sprites in the OAM secondary buffer though. No weird evaluation happens here.
4. If the secondary OAM is full, the weird evaluation starts! If 'n'=64, then 'n' warps to 0. Step 4 now takes place.
zzzz898 wrote:
Does 1 and 2 happen on the same cycle ?

Nope. Data must be read, then written to the secondary OAM. Next, it's checked if the buffer's full (8 sprites found).

Top

 Post subject: Re: Sprite evaluation timingPosted: Thu Oct 04, 2018 12:09 am

Joined: Mon Aug 20, 2018 1:23 am
Posts: 4
Well, now I'm confused. The way I had it setup didn't work (step 1 and step 2 happen on different cycles):
1. fetch data from OAM
2. step 1 - sprite not in range
3. fetch data from OAM
3. step 2 - go back to step 1

There is no way you can scan through 64 different sprites, if 1 of them takes 4 cycles, right ?

The way I have it now works better, it looks like this:
1. fetch data from OAM
2. step 1 - sprite not in range, decide to go to step 1 (step 1 and 2 happen on the same cycle, this is what I meant <<)
3. fetch data from OAM
4. and so on...

Top

 Post subject: Re: Sprite evaluation timingPosted: Thu Oct 04, 2018 5:49 am

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21311
Location: NE Indiana, USA (NTSC)
1-2. read Y, calculate LY - Y, and compare to the current sprite size
3-8. if LY - Y in range, read tile, attributes, X

64 times of 1-2 (128 dots) and 8 times of 3-8 (48 dots) will fit into the 192 dots of picture between secondary OAM clearing (1-64) and hblank (257+).

_________________
Pin Eight | Twitter | GitHub | Patreon

Top

 Post subject: Re: Sprite evaluation timingPosted: Sun Oct 07, 2018 9:37 am

Joined: Mon Aug 20, 2018 1:23 am
Posts: 4
Yes, that's what I meant, thanks

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 1 of 1 [ 5 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 forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki