PDA

View Full Version : Differences between IBM CGA cards



reenigne
April 6th, 2012, 08:55 AM
Anybody know what the difference is between the various IBM CGA card part numbers? I know of four: 1501486, 1504910, 1501981 and 1501982. The one I have is a 1501486 and as far I can tell the circuit is the same one as in the XT Technical Reference Manual ibm_techref_v202_3.pdf available from http://www.retroarchive.org/dos/docs/index.html, even down to the composite DAC resistor values being 3.3K, 13K, 5.6K and 2.2K. It looks like the ones at http://oldibmpc.sitesled.com/Expansion%20cards/IBM%20Corp.html, except the board is red instead of green.

I found a high-res image of a 1501981 at http://www.yjfy.com/museum/video/Video_8-bit_ISA.htm and it looks identical as far as the logic is concerned, but there are a few more resistors and the resistor values look different. I'm wondering if they were changed to make the composite signal adhere better to the NTSC standard and therefore be more consistent between different monitors, but that's just a guess.

The only other CGA schematic I've found is the one in IBM_5150_Technical_Reference_6025005_AUG81.pdf available from http://www.minuszerodegrees.net/manuals.htm#IBM but that doesn't list any resistor values.

Anybody here have any more information? If you have a CGA card with part number other than 1501486, I'd be interested in running some tests on it, especially if it's connected to a composite monitor. Thanks!

modem7
April 6th, 2012, 03:06 PM
The circuit diagram in the Options and Adapaters (http://www.minuszerodegrees.net/oa/oa.htm) manual shows DAC resistor values (R5/R6/R7/R8) of 680, 1K, 680 and 750.
And R1 (transistor emitter) there is 75, instead of 100.

reenigne
April 6th, 2012, 05:40 PM
The circuit diagram in the Options and Adapaters (http://www.minuszerodegrees.net/oa/oa.htm) manual shows DAC resistor values (R5/R6/R7/R8) of 680, 1K, 680 and 750.
And R1 (transistor emitter) there is 75, instead of 100.

Ooo, thanks - I had somehow managed to completely overlook the Options and Adapters manual.

That's really interesting - it seems that this version of the the CGA doesn't include the -BLANK signal in the composte output, but does include the "G OUT" (green) signal, which is another way (other than the resistor values) that the composite colours will differ between CGA versions.

Jorg
April 6th, 2012, 05:43 PM
These are the two I got but I'd have to make a better pic.
http://i30.photobucket.com/albums/c333/SockEwing/IMGP2921.jpg

modem7
April 6th, 2012, 07:07 PM
I only have two IBM CGA cards, but one of those is the eary version (black bracket).
A photo comparing the two is at http://www.minuszerodegrees.net/5150/early/5150_compare_cga_adapter.jpg

Some differences:
1. Circuitry in top-right corner moved to the left to accomodate new type of mounting bracket.
2. Different value DAC resistors.
3. Extra resistors added.

reenigne
April 6th, 2012, 09:06 PM
Awesome - thanks again, modem7.

Based on the evidence I've seen so far, the chronology seems to be this:

The first CGA card was the 1804472 with the black bracket. This is the one whose schematic is in ibm_techref_v202_3.pdf. It has 7 resistors in the composite output stage (plus 1 for the ROM for a total of 8).

Next came the 1501486 (PCB number 1501453). This has the addition of four 30 ohm resistors for the digital output pin header, and moved the digital output pin header slightly to accomodate the new mounting bracket. It also has 7 resistors in the composite output stage (12 resistors altogether).

Then I think was the 1504910, and I think this is the one whose schematic is in IBM_5150_Technical_Reference_6025005_AUG81.pdf (but I'm not completely sure, I haven't seen an image of this board or of a board with this schematic). This schematic doesn't show the 30 ohm resistors, but I suspect that is an oversight and that they'll be on the board since they were there on the earlier 1501486. This schematic adds the red, green and blue signals onto the composite output so that if you're using a monochrome composite monitor you'll get 16 shades of grey instead of 4. There are 9 resistors in the composite output stage in this schematic (probably 14 altogether). With this change, there are now two resistors instead of three at the emitter of the transistor. These seem to be relatively rare.

Finally came the 1501981 (PCB number 1501982), whose schematic is in OA%20-%20IBM%20Color%20Graphics%20Monitor%20Adapter%20(C GA).pdf. This has several more changes to the composite output stage: the removal of the -BLANK signal, a 75 ohm resistor instead of 100 ohm on the emitter of the transistor and resistors between the base of the transistor and the 0V and +5V lines (130 and 360 ohms respectively). These had 10 resistors in the composite output stage (15 altogether). Some of these had a HD6845P CRTC instead of the usual MC6845P.

twolazy
April 6th, 2012, 10:02 PM
8433 I just so happen to have two I believe, have yet to tear open my 5150 to see if the other matches, I think it is green though, this one is my backup! (Came out of my 1st 5162, believe its the stock) :D

BTW, this is a 1501981APS.

Great Hierophant
April 7th, 2012, 06:39 AM
Perhaps the 1504910, which adds more gray shades would likely be seen in stock IBM PC Portables, as it had the mono composite monitor built in. But wouldn't adding the red, green and blue signals directly on the composite output change the color in some way?


Awesome - thanks again, modem7.

Based on the evidence I've seen so far, the chronology seems to be this:

The first CGA card was the 1804472 with the black bracket. This is the one whose schematic is in ibm_techref_v202_3.pdf. It has 7 resistors in the composite output stage (plus 1 for the ROM for a total of 8).

Next came the 1501486 (PCB number 1501453). This has the addition of four 30 ohm resistors for the digital output pin header, and moved the digital output pin header slightly to accomodate the new mounting bracket. It also has 7 resistors in the composite output stage (12 resistors altogether).

Then I think was the 1504910, and I think this is the one whose schematic is in IBM_5150_Technical_Reference_6025005_AUG81.pdf (but I'm not completely sure, I haven't seen an image of this board or of a board with this schematic). This schematic doesn't show the 30 ohm resistors, but I suspect that is an oversight and that they'll be on the board since they were there on the earlier 1501486. This schematic adds the red, green and blue signals onto the composite output so that if you're using a monochrome composite monitor you'll get 16 shades of grey instead of 4. There are 9 resistors in the composite output stage in this schematic (probably 14 altogether). With this change, there are now two resistors instead of three at the emitter of the transistor. These seem to be relatively rare.

Finally came the 1501981 (PCB number 1501982), whose schematic is in OA%20-%20IBM%20Color%20Graphics%20Monitor%20Adapter%20(C GA).pdf. This has several more changes to the composite output stage: the removal of the -BLANK signal, a 75 ohm resistor instead of 100 ohm on the emitter of the transistor and resistors between the base of the transistor and the 0V and +5V lines (130 and 360 ohms respectively). These had 10 resistors in the composite output stage (15 altogether). Some of these had a HD6845P CRTC instead of the usual MC6845P.

reenigne
April 7th, 2012, 07:23 AM
Perhaps the 1504910, which adds more gray shades would likely be seen in stock IBM PC Portables, as it had the mono composite monitor built in. But wouldn't adding the red, green and blue signals directly on the composite output change the color in some way?

It won't change the composite colours in the normal BIOS mode 6 with palettes 8, 7 or 15 (except possibly for a difference in brightness and/or contrast), but it will change the other composite colours.

According to my calculations, the composite output for 1501486 is approximately 0.72*CHROMA + 0.28*I, giving levels of (0, 0.28), (0, 0.72) and (0, 1) with those three palettes respectively.

The composite output for 1501981 is 0.29*CHROMA + 0.32*I + 0.07*B + 0.22*G + 0.1*R, giving levels of (0, 0.32), (0, 0.68) and (0, 1) respectively (since CHROMA=R=G=B for these palettes).

I'll make a new version of my all-modes, all-palettes CGA colour chart to show all the differences between the two major CGA versions.

Great Hierophant
April 7th, 2012, 08:29 AM
Look forward to it. I assume when you mean "palettes 8, 7 or 15" you mean dark gray, light gray and white, respectively. Palette 0 is obviously black. I assume games used white to offset any darkening from the composite video. I have never heard of a game using one of the remaining actual color choices for the foreground, but it is not impossible.

Do you think its possible to implement something like a color chart to run on a vintage machine?

reenigne
April 7th, 2012, 09:27 AM
I assume when you mean "palettes 8, 7 or 15" you mean dark gray, light gray and white, respectively. Palette 0 is obviously black. I assume games used white to offset any darkening from the composite video.

Right, right and right.


I have never heard of a game using one of the remaining actual color choices for the foreground, but it is not impossible.

Yeah, I'm kind of surprised that they didn't - some fantastic lighting effects could have been done by changing the palette register to simulate changing the colour of the incident light.

All the games which use 320x200 modes will have different composite colours on the different CGA cards, though.


Do you think its possible to implement something like a color chart to run on a vintage machine?

Yes, and in fact that's exactly what my icon is a picture of (mode 6, colour burst enabled, 1501486 with a palette change every 12 scanlines). The program should work on any machine which implements the CGA status register correctly - I'll convert it to a .com file so others can run it more easily (at the moment it requires my keyboard port code loader hack) and make it do the other modes as well.

I'm also tempted to make a modification to my 1501486 to add a second composite output which duplicates the 1501981 DAC so I can calibrate my simulation of that too.

Great Hierophant
April 7th, 2012, 12:17 PM
I am not sure how widely known it was that you could change the pixel color in Mode 6. It is obliquely mentioned in the first version of the IBM PC Tech Reference (which also mentions using IRQ2 for vertical retrace). I know that Sierra did release some of its SCI0 or SCI1 16-color games with a mode 6 driver that used blue instead of white, but the color burst is not enabled. http://vogons.zetafleet.com/viewtopic.php?t=9765&postdays=0&postorder=asc&start=180

reenigne
April 7th, 2012, 02:55 PM
Okay, I've put a little program at http://www.reenigne.org/misc/chart.com that displays the chart as shown in my icon and cycles through all the graphics modes (and foreground palettes for 320x200 modes) when you press a key. Pressing Esc should take you back to DOS. I haven't actually tried it in DOS yet, so it might be broken if the timer interrupt takes too long, and/or exiting to DOS might be broken.

Great Hierophant
April 8th, 2012, 05:48 AM
I tried the program on my Tandy 1000SX on an RGB monitor using MS-DOS 5.0. The program works correctly and exits correctly. It does not quite work correctly in DOSBox. It cycles through eight screens :

1a00 - Mode 6 All Foreground Colors Color Burst Enabled
1e00 - Mode 6 All Foreground Colors Color Burst Disabled (identical to Color Burst Enabled on RGB monitor)
0a00 - Mode 4 Palette 0
0e00 - Mode 5 Palette 0 (identical to Palette 1)
0a10 - Mode 4 Palette 0 Intense
0e10 - Mode 5 Palette 0 Intense (identical to Palette 1)
0a20 - Mode 4 Palette 1
0e20 - Mode 5 Palette 1 (identical to Palette 0)
0a30 - Mode 4 Palette 1 Intense
0e30 - Mode 5 Palette 1 Intense (identical to Palette 0)

1a/1e/0a/0e - Value in Mode Control Register
00/10/20/30 - Value in Color Select Register

Great Hierophant
April 8th, 2012, 06:33 AM
Works just fine with my IBM PC 5150 with a 1501981 CGA card. So many colors!

Numbers across top represent either background color (Modes 4-5) or foreground color (Mode 6).

reenigne
April 8th, 2012, 09:29 AM
Oh good.

I'm not surprised it doesn't work in DOSBox - changing the mode register on specific scanlines is a rather unusual thing to do, as is using graphics modes with the CRTC registers set up for text mode (8 scanlines per character row). I'm surprised it does as well as it does, though - it does successfully switch palettes every 12 scanlines.

I've updated the CGA colour chart (http://www.reenigne.org/misc/cga_composite.png) with a couple of fixes - one minor one (colour 8 is darker) and one major one (corrected the gamma, so everything's darker). I've second CGA colour chart for the 1501981 (http://www.reenigne.org/misc/cga_composite_1501981.png). Comparing the two side by side, lots of differences are apparent but they really all come down to the chroma colours having different lumas. This is particularly noticable when the colour burst is disabled because in that case the chroma colours look all the same when they don't have different lumas.

The 1501486 chart still doesn't look quite the same as the colours on my machine - I think some of the chroma waveforms are shifted slightly due to logic delays which, while much less than a clock cycle, still correspond to a visible difference in colour.

I might rearrange these charts so that the digital ouptuts, monochrome composite outputs and colour composite outputs are not interspersed - it'd probably be easier to understand and would correspond to the output of the chart.com program.

Great Hierophant
April 8th, 2012, 11:16 AM
A comparison of the chart leads to some interesting differences. The 1501486 seems to show more colors and brighter ones generally, while the 1501981 shows more grayscale shades. It seems like each is best suited to a particular type of monitor.

Great Hierophant
April 8th, 2012, 04:04 PM
The IBM PCjr. also supports color through the composite video port, but the logic from the Technical Reference to get there seems much more straightforward than on any CGA board. I know it supports 16 shades of gray and obviously direct color, but does it even support artifact color?

reenigne
April 8th, 2012, 05:34 PM
The IBM PCjr. also supports color through the composite video port, but the logic from the Technical Reference to get there seems much more straightforward than on any CGA board. I know it supports 16 shades of gray and obviously direct color, but does it even support artifact color?

I think it must do. I just checked the PCjr Technical Reference manual and it uses a gate array to replace much of the CGA's discrete logic, but there is a composite colour output signal, and the composite DAC output stage looks pretty similar to the 1501981 version, though the resistor values are slightly different (750, 1.1K, 2.2K and 3.3K instead of 680, 1K, 2K and 3K for I, G, R and B respectively).

I'm sure it supports artifact colour because (given that chroma colour works) it's harder to make artifact colour not work than it is to make it work. I'm not sure whether it uses the same color burst phase as CGA or as Tandy 1000 though (or even something else entirely).

VileR
April 9th, 2012, 12:53 PM
Thumbs up for an interesting (and useful!) thread, folks.


I just checked the PCjr Technical Reference manual and it uses a gate array to replace much of the CGA's discrete logic, but there is a composite colour output signal, and the composite DAC output stage looks pretty similar to the 1501981 version, though the resistor values are slightly different (750, 1.1K, 2.2K and 3.3K instead of 680, 1K, 2K and 3K for I, G, R and B respectively).

Check out this video at approximately 07:47 - http://www.youtube.com/watch?v=s5a6jKUkjlA
The 16 color bars on the PCjr boot screen show the same effect as the 1501981, so that looks right.


Perhaps the 1504910, which adds more gray shades would likely be seen in stock IBM PC Portables, as it had the mono composite monitor built in.

Not my photo (credit goes to RJBJR from this forum), but here's what the output looks like on a 5155 Portable:

http://i.imgur.com/aMlpws.jpg (http://i.imgur.com/aMlpw.jpg)

Looks just like the older CGA revision (1501486), with the "greys" being the same. Interestingly, the PC Portable was released only one month before the PCjr, but there could have been minor revisions of both.

Great Hierophant
April 9th, 2012, 05:38 PM
I presume that the resistors that connect the R,G,B & I signals give the composite video its direct color, which is what makes solid colors appear pretty close to the real deal. But the CGA had a portion of its logic, including green and magenta signals, tied to flip flops and a demultiplexer, which I would guess is where the artifact color comes into play. So does the PCjr.s gate array replicate that?

I also count four shades of gray on that screen in addition to black, so how is that explained?


Thumbs up for an interesting (and useful!) thread, folks.



Check out this video at approximately 07:47 - http://www.youtube.com/watch?v=s5a6jKUkjlA
The 16 color bars on the PCjr boot screen show the same effect as the 1501981, so that looks right.



Not my photo (credit goes to RJBJR from this forum), but here's what the output looks like on a 5155 Portable:

http://i.imgur.com/aMlpws.jpg (http://i.imgur.com/aMlpw.jpg)

Looks just like the older CGA revision (1501486), with the "greys" being the same. Interestingly, the PC Portable was released only one month before the PCjr, but there could have been minor revisions of both.

reenigne
April 9th, 2012, 07:20 PM
I presume that the resistors that connect the R,G,B & I signals give the composite video its direct color, which is what makes solid colors appear pretty close to the real deal.

Not quite - these signals generate a monochrome signal from the RGBI image. On a 1501486 it's just the I signal, on a 1501981 it's a signal corresponding to what you'd see if you took a black and white photo of an RGB monitor displaying the same image.


But the CGA had a portion of its logic, including green and magenta signals, tied to flip flops and a demultiplexer, which I would guess is where the artifact color comes into play.

Actually the flip flops and multiplexer generate the direct colour (what I call chroma colour) - i.e. the 6 different hues you see if you draw solid blocks of colour in text mode. They work by generating 3.58MHz signals at various phases. Composite monitors (and NTSC) transmit colour pictures in a single signal by having the phase of the 3.58MHz component of the signal (with respect to the phase of the color burst signal) corresponding to the hue, and the amplitude of this signal correspond to the saturation. So by adding one of these 6 signals to the composite output, we get one of the 6 different hues (the multiplexer also has two DC signals - logic 0 and logic 1, for black and white respectively).

It's no coincidence that 3.58MHz is 1/4 of the PC's crystal oscillator frequency (14.318MHz) and 3/4 of the CPU clock frequency. The period of that signal frequency also corresponds to the amount the beam moves horizontally when drawing 4 "hi-res" pixels or 2 "low-res" pixels. That means that we have another way to generate a 3.58MHz signals - by drawing a pattern on the screen that repeats every 4 "hi-res" pixels (or 2 "low-res" pixels) horizontally. And in fact that is exactly what the artifact colours are. So these colours continue to work even if the multiplexer isn't outputting any of the 3.58MHz chroma signals in the visible part of the signal.

Another way to think about artifact colours is that each pixel has a colour which depends on it's horizontal position in that 3.58MHz cycle. So in hi-res mode, pixels with horizontal coordinates 0, 4, 8, 12... are yellow, 1, 5, 9, 13... are red, 2, 6, 10, 14... are blue and 3, 7, 11, 15... are cyan. These pixels are wider than 1/640th of the screen on a composite monitor - they're more like 1/160th of the screen, so you can make solid colours with different combinations of these 4 "primary" colours.


So does the PCjr.s gate array replicate that?

The gate array takes the data from video memory or character ROM at the address generated by the CRTC (and the other signals from the CRTC) and generates the pixel colour data (as RGBI and chroma for composite) and output sync signals.


I also count four shades of gray on that screen in addition to black, so how is that explained?

On a monochrome composite monitor, the 3.58MHz signals won't be interpreted as colours, so you'll see them "how they really are" - as patterns of vertical lines with different horizontal offsets, repeating every 4 "hi-res" horizontal pixels. If you look closely at RJBJR's picture you'll see them. Because this is a 1501486-type CGA card, the output consists of this chroma signal from the multiplexer plus the intensity signal. So that's how we get our 6 intensities: three possible chroma outputs (off, oscillating at 50% duty cycle, on) times 2 possible luma ("I" bit) outputs (off, on).

I also know that this image was made with the color burst signal being on - when it's disabled it's not just the color burst signal just after the horizontal sync pulse that's turned off - the CGA card also disables the 6 chroma signals going into the chroma multiplexer with inputs on the flip-flops that make them all go high. So if color burst was disabled then you'd only see 4 intensities - the 12 bars in the middle would be the same as the 2 bars on the right.

Trixter
April 10th, 2012, 08:01 PM
Yeah, I'm kind of surprised that they didn't - some fantastic lighting effects could have been done by changing the palette register to simulate changing the colour of the incident light.


Many games changed both the background index and the palette intensity for some special effects. Defender of the Crown uses the "dim" red/brown/green palette for every scene except when you rescue the maiden, then to simulate a more harshly-lit room, it switches to the hi-intensity version of said palette. I've seen similar changes whenever there is a "shot" or "bang" in a game. For background color changes, there are many examples; probably the easiest to view is King's Quest which sets background to blue so that it has a pure red, green, and blue to work with in mixing colors (to poor effect, unfortunately).

This is all with an RGB monitor. I have never seen a CGA game that intentionally tried palette tricks to change the composite colors. In fact, I don't think I've seen a single CGA game that attempted anything other than the "default" composite colors.

Trixter
April 10th, 2012, 08:06 PM
Okay, I've put a little program at http://www.reenigne.org/misc/chart.com that displays the chart as shown in my icon and cycles through all the graphics modes (and foreground palettes for 320x200 modes) when you press a key. Pressing Esc should take you back to DOS. I haven't actually tried it in DOS yet, so it might be broken if the timer interrupt takes too long, and/or exiting to DOS might be broken.

Works beautifully on my stock 5160 connected to a JVC broadcast monitor. There is some flicker on the left-hand side of the screen; if you have the source anywhere, I'd be curious to see if I can eliminate it.

reenigne
April 10th, 2012, 08:43 PM
I was hoping you'd find this thread, Trixter - I knew you'd like that chart program!


I have never seen a CGA game that intentionally tried palette tricks to change the composite colors. In fact, I don't think I've seen a single CGA game that attempted anything other than the "default" composite colors.

Which can't just be because it wasn't mentioned that you could do that in the technical reference manual, surely? Lots of games used tricks that went above and beyond that, and modifying the palette register in that mode is a pretty natural experiment to do. Perhaps even back then it was known that the results wouldn't necessarily be consistent between monitors and graphics cards unless you used grey or white.


Works beautifully on my stock 5160 connected to a JVC broadcast monitor. There is some flicker on the left-hand side of the screen; if you have the source anywhere, I'd be curious to see if I can eliminate it.

It's here (https://github.com/reenigne/reenigne/blob/master/8088/cga/artifact/chart.asm). The flickering happens because the palette change happens at a different place depending on exactly when the "waitForDisplayDisable" loop finishes. In 640x200 mode this doesn't matter because the overscan area is always black but in 320x200 mode, the palette register controls the overscan colour as well as a colour in the visible area so the palette change is visible. I'm not sure how to make it stable without making the whole thing completely CPU-timed (and therefore very non-portable). I suppose you could do it with a timer interrupt like California Games does, but then you'd have some fiddly work to make the switch happen at a consistent place between runs of the program. Let me know if you manage it.

I was looking at the schematics again earlier and noticed another difference between the ibm_techref_v202_3.pdf and OA%20-%20IBM%20Color%20Graphics%20Monitor%20Adapter%20(C GA).pdf schematics - as well as correcting a few mistakes in the older schematic and the composite differences I mentioned before, there is also a change to how the horizontal sync pulse is sequenced (the logic around U64). I think what it's doing is asserting the horizontal sync pulse twice on each scanline, once for the normal sync pulse itself and then again shortly afterwards to reduce the voltage during the color burst signal (which might otherwise be too high because of the added luma). Though this seems like it would halve the length of the vsync pulse, so maybe I'm wrong. Too bad they didn't fix the broken color burst in 80-column mode while they were tinking with that bit! Though I guess 80-column mode on composite wasn't really supported anyway because the text is so unreadable.

Trixter
April 11th, 2012, 12:11 PM
I was hoping you'd find this thread, Trixter - I knew you'd like that chart program!

You know me well ;-) Next time, feel free to email me -- I know I'm not great at returning email, but I do read everything I get...



Perhaps even back then it was known that the results wouldn't necessarily be consistent between monitors and graphics cards unless you used grey or white.


I concur, although my personal preference is to do so anyway, because even if the colors might be inconsistent across customers, there are still more of them.



It's here (https://github.com/reenigne/reenigne/blob/master/8088/cga/artifact/chart.asm). The flickering happens because the palette change happens at a different place depending on exactly when the "waitForDisplayDisable" loop finishes. In 640x200 mode this doesn't matter because the overscan area is always black but in 320x200 mode, the palette register controls the overscan colour as well as a colour in the visible area so the palette change is visible. I'm not sure how to make it stable without making the whole thing completely CPU-timed (and therefore very non-portable). I suppose you could do it with a timer interrupt like California Games does, but then you'd have some fiddly work to make the switch happen at a consistent place between runs of the program. Let me know if you manage it.


Scanning the source, I think can manage it by rearranging some things and precaching values from memory during the non-wait periods. Specifically looking at this:



lineLoop2:
waitForDisplayEnable
waitForDisplayDisable
loop lineLoop2
inc bl
mov al,bl
dec dx
out dx,al
inc dx


The "inc bl" can be moved before lineLoop2, which will probably make the difference. I'll poke around tonight (pun intended).

No need for the interrupt timer. I used to think that California Games used interrupts as the only way to get the palette switch happening at the right time. Since we had those conversations a few years ago, I've changed my mind: I think they did it more so that they could just "set and forget" the display mode and gain a lot of CPU time back to run the game mechanics. The real cleverness of that technique was not how they implemented it, but how they intentionally switched between palettes that had a shared color (red) and arranged the graphics on scanline boundaries using that color so that the switch was undetectable. In fact, they hid the palette switch inside a few scanlines, so that if the switch happens messily, it is still hidden (ie. they gave themselves a buffer). That's the true genius.

Using all three (hi) palettes and hiding between the shared colors (red and white) during the switch, you get red, cyan, magenta, white, green, and yellow onscreen at once (just not mixed in the same scanline), plus the background color of your choice (1 per scanline). I used to think that I would write a JPEG viewer using this technique, but now I'm much more interested in practical combinations of colors in composite mode!

BTW when I run the chart program I get a color screen, then a B&W screen, then a different color screen, then a B&W screen, etc. Is this intentional? Are you toggling the color burst on/off on every keypress?


Too bad they didn't fix the broken color burst in 80-column mode while they were tinking with that bit! Though I guess 80-column mode on composite wasn't really supported anyway because the text is so unreadable.

Sounds reasonable. Nobody in 1981 was outputting 80-col text to a TV (monochrome, sure, but not a TV).

I still don't fully understand NTSC color generation, but I'm glad you do!

reenigne
April 11th, 2012, 01:08 PM
Next time, feel free to email me

I would have done if you hadn't commented on the post.


The "inc bl" can be moved before lineLoop2, which will probably make the difference. I'll poke around tonight (pun intended).

Oh, good thinking - that should move the flicker left by 24 hdots, which might be enough. If not, changing the "mov al,bl" to "xchg ax,bx" (and swapping it back after the out) should give another 12 hdots, and moving a waitForDisplayEnable/waitForDisplayDisable pair after the "loop lineLoop2" (reducing cx to 11) should give another 24. Move it too far left though and it might reappear on the right on faster machines!


In fact, they hid the palette switch inside a few scanlines, so that if the switch happens messily, it is still hidden (ie. they gave themselves a buffer). That's the true genius.

Yeah, it's too bad they screwed up the implementation and made the compatibility test too sensitive so it was disabled on a lot of machines on which it probably would have worked just fine.


BTW when I run the chart program I get a color screen, then a B&W screen, then a different color screen, then a B&W screen, etc. Is this intentional? Are you toggling the color burst on/off on every keypress?

Yes, it cycles through all the possible modes with color burst both enabled and disabled. Actually the order is a bit different in the .asm file than in the .com file - I changed the .asm file to match the same order as my colour chart image (and removed the redundant palette combinations with black and white 320x200 mode) but didn't re-assemble with those changes.

Great Hierophant
April 11th, 2012, 03:37 PM
I read in one of the IBM Tech References that the dot clock in 160 pixel modes is 3.58Mhz, in 320 modes it is 7.16Mhz and in 640 modes it is 14.318MHz. I would suggest that correlates to your earlier statement of drawing two and four pixels respectively in the time the beam expects to draw one. I believe the idea behind artifact color is that the beam does not have the time to turn off in between pixels, so you get solid color across dot - no dot - dot. You also get faint lines too, sometimes visible, sometimes not.

Maybe I missed it, but how do you explain the arbitrary selection of the color depending on the horizontal position of the dot? You say that the pattern is yellow, red, blue and cyan. It would seem then that the CGA hardware is cycling through the color wheel as the beam travels across the screen, since that is the proper sequence with yellow being closest to the burst.

I understand that shifting the phase of the color burst signal produces hue and the amplitude of the signal saturation. A true color burst signal is a sine wave, and a CGA color burst is a square wave, and I assume that the square wave has a 50% duty cycle. What happens if you change the duty cycle (modulating the frequency?) I would think that the CGA card would output chroma as on, off and at 50% amplitude.

Trixter
April 11th, 2012, 06:56 PM
Oh, good thinking - that should move the flicker left by 24 hdots, which might be enough. If not, changing the "mov al,bl" to "xchg ax,bx" (and swapping it back after the out) should give another 12 hdots, and moving a waitForDisplayEnable/waitForDisplayDisable pair after the "loop lineLoop2" (reducing cx to 11) should give another 24.

Now you're thinking like a cycle eater :-) xchg is slower than mov, so I didn't do that, but the other two changes worked. Here is a working loop that displays no artifacts onscreen:



mov cx,11
inc bl
lineLoop2:
waitForDisplayEnable
waitForDisplayDisable
loop lineLoop2
waitForDisplayEnable
waitForDisplayDisable
mov al,bl
dec dx
out dx,al
inc dx
pop cx
loop rowLoop2

reenigne
April 11th, 2012, 07:08 PM
I believe the idea behind artifact color is that the beam does not have the time to turn off in between pixels, so you get solid color across dot - no dot - dot.

Kind of - but it's not an intrinsic property of the CRT hardware that it can't switch the beam on and off that fast - after all, the 5153 monitor has a very similar tube to that of contemporary composite monitors and that has no trouble going from black to white or vice-versa in a time of 1/(14.318MHz). The band-limiting is actually done as part of the composite Y/C separation, to avoid the 3.58MHz signals corresponding to colours from being displayed as light and dark patterns on the screen, not by the beam itself.


You also get faint lines too, sometimes visible, sometimes not.

That's because the Y/C separator isn't perfect and (depending on the monitor) lets some 3.58MHz signals through.


Maybe I missed it, but how do you explain the arbitrary selection of the color depending on the horizontal position of the dot? You say that the pattern is yellow, red, blue and cyan. It would seem then that the CGA hardware is cycling through the color wheel as the beam travels across the screen, since that is the proper sequence with yellow being closest to the burst.

Right, though it's really the colour-decoding hardware in the monitor that is cycling through the colour wheel as the beam travels across the screen. The CGA card outputs a yellow-hued color burst signal shortly after the horizontal sync pulse which the monitor uses to determine which phases correspond to which hues (so, same phase as burst = yellow, 180 degrees out of phase = blue, 90 degrees advanced = cyan and so on).

One possible way to do the decoding (which is actually the method that I use to do the decoding in software) is to have two 3.58MHz sinewave signals in the monitor (I for in-phase and Q for quadrature) which are 90 degrees out of phase. These are multiplied with the composite signal and the results low-pass filtered to get rid of the 3.58MHz signals. There is a third signal Y (luma) which is just the low-pass-filtered composite signal. Then the red, green and blue signals fed to the electron guns are just different linear combinations of Y, I and Q. Y is "brightness", I is "orange-blueness" and Q is "purple-greenness" (the wikipedia article on YIQ (http://en.wikipedia.org/wiki/YIQ) has some diagrams which might make that easier to understand).

Now, if you have two sinewaves 90 degrees out of phase, they define a circular trajectory in 2D space (colour space in this case) and that is the "cycling through the color wheel" that happens at 3.58 million cycles per second.


A true color burst signal is a sine wave, and a CGA color burst is a square wave,

That doesn't matter. A square wave is just a sine wave with some higher frequency components added on (which you can find by doing a Fourier decomposition of the wave). The higher frequencies will be ignored by the monitor so a square wave color burst will work just as well as a sine wave.


and I assume that the square wave has a 50% duty cycle.

Right. All the 3.58MHz signals involved here are 50% duty cycle except for artifact colours produced by lighting 1 out of 4 or 3 out of 4 pixels in 640x200 mode (which are rectangle waves of 25% and 75% duty cycle respectively).


What happens if you change the duty cycle (modulating the frequency?)

Frequency is not the same thing as duty cycle - frequency is how many times per second the wave goes through a complete cycle (one high and one low), duty cycle is the proportion of the cycle the wave spends "high".

For the color burst signal that happens after the horizontal sync pulse, the duty cycle doesn't matter - as long as the frequency and phase are correct and the amplitude and DC offset are within range, the burst will do its job. If the frequency is too far off it won't be recognized as a color burst.

For the signal corresponding to the visible picture, changing the duty cycle will have the effect of brightening or darkening the corresponding colour.


I would think that the CGA card would output chroma as on, off and at 50% amplitude.

I'm not sure what you mean by this. The 6 hue signals that go into the multiplexer (i.e. not black and white) all have 50% duty cycles. So yes, referring to the output signal from the multiplexer as "chroma" - it's either on, off or a square wave of 50% duty cycle of some phase depending on the colour.

Duty cycle isn't the same thing as amplitude, though - the amplitude of the chroma signal as sent to the monitor is defined by the resistor network that forms the CGA's composite output DAC. For the 1501486 the chroma amplitude (peak to peak) is about .75V and for the 1501981 is about .31V, which explains why the chroma colours are more saturated on the earlier card.

The amplitude (and therefore saturation) of the artifact colours depends on the raw pixel colours that you're oscillating between (i.e. the colours you'd see on an RGB monitor). For the usual 640x200 mode with palette 15, it's about 1.05V swing on both cards, so the artifact colours will be much more saturated than the corresponding chroma colours, and will be consistent between cards. Though only green and magenta are directly comparable - the other two 50% duty cycle artifact colours, orange and aqua, aren't available as chroma colours and the other 4 chroma colours (blue, red, yellow and cyan) can only be represented as artifact colours with 25% and 75% duty cycles.

reenigne
April 11th, 2012, 07:29 PM
Here is a working loop that displays no artifacts onscreen:

Great, thanks!


xchg is slower than mov, so I didn't do that,

It's 1 cycle slower on the execution unit, but when you're exchanging a word register with AX it's also 1 byte shorter so 4 cycles faster on the bus interface unit. Since almost all code is bus bound, changing a mov to a 1-byte xchg will almost always save you 4 cycles (the exception being if it's right after a mul, div or long-running shift and right before an instruction that clears the prefetch queue like jump, call, ret or interrupt).

Great Hierophant
April 11th, 2012, 08:03 PM
I think I want an older CGA card, but I only have newer ones. If you have a newer CGA card, I assume you would have to cut the resistors for the RGB signals being fed directly to the composite output. Then you would have to grab a BLANK signal, switch the resistors and enjoy the brighter and more vibrant colors.

Now, there are three schematics of the CGA card available from IBM and have been put on the Internet. The first (presumably 1804472) is found in the IBM PC Technical Reference Manual, First Edition August 1981. The second (presumably 1501486) can be found in the IBM PC and XT Technical Reference Manuals, Revised Edition April 1983 and the third (presumably 1501981) is found in the Technical Reference Options and Adapters, Revised Edition April 1984. It is interesting that on both the early and the late schematics, the R,G,B signals are being fed directly into the composite video output, but on the middle they are not.

Trixter
April 11th, 2012, 08:20 PM
It's 1 cycle slower on the execution unit, but when you're exchanging a word register with AX it's also 1 byte shorter so 4 cycles faster on the bus interface unit. Since almost all code is bus bound, changing a mov to a 1-byte xchg will almost always save you 4 cycles (the exception being if it's right after a mul, div or long-running shift and right before an instruction that clears the prefetch queue like jump, call, ret or interrupt).

Doh, I forgot about the accum,reg and reg,accum optimizations. You're right, it is faster. I was looking at the reg,reg size/timings.

reenigne
April 11th, 2012, 09:00 PM
I think I want an older CGA card, but I only have newer ones. If you have a newer CGA card, I assume you would have to cut the resistors for the RGB signals being fed directly to the composite output. Then you would have to grab a BLANK signal, switch the resistors and enjoy the brighter and more vibrant colors.

I think the -BLANK signal probably won't make any noticable difference, which is why they removed it in the 1501981. Probably just removing R6, R18 and R19 and replacing the 750 ohm resistor R8 with a 270 ohm resistor should give you something pretty close to a 1501486. The only problem I foresee with doing that is that the lower DC offset of the color burst might be too far out of spec for some monitors yielding no colour at all. If that happens there's a bit of rewiring that could be done to increase it but it probably wouldn't be quite so reversable as the resistor changes.


Now, there are three schematics of the CGA card available from IBM and have been put on the Internet. The first (presumably 1804472) is found in the IBM PC Technical Reference Manual, First Edition August 1981. The second (presumably 1501486) can be found in the IBM PC and XT Technical Reference Manuals, Revised Edition April 1983 and the third (presumably 1501981) is found in the Technical Reference Options and Adapters, Revised Edition April 1984. It is interesting that on both the early and the late schematics, the R,G,B signals are being fed directly into the composite video output, but on the middle they are not.

I think the schematic in IBM_5150_Technical_Reference_6025005_AUG81.pdf is actually more recent than the one in ibm_techref_v202_3.pdf - as well as having the +R, +G and +B signals feeding the composite DAC, it also fixes a mistake in the earlier schematic (there's a place in ibm_techref_v202_3.pdf which just wouldn't work at all as drawn). I'm not sure how a later schematic ended up in a manual dated 1981 but maybe the schematics were replaced at some point before the manual was scanned.

This particular schematic seems to be somewhere in between that of the 1501486 and the 1501981, so I think (by process of elimination) it must be the 1504910.

reenigne
April 18th, 2012, 03:36 PM
There's been some more discussion about the different CGA model numbers over at Vogons (http://vogons.zetafleet.com/viewtopic.php?t=12319&postdays=0&postorder=asc&start=180&sid=2fec0b400faac9b080301b9038f000b0), and NewRisingSun and I have come to the conclusion that 1504910 was not in fact a separate CGA card by itself, but the Stock Keeping Unit (SKU) number corresponding to whatever CGA card is available (or, equivalently, the box containing a retail CGA card) based on the fact that this number appears on IBM price lists in both 1981 and 1986.

The main remaining mystery then relates to the schematic in IBM_5150_Technical_Reference_6025005_AUG81.pdf - is it an earlier or later iteration of the CGA card than the one in ibm_techref_v202_3.pdf? If earlier why does the composite output stage look more like the later 1501981's and why doesn't the circuit in US patent 4,442,428 use this circuit? If later then why does it appear in the August 1981 manual, why does it have lower resistor numbering and why doesn't it have the resistor values?