NTSC vs PAL

[JonBrawn]

I was thinking the other day about how to tell the difference between an NTSC VIC-20 and a PAL VIC-20. I have one of each, and I'm going to be doing some software work that needs to know if this is the NTSC or a PAL one.

The easy way of course is to check the KERNAL ROM's VIC register initialization table, however, I thought of a ROM-independent way of doing this - if you repeatedly read the $9004 raster register, keeping track of the highest value read, then after a couple of frames (i.e. after seeing 'the value I just read' < 'the value I previously read' a few times) then if the maximum value seen is < 142 then you are NTSC and if it is > 142 then you are PAL.

Is this a well-known technique?

I'm going to have a rummage in the KERNAL ROM and see if I can produce a universal image that selects accordingly (the raster register counts up even when the VIC's other registers haven't been programmed yet).

[tokra]

Basically polling $9004 is a valid way to check if you have an NTSC- or PAL-VIC. I did a similar routine to check if an emulator is used back before VICE supported NTSC-interlace. But you can easily use the same method to check for PAL/NTSC:

Code: Select all

.C:033c  A9 00       LDA #$00
.C:033e  8D 54 03    STA $0354
.C:0341  AA          TAX
.C:0342  A8          TAY
.C:0343  A9 83       LDA #$84       <-  or any other raster-value only available in PAL
.C:0345  CD 04 90    CMP $9004
.C:0348  D0 03       BNE $034D
.C:034a  8D 54 03    STA $0354
.C:034d  88          DEY
.C:034e  D0 F5       BNE $0345
.C:0350  CA          DEX
.C:0351  D0 F2       BNE $0345
.C:0353  60          RTS

This basically polls $9004 for about 256x256 times and if the raster-value is $84 marks this in $0354 which your program can then read and check whether it is set (PAL) or zero (NTSC).

[Mike]

Yet, (for example) checking $EDE4 for the default XPOS value being either 5 (for NTSC) or 12 (for PAL) is *much* simpler than doing those raster line range checks. Furthermore, if a program takes the table at $EDE4 as base values and adds or subtracts offsets, the screen window can be resized with code that is the same for PAL and NTSC.

Regarding a potential "malicious" user that wants to trick this technique by swapping in the other TV norm's KERNAL: it is absolutely no use for a PAL VIC-20 to have an NTSC KERNAL fitted, neither the other way round it is. Not only makes this the screen window off-center, but also the timing values for jiffy clock and RS232 Baud rates are completely off. A program really can't be expected to operate under such screwed-up circumstances.

I'm going to have a rummage in the KERNAL ROM and see if I can produce a universal image [...]

Such a KERNAL will break a lot of programs which use aforementioned method(s) to adapt for PAL/NTSC. Neither would this help in case of off-centered cartridge displays: the take-off of the cartridge code happens quite early in the reset sequence, and in most cases said code blissfully ignores the default values at $EDE4 and provides own defaults for only one TV norm instead - likely, for the one the developer used.

An universal image with a raster line range PAL/NTSC detection might though come handy for a dead-test KERNAL, where the original KERNAL has been replaced and the VIC display ought to be set up correctly before the code continues with tests.