Apple II clock circuit question...

CVT wrote:

...from the sine wave you see on each bar itself.

 

 

I see no sine waves. Of course, this was a provocative question. It is fun to see someone explaining things he himslef does not fully understand. 

retro_devices wrote:

I see no sine waves.

...

LOL! You see no sine waves because it doesn't look like you have any idea how the color is encoded. Do you see them now??

SineWaves.png

Hint: Sine waves is almost everything you should be seeing! :)

CVT wrote:

LOL! You see no sine waves because it doesn't look like you have any idea how the color is encoded. 

 

 You are the only one who knows the color TV systems, you invented NTSC, PAL, SECAM ;) You even invented the hot water, but your invention is somewhat cool ;)  Go back to school to learn about interpolation.

The question is waves of WHAT you are seeing?

retro_devices wrote:

CVT wrote:

LOL! You see no sine waves because it doesn't look like you have any idea how the color is encoded. 

 

 You are the only one who knows the color TV systems, you invented NTSC, PAL, SECAM ;) You even invented the hot water, but your invention is somewhat cool ;)  Go back to school to learn

...

I am not going to continue this conversation, because once again you are being a troll. My only suggestion to you is to act online as you would act in person, and in person you are a pretty cool and helpful dude. At least that was the impression I got from the two or three occasions we met in person. If you did that, perhaps they would not have banned you from the Bulgarian retro forum.

The question of how the monitor or TV recovers the color signal is related to the subject of phase-locked loops (PLLs), which if anything would be the topic to re-learn. PLLs have many interesting and surprising properties which may be at play in creating the kinds of distortion seen in these cases. For example, if there are colored dots displayed with particular patterns, it can appear to the PLL as a subharmonic of the colorburst, and cause it to jump suddenly into a different phase. We discussed the problem of dot crawl, which is also related.

In post #56, 'robespierre' wrote:

" For example, if there are colored dots displayed with particular patterns, it can appear to the PLL as a subharmonic of the colorburst, and cause it to jump suddenly into a different phase. "

Uncle Bernie comments:

I've never seen this effect with a valid video signal conforming to the NTSC standards. In a valid video signal with proper horizontal sync levels and timing, no "colored dots displayed with particular patterns" can ever affect the color subcarrier oscillator in the TV or monitor, as long as these "colored dots" do not appear too close to the color burst position. It's not a true PLL either (in most cases). A true PLL compares the phase of an input signal and the local oscillator all the time, and adjusts the local oscillator such that the phases track. The TV can't do this for obvious reasons: the color burst is not available all the time during the whole TV scan line. So whatever the circuit level solution is, the local oscillator in the TV regenerating the color subcarrier from the burst only can do phase comparisions while the color burst is present. This is governend by the so-called "sandcastle" impulse in analog TV sets. Now, digital TV sets or monitors (i.e. flatscreen LCB based ones) are an entierly different animal. But even there you would not expect the color decoder to have subcarrier phase jumps in the live (visible) part of the TV scan line.

The problem with digital NTSC decoders is that most use a trick algorithm to separate luma and chroma signals based on a digital delay line. Since in pure, standard conforming NTSC the phase of the color subcarrier jumps by 180 degrees every other scan line, all you need to do is to add the digitized video signal of the prior scan line to the present scan line, and the chroma signal cancels out (assuming the colors have low spatial resolution, which is the case for typical TV pictures). So what is left over after the add is the  luma signal. Subtract that from the current digitized video signal  and the chroma signal is left. This is just an example, there are many different implementations because everybody tried to dodge the patents of the competition. The idea was to avoid expensive digital filters and just use a shift register based delay line. But the whole digital trickery concept falls apart when some nasty video game console (or Apple II, or Atari 8-bit, or ...) makes non-standard NTSC-ish video with either not doing the 180 degree phase jump per TV scan line, or, worse, has a non-standard-conforming time duration of the scan line (should never happen with TV broadcasts, as they ran on atomic clock timebases, and prior to that, on very accurate, ovenized crystal oscillators). For us this meant we had to put a "classic" NTSC decoder in all of our digital TV chip sets we developed in the 1990s. Once the 180 degree phase jump was found to be missing, the color decoder would switch from the mode with the delay line to the "classic", filter based approach, which however used a very cheesy and cheap digital filter that would not deliver the picture quality needed for real movies or broadcasts. This was necessary because consumers of course expected (and rightfully so) that their video game consoles would work with their new TV. The company had a "chamber of horrors" with specimen of the worst offenders in terms of video games consoles. Our ICs were expected to produce proper colors for all of these.

All this know-how was lost, of course. So for new flat screen TVs you can expect that they will not work with these vintage computers or video game consoles from the 1970s to early 2000's. I must admit that even my Apple-1 color graphics card in its present form is  a real pig when it comes to NTSC standard conformity. I cleverly and deliberately designed it to make slightly longer TV scan lines, to dodge the issue with implementation of the 'long cycles' the Apple II has to use to get the timing right, but would require a mod to the Apple-1 motherboard. As I expected, this foul trick works like a charm with real analog, CRT based TVs of the 1990s, but alas, on most of the modern, Chinese made flat screen TVs/monitors I have as specimen these either have no colors (not recognizing the signal as NTSC) or they don't accept the signal at all - no video.

So I'll have to redesign my Apple-1 color graphics cards such that it works together with a modified Apple-1. This is very, very ugly but alas, there is no other way to implement an Apple II compatible color graphics card without the "long cycles" and still having the proper TV scan line duration.

This is mentioned just to clarify the situation with color issues we see nowadays. This technical rabbit hole goes deeper than most people think. Most weird effects seen with Apple II (or other vintage hardware) on modern TV/monitors are NOT easily explained, and most explanations you can find are just wrong. Such like "colored dots displayed with particular patterns" claimed to affect a non-existing PLL.

- Uncle Bernie

UncleBernie wrote:

Since in pure, standard conforming NTSC the phase of the color subcarrier jumps by 180 degrees every other scan line, all you need to do is to add the digitized video signal of the prior scan line to the present scan line...

Sorry, this is wrong in several ways. I guess you are mistaking to some extent PAL for NTSC.

In post #58, 'retro_devices' wrote:

"Sorry, this is wrong in several ways. I guess you are mistaking to some extent PAL for NTSC."

Uncle Bernie comments:

No, YOU are mistaken. Don't try to argue with a true TV/Video professional who led the design team which designed the very last generation of TV ICs for CRT based TVs in the history of mankind. I know *everything* about PAL, NTSC and SECAM.

The reason why the NTSC standard uses a 180 degree phase jump of the color subcarrier on every other TV scan line is this:

On legacy B&W TVs with no "color trap" filter you can actually see the color signal, which is phase modulated, as we all should know.

The consequence is that for areas with the same color (actually, "tint") there would be a vertical stripe pattern which is very easily seen by the human eye (because the human eye has an "edge detector" neural circuit built in, it is very sensitive to this kind of pattern). This would be annoying to the TV viewer using a B&W TV. So the NTSC committee decided to use the trick with the 180 degree phase jump, which turns areas of the same color (actually, "tint") into a fine dot pattern in which the dots of adjacent scan lines are never lining up. This dot pattern does not trigger the "edge detector" neural circuit in the human eye, and is perceived as a shade of grey instead.

Many TV experts agree that the work of the NTSC commitee piggybacking the new color TV system onto the existing B&W infrastructure without requiring any mods to the installed TV set base at the consumers was the finest achievement in American consumer electronics ever (we need to give extra credits because this all was done with vacuum tube based analog circuits). The only issue with the NTSC system which never was fully cured is the phase shifts of the color subcarrier which may occur under certain reception circumstances. This led to the 'tint' control knob on the TV sets where the viewer can adjust the phase in case of the faces / skin of the people on the screen turning green.

PAL - developed by Walter Bruch at Telefunken / Germany in the early 1960s - used a slightly modified NTSC concept in which the 180 degree phase jump on every other TV scan line only is applied to the R-Y' signal, and not to the whole color subcarrier. In the PAL system, the color burst alternates in phase by +/- 45 degrees from the original color subcarrier (which does not change in phase) on every other scan line. This allows the TV to synchronize the 'PAL switch' which controls the sign reversal of the R-Y' signal in the TV receiver.

The purpose of this trick in the PAL system is to enable automatic compensation for color subcarrier phase errors, which in NTSC has to be done manually with the 'tint' control knob. If you work out the vector math, you can see how that goes, and that the correct phase is obtained (for phase errors below a reasonable bound), but the vector gets shorter (desaturation of the color).

This is where you mixed up the two systems. But if you are coming from a country where SECAM was used, this is to be expected. Once you mind is polluted with "bouteilles" and "cloche filters", and frequency modulation of the color difference signals, you can't understand neither NTSC nor PAL anymore, unless you get a lobotomy before re-learning everything.

- Uncle Bernie

jeff d wrote:

Can anyone tell me if the II motherboard is boded to earth ground?

...

On my Apple II+ it is.

Btw, can you post two oscillograms of the video signal showing one line, one in text mode and another for some color game like Choplifter?

Alternatively you can use this Basic program to generate the EBU color bar pattern. Well, not exactly, but at least as close as the Apple II can get to it:

 5  GR : POKE 49234,0

 10  COLOR= 15: GOSUB 100

 20  COLOR= 13: GOSUB 100

 30  COLOR= 7: GOSUB 100

 40  COLOR= 12: GOSUB 100

 50  COLOR= 11: GOSUB 100

 60  COLOR= 9: GOSUB 100

 70  COLOR= 2: GOSUB 100

 80  COLOR= 0: GOSUB 100

 90  IF PEEK (49152) > 127 THEN  GR : HOME : END 

 95  GOTO 90

 100  FOR X = OFFSET TO OFFSET + 4

 110  VLIN 0,47 AT X

 120  NEXT X

 130  OFFSET = OFFSET + 5

 140  RETURN 

If you do the latter, I can do a 1:1 comparison with my Apple II+. The advantage of vertical color bars is that every line is the same, so it doesn't matter on which one you trigger.

UncleBernie wrote:

No, YOU are mistaken. Don't try to argue with a true TV/Video professional who led the design team which designed the very last generation of TV ICs for CRT based TVs in the history of mankind. I know *everything* about PAL, NTSC and SECAM.   

    Obviously Tektorinix engineers know less than you ;) :

 https://www.tek.com/en/support/faqs/why-do-ntsc-and-pal-color-bursts-look-different-when-displayed-waveform-monitor

jeff d wrote:

Can do so later this evening, can you tell me if there's any specific spot on the board which would be best? Can do composito output jack,

The composite output jack, with the monitor plugged in and turned on would be best.

I did a typo in my message #62, the respective company name is Tektronix, of course. 

retro_devices wrote:

UncleBernie wrote:

No, YOU are mistaken. Don't try to argue with a true TV/Video professional who led the design team which designed the very last generation of TV ICs for CRT based TVs in the history of mankind. I know *everything* about PAL, NTSC and SECAM.   

retro-devices, would you please stop trolling on this thread about your half-knowledge, or lack thereof, on legacy analog color TV systems ?

You only embarrass yourself.

Tektronix made  a few fine instruments for analog TV work, such as the Tek 1710 waveform monitor and the Tek 1720 vectorscope, and they certainly know how analog color TV works. But there always are idiots who have no clue and then misinterpret what these fine instruments show.

My above discussion about the color burst phases is based on alternate scan lines only. There also is a schedule for color burst phasing from field to field. And on top of that there is a schedule for frame to field mapping (because movie / film footage has a frame rate incompatible with TV field rates of 50 Hz or 60 Hz).

I'd recommend you to consult the relevant ITU standards for NTSC and PAL broadcasts before you continue to pollute this thread with your nonsense.

Note that you have to pay real money for these standards. They are not in the public domain. This is why all too many contributors to Wikipedia write stuff that is NOT conforming to these standards, out of ignorance. I happen to have a fat binder of the relevant ITU standards  because that has been my daily work for many years. So you can believe me that I know what I'm writing here, and not only from my memory.

- Uncle Bernie

Yes, there is quite a bit of noise. Are you limiting the bandwidth to 20 MHz on your oscilloscope?

Other than the noise, I can't see anything wrong with the signal. For comparison here is what I am seeing on my Apple II+ with a 10:1 probe and the bandwidth limited to 20 MHz:

Monochrome line with all As:

MonochromeAAAA.png

The vertical bars from the Basic program in my previous post:

Bars.png

Zoomed in on the colorburst only:

BarsColorburstZoom.png

retro_devices wrote:

UncleBernie wrote:

Since in pure, standard conforming NTSC the phase of the color subcarrier jumps by 180 degrees every other scan line, all you need to do is to add the digitized video signal of the prior scan line to the present scan line...

Sorry, this is wrong in several ways. I guess you are mistaking to some extent PAL for NTSC.

In this particular case UncleBurnie is 100% correct. In standard interlaced NTSC both the phase of the colorburst and the phase of the visible line interval alternate by 180 degrees relative to the horizontal synchronization pulse with each successive line in a field.

The Apple II+'s non-interlaced NTSC signal however doesn't do this. Its colorburst stays locked and does not alternate its phase between successive lines. I could not check what happens with a standard non-interlaced NTSC signal, since my pattern generator only produces interlaced NTSC.

UncleBernie wrote:

I know *everything* about...

 

 

When you hear someone claiming they know everything that person is usually not sincere (I am refraining from expressing more directly, so far) or in aviation this is called lack of situational awareness. 

What a coincidence --The International Telecommunication Union (ITU) seems to define the same as Tektronix engineers annotated professionally on their page I was referring above:

https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.470-6-199811-S!!PDF-E.pdf

CVT wrote:

In this particular case UncleBurnie is 100% correct. In standard interlaced NTSC both the phase of the colorburst and the phase of the visible line interval alternate by 180 degrees relative to the horizontal synchronization pulse with each successive line in a field.

 

The Apple II+'s non-interlaced NTSC signal however doesn't do this. Its colorburst stays locked and does not alternate its phase between successive lines. 

Do you mean UncleBurnie is often wrong in other not so particular cases? Poor Apple2 computers, they also adhere to that standard. Luckily they do not use interlaced scanning, or our eyes/brains since teenage years would have flickered synchronously long after displayed images were out of sight.

retro_devices wrote:

Do you mean UncleBurnie is often wrong in other not so particular cases?

I simply meant that UncleBurnie was 100% correct in this particular case - something I was able to easily verify with my pattern generator and oscilloscope.

@CVT would you show screenshots of your scope observaitons. What model is your pattern generator?

retro_devices wrote:

@CVT would you show screenshots of your scope observaitons. What model is your pattern generator?

Sure, why not! I use a cheap video converter, which acts as an EBU color bar pattern generator when no input signal is present. Besides if you google "NTSC carrier phase change by 180 degree" you find many mentions of this, so there is no reason to believe that this is a peculiarity of my pattern generator.

The procedure: I simply connect it to my oscilloscope and capture any 4 lines of the vertical bar pattern. Then I zoom-in to the first line, so that I can clearly see the colorburst, the entire white bar and part of the yellow bar and save a reference. I move the reference up by a couple of pixels, so that it's visible:

Newfile3.png

Then I scroll to the second line and line up until the end of the sync pulse and the beginning of the white bar line up. We can clearly see that both the colorburst and the yellow bar are out of phase by 180 degrees:

Newfile4.png

Then I move to the third line - back in phase again:

Newfile5.png

And finally the forth line - once again out of phase:

Newfile6.png

jeff d wrote:

No, I never had  a need to limit bandwidth as the board is a big antenna and whatever it picks up can be an influence... at least that's my thinking.

The monitor has a limited bandwidth, so it also filters out the higher frequencies and they have no effect. If the signal looks good on the oscilloscope with the 20 MHz bandwidth limit on, it's good to go. And yours looks good, except for the Vpp. At 1.64 Vpp it seems a bit high. Notice that mine is 0.9 Vpp and I reduced it precisely in order to avoid this type of artifacts I was getting in text mode on my Trinitron TV.

CVT wrote:

retro_devices wrote:

@CVT would you show screenshots of your scope observaitons. What model is your pattern generator?

 

Sure, why not! I use a cheap video converter, which acts as an EBU color bar pattern generator when no input signal is present. Besides if you google "NTSC carrier phase change by 180 degree" you find many mentions

There are "mentions"  but they state the colorburst phase is indeed changed by 180 degrees but from FRAME to FRAME, not within a single frame. Just point one that describes consecutive llines within a phase change, please. 

Maybe this will help. The NTSC subcarrier frequency is 455/2 times the horizontal line frequency. Or, if you prefer, the line frequency is derived from the subcarrier by dividing by 227.5. Either way, you can see that there is an extra one-half cycle of subcarrier between each consecutive horizontal line. This gives the phase change we're talking about, although it's not technically correct to call it a phase "jump." The subcarrier maintains a constant phase but the sync pulse (and the rest of the horizontal line) shift by half a cycle every other line. The scope captures CVT presented in post #73 clearly show this.

retro_devices wrote:

There are "mentions"  but they state the colorburst phase is indeed changed by 180 degrees but from FRAME to FRAME, not within a single frame. Just point one that describes consecutive llines within a phase change, please. 

 

Sure, why not: https://msys-mv.blogspot.com/2011/01/why-is-ntsc-color-carrier-frequency.html

CVT wrote:

 

Sure, why not: 

You  must be joking -- an ARM blog as a reliable source of information ;) Just read this sentence from that source: " To make this possible, the carrier phase must change by 180 degree for each line and also for each frame." If it is changed each line, of course it is changed in frames.  

retro_devices wrote:

CVT wrote:

 

Sure, why not: 

You  must be joking -- an ARM blog as a reliable source of information ;) Just read this sentence from that source: " To make this possible, the carrier phase must change by 180 degree for each line and also for each frame." If it is changed each line, of course it is changed in frames.  <

You asked for one mention and I gave you one. There are many others, you can find them on your own. This is enough to prove beyond a reasonable doubt that what I am seeing in my pattern generator is not a peculiarity of this one device.

That being said, if you find a source of interlaced NTSC that doesn't follow this, please let us know. I am really interested in this topic, since I am planning to add color to the 480i mode of my card and I want to do it correctly.

P.S. I just realized something: I have a second device that can output standard NTSC! It's a digital TV receiver and two of the channels in Sofia happen to broadcast a color bar pattern. Will check it later today and share the results.

Well, no surprise there! The digital TV receiver behaves exactly like the pattern generator. Here is the second line against the reference of the first line:

IMG_7880.JPG

Yes. That's true. But it is true that Tektronix engineers were also right!  ;)  Despite ridiculous difficulty to freely obtain this ancient and morally old standard and avoiding empirical and non-reliable controversial partial blog/forums sources, I found clear, complete and reliable information in this US patent:

https://patentimages.storage.googleapis.com/8a/5e/9f/3354098e909db6/US4660074.pdf

 retro_devices wrote:

I found clear, complete and reliable information in this US patent...

 The only thing clear in this patent is that it DOES NOT describe the standard NTSC format. It may be a clever way to eliminate dot crawl - and may be "compatible" with NTSC - but is certainly does not describe what is being discussed here. In fact, on col 2, lines 49-51 of the patent, it states "Consequently,there will be 227 cycles of the color subcarrier per line, instead of 227.5 cycles," which directly confirms the phase inversion between consecutive lines of a "pure" NTSC signal.

Yes, I agree that no single source is that reliable by itself. This is why I go with multiple sources and add them up. I mean if two separate device implementations + an ARM programmer from the Net + a patent from 1987 + a diagram from a site called ntsc-tv.com (attached below) + UncleBurnie all tell you the same thing, you can be virtually certain that it is so. Actually that many might be an overkill, but we're having fun here.

Source: https://www.ntsc-tv.com/ntsc-index-06.htm

sprfrm.png

jeffmazur wrote:

 retro_devices wrote:

I found clear, complete and reliable information in this US patent...

 The only thing clear in this patent is that it DOES NOT describe the standard NTSC format. It may be a clever way to eliminate dot crawl - and may be "compatible" with NTSC - but is certainly does not describe what is being discussed here.

What is wrong exactly with the description in column 2, rows 17-35?  It answers perfectly my questions and previous doubts.

retro_devices wrote:

What is wrong exactly with the description in column 2, rows 17-35?  It answers perfectly my questions and previous doubts.

 

Yes it does answer the question about phase reversal completely! Specifically, the part that says "inverting the suncarrier phase 180° for each successive line." That is what we have all been trying to tell you in the last several posts (what you asked for in post #77) . So are you now in full agreement and your "previous doubts" were unfounded?

Oh, what a "fight club" because of 'retro-devices' being an unbeliever in how NTSC works.

But the info posted by 'CVT' in post #85 should clarify a lot of things. That website is a very nicely made one, with pictures that explain a lot.

Also note that that picture got "frame" and "field" right. It was mixed up or used in an imprecise way in previous posts.

Here are a few further comments to make the link to the Apple II and to the issues it may have with color pictures:

- Woz developed the Apple II from the Apple-1, which used the same 14.3181818 MHz master clock, the same "all on one motherboard with a slot card connector" concept, and the same cassette interface modulation system, except that the Apple II added a checksum byte, which the Apple-1 ACI did not have (impossible to do in a  256 Bytes firmware PROM for all the cassette interface code).

- Woz wanted the Apple II to be a "game machine" with colorful graphics and "paddle" input devices, so he could run games like "Pong" and "Breakout" (Source: "iWoz", his autobiography)

- In the process of developing the Apple II hires graphics, he discovered that if he wanted to use the 'color artifacting' method to make colored vertical lines (by strategically placing dots at the right places, as it is done in all Apple II hires games), these vertical lines would be jaggy, because to get the same color, he would need to alternate the dot positions from scan line to scan line on even or odd positions. His solution: violate the NTSC standard and dispense with the 180 degree color burst phase change from scan line to scan line. He did this by increasing the scan line duration from 227.5 color subcarrier periods to 228 color subcarrier periods. But for doing this without losing the  PHI1/PHI2 interleaved access to the RAM (PHI1: video scanner accesses the RAM, PHI2: 6502 accesses the RAM), he had to invent a clever trick to get the timing right. This trick is the introduction of the 'long CPU cycles'. It was inventive and truly pioneering work, which earned Woz the U.S.-Pat. 4,136,359, titled "MICROCOMPUTER FOR USE WITH VIDEO DISPLAY". You can find it here:

https://commons.wikimedia.org/wiki/File:US4136359_Microcomputer_for_use_with_video_display.pdf

To cite from the abstract of the patent:

" A microcomputer including a video generator and timing means which provides color and high resolution graphics on a standard, raster scanned, cathode ray tube is disclosed. A horizontal synchronization counter is synchronized at an odd-submultiple of the color subcarrier reference frequency. A "delayed” count is employed in the horizontal synchronization counter to compensate for color subcarrier phase reversals between lines for the non-interlaced fields. This permits vertically aligned color graphics without substantially altering the standard horizontal synchronization frequency. Video color signals are generated directly from digital signals by employing a recirculating shift register. "

Here you have it. Note the text "... color subcarrier phase reversals between lines ..." which is incorrect, if we are nit-picking. Neither in NTSC nor in PAL, the color subcarrier itself will change phase from scan line to scan line. Only the color burst will change phase from scan line to scan line. And in case of NTSC, this is just due to the fact that a NTSC standard conforming scan line is exactly 227.5 periods of the color subcarrier long.

(There are several reasons why the color subcarrier phase must stay constant from scan line to scan line. One of the reasons is the difficulty of synchronizing the color subcarrier oscillator in the TV to the color burst. Since the color burst is short, it would be impossible to 'pull' the crystal oscillator in the TV to the opposite phase once each scan line. But if the color subcarrier phase stays the same, only very slight adjustments to the oscillator are necessary. This can be done with simple analog circuits available at the time NTSC and PAL were introduced. Digital integrated circuits for TV did not exist until many decades later. Do not underestimate the technical challenge to synchronize a local crystal oscillator to the color burst. There are lots and and lots of patents out there seeking to solve the issues with that. SECAM has the advantage that no color burst is used and no crystal is needed in the TV receiver. Crystals of the required quality were expensive back then. So this is often cited as a big advantage of SECAM. But alas, SECAM transmits only one color difference signal per scan line, using frequency modulation, which avoids the phase error issues leading to the 'tint' adjustment knob as seen with NTSC. So SECAM needs a delay line to store the color difference signal of the previous scan line to have both color difference signals available for the present scan line. This delay line was a glass block with ultrasound transducers. Which is not exactly cheap to make with the required precision. So the argument with saving the crystal may be a wash: they eliminated the expensive crystal and added the expensive delay line. But I think that once the French had solved the issues with mass producing these delay lines, it may have been cheaper than the crystal. In any case, the technical advance in these ultrasound delay lines and the demonstrated ability to mass produce them may have inspired Walter Bruch to use such a delay line for his PAL system)

But back to the Apple II. Once you have read (and understood) Woz' patent, you will understand how the Apple II color graphics system works, and why it was innovative enough to grant him a patent. (I think that Woz should have tried to patent the motherboard architecture as such, with the expansion slots, an idea which IBM stole for the first PC).

Here are the downsides of Woz' patented solution:

- the CPU bus cycle rate is locked to the video generator cycles, and this makes it difficult to run the 6502 faster than the measly ~1 MHz. It is possible, though, when the 6502 is put into its own "island", as I did with my "Replica 2e" project, which has its own thread: 

https://www.applefritter.com/content/uncle-bernies-replica-2e-ww-prototype-apple-iie-replica

- yet another problem, which is very relevant to some of the issues the original OP mentioned along the thread, is that the whole Apple II system runs from clocks derived from the 14.3181818 MHz master oscillator by division. The video section in particular clocks many ICs with that frequency or with half of it. And the whole ground and power rails in that system will 'ring' and be polluted (as we can see in the oscillograms provided by the OP)

This 'pollution' will inevitably have some harmonics or subharmonics infesting the video signal, which match the color subcarrier frequency. And some TVs (like the 1990s era CRT based TV I have) are sensitive enough to 'pick' a false color burst out of that mess. So despite of the absence of the real color burst in text modes, the TV will wrongly think it's color mode, and the text will have colorful noise on certain vertical edges. These false colors are never stable because there is no real color burst, and so the phase of the subcarrier oscillator in the TV will wander about. This is even more annoying that having static 'artifact colors' from the vertical edges of the text characters. The remedy is to disable the transistor on the Apple II motherboard which supresses the color burst in text lines. This "improvement" was added to the Apple II to avoid color artifacting in text mode seen in the earlier motherboard revisions, but if you have a sensitive TV, then this "improvement" makes matters worse (I could not stand it, and could not do any programming work with the Apple II in that state).

I tried out several remedies as published by other people, but none of them worked with my Apple II and my TV. So I took that "color burst suppression" out from an Apple II clone and this got me color artifact impaired text on my color TV, but at least these artifacts were static and did not change all the time. I also added a B&W monitor to get a much improved text. Only after these measures  I was able to work for hours on the Apple II without getting a headache from the text display.

I think it is impossible to "clean up" the noise on the Apple II motherboard power and ground rails enough to fully remedy the problem for all TVs. Some TVs are more sensitive than others. The trick of course is to clean up the video signal just enough that the TV never misidentifies the noise as a valid color burst. For some TVs this may be possible. For others, not.

- Finally, the issue with modern flat screen TVs. Since the Apple II video signal violates the NTSC standard (ever so slightly, no issue for analog TVs, except for the noise problem mentioned above), you can't expect that a flat screen TV or monitor will produce the right colors or even recognize the signal. I have a whole "zoo" of such specimen around and some show just black and white, while others, more modern ones, don't show a picture at all (or show the error message "no signal").

This is called "technical progress", folks. Mankind has lost the technology to display Apple II color signals. They also lost the technology to land a man on the moon and bring them safely back to Earth. Recent events with the Boeing "Starliner" being too dysfunctional to bring back the crew (now stranded on the ISS) also shows the consequences of employing DIE and WOKE "engineering" teams. I'd have expected that a rocket designed by DIE and WOKE would blow up on the launch pad, if the engines would ignite at all. But it turned out they used a proven launch vehicle (Atlas V N22) but here is the catch: it uses Russian made RD-180 engines in the first stage. Only the upper stage uses rocket engines "Made in the USA". How long will they be able to make such engines ? One of the movies I can recommend is "Idiocracy" of Y2006. Back in 2006  thought it's crap and an ill-conceived comedy. I was mistaken. It now looks more and more like a documentary of the future we are hurtling to.

- Uncle Bernie

jeffmazur wrote:

retro_devices wrote:

What is wrong exactly with the description in column 2, rows 17-35?  It answers perfectly my questions and previous doubts.

 

That is what we have all been trying to tell you in the last several posts .

Why "We"?!! You were not part of those who were explaining anything in this topic!.Propably you were not sure of the answer too and silently were reading the topic. Once everything was clear, you decided to participate on the "right side".

jeff d wrote:

...

So I'm stuck with htis crappy RCA monitor.

...

You can't use it to diagnose a video signal though. Surely you can pick up a 14" CRT TV from the 90s anywhere in Europe for under $50 that supports NTSC and has SCART.

Take this little car rear view camera LCD display for example:

Later.jpg

It supports both PAL and NTSC and I use it all the time when fixing stuff. However when I connect it to my Apple II+ it displays absolutely nothing!

jeff d wrote:

My color ocmposites are on the back burner in various states. one has a cracked motherboard around the flyback, the others have equally disturbing issues. So I'm stuck with htis crappy RCA monitor.

Due to similarities in signal timings, non-composite inputs can sometimes accept Apple II video for an acceptable picture.  Look for these other possible inputs on your monitor:

• S-Video - feed the Apple's composite output into the Y (luma) for a high resolution monochrome picture in both text and graphics modes
• YCbCr Component Video - feed the Apple's signal into the Y port for a high resolution monochrome picture in text mode only (no graphics)
• ColorStream Component Video - feed the Apple's composite signal into the green Y socket for monochrome text (no graphics)

Many monitors made for the North American market support 60Hz text modes as 240p or 480i through their component video inputs.  Graphics modes are not supported, probably because the color burst interferes with horizontal sync.

Picture #1 - an inexpensive S-Video breakout cable permits you to feed Apple composite into the Y input (white), or you can build your own from a spare S-video cable like Chris Torrence did in one of his videos

IMG_1325.JPG

Picture #2 - when connected through S-video, a TV or monitor displays a high-resolution monochrome image reminiscent of the Monitor ///

IMG_1324.JPG

Picture #3 - ColorStream or YCbCr component inputs, connect the Apple to the green Y input (for text mode only)

IMG_1326.JPG

Picture #4 - Apple composite signal is a bit too "hot" for component inputs, so text may be smeared...but it's definitely legible

IMG_1331.JPG