It is currently Sat Dec 16, 2017 9:30 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Fri May 06, 2016 4:09 pm 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 159
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?

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Top
 Profile  
 
PostPosted: Fri May 06, 2016 4:17 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
HihiDanni wrote:
The register docs [for reading the beam position] 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?

Yes.

Quote:
Is it stopping the counter

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.


Top
 Profile  
 
PostPosted: Fri May 06, 2016 5:25 pm 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 159
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.

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Last edited by HihiDanni on Sat May 07, 2016 2:52 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat May 07, 2016 2:05 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
> - 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.


Top
 Profile  
 
PostPosted: Sat May 07, 2016 2:50 pm 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 159
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:
Quote:
These values are latched by reading $2137 when bit 7 of $4201 is set, or by clearing-and-setting bit 7 of $4201 either by writing $4201 or by pin 6 of Controller Port 2 (the latch occurs on the 1->0 transition).

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Top
 Profile  
 
PostPosted: Wed May 18, 2016 9:43 am 
Offline
User avatar

Joined: Sun Jul 01, 2012 6:44 am
Posts: 337
Location: Lion's den :3
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:

Code:
   lda $213F            ; reset OPHCT/OPVCT flip-flops (is this necessary at all?)
   lda $2137            ; latch H/V counter
   lda $213D            ; read V-counter
   sta temp
   lda $213D
   ; sta /dev/null      ; discard upper 1 bit

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

What am I missing? :?:

_________________
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)


Top
 Profile  
 
PostPosted: Wed May 18, 2016 11:15 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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").


Top
 Profile  
 
PostPosted: Thu May 19, 2016 9:10 am 
Offline
User avatar

Joined: Sun Jul 01, 2012 6:44 am
Posts: 337
Location: Lion's den :3
koitsu wrote:
Try reversing your $213F and $2137 reads.

Thanks, koitsu, I actually got it to work. :D 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). :wink:

_________________
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)


Top
 Profile  
 
PostPosted: Fri May 20, 2016 7:01 am 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
"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...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [Bot] and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group