In different areas of the world different video standards are used for broadcasting TV signals. The most common ones are NTSC and PAL. The main difference between them is the way the color information is encoded, but they also have different line resolutions and frame rates. When taking a simplified view a NTSC signal has 60 frames per second with 262 lines each, PAL has 50 frames with 312 lines each. It is a bit more complicated in reality, because normal TV broadcast is interlaced, only half of the picture is drawn at once, half of the lines are black and filled in by the next field. To differentiate between them one of the fields is one line longer than the other and a full frame of two fields has 525/625 lines. The Odyssey² and the Videopac G7000 both generate a non interlaced display, so I will use the 262/312 lines value. When broadcasting there are even several sub-standards dealing with the sound encoding into the video signal, but these are not relevant for programming. There is another video standard called SECAM which uses another way to encode color, but it uses 50 frames and 312 lines, so it is very similar to PAL. I think the Jopac consoles are the SECAM version of the Videopac G7000, but I don't have any more information about them. If you know something about them please E-Mail me.
The Odyssey² generates a NTSC signal, the Videopac G7000 a PAL signal. The Odyssey² is the base model, the Videopac G7000 has a lot of additional logic to generate a PAL compatible signal. Both consoles use a single Quartz to generate several clock signals, including the CPU clock. This means all internal clocks differ slightly, which has a big impact on programming. The Videopac+ G7400 uses different clock sources for CPU and VDC, so there is no fixed relationship between CPU and VDC clock. The frequencies are the same as for the Videpac G7000.
| Odyssey² | Videopac | |
|---|---|---|
| Main clock | 7.15909 MHz | 17.734476 MHz |
| VDC divider | 2 | 5 |
| VDC clock | 3.58 MHz | 3.55 MHz |
| CPU divider | 4/3 | 3 |
| CPU clock | 5.37 MHz | 5.91 MHz |
| Instruction cycle | 2.79 µs | 2.54 µs |
| Lines per frame | 262 | 312 |
| Frames per second | 60 | 50 |
| Instructions per line | 342/15 = 22.8 | 380/15 = 25.3 |
| Lines of VBLANK | 22 | 72 |
| Instructions per VBLANK | ≅500 | ≅1820 |
It is common to use the frame as basis for all timing information. This means that the same code runs 20 % faster on NTSC machines. But there are less CPU clocks available per frame, too. Even worse is the much shorter VBLANK time on NTSC machines. To be able to change VDC objects you have to turn the graphics off. So the only time to change graphics without disturbing the picture is inside VBLANK, but this is 3 times longer on PAL. Additionally the CPU runs slower on NTSC, making the situation worse again.
Coding only for PAL gives you much more CPU power, so it is possible to create more complex games which only work on PAL machines. But if the game is simple enough you should try to make it run on NTSC, too. So for development it is better to test your code on NTSC machines, if it has no timing problems there it won't have any on PAL. The only exception is code that relies on exact timing, like eg. changing the background on the fly. This code needs to be different on PAL and NTSC.
If you are writing code which only runs on the Videopac+ G7400 I think it is ok to ignore any NTSC issues. The Odyssey³, the NTSC version of the Videopac+ G7400 only exists as several prototypes, and I think anybody owning one will have a Videopac+ G7400, too.
This program shows how to detect if your program is running on a PAL or NTSC machine. I only explain the detection routine here, the interpretion and drawing parts are left out. The program is based on an idea by from René van den Enden.
This program checks the length of the VBLANK pulse. This pulse can be seen on the external input T1 starting at VSYNC. So this routine waits for VSYNC and counts in a loop until T1 is 0 again. The result is the loop counter, it is 0d6h on PAL and 034h on NTSC. This program uses the standard interrupt routines, adding code into the VSYNC or sound interrupt will influence the results. That is also the reason why it waits until all sounds have finished.
start
; wait for end of keyclick
mov r0,#iram_irqctrl
mov a,@r0
jb6 start
call waitvsync ; wait until vsync
; count until pulse ends
count clr a ; init counter
loop inc a
jz error ; counter overflow
nop ; prevent overflow on PAL
nop
nop
jt1 loop
error mov r1,a
show ; show result, PAL: D6, NTSC: 34