Detecting PAL or NTSC VIC Via Software

Basic and Machine Language

Moderator: Moderators

Post Reply
RJBowman
Vic 20 Enthusiast
Posts: 198
Joined: Tue Oct 25, 2011 7:50 pm

Detecting PAL or NTSC VIC Via Software

Post by RJBowman »

How do you tell, via software, weather you are running a PAL or NTSC VIC20?
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Post by tokra »

Memory location $ede4 - (60900) is the initial value for $9000 - which is 5 on NTSC-machines and 12 on PAL-machines.
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

What tokra said.

Which kind of program are you going to write that actually requires you to differentiate between PAL and NTSC VIC-20s? Just curious.
tlr
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Post by tlr »

If you need to be ROM independent you can determine this be searching for a raster line that only exists on PAL using $9004.
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

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.
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Post by tokra »

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.
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:

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
This runs for enough cycles to make sure rasterline $83 (131) is hit which it only does on a real VIC every second half-frame, but never in VICE. On a real machine $033c will be set to $83. In VICE it stays at $00
RJBowman
Vic 20 Enthusiast
Posts: 198
Joined: Tue Oct 25, 2011 7:50 pm

Post by RJBowman »

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.
User avatar
vicist
Vic 20 Afficionado
Posts: 352
Joined: Tue Oct 09, 2012 5:26 am
Location: Sheffield, UK

Post by vicist »

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 :shock:
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. :P
tlr
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Post by tlr »

Mike wrote:Good question. What use is it to have a PAL KERNAL in a NTSC VIC-20, and vice versa?
You could possibly have a completely different ROM but you still want to know if it's a 6560 or 6561.

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.
RJBowman
Vic 20 Enthusiast
Posts: 198
Joined: Tue Oct 25, 2011 7:50 pm

Post by RJBowman »

How common are machines with non-standard ROMs?
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

RJBowman wrote:How common are machines with non-standard ROMs?
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.

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.
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.
Indeed, and the latter case is what I like to call 'incompatible by accident'.
vicist wrote:nobody on the forum had suggested anything different. :(
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.
User avatar
e5frog
Vic 20 Nerd
Posts: 551
Joined: Sat Feb 17, 2007 5:46 pm
Website: http://channelf.se
Location: Sweden
Occupation: Service Engineer

Post by e5frog »

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. ;-)
My other interest: http://channelf.se
Post Reply