i have been reading wiki (again and again, and agai..) and the post asking for explanation of some things regarding wiki info on sprites (or what Q. discovered) and i simple dont get it. I mean..
- Cycles 64-255 : the numbers in the doc (1. 2a. 2b.) are actually cycles? i mean the number itself and not sub-number sections.
- Cyles 256-319: its clear but when the ppu fetches sprite data? i mean read pt data and those things.
i home someone clarify things to me.
I've been trying to connect to the wiki ever since I saw this post so I could refresh myself on how it's layed out, however I haven't been successful (is the server down?)
Anyway, from what I remember of the way that page is layed out, the numbers are NOT cycle numbers, but rather they're used to indicate the steps the PPU goes through. For example *I think* step 1 says something like "Fetch Y coord from OAM[n][0] and store in next available slot in secondary oam". That step would take 2 cycles (one for the fetch, and one for the write to secondary OAM).
Other steps will take longer -- for example I think there's a step on there that is "copy the next 3 bytes to secondary OAM" -- which of course would take 6 cycles (fetch, write x 3).
The numbers (1. 2a. 2b, etc) just indicate the steps. The PPU will jump to certain steps under certain conditions, which the wiki page lays out: "If exactly 8 sprites found, go to 3"... or "If more than 8 sprites found, go to 4" ... or stuff like that.
Disch wrote:
I've been trying to connect to the wiki ever since I saw this post so I could refresh myself on how it's layed out, however I haven't been successful (is the server down?)
Same problem here, and also with the Nintendulator website, so it seems that something's wrong with all of *.ath.cx...
The new wiki is nice, but it needs to be on a reliable and accessible server.
blargg wrote:
The new wiki is nice, but it needs to be on a reliable and accessible server.
Yeah, I get the idea. I've tried contacting the owner yesterday, but I couldn't get a hold of him. I'll try again tonight, so hopefully it'll be back online soon.
Disch wrote:
Other steps will take longer -- for example I think there's a step on there that is "copy the next 3 bytes to secondary OAM" -- which of course would take 6 cycles (fetch, write x 3).
May I ask how you guys are figuring out exactly what the NES PPU is doing for each clock cycle? The only way I can imagine is by changing everything on each clock cycle to try and determine when the PPU caches variables for internal calculations... and that sounds like it'd take a painfully long time to do.
byuu wrote:
May I ask how you guys are figuring out exactly what the NES PPU is doing for each clock cycle? The only way I can imagine is by changing everything on each clock cycle to try and determine when the PPU caches variables for internal calculations... and that sounds like it'd take a painfully long time to do.
That's what is done, and the process can be semi-automated. Imagine a loop that makes a delay of exactly n cycles after vblank, and then setting it for all values of n for n=10200 to 10541. Then run it on the NES at each value (shouldn't take longer than about 10 seconds), and make sure that the first value that switches to a different behavior is the same on the NES and on your emulator. Some effects are also visible outside the PPU, through the OAM data register and the like, or through a so-called "3-in-1" logic analyzer taking a sample of all PPU signals after each master clock tick.