Detecting NTSC/PAL VICs
Moderator: Moderators
Detecting NTSC/PAL VICs
Hi All,
I'm sure I saw a mention in the forums some time ago about being able to detect a PAL vs NTSC VIC programatically, but for all my searches I can't find it again
Does anybody recall which memory location it is and the value it contains PAL vs NTSC?
I'm sure I saw a mention in the forums some time ago about being able to detect a PAL vs NTSC VIC programatically, but for all my searches I can't find it again
Does anybody recall which memory location it is and the value it contains PAL vs NTSC?
Of course if some naughty fellow has replaced the Kernel ROM with one for the wrong machine, it won't work. On the other hand it means the VIC would boot up with an off-centered screen every time. But to this point it is the best/simplest way I can think of. One probably could wait for a certain raster line and set up a timer but it would be more work for the same benefit.
Anders Carlsson
I thought I'd give an example of the raster line method, which as noted does not rely on the Kernal ROM.
This is the way it is implemented in victracker:
(must have interrupts disabled)
This is the way it is implemented in victracker:
(must have interrupts disabled)
Code: Select all
;**************************************************************************
;*
;* CheckPAL
;* Returns: Acc=0 on NTSC-M systems, Acc!=0 on PAL-B systems
;* (and sets PAL_Flag accordingly)
;*
;******
CheckPAL:
; find raster line 2
lda #2/2
cp_lp1:
cmp $9004
bne cp_lp1
; now we know that we are past raster line 0, see if we find raster line 268
; before we find raster line 0
cp_lp2:
lda $9004
beq cp_ex1
cmp #268/2 ; This line does not exist on NTSC.
bne cp_lp2
cp_ex1:
sta PAL_Flag
rts
Thanks for all the replies. I've gone with the EDE4 method for now, less bytes and I'm not too bothered if my code wont run on custom kernals.
It seems to work fine when testing in VICE (NTSC and PAL) and on a real PAL VIC. I don't have access to an NTSC VIC to test. Would anybody be willing to test out a PRG for me to make sure that there is no flicker and the screen is visible? (It's a game in progress, no interaction yet, requires 8/16K expansion).
Thanks
It seems to work fine when testing in VICE (NTSC and PAL) and on a real PAL VIC. I don't have access to an NTSC VIC to test. Would anybody be willing to test out a PRG for me to make sure that there is no flicker and the screen is visible? (It's a game in progress, no interaction yet, requires 8/16K expansion).
Thanks
Well, there are some machines around that have PAL ROM's but are NTSC-converted...brighty wrote:I'm not too bothered if my code wont run on custom kernals.
I used this in VIMM:
Code: Select all
; detect the system
lda #0
sta SYSTEMSEL
0$ lda $9004
cmp #1
bne 0$ ; wait for line 1
1$ lda $9004
beq 2$ ; line 0 reached -> NTSC
NTSC_LINES = 261
cmp #NTSC_LINES/2+2
bne 1$
inc SYSTEMSEL
2$ ; system detected: 0 for NTSC, 1 for PAL
Thanks a million. The PRG can be found hereamramsey wrote:I can do it. I've got an NTSC vic with memory expansion. Do you have a link to the file?
Looks really good. The screen was centred, no flickering or any funny business. The only problem was that the score at the top was cut off (about half of it) on my TV screen. I tried it out on a 1080 monitor also and the score was completely missing.
There was perhaps enough room at the bottom of the screen for about 1/2 a level of blocks or so. When the baddies jump off the bottom they can be seen right until the plastic on the monitor (ie- no border at the bottom).
Loading on 1080 (to give you an idea of the normal borders on the vic)
Gameplay
15 second video (probably have to right click and save it):
http://aaronramsey.com/public/vic20/qbert.mpg
There was perhaps enough room at the bottom of the screen for about 1/2 a level of blocks or so. When the baddies jump off the bottom they can be seen right until the plastic on the monitor (ie- no border at the bottom).
Loading on 1080 (to give you an idea of the normal borders on the vic)
Gameplay
15 second video (probably have to right click and save it):
http://aaronramsey.com/public/vic20/qbert.mpg
First off, a big thanks for putting in the time and effort to help me out, I really appreciate it. I can only test the NTSC version on VICE and this really illustrates the necessity of testing on real hardware.amramsey wrote:Looks really good. The screen was centred, no flickering or any funny business.
I suspected I was pushing the display borders a bit on NTSC trying to display 28 rows. I think I can get away with trimming the top row off and moving the score down. I'll have a play with this over the weekend. I'll add keyboard input for screen centering too (horizontal & vertical), to allow for any differences between TVs and monitors.amramsey wrote:The only problem was that the score at the top was cut off (about half of it) on my TV screen. I tried it out on a 1080 monitor also and the score was completely missing.
There was perhaps enough room at the bottom of the screen for about 1/2 a level of blocks or so. When the baddies jump off the bottom they can be seen right until the plastic on the monitor (ie- no border at the bottom).
Once again, thanks a million for the work you put in, especially with the video and pictures, they truly do speak a 1,000 words.
Ah, I didn't know people swapped ROMs like that I'll change the detection code over the weekend to use a1bert/tlr's method.a1bert wrote:Well, there are some machines around that have PAL ROM's but are NTSC-converted...brighty wrote:I'm not too bothered if my code wont run on custom kernals.
Thanks to both of you for the code and info. My credits list is growing already
Actually it's the other way around: the ROM's are original, but the video chip has been changed. See http://www.iki.fi/a1bert/Dev/PAL2NTSC.htmlbrighty wrote:Ah, I didn't know people swapped ROMs like that