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!!
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).
8 sprites can be overflow if you emulate the crazy logic where it uses the wrong address to look at Y position.
- 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 a lot everyone! I really appreciate it. I will implement both as clearing at the beginning of a new frame!
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...
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.
- 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.
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.
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..."
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 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!!
Bee52 uses the sprite overflow bit for the status bar, iirc.
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.
-
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.
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!