Detecting PAL or NTSC VIC Via Software
Moderator: Moderators
Detecting PAL or NTSC VIC Via Software
How do you tell, via software, weather you are running a PAL or NTSC VIC20?
- Mike
- Herr VC
- Posts: 4816
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Good question. What use is it to have a PAL KERNAL in a NTSC VIC-20, and vice versa?
http://sleepingelephant.com/ipw-web/bul ... 0&start=17
The table at $EDE4 provides the init values for the VIC registers, and it can easily be used to provide TV system independence: instead of using absolute values for the horizontal and vertical positioning registers, one uses an offset added or subtracted from the default values. This gives same visual result - regardless whether PAL or NTSC is used.
That's the method how MINIGRAFIK sets the values for the 20x24 display (actually 12 double-height character lines) and recenters the picture.
Of course, there are also limits which can't be exceeded (you can't POKE negative values, NTSC uses more screen estate from the beginning, while PAL has a bigger border which could be used) - in that sense NTSC is the lower common denominator.
http://sleepingelephant.com/ipw-web/bul ... 0&start=17
The table at $EDE4 provides the init values for the VIC registers, and it can easily be used to provide TV system independence: instead of using absolute values for the horizontal and vertical positioning registers, one uses an offset added or subtracted from the default values. This gives same visual result - regardless whether PAL or NTSC is used.
That's the method how MINIGRAFIK sets the values for the 20x24 display (actually 12 double-height character lines) and recenters the picture.
Of course, there are also limits which can't be exceeded (you can't POKE negative values, NTSC uses more screen estate from the beginning, while PAL has a bigger border which could be used) - in that sense NTSC is the lower common denominator.
I did this once to determine whether an NTSC-VIC20 is a real machine or running on VICE. First set bit 7 of $9000 (interlace mode on), then:tlr wrote:If you need to be ROM independent you can determine this be searching for a raster line that only exists on PAL using $9004.
Code: Select all
.C:033d A9 00 LDA #$00
.C:033f 8D 3C 03 STA $033C
.C:0342 AA TAX
.C:0343 A8 TAY
.C:0344 A9 83 LDA #$83
.C:0346 CD 04 90 CMP $9004
.C:0349 D0 03 BNE $034E
.C:034b 8D 3C 03 STA $033C
.C:034e 88 DEY
.C:034f D0 F5 BNE $0346
.C:0351 CA DEX
.C:0352 D0 F2 BNE $0346
.C:0354 60 RTS
I was asking because I was curious. There are a lot of programs that only work on one machine or another.
Some of these programs do very complex things that will only work on one machine type due to timing issues, but some might only require a slight change to work on either machines. That slight change could be enacted by the program itself, but I think that some programmers don't bother.
Some of these programs do very complex things that will only work on one machine type due to timing issues, but some might only require a slight change to work on either machines. That slight change could be enacted by the program itself, but I think that some programmers don't bother.
I am one such programmer
I wrote a game that shakes the screen about when you failed by changing locations 36864 and 36865.
See thread: http://sleepingelephant.com/ipw-web/bul ... php?t=6134
The default values for pal/ntsc are different so when centering the screen after the movement by pokeing the pal default values back into these registers, the ntsc screen was way off. My answer to this problem was initially to write an ntsc version of the program using the ntsc default values.
This, of course, is NOT the way it should be done, but not having programmed anything for 30 years
brain rust had set in and nobody on the forum had suggested anything different.
The simple answer was to read the default values into variables, shake the screen based on the values, then restore the defaults from the variables.
Ignorance is not the same as laziness. There are some brilliant people here on Denial and if you ask the right questions you will be rewarded with equally brilliant answers.
I wrote a game that shakes the screen about when you failed by changing locations 36864 and 36865.
See thread: http://sleepingelephant.com/ipw-web/bul ... php?t=6134
The default values for pal/ntsc are different so when centering the screen after the movement by pokeing the pal default values back into these registers, the ntsc screen was way off. My answer to this problem was initially to write an ntsc version of the program using the ntsc default values.
This, of course, is NOT the way it should be done, but not having programmed anything for 30 years
brain rust had set in and nobody on the forum had suggested anything different.
The simple answer was to read the default values into variables, shake the screen based on the values, then restore the defaults from the variables.
Ignorance is not the same as laziness. There are some brilliant people here on Denial and if you ask the right questions you will be rewarded with equally brilliant answers.
You could possibly have a completely different ROM but you still want to know if it's a 6560 or 6561.Mike wrote:Good question. What use is it to have a PAL KERNAL in a NTSC VIC-20, and vice versa?
Another way is to measure the amount of cycles between raster lines or measure the number of cycles per frame.
For stock VIC-20 programs the kernal method should be sufficient though.
- Mike
- Herr VC
- Posts: 4816
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
The Japanese VIC-1001 sports a NTSC KERNAL with extra support for the Hiragana characters in the keyboard driver. Furthermore there is a Swedish (PAL) version, which - again - changes the keyboard layout. There are also the JiffyDOS KERNALs (PAL and NTSC) around.RJBowman wrote:How common are machines with non-standard ROMs?
A non-standard KERNAL with substantial alterations would make most non-trivial programs fail to run on it. Most custom KERNALs (especially on the C64, where they are *much* more common) take care to leave the position and contents of important code entry points and data tables intact, and I consider the init table of the VIC registers such an example.
For me, making a program somehow 'proof' against a non-standard KERNAL is not worth the trouble.
Indeed, and the latter case is what I like to call 'incompatible by accident'.Some of these programs do very complex things that will only work on one machine type due to timing issues, but some might only require a slight change to work on either machines.
I'm sorry, but the PAL vs NTSC issue (that programmers might have something to consider) pops up in roughly every 10th post in the Programming section here.vicist wrote:nobody on the forum had suggested anything different.
- e5frog
- Vic 20 Nerd
- Posts: 551
- Joined: Sat Feb 17, 2007 5:46 pm
- Website: http://channelf.se
- Location: Sweden
- Occupation: Service Engineer
IMHO software should be written to work on stock machines and/or support widespread mods/hardware.
If a program doesn't work because someone decided to plug something else than the original Kernal in there then that's their problem.
If a program doesn't work because someone decided to plug something else than the original Kernal in there then that's their problem.
My other interest: http://channelf.se