Hi all,
As per subject: it was released after the //e which could do colour in PAL on composite. But the PAL version of the //c is only B/W. Why is that? Lack of space of the board? Cost saving?
I'd imagine it's like the Europlus: it's an NTSC video output running at 50Hz so it shows as B/W in PAL.
Thanks! :)
The Apple IIc actually did include a PAL colour encoder. It was embedded inside of the RF Modulator unit, which has both PAL composite and RF outputs.
(I don't know the RF modulator shipped in the box with PAL IIc machines or if it was an optional purchase)
YouTube Video: Apple IIc PAL Colour
A2M4023 PAL RF Modulator Images
interesting thanks. I meant the Apple//c composite output though.
Now that I actually watched those links (!) I see why I was confused. That's not an RF modulator I think, it has a composite output if not mistaken? It's very interesting.
So now I am wondering whether that was a business choice: most users wouldn't need colour so let's add a B/W composite port and sell the adaptor for those who need colour. All of this is very interesting! :)
In post #3, 'tony359' wrote:
" I meant the Apple//c composite output though. "
Uncle Bernie explains:
With exception of the PAL Apple IIe, none of the Apple II composite outputs ever supported PAL colors, so all you will get from these outputs when using a PAL monitor is Black & White.
The root cause of this is that Apple II uses "color artifacting" to make colors from a video dot stream that originally ALWAYS is B&W. (Some people think that only the HIRES modes use color artifacting, but this is a fallacy - even the LORES and the DBL HIRES modes actually get all their colors from color artifacting).
WHAT IS "COLOR ARTIFACTING" ?
In technical terms, it is a contamination of the color channel by crosstalk leaking from the luminance channel (B & W !!!!) into the color channel.
This has been a peril of both the NTSC and the PAL color TV system since their inception. TV studious banned certain weaving patterns on clothing or ties because these would produce an unnatural "rainbow color" effect on color TV receivers, especially annoying and rainbow-ish when the person did move. TV productions had to adapt to these rules and avoid certain patterns on any object in the scene. The reason is that any dot or stripe pattern in black and white which is "seen" by the camera at an angle and under movement such that it produces a rythm in the B&W which has the color subcarrier frequency (3.579 Mhz in NTSC, 4.433 MHz in PAL), it will turn that B&W pattern into (unwanted) colors. Hence, the term "artifact colors".
You could make the point that TV studios should have the money to buy filters which would notch out these frequencies from the B&W = luminance signal, and they did that, but there are technological limitations, and some "artifacts" always get through.
HOW THE APPLE II USES "COLOR ARTIFACTING"
Woz' genius turned this problem into a virtue ... by clocking the B&W video dot stream with a multiple of the NTSC color subcarrier frequency (14.318 MHz for LORES, 7.159 MHz for HIRES). The problem he saw in the first wire wrapped Apple II prototype is that although this trick would give 16 colors in LORES and 4 colors (black, white, magenta, green) in HIRES, vertical lines in HIRES would need to be staggered by one dot on alternating lines to be of uniform color. Hence, he added 0.5 color subcarrier periods to each TV scan line, violating the NTSC standard. These are the two 'long' CPU cycles per TV scan line which won him the patent on the Apple II: U.S.-Pat. 4,136,359 - "Microcomputer for use with video display", which was filed on 11th April 1977, granted on 23rd January 1979, and expired on 11th April 1997 - long after the Apple II had been discontinued. And the patent did not deter the Taiwanese or Bulgarian copycats of the Apple II (so far a warning about the uselessness of patents if the idea is just too good).
THE PAL CONUNDRUM
The PAL system, invented by Walter Bruch of Telefunken company in Germany, sought to avoid the color fidelity ailments of the NTSC system, and how they did it was to flip the phase of the color subcarrier on alternating TV lines (PAL = "Phase Alternation Line"). This can compensate a static phase error in the TV channel. The color tint is preserved even in presence of a phase error, but the error compensation desaturates the color in the direction of white ... so a badly phase error infected, saturated red may turn into a pink. But unlike NTSC, a human face will never turn green, or reddish, as it may happen in the NTSC system (mocked as: NTSC = "Never The Same Color").
The way PAL works poses a fundamental problem for the Apple II: how to turn the "artifact colors" into the same PAL colors ?
As it turns out, this is impossible to do at a budget when using only the composite (NTSC) video signal, at least with 1970s/1980s technology (it would be a rack of equipment). What the designers at Apple did for the "PAL card" was to route the raw video dot stream and the dot clock to the PAL card in which a PAL decoder IC (usually, the TCA650) is run backwards, or, in other words, being abused as a PAL encoder (real PAL encoder ICs are rare ... a TV studio would use a handful, and how many TV studios per country ... so no market for encoder ICs. This situation changed with the early color TV games, and VCRs, but these came later in history ...)
The PAL card combined with a changed master oscillator clock was the only way to get PAL colors out of an Apple II, and it worked reasonably well. In the PAL Apple IIe, the "PAL card" is integrated on the motherboard, again, a TCA650. On the PAL Apple IIc, it has been moved into a small "dongle" which plugs into the backside of the machine. You have the advantage that the composite video output can be plugged into a B&W monitor at the same time ... so you can actually read the 80 column text, when the 80 column text mode is engaged.
Alas, most PAL Apple IIc I've seen on Ebay don't come with that small dongle, as it has been lost over the 40 years since it was bought. Sad.
Hope this post clarifies everything about Apple II PAL (and Apple IIc PAL) for the next few millennia ;-)
- Uncle Bernie
Very nice write-up! We should really have a Wiki here, to save explanations like this...
... and about the composite output of Apple ///. The PAL Apple /// suffers from the same issue like his II and IIc "PALs".
Thank you for taking the time to write this very comprehensive explanation! Indeed this should be stored somewhere online: I tried searching on this topic before asking and could not find anything. (Though Google tends to focus on modern machines when "apple" is in the name!)
So the lack of colour "out of the box" for the //c was a choice. The required circuitry was moved to a dongle to keep costs down. I do recognise the "SEROUT" pin of the digital output as the same "SEROUT" line going into the PAL section of the Apple //e - as you say in the //c Apple just moved the whole PAL section to the dongle.
Hence I am NOT expecting to see an NTSC colour burst on the PAL //c? It's not even a "50Hz NTSC colour machine" like the Europlus is?
Though, American machines were proper colour NTSC as the colours were simpler to achieve, hence cheaper, correct?
Thanks again!
I checked the video output and it does have the NTSC colour burst. But if I think about that, I think the PAL Apple //e has it too and there is a "trap" on the circuit to remove it and have it replaced by the PAL decoder/encoder.
Actually the Apple IIe PAL has a switch, which bypasses the PAL chip:
IMG_5382.JPG
Any time you want to use a double hi-res application like A2Desktop or a RGB card, you have to switch it to MONO, which is why I made mine external.
I'd be curious to see where the switch is located on the circuit - from a schematics perspective. I cannot find it.
It should only avoid the color burst to happen - hence your display never tries to display colours.
Here is the video circuit of the PAL edition of the Apple IIe. The switch SW1 is right in the center:
Apple IIe PAL.png
The schematic says that the "MONO" switch disables both the PAL encoder (TCA650) and the color subcarrier trap. So in MONO mode, NTSC artefact colors should be visible on NTSC-3.56 compatible monitors such as the International Apple Composite displays.
I am still wondering what exactly causes the interference light "watermark" wavelike noise that moves lightly on the color screen image on all Apple II PAL computers (with PAL color) implementation (which are generally all according to Gary Baker's design).
Bulgaria was behind the Iron Curtain. The Western world patents were not valid/legal in our block and vice versa. On the contrary, no copyright law was applicable, absolute freedom, even the copying was at government level along with production/factories.
I am also curious about that. I have noticed on my Apple IIe that by adjusting C112 I can bring these waves to a standstill, however as components heat up, they start moving slowly again, so I need to adjust it continuously. The only thing that works is get them moving fast enough so I don't see them.
The effect is usually called "dot crawl" and is caused by interference between the luminance and chrominance components. It is the reason for keeping Y/C separate such as on the C64 monitor connector.
It looks like by deleting C118 and feeding the chroma output into a separate amplifier, the same could be achieved on the PAL IIe.
Or could it be just a crappy 4.43 MHz generator that has trouble maintaining a temperature-stable frequency?
No.
In posts #13 and #14, 'retro-devices' and 'CVT' asked:
" I am still wondering what exactly causes the interference light "watermark" wavelike noise that moves lightly on the color screen image on all Apple II PAL computers (with PAL color) implementation "
Uncle Bernie has a conjecture:
I do have a PAL Apple IIe but no time to investigate. But I have a conjecture I can offer to you:
the effect may be a 'beat frequency' between the PAL subcarrier oscillator in the PAL encoder and the master clock oscillator on the motherboard (and harmonics from any derived signals in the digital logic, too).
To prove this conjecture being right, you would need to replace one of the oscillators with a PLL based frequency synthesizer, or replace both, and target a pair of frequencies where there is no beat. If you have two very precise function generators based on direct digital synthesis which can be phase locked together, you would not need to build a circuit board. If you have a Hewlett Packard / Agilent / Keysight 33120A with option 001, you would need only this one to do the experiment.
In TV studios, absolutely everything (field frequency, line frequency, color subcarrier) was generated by phase locking techniques from one master timebase - which in early TV studios was a very expensive ovenized crystal oscillator, and later it was a rubidium based atomic clock. Two TV studios running on atomic clocks are able to mix their video signals in real time on one screen using analog circuits without any visible problems. This never was trivial to do. Even "Picture-in-Picture" functions on consumer TVs had to use a lot of tricks and never were perfect.
Everything being derived from a master clock by PLL and the avoidance of beat frequencies and the leaking of harmonics or subharmonics of some signals into other signals is the reason behind the weird numbers for the color subcarriers chosen for PAL and NTSC.
Would be interesting to do the experiment but alas, I have no time for that at the moment. Maybe some reader of this post has the necessary instrumentation in his lab and the skills to do it without blowing up the Apple IIe (adjust the signal levels right)
Addendum: as mentioned by 'robespierre' in post #15, splitting the luma (Y) and chroma (C) signals and never mixing them of course can mitigate the problem greatly, too. However, the TV / monitor will add the luma signal to the demodulated color difference signals in order to make the three R G B signals. And this is where the 'beat' effect may sneak in again, although to a lesser extent as if the Y and the C would be mixed into a composite video signal.
- Uncle Bernie
Yes, thank you -- you are right. I was forgetting about this because the NTSC Apples have no sign of dot crawl while NTSC is more vulnerable to it. Have to consult Jim Sather's books to see how the interference was avoided. Would be interesting to get S-Video output from a PAL card some day, but I even do not own one, so far -- I don't want to mess with the built-in PAL circuitry within some Apples.
Actually the crawl is caused by the frequency slowly changing with temperature. I just adjusted C112 so that waves were standing still and then I heated up the area of the generator with my hot air gun. They started crawling super-fast, but then as the board cooled, they slowly came back to a standstill. And since C112 is there to adjust the PAL color subcarrier frequency and adjusting it has the same effect, I don't see what else could be causing the frequency to change over time other than the components heating up.
Of course I am not talking about the waves being there, but crawling up or down, which is the really annoying part.
In post #19, 'retro_devices' wrote:
" I was forgetting about this because the NTSC Apples have no sign of dot crawl ..."
Uncle Bernie comments:
True that but don't over-simplify the topic to avoid confusion of readers. In the NTSC Apple II, everything is derived from the 14.3181818 MHz master clock. This is the LORES dot clock (in the IIe, also the DBL HIRES dot clock). Divided by 2 it's the HIRES dot clock, 7.1590909 MHz. Again divided by 2 it's the NTSC color subcarrier frequency used to make the NTSC color burst, 3.57954545 MHz.
What happens in HIRES mode is that by placing dot patterns 00, 01, 10, 11 you get four colors, 00 being black, 11 being white. Magenta and green come from the 01 and 10 patterns --- because if you draw these dots in a repeated pattern, you can see the two phases of color subcarrier frequency made by the dots ! And this is exactly the trick how the Apple II makes colors by color artifacting. It is a brutal method - the Y signal (the dots) fully blasting into the chroma channel, C, with NO attenuation and NO filtering (only the color burst is filtered by a LC tank on the Apple II motherboard).
The other two colors available in HIRES mode, orange and blue, are generated by delaying the dot stream by one master clock of 14.3181818 MHz. This delay is turned on by setting the MSB of the video memory byte (which contains only seven dots). This feature was not present in the Rev. 0 motherboards and was added later.
In LORES and DBL HIRES mode, what actually happens is that the video signal with a 14.3181818 MHz dot rate greatly overwhelms the capabilities of the TV or monitor in terms of bandwidth. In a simplified manner, you can treat the video channel in the TV/monitor as a low pass filter, although the truth is a lot more complex when it comes to separation of luma and chroma signals, there also are notch and bandpass filters, and further filters after the demodulators. But for the sake of discussion, if you just have a simple lowpass filter with a cutoff frequency of about 5 MHz, or a bit lower, this filter will average out the "dots" coming in at 14.3181818 MHz, and this average will be the luma (or B&W) level. This is why LORES graphics contain colors like yellow and aquamarine, some white in them, and why there also are dark browns and dark blues. Now, the color: using Fourier series theory, you could draw an equivalent 14.3181818 MHz dot impulse response for each dot at the position of the dot, four possible dot positions per LORES pixel, and then add them up, do the low pass function, and after removing the DC content you would arrive at a sine wave of 3.57954545 MHz having different phases and amplitudes. Note that this is the NTSC color cubcarrier. The different phases map to different tints while the different amplitudes map to different color saturations. This is why the LORES mode offers so many more nice colors, and why HIRES mode never can make yellow or aquamarine.
The DBL HIRES mode of the Apple IIe with the 80 columns card offers the full LORES color palette at the same resolution as the legacy HIRES mode.
I have been experimenting a bit with this color system because I'm not fully satisfied with the six colors available in HIRES. This is not enough for my 'Codebreaker' game using color orbs instead of letters (these two options train different parts of the human brain, so both should be available in the game. I ended up with a small circuit in one GAL which adds to the Apple II and yields 10 colors (8 real colors plus black and white), see post #9 of this thread:
https://www.applefritter.com/content/extra-colors-hires-graphics-wanted
Alas, it's a little bit imperfect for playing 'Codebreaker' because the four blue to green orbs are difficult to discern. I shelved this project at this point until I have more time to improve it. I could add some luma or color saturation change for some of these four offenders in the circuit, or do it by software (adding white or black specks as a dither which would change the apparent luminance as seen by the human eye, to make these four offenders more easily discernable.
BENEFITS AND CHALLENGES OF THE APPLE II GRAPHICS SYSTEM FOR PROGRAMMERS
So you can see that even I am quite fascinated with the Apple II color system. It's so simple and stripped down to the minimum hardware expense and still allows the programmers to write great games. The first games for the Apple II were horrible and looked extremely crude, graphics wise, because the programmers had not yet developed the skills and the programming tricks needed to get a nice result in par with the C-64 or the 8-bit Ataris. But from around 1982 upwards, they had caught up and were able to produce stunning games which were in par or sometimes even better, than their Commodore or Atari counterparts. If you have all these machines in your collection, you can compare the various titles as ported between the machines. There are plenty of games where the graphics of the Apple II version excel and look much better than those on the competitors, despite these used much more sophisticated graphics hardware. The ability to pull this off on a software level only always has fascinated me. This is why I still write graphics code for the Apple II (from time to time, as I'm quite busy with hardware projects).
CONCLUSION - TRY IT OUT !
The bottom line here, especially for newcomers to the Apple II world, is that you just should go ahead and learn coding color games in 6502 assembly language on the Apple II. This learning curve leads to a fascinating journey into a long forgotten land of magic, even for the high IQ / geek types.
And once you have the results on the screen, you get the immensly satisfying feeling of "I did that". Which does not exist to this extent when you generate the same images using more sophisticated graphics hardware. Or, fast forward into the 21st Century, if you write a 3D game using openGL on a Linux machine. I looked into that, too, ever being the curious type, and wrote some code, just to find even raycasting etc. is so incredibly easy to do with summoning all the powerful library functions offered, that it almost looks like cheating (I wanted to write something like AppleII "Wayout", a 3D maze game). And I never got the feel of satisfaction to be really in control of these things ... relying of some 10's of millions of lines of code written by others. They may be giants in their field (writing such code and making the libraries available to the lesser minds) but where is the satisfaction with "I did it ?" ... it's not there. And never will be there. Because all you did is to summon a genie out of a bottle who did the difficult work for you. Work which you don't even need to understand how it's really being done.
I think this short philosophical excursion can explain why more and more people - even younger ones - venture into vintage computers like the Apple II or, even more fascinating, the Apple-1. Because if you write some code on these machines which then works and "shows off" you have the "I did that" feeling. Which is much more satisfying than just summoning genies. Oh, and it's also worth to mention that on these vintage computers you can also do hardware hacks - not so easy, or even impossible, with modern ones.
- Uncle Bernie
No. The crawl is caused by a frequencies interference or beat. Even without frequencies change there may be a visible "crawl".
CVT, your empirical ways of learning things are a bit disappointing, be careful with that "heating gun there"...
@UncleBernie, the theory of operation of color and graphics generation in Apple2s is well descibed in Jim Sather's books. I wish we had such books behind the "iron curtain" back in the days. Thank you for reminding that operation to us. My question was a bit different.
No, you are wrong and it's obvious why. If the frequency was not changing due to the temperature, once I bring the crawl to a standstill by adjusting C112, it would simply stay that way. It would not start moving by itself and require continuous adjustment in order to keep bringing it to a standstill. On my ESP32 SoftCard for example when I produce PAL signal, the dot crawl is fixed and it never moves up or down.
There is no controversy between what I say and your empirical observations, you have to assemble in your mind the bigger picture. First think why there are no such artifacts with the NTSC picture that Apple2's display, or standing still with the mentioned ESP card (is this an ad even in this topic ?)
Are you sure "you produce PAL signal"? Most likely you used an open source ESP library for generating composite video.
Thanks! My schematic doesn't show it! :)
You don't seem to understand that we are talking about the crawl being at a standstill vs moving in PAL. In NTSC there is no dot crawls whatsoever. It was already explained to you by someone else why there is no dot crawl in NTSC and why. I am bringing up my card to make the point that when the frequency is stable and derived from a single generator (as is the case with the ESP32), the crawl is at a standstill. In the Apple IIe PAL edition, you have 2 generators and at least one of them is not temperature stable.
I will try to explain it with your level - without knowing the details of that ESP card because a compilation of nested open source computer emulators into an ESP platform present absolutely no interest to me, I can predict that if you heat that card with your "gun" the artifacts will continue to stand still. I see you've just edited your message , so you seem to have just understood the reason behind the "dot crawl":
The temperature stability is by far not the only factor though.
This is exactly what I was telling you: it remains at a standtill as the temperature chages. And I don't need to heat it up manually - it gets pretty hot all by itself.
I understood the reason in Post #20 when I heated up the 4.43 MHz generator with the heat gun.
It is the ESP32 that produces the signal, not me, but I wish there was one good open source library for composite, so I didn't have to collect code from so many different projects and demos and ultimately rewrite everything.