This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

NES PPU Status Register Bits (need clarification please)

NES PPU Status Register Bits (need clarification please)
by on (#48351)
Before you go on reading please note that this is a very low level technical question. I am recreating the NES in hardware using pure Verilog HDL. I have a question regarding the PPU's status register bits.

From Brad Taylor's 2C02 Tech Ref:

Bit 5 - more than 8 objects on a single scanline have been detected in the last frame

Bit 6 - a primary object pixel has collided with a playfield pixel in the last frame

My question is, are both of these bits *really* just on a per frame basis (i.e. once the bits are set they remain set for the entire frame)?? I suppose I could believe the sprite 0 hit flag is on a per frame basis but the sprite overflow flag really seems like it should be on a per scanline basis...

I know someone out there can help!! :)

THANKS A LOT!!

by on (#48356)
Yes both flags are cleared at start of the frame, and when set they remain set. Altough many emulators (if not all ?) emulate the bit 5 in a completely wrong way, but since no games look at it it doesn't really matter.

Someone has coded ONE demo that says the grayscale mode if bit 5 is set, and the difference of results between the emulators were disastrous. Some emus considered 8 sprites as overflow, while some required 9 to set the bit (which I belive is correct). Some reset it every scanline, while some only reset it at the begining of the frame (which again I belive correct).

by on (#48360)
8 sprites can be overflow if you emulate the crazy logic where it uses the wrong address to look at Y position.
Re: NES PPU Status Register Bits (need clarification please)
by on (#48365)
- True, true. So, this thing:

Bit 5 - more than 8 objects on a single scanline have been detected in the last frame

would be changed to:

Bit 5 - more than 8 objects have been detected in the current frame

- Of course this is triggered in a certain scanline; in other words, AFAIK, there's no "frame scanning" for such overflow. Once it's set in scanline N, it remains set until VBlank ends.

EDIT: personally, the word "frame" is deprecated. I would use "time" instead.
Thanks!
by on (#48368)
Thanks a lot everyone! I really appreciate it. I will implement both as clearing at the beginning of a new frame!
Hmmm...
by on (#48369)
Bregalad wrote:
Altough many emulators (if not all ?) emulate the bit 5 in a completely wrong way, but since no games look at it it doesn't really matter.


Bregalad, am I reading this right? You're saying there are no games that even use bit 5?? That seems strange...
Re: NES PPU Status Register Bits (need clarification please)
by on (#48374)
Fx3 wrote:
Bit 5 - more than 8 objects on a single scanline have been detected in the last frame

would be changed to:

Bit 5 - more than 8 objects have been detected in the current frame

Not really... You can have 64 in the same frame and never trigger that bit... Just don't put 8 or more sharing the same scanlines! =)

Sprite rendering is scanline-based, so you can't get rid of the word "scanline". I see nothing wrong with the original description, except that 8 sprites can be enough to set the flag. This flag is too complicated to be explained in a single line of text.
Re: NES PPU Status Register Bits (need clarification please)
by on (#48378)
- You didn't read my last note, eh? :)
Fx3 wrote:
- Of course this is triggered in a certain scanline; in other words, AFAIK, there's no "frame scanning" for such overflow. Once it's set in scanline N, it remains set until VBlank ends.

by on (#48381)
Of course I read. I'm well aware that you know how things work, as apparently your emulator is quite accurate. I was just remarking on the fact that your sentence was a poor replacement for the other one, as it is even less clear.
Hey
by on (#48382)
Come on guys, we're all friends here. :)

Did anyone have an answer to my other question? Repeated below...

"Bregalad, am I reading this right? You're saying there are no games that even use PPU Status bit 5?? That seems strange..."

by on (#48384)
I'm not aware of any games that use that bit, but saying that no game ever uses it might not be correct without testing every single game (which is impossible). I don't think anyone here ever mentioned a game needing that flag, but that doesn't mean there isn't one.
Thanks!
by on (#48385)
Thanks so much guys!! You all rock! :)

By the way, I'm almost done with the initial rev of my HDL implementation. I need to iron out a few things with sprites before moving on though. Right now I have a bare minimum foundation support (i.e. sprite and background rendering with no mappers). I want to make sure what I have is absolutely *rock solid* first, then I will work on adding a few of the most common mappers, and then start on sound.

I will be posting pictures on my website of my progress soon. I am just doing this for hobby at home because I love this stuff!!! This is not for a college project or anything like that. I have no intentions of ever stopping work on this - I plan on just making it better and better and implementing as many mappers as possible. :)

Pz!!

by on (#48386)
Bee52 uses the sprite overflow bit for the status bar, iirc.

by on (#48387)
The NES doesn't have any mappers built in. It just accepts whatever the cartridge gives it.

I think the NOACs that hook directly to flash ROM do use a mapper.

by on (#48388)
- Verilog info. ^_^;;

- I really don't know a game that takes the sprite overflow bit into its engine. Sprite 0 collision is the most used AFAIK. Probably, it's required to create or manage the 8-sprites limitation. I know that a few Konami games use some OAM cycle through the sprites to avoid flickering.
RE: Mappers
by on (#48389)
Dwedit wrote:
The NES doesn't have any mappers built in. It just accepts whatever the cartridge gives it.


Oh yeah, I totally understand that. But they still need to be implemented in my HDL to allow other games to work properly. I have looked at the most common ones and they seem pretty straight forward and pretty well documented. Should be lots of fun! :)