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?

Improve this question
3
  • 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.
    – Героям слава
    Jan 18 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.
    – Героям слава
    Jan 18 at 17:17
  • 1
    it looks like you're right. There are 2 different frequencies: eab.abime.net/showthread.php?t=66354
    – Jean-François Fabre
    Jan 18 at 18:47

1 Answer 1

Reset to default
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).

Improve this answer
9
  • 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 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 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 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 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 at 20:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .