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).
NTSC vs PAL
Moderator: Moderators
- JonBrawn
- Vic 20 Devotee
- Posts: 225
- Joined: Sat Sep 11, 2021 10:47 pm
- Website: http://youtube.com/@vicenary
- Location: Austin TX USA
- Occupation: CPU design engineer
NTSC vs PAL
Working on FPGA replacement for 6560/6561
https://youtube.com/@vicenary
https://youtube.com/@vicenary
Re: NTSC vs PAL
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:
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).
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
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: NTSC vs PAL
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.
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.
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.
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.JonBrawn wrote:I'm going to have a rummage in the KERNAL ROM and see if I can produce a universal image [...]
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.