15

Usually, computers that came in separate PAL and NTSC versions used slightly different CPU frequencies because the video and CPU clock were derived from the same crystal (the Apple II and Commodore 64 were already mentioned here, and this excellent answer goes into the history of color computers).

However, the Amiga could be switched in software between PAL and NTSC by holding both mouse buttons on power up. This seems to be an addition made for the ECS chipset over the OCS chipset.

That makes me wonder: Was the Amiga capable of running the CPU at two different speeds (Wouldn't that require two different crystals, one for PAL and one for NTSC?), or was the ECS chipset capable of generating it's own clock signal, thus finally making the video clock completely independent of the CPU clock?

Michael Stum
  • 1,680
  • 11
  • 21
  • I don't think the ECS generates its own clock signal. That would point to the possibility that the CPU runs at different speeds depending on what you choose, but I don't know that for sure. – Omar and Lorraine Jan 18 '23 at 17:16
  • 1
    Another machine that can switch between 50Hz and 60Hz video refresh rate is the DEC Rainbow 100. But the Rainbow 100 has a constant speed for its CPUs. – Omar and Lorraine Jan 18 '23 at 17:17
  • 1
    it looks like you're right. There are 2 different frequencies: http://eab.abime.net/showthread.php?t=66354 – Jean-François Fabre Jan 18 '23 at 18:47

1 Answers1

12

ECS Amigas have an (one!) oscillator either clocking at 28.375MHz for PAL or 28.636MHz for NTSC versions. The oscillator is soldered in and cannot be changed in software. This base frequency is divided by 4 and provides the CPU clock. (That means, the system and CPU clock cannot be changed by pressing both buttons)

Pressing both mouse buttons on an ECS Amiga when booting will re-initialize the chipset to the "opposite" mode within the limits of the system clock producing a "somewhat NTSC or PAL signal". (With quite some degree of "somewhat": "Within the limits" means you will probably not see any of those limits in normal operations. They might appear as glitches, for example, when you try to genlock a PAL Amiga running in NTSC mode to an NTSC signal or vice versa).

The same thing happens when you change the PAL/NTSC jumper on the motherboard (where present).

tofro
  • 34,832
  • 4
  • 89
  • 170
  • The two rates are about 1% apart. I would expect that to be a non-issue with RGB or composite monochrome monitors, but I don't think any common monitor would be able to correctly lock onto a chroma signal that is off by more than a fraction of a cycle per scan line, and the quoted crystal speeds would yield a difference of about two cycles per scan line. I think the most likely outcome would be that the monitor would lock onto a rate that was almost exactly two cycles per scan line faster or slower than the supplied reference, so an NTSC display driven with the wrong rate... – supercat Jan 19 '23 at 15:58
  • ...would have vertical stripes where colors were correct, and colors would be shifted around the rainbow between them. Using a PAL display with the wrong rates would yield a pattern of stripes where the colors were correct and reversed, separated by grayish regions. – supercat Jan 19 '23 at 16:02
  • @supercat That (the 1%) would be true if the frequencies would be running through the same dividers in PAL and NTSC mode until coming down to the respective vertical and horizontal frequencies of the video output - And because it seems to work I must assume they don't. I guess the Amiga's video circuitry is applying different clock dividers for NTSC on PAL vs. PAL on PAL or vice versa. With both frequencies you can come pretty close to the standard rates. – tofro Jan 19 '23 at 16:13
  • I would expect there to be one set of dividers intended for generating NTSC video using an NTSC crystal, and one for generating PAL video using a PAL crystal. A 1% error in horizontal or vertical scan rates would not be a problem on most displays, since the display would get kicked every cycle, but a display has to generate ~200 cycles of colorburst autonomously on every scan line between synchronization events. – supercat Jan 19 '23 at 16:35
  • @supercat The Amiga does not output color composite. If you have a selectable video mode between 50Hz (288p, 576i) and 60Hz (240p, 480i) video timings, the RGB is encoded into PAL or NTSC color signal in the external video modulator. And contary to your expectations, a normal TV will have no problems receiving standard colourburst that is not synchronous or locked with the line rate. If TVs had been picky about the incoming video signal, would have prevented most home computers to be connected to a TV (maybe I should not bring up progressive signal output instead of interlaced here). – Justme Jan 19 '23 at 20:16
  • @Justme: Generation of usable NTSC composite color signal requires that a color encoder have a reference within about 0.1% of 3.579545MHz. If one is using a color encoder external to the Amiga, the quality of the external chroma reference is what will matter. Most monitors will tolerate some sloppiness in most aspects of video timing, but not the chroma frequency. They have a 3.579545MHz crystal oscillator, and can nudge its phase to match a reference but can't nudge the frequency. – supercat Jan 19 '23 at 20:40
  • @supercat I know, and the external modulator still uses it's crystal for colourburst generation so it will be unchanged. But I was not talking about changing colourburst rate, but line rate. The TV can show video that does not strictly adhere to studio/broadcast video specification. It usually allows for tolerance in line length and number of lines. – Justme Jan 19 '23 at 20:54
  • @Justme: I guess I'd thought the later Amigas had re-added the composite video output; if they had done so, the effect of using the wrong crystal on line rate would not have been an issue when using RGB, but would have rendered the composite color output useless. – supercat Jan 19 '23 at 21:16
  • @supercat PAL and NTSC have also other differences. If you live in PAL country, you still want PAL colour output even if you use 60 Hz scan rate, and vice versa, in NTSC country you want NTSC colour output even at 50 Hz scan rate. Which is why it actually makes sense not to change the modulator colour carrier. On the other hand, the NTSC machine won't run at PAL rate even if you output 50 Hz video, so sound output frequencies and timer interrupts for tempo may run at slightly incorrect rates. – Justme Jan 19 '23 at 21:28