BGnHOFS Register Assignment

Regarding the following from Anomie's regs.txt (same info exists in fullsnes.txt):
1) Can anyone explain to me that insane horizontal offset assignment? Why does it do this?? The vertical offset assignment makes perfect sense to me but what's up with the horizontal?

2) Assuming that 'Reg' refers to the current BGnHOFS register value that is being written to (although this isn't stated anywhere), the '((Reg>>8)&7)' part doesn't make any sense. The registers are only 10-bit. So if you right-shift by 8 then you only have 2 bits left. So doing a mask of the lower 3 bits (i.e. '&7') doesn't make any sense. Are you just supposed to set the upper bit to 0?

Some notes:
- 'Current' is the 8-bit value that's being written *right now* to the PPU by the CPU.
- 'Prev' is an 8-bit latch value storing the last 8-bit value written to any of these registers.
- Assuming that 'Reg' is the current value stored in the 10-bit BGnHOFS register. Not sure why he doesn't just use BGnHOFS instead of creating a new undefined term of 'Reg'.....??

Thanks!

nocash's documentation explains this a little better: http://problemkaputt.de/fullsnes.htm


In other words: the behaviour of $210d and $210e is multi-purpose depending on if you're in modes 0-6 or mode 7. For modes 0-6, they're 10-bit (range 0-1023) as described (I'm avoiding modes 5 and 6 :-) ). For mode 7, it's more complicated (see "SNES PPU Rotating/Scaling" right beneath that).

Do you need me to post pages from the official documentation that depict these registers' use on the actual screen? They're not particularly useful, but it is covered.

Yep, got it. So just keeping the discussion specific to registers $210F-$2114 I believe both of my original questions are still valid. Those registers are physically only 10-bit according to both docs. And I still don't understand why that assignment is so weird. There must be a reason behind it...well, we are talking SNES, so I suppose that's not necessarily true. But I don't even see how that assignment pattern is even supposed to work properly.

Okay, so this is more about 1) a complaint about the syntax of the documentation (the fields in question aren't described anywhere), and 2) why does the PPU internally operate that way (re: all the bitshifts and AND'd with a bitwise NOT of 7 (so %1000)). Yeah?

Yes that's it.

Although I wouldn't really say "complaint" about the syntax. It could be that the syntax is actually better than how I would describe it but I'm just not understanding something properly...?

To put question 1 more simply, why isn't the horizontal offset assignment just the exact same as the vertical offset assignment? Why do they even need to be different at all? It must be something to do with the graphics rendering that I either don't understand or haven't learned/seen yet.

I'm under the impression the "crazy formulas" shown only pertain to mode 7. But I can't be sure because of how the documentation is formatted.

If they apply universally to all modes, then my theory would be that the whole current vs. prev vs. written value (presumably Reg) thing is probably an effect of the PPU having some kind of latch buffering going on. Warning: I'm talking out my ass here a bit -- and as such I hope byuu or Revenant or lidnariq appear and correct me, honestly! -- but the NES PPU is very much like this. In fact, it's one of the things (once understood) that "revolutionised" NES emulation. There's a reason there's an enormous doc about it maintained by many of us.

I will say it's strange that the formula is (current*256) | (previous & %11111000) | ((regvalue/256) & %00000111). I'm kinda curious what those "magic 4 bits" are about.

Did you mean magic *3* bits? My total guess is that they have something to do with the fine horizontal scroll.

I'm definitely out of my depth, much as I appreciate koitsu's flattery
All I can really say is that bsnes-plus HEAD includes the following

This looks like it means you'll get odd (and unhelpful) behavior if you interleave writes to different registers.

The reason is due to internal latching. The low three bits of the horizontal offset are special and used for internal tile rendering/fetching. You can think of them as actually separate registers internally. Or not, I'm not your father :P

This matters. Try running Theme Park, it'll screw up if you don't do the horizontal scroll latching correctly. Stuff like this, it's best to just grit your teeth and implement it as we've described it :/

It's screwy, yes, but it's not nearly as bad as the NES' loopy_t/v stuff.

Me too, to be honest I tend to just defer to the bsnes/higan source code for stuff like this, since I don't have a huge amount of hands-on experience with the weird quirks of the SNES PPU.

I appreciate all the replies but I don't think either of my questions has actually been answered. Well, maybe a little...
I suppose this is an answer to question 1 but it's very vague. Any more details? The low 3 bits are definitely used for fine horizontal scrolling but I don't see how that relates to "internal latching". I'm trying to understand the purpose of the strange assignment pattern.

I wrote out a few examples by hand and it seems that the weird assignment behavior only makes a difference if you write to a BGnHOFS register only once instead of the required 2 times. If you always write to the register twice for both low and high bytes I don't believe there is any way that the final register value could contain anything other than what the user wrote. Am I wrong about that? Or is the weird assignment pattern only important for when/if a game writes to the BGnHOFS register once instead of twice?

For my second question I still don't see how this part of the assignment '((Reg>>8)&7)' makes any sense for a 10-bit register. It would make a lot more sense if it was '((Reg>>8)&3)'. Are you just always supposed to set the upper of the three bits to 0 since it's only a 10-bit register? I don't see higan source doing that though...

Additionally, Anomie's regs.txt states that the offset registers $210D-$2114 can only be written during F/V/H-blank (as denoted by the "ww+++-"). Is that actually true? Looking at higan source I don't see anything preventing them from being written whenever you want. Also, unless I made a silly goof, I just tried to set the registers to a non-zero value outside of F/H/V-blank and it worked just fine. I can see why you _shouldn't_ write to those registers outside of F/H/V-blank, but it does seem to be physically possible.

Anomie is conservative that way; as I heard it he doesn't declare something writable if he isn't sure.

You can indeed write to the scroll registers in the middle of active display. The PPU won't notice right away, but after a couple of slivers (in my experience) the new values will take effect. Air Strike Patrol does this, as does my shmup port.

You can change a number of things mid-scanline. Changing the VRAM locations of OBJ data via OBSEL works cleanly during active display, and won't produce any visible changes until the next line (HBlank seems to be a better time to change the size bits, if you must mess with them mid-frame). Changing BGMODE mid-line produces garbage in the BG layers for a short period, but ultimately works in all cases tried so far (that I'm aware of); just don't change to Mode 7 from something else mid-line as the init won't have been done and the results will not be as expected...

Best guesses:
The fine X scroll probably does something similar to how the NES PPU's fine X scroll is implemented using one output of a multiplexer. It may well be in an entirely different section of the IC, and it might have been easier to route the existing upper byte of the X scroll value instead of the FIFO.

By elimination, the X scroll registers have to be at least 11-bit, because when it's moved over into the fine X scroll the &4s bit isn't 0.

They're only the same if your write pattern is BGxHOFS BGxHOFS BGxVOFS BGxVOFS. If you were tempted to do something like BGxHOFS BGxVOFS BGxHOFS BGxVOFS you'd get something uphelpful.

OTOH, if I'm reading this right, you could also do something daft like BG4VOFS BG1VOFS BG4VOFS BG2VOFS BG4VOFS BG3VOFS and it would be usable... if obfuscatory. But you couldn't with the BGxHOFS registers.

But ... yeah ... viewtopic.php?p=183215#p183215

> I'm trying to understand the purpose of the strange assignment pattern.

I want to avoid speculation, but my opinion is that they're trying to reduce transistors infinitesimally through latching less bits of the BGnHOFS registers.

If you really want to know for sure why it's doing it, I'm afraid you'd need to analyze die scans.

Again, I'm sorry to say it, but opinions don't really matter. This is what it does, and it's what you have to emulate =(

By all means though, try to verify it, try to break the assumptions, maybe you'll find new edge cases we didn't know about, which can lead to making better sense of things.

> Additionally, Anomie's regs.txt states that the offset registers $210D-$2114 can only be written during F/V/H-blank (as denoted by the "ww+++-"). Is that actually true?

That's not true. Air Strike Patrol writes to the BG3dOFS registers during active display. It does it to show a hud on the left side of the screen, while rotationg the "player start" text on the same BG in the middle of the screen.

(obviously, use higan/accuracy if you want to see the effect. Other emulators don't animate the player start rotation effect.)

Don't forget: anomie quit the SNES scene without saying goodbye so he could go edit Wikipedia instead. He left a very long time ago, and his docs haven't been updated. I've learned a lot since then.

> Changing BGMODE mid-line produces garbage in the BG layers for a short period, but ultimately works in all cases tried so far

And I really need to stress that this is the most psychotic one of all. It completely breaks the idea of trying to have separate state machine paths for each BGMODE. You can't do that if you care about perfection.

I'm almost 100% certain that the bits of the BGnHOFS registers are actually split between the two chips that comprise the S-PPU: the low 3 bits are on PPU2, and the rest of the bits are on PPU1. VRAM addressing is controlled by PPU1, but the BG shift registers pretty much have to be on PPU2, because there's no data path to send rendered BG pixels between the two chips (there's only the 9 pins for sprite pixels). The low 3 bits of hscroll don't affect VRAM addressing, they affect which bit of the shift registers gets selected as output.

Oh, that would make the weird bit math much clearer.

It would mean the situation is something more nearly like:
new_coarse_nHOFS = (cur_write<<5) | (PPU1_HVOFS_LATCH>>3)
new_fine_nHOFS = PPU2_nHOFS_LATCH

Excellent insight as always, AWJ.

We're certainly not doing ourselves a lot of favors by trying to implement the logic of both the PPU1 and PPU2 into the same class, as if they're one chip :/

Might lack of register splitting be one cause of the "Super Famiclone" behavior of the post-2/1/3 revision?

Thanks everyone. This was very helpful. After AWJ mentioned about the 3 LSbits being only in PPU2 things made a lot more sense. I actually already knew that those bits were only in PPU2 but I wasn't connecting that with its effect on the register assignment. Cool stuff!
I just wanted to clarify on this...So you believe that all the scroll registers are 11-bit even though all the docs that I can find say they're 10-bit? It's not clear to me what purpose an 11-bit register would server. Only 10 bits are required for the maximum permissible scroll in any background configuration (I'm excluding $210D/E since those are also used for Mode 7).

From Anomie's regs.txt:
I think it would be very highly unlikely for Nintendo to insert a redundant flip-flop in the circuit design. A transistor saved is a penny earned.

I mean, it's "11" bits because there's a "redundant" 3-bit latch in PPU2 for each horizontal scroll register. Keeping track of D2 on the first write so that it can be transfered later. It's there to make the API not suck.

Total number of latches is apparently
13 bits per horizontal scroll: seven coarse, three fine, and three for a 1-deep FIFO for fine scroll
10 bits per vertical scroll
eight bits shared across all eight registers in PPU1 as a 1-deep FIFO