What the heck does "latch" mean?

I started writing a DMA manager and I think it'd be useful to know just how far into (or past) VBlank I am after all the DMA stuff has been completed. So it'd be cool if I could just grab the vertical scanline counter. The register docs mention something about setting the appropriate IOBit and then accessing a register to "latch" the counter.

What exactly does "latch" mean? Is it just taking a snapshot of this counter? Is it stopping the counter so that I have to unlatch it or the universe will explode?? And what side-effects are there, if any?

Yes.


No.

The reason it's connected to IOBit in the first place is because it shares hardware with the circuit that processes the signal from the Super Scope and Justifier light guns.

Alright, that's pretty simple then. Thanks! Gonna add a couple things in case anyone stumbles across this thread looking for info, because we could always use more SNES documentation:

- If you use initsnes.asm, register $4201 is initialized to #$ff, so when latching the counter you should clear and then set bit 7 so it's safe to ignore this register when latching, since it's already the right value.
- The register docs mention that bits 1 through 7 of the high byte are open bus, so remember to "and #$01" after the second read before you store.

> - If you use initsnes.asm, register $4201 is initialized to #$ff, so when latching the counter you should clear and then set bit 7.

It's easier to just read $2137 to latch the counters. But if $4201.d7 is clear, then that won't work, so leave it set.

Hmm, looks like you're right. I removed the instructions dealing with $4201 and it continued to work. For once, it seems like the available documentation has made me overly cautious!

Edit: Seems like it was just written confusingly:

I'm messing around with the H/V counter latches as well right now, but I can't for the life of me get them to do what I want.

WRIO ($4201) is initialized to $FF and shortly after set to $C0, so bit 7 is kept set.

Still, when I do this:


... it writes some garbage to my temp variable instead of the expected V-counter value.

What am I missing?

Try reversing your $213F and $2137 reads. See page 2-11-1 or Chapter 11 in the official developers manual. I've never used these registers so I have no idea how to confirm or document the proper behaviour. (I know, there's confusing/borderline conflicting information scattered around the manual with regards to $2137/213C/213D/213F)

How $4201 fits into this is a bit strange (to me), since based on what's in the documentation (or how I interpret it), that means you're setting $4201 to $C0 (%11000000), which means a read of $4213 should return data in bit 7 and bit 6. (Also note that the manual says things like "refer to page 1-27-23" -- these are mistakes, they meant 2-xx-xx).

If my memory serves me right (I could be wrong!), in the early snesdev days, Gau (a guy I worked on the Super Kid Icarus project with) wrote a fairly lengthy/clear document on how these registers work, specifically for the MultiTap. The best I can find right now is (see "Controller Ports"): http://wiki.superfamicom.org/snes/show/ ... nd+Pinouts and http://problemkaputt.de/fullsnes.htm#snesiomap (see "SNES Controllers Multiplayer 5 (MP5) (Five Player Adaptor)", though there are several other sections discussing it, including "SNES PPU Timers and Status").

Thanks, koitsu, I actually got it to work. There were no less than three issues to overcome though:

1. Read $2137 before $213F (doing it in reverse order still latches the H/V counter, but yields slightly different results)
2. Time the $213C/D reads correctly (more on that below)
3. Track down and squat a well-hidden bug that affected WRIO ($4201)

Phew!

In my particular case, the goal is to implement some sort of CPU load display that shows what scanline it's on when all active-display calculations have finished. At first (and even after issue #3 had been resolved), I always got a value around 249 for the lower 8 bits of $213D. Turned out that my NMI routine finished at scanline ~243, and everything else took about 5 to 6 scanlines. IOW, to get a meaningful value, you have to compensate for the time difference between RTI and scanline ~261, e.g. by waiting until the Vblank flag in HVBJOY/$4212 clears so your routines are sure to execute around scanline 0.

Anyway, I'm glad to finally have proof that it's my CalcMode7Matrix routine causes slowdowns on the Mode 7 map screen, just as I'd suspected (sigh).

"Latch" makes more sense when you approach it from a circuitry perspective, where you aren't yet into the "only things on clock edge" matter perspective. It means a flip-flop (basically a one-bit memory component), and it means to store/lock-ini the data (latch) it into said flip-flop. The trigger doesn't have to be an oscillator/clock, so...