How to detect PAL or NTSC consoles?

[GroovyBee]

I like to make my games auto detect what TV system they are running on and adapt their timings/colours accordingly. Is this possible on the Inty? Is there a convenient EXEC memory location to read or even an EXECutive call to make?

[intvnut]

I like to make my games auto detect what TV system they are running on and adapt their timings/colours accordingly. Is this possible on the Inty? Is there a convenient EXEC memory location to read or even an EXECutive call to make?

 

None that I know of. Instead you have to make use of the fact that NTSC machines are slightly slower and PAL machines are slightly faster. (That also reminds me, I still need to add a --pal switch to jzIntv.)

 

NTSC machines have 60Hz refresh and a CPU clock of 3.579545 MHz / 4 = ~895kHz. PAL machines have a 50Hz refresh, and I believe a CPU clock of 4.0MHz / 4, or exactly 1MHz. I used the following code in my Synth demo to detect PAL vs. NTSC, although I admit I haven't tried it yet on a PAL machine:

 

;; ======================================================================== ;;
;;  NTSC_PAL1   \_ Autodetect NTSC vs. PAL by counting cycles between       ;;
;;  NTSC_PAL2   /  interrupts.  NTSC is approx 14932; PAL is approx 20000.  ;;
;; ======================================================================== ;;
NTSC_PAL1   PROC
           SETISR  NTSC_PAL2,  R0
           EIS

           CLRR    R2
@@loop:     INCR    R2              ; \_ 15 cycles
           B       @@loop          ; /

           ENDP

NTSC_PAL2   PROC
           SUBI    #8,         SP
          
           ; NTSC should go around a little under 995 times;
           ; PAL should go around a little under 1333 times.
           ; Midpoint is 1164.  Above that, it's PAL, below is NTSC.
           CMPI    #1164,      R2
           BLT     @@ntsc

           MVII    #2,         R2
           B       @@common

@@ntsc      MVII    #1,         R2
@@common:   MVO     R2,         NTSC_PAL

           SETISR  ISR,        R0
           B       ISRRET
           ENDP

 

(Notes: SETISR is a macro that just moves the requested label into $100/$101. ISRRET is $1014.)

 

So, what I do is have my "INIT_ISR" do is set NTSC_PAL1 as the next ISR. In my main (non-interrupt) code, I spin until I see NTSC_PAL become non-zero to know I'm done with initialization.

[GroovyBee]

I'd thought of that way too but I was hoping that there might be a known value in the EXECutive ROM. When I get my CC3 I'll difference the EXECutives and then maybe we can accumulate some known data about each variant.

[intvnut]

I'd thought of that way too but I was hoping that there might be a known value in the EXECutive ROM. When I get my CC3 I'll difference the EXECutives and then maybe we can accumulate some known data about each variant.

 

So far as I know (and I believe a couple have tested for me) the EXECs are identical between the NTSC and PAL versions. It also doesn't seem to have any detect code to determine which system it is. All the Mattel games that relied on the EXEC just ran more slowly (and played notes a couple steps sharp) on PAL and did nothing to compensate.

 

You may have better luck seeing if some STIC register (or an unimplemented register in the $00 - $3F range) behaves differently between PAL and NTSC. The STIC is pretty much the main thing different between PAL and NTSC Intys.

[OldAtarian]

Are there PAL and NTSC INTV consoles? I thought all INTV cartridges worked in all INTV consoles.

[intvnut]

Are there PAL and NTSC INTV consoles? I thought all INTV cartridges worked in all INTV consoles.

 

Yes, there are PAL and SECAM units in addition to NTSC (and whatever Japan used for the Bandai units).

 

Because the STIC handles all the video generation, you do get much better software compatibility than you do on a system where the software is responsible for figuring out how many scanlines to send. *cough*2600*cough*

 

The main difference between the two Intellivisions: PAL/SECAM have a 50Hz refresh (and therefore 50Hz retrace interrupt), and the CPU runs at 1MHz. NTSC have a 60Hz refresh, but run only 895kHz (NTSC colorburst / 4). PAL systems have slower interrupt rates AND faster CPUs. Must be nice. (The faster clock is also why music comes out a little sharp on a PAL system as compared to NTSC.)

 

So, if you develop your game on an NTSC machine and properly synchronize to the ISR, then it should run just fine on a PAL system. It'll just run a bit slower if you base all your even timing on interrupts (which is the most common thing to do). I know that Arnauld Chevallier is taking a bit different approach for one of his games: He's designing all his games for 50Hz, and when run on an NTSC system, he skips 1 frame out of 6, so that games play the same on both PAL and NTSC. Good on him, I say. :-)

Edited November 9, 2010 by intvnut