Fantasy CGA redesign

[reenigne]

I've spent a long time (probably way too long) staring at the schematics for the IBM CGA cards for one reason or another, and doing so has given me an idea for a sort of game. I'm not sure if there's anybody out there other than me who would be interested in playing it but if there is I'm sure this is the best place to find them.

The game is this: you have time travelled back to 1980 and find yourself working on Don Estridge's team at IBM, and your job is to design the CGA card. Knowing what you know now, how would you design it differently to make it more versatile for the games programmers who will write software targetting it? You still have the same constraints:

• It has to support the same RGBI and composite monitors.
• It has to have a 320x200 4 colour all-points addressable mode.
• It has to have a 640x200 2 colour all-points addressable mode.
• It has to have 40x25 and 80x25 text modes with the same colours, font and attributes.
• The flashing text and cursor have to flash at the same rates.
• Text must not blink when the cursor is on.
• It has to have 16KB of DRAM.
• It has to be based around a 6845 CRTC.
• It has to fit on a standard full-length ISA card.
• It has to include light pen support.
• You can't increase the cost.
• You have to continue to use the same TTL discrete logic chips used in the original card - no ULA/PAL or anything like that (74-series TTL chips that were available in 1980 but weren't actually used on the CGA are also allowed).
• It can't conflict with any of the other memory addresses or IO ports used by the original PC.

Software compatibility isn't necessary (remember no CGA software has been written yet!)

I haven't been able to find a 1980-era price list for 74xx/74Sxx/74LSxx logic chips, but for the purposes of the game the absolute prices aren't really important, only the ratios between them. I'm sure the chips used to be more expensive back then but the price ratios probably haven't changed too much so here's the modern prices for large quantities of the nearest available equivalents.

Here are some possible changes, roughly in order of least to most difficult:

• Modify the wait state so it's between 0 and 6 CPU cycles instead of between 3 and 8 CPU cycles as it currently is.
• Change the CGA character ROM from this to this, replacing the third quarter (the unused "thin font") with some patterns which are useful for "graphics in text mode", and make it selectable from software (perhaps repurposing the palette register bits that have no effect in text mode). This would make the 160x100x16 mode much more flexible, becoming a pseudo-640x100x16 mode and a pseudo-320x200x16 mode depending on whether the top or bottom half of the characters are being used. These modes aren't all-points-addressable (there isn't enough RAM for that) - each 8-pixel by 2-scanline block can only have 2 different colours in it, so they would suffer from "attribute clash" like a Commodore 64 or ZX Spectrum. This change would also make many thousands of extra colours possible with a composite monitor.
• Add an option (perhaps reusing the +BLINK mode bit) to not ignore the CRTC's MA12 line in graphics modes. In combination with some CRTC tricks, this makes it possible to implement a linear memory layout instead of the normal interlaced layout.
• Add an option to ignore the RA0 bit in graphics modes, making possible modes like 640x100x2 and 320x100x4 with 2 memory pages.
• Fix the color burst in 80-column text mode - just requires making the color burst pulse a fixed length instead of being gated by the HSYNC pulse from the CRTC.
• Allow interlaced modes to work by starting the vsync pulse start when the CRTC says it starts instead of waiting for the next hsync pulse. This means we have to count for 171 lclk periods instead of 3 scanline periods to determine where the vsync pulse ends (since we need a 3-scanline sync pulse and the CRTC generates a 16-scanline one) so we'd probably need an 8-bit counter.
• Get rid of the wait state on CGA writes altogether by caching writes until CGA RAM is available.
• Allow combining graphics modes with +HRES (160 bytes per line) yielding 1280 column 2 colour and 640 column 4 colour modes (albeit with a reduced viewport or splitscreen since there isn't enough RAM for these modes at full screen). This is *almost* possible with current CGA, but the bytes are not latched at the correct times due to the circuitry that eliminates snow in graphics modes. Also to get 1280 columns you'd need to get rid of the 14.318MHz pixel latch, which might destabilize the image too much (1280 columns isn't terribly useful to start with because of the dot pitches of the available monitors).
• Make the palette fully adjustable in 640x200x2 and 320x200x4 modes (i.e. have 16 bits of palette registers instead of 6) so CGA games don't all have the same ugly green/red/yellow or cyan/magenta/white palettes. In the alternate universe where this change had been made, most CGA games would look dramatically better!
• Allow a 160x200x16 all-points addressable mode (i.e. add a 4-bit pixel sequencer). Combined with some of the other changes this could also yield a 320x100x16 mode and reduced-viewport or splitscreen 320-column 16-colour modes.
• Make the palette fully adjustable in 16-colour modes (i.e. have 64 bits of palette registers) allowing for all sorts of fun palette animation tricks. Probably not possible with existing CGA parts but maybe with a 7489 or similar?
• Eliminate snow altogether during writes. This is actually very hard because there just isn't the memory bandwidth in +HRES mode to retrieve bytes fast enough for the screen and also allow the CPU access. One way might be to store up all the writes and then perform them during the horizontal blanking period. Eliminating snow during reads would require making the CPU wait until the end of the scanline, and probably isn't worth it.

Steve Wozniak was famous for being able to do amazing things with very small amounts of discrete logic - I wonder what the CGA would be able to do if he had designed it.

Any suggestions for good ways to achieve any of these changes? Or other changes that you'd want to make to the card?

 

[eeguru]

I'm pretty sure most of the early video cards on PCs used early synthesized ASICs. Outputting a single video mode would be complex but straight forward using discrete logic. However supporting all the video modes available in CGA for memory fetch & refresh, text/palette lookups, and frame clocking in discrete logic would be a really big board.

What is a more interesting project in my mind, although a bit impractical for a hobbyist, would be to take a modern PLD synthesis tool like Synplify Pro and impose upon it a target logic architecture made from commodity 74xx chips and no routing constraints rather than a macro cell and routing design from a given PLD vendor. That way you could code a CGA design at a logic equivalency level and it would synthesis the schematic for you. I suppose one could attempt to write a custom logic fitter using Icarus to parse the HDL into a truth table and some creative coding on the backend.

 

[reenigne]

supporting all the video modes available in CGA for memory fetch & refresh, text/palette lookups, and frame clocking in discrete logic would be a really big board.

And yet IBM's designers managed to do it with 59 74xx chips on a (full length) ISA card! Here's the schematic. The frame clocking is done by a special chip (the MC6845 CRTC - basically counters for character, address, scanline and row and comparators to generate sync pulses) but all the rest is discrete logic.

The Acorn, Sinclair ZX81/Spectrum, Amstrad, Commodore VIC/C64 and later PC standards like PCjr and EGA all used ULAs/PALs/ASICs of some sort. I think the machines which used discrete logic were just Apple I/II, Commodore PET, Sinclair ZX80 and IBM CGA/MDA. I'm sure others will correct me and/or expand those lists though.

What is a more interesting project in my mind, although a bit impractical for a hobbyist, would be to take a modern PLD synthesis tool like Synplify Pro and impose upon it a target logic architecture made from commodity 74xx chips and no routing constraints rather than a macro cell and routing design from a given PLD vendor.

That's fascinating - I would never have guessed that it would be possible for PLD synthesis software to be able to target discrete TTL logic chips! That would sort of take some of the fun out of my game, if I could get the computer to play it... Though I suppose there would still be some fun in trying to think of new features and seeing what can be synthesized given the constraints.

 

[vwestlife]

[*]Change the CGA character ROM from this to this, replacing the third quarter (the unused "thin font") with some patterns which are useful for "graphics in text mode"

The thin font actually did have one legitimate use: to allow the difference between normal and high-intensity text to be distinguished on a truly monochrome (not grayscale) display, such as the 1-bit 640x200 LCD panel used by most early laptops. I think my Toshiba T1100FD does it backwards: normal = thick font and "bright/hi-int." = thin font, but nonetheless it can and does use a combination of both fonts on the screen simultaneously. I believe IBM's own PC Convertible does it this way as well.

[*]Make the palette fully adjustable in 640x200x2 and 320x200x4 modes (i.e. have 16 bits of palette registers instead of 6) so CGA games don't all have the same ugly green/red/yellow or cyan/magenta/white palettes. In the alternate universe where this change had been made, most CGA games would look dramatically better!

This is the most realistic item on your entire list, because virtually every other computer in the '80s did it that way. It really makes you wonder if the CGA's two palettes started out as two suggestions of a "safe starting point" palette to use as a default, and somewhere along the line "default palette" in the design notes got mis-translated into "mandatory palette"!

It also would be nice to let the border color in graphics mode be changed independently of the background color, like the way it is in text mode, instead of having it always the same the background color -- and also the ability to change the background and border colors in hi-res 640x200 graphics mode, for that matter. Anyone who's used an Apple IIGS will know that simply being able to individually set the foreground, background, and border colors will suddenly make a monochrome display mode (e.g. Apple's text mode) become a lot more appealing on a color monitor!

 

[Chuck(G)]

Use the NEC 7220 CRTC instead of the 6845. For what could have been, take a look at the NEC APC, which was a contemporary of the 5150.

 

[reenigne]

The thin font actually did have one legitimate use: to allow the difference between normal and high-intensity text to be distinguished on a truly monochrome (not grayscale) display, such as the 1-bit 640x200 LCD panel used by most early laptops. I think my Toshiba T1100FD does it backwards: normal = thick font and "bright/hi-int." = thin font, but nonetheless it can and does use a combination of both fonts on the screen simultaneously. I believe IBM's own PC Convertible does it this way as well.

Neither of those used the IBM CGA/MDA character ROM though - the Toshiba wouldn't have used IBM proprietary ROMs and the I don't see the character ROM inside the PC Convertible.

I'm guessing that it was made that way because IBM thought they might need a thicker font for composite than for RGB (or vice-versa) but then realized otherwise when it was completed. Or maybe they wanted to delay choosing which font looked best until the hardware was up and working, and the schedules were such that they needed to get the ROMs made early.

This is the most realistic item on your entire list, because virtually every other computer in the '80s did it that way.

I think all those other colour machines used ULAs/PALs/ASICs though - the only discrete TTL colour machines were the Apple II and IBM CGA, neither of which had a full set of palette registers. These palette registers are probably quite a natural fit for ULAs because there's lots of flip-flops hanging around that you can use for the palette RAM, whereas with discrete logic you needed quite a few chips for each register (the flip-flop array itself plus CPU addressing logic and logic to decide what to do with the output).

It really makes you wonder if the CGA's two palettes started out as two suggestions of a "safe starting point" palette to use as a default, and somewhere along the line "default palette" in the design notes got mis-translated into "mandatory palette"!

My theory on the origin of the palettes is this: you've got two data bits from the video RAM and you need to transform that into four bits (R, G, B and I) from the output, but you also want to be able to use all 16 possible colours. The simplest thing you can do is to connect the two data bits to two of the output bits and connect the other two output bits to register bits. Given that the eye is better at distinguishing changes in red and green than in blue or brightness, those two are the obvious output bits to connect up to the data bits. That gives you four possible palettes: black/green/red/brown, blue/cyan/magenta/grey, dark grey/light green/light red/yellow and light blue/light cyan/light magenta/light grey, which are the same as the 4 main CGA palettes except for colour 0. I'm guessing that to maximize contrast they wanted to allow that to always be made black.

That doesn't explain why they added the colour select register at all though. I guess they liked using 74LS174s for the registers for some reason, but ran out of bits in the mode select register for all the features they wanted, so added a second register and then discovered that they had 4 spare bits that they could use to complete define a colour which could be used in various places: the foreground in 640x200x2 mode, colour 0 and the border in 320x200x4 mode and the border in text mode. They may have wanted to allow emulation of green, amber and white screens in 640x200x2 mode, and that was the easiest and most flexible way to accomplish that. They may also have wanted to be able to change the border colour in software for debugging purposes (like democoders later did to visualize how many rasterlines a particular piece of code took to run), and the colour select register would have enabled that too.

What's most mysterious to me, though, is why disabling the color burst bit in 320x200x4 mode changes the palette to cyan/red/white (i.e. forces blue on for two of the colours). Perhaps because the green/red/yellow palette wouldn't have worked very well on a monochrome composite monitor since all those three colours end up at the same shade of grey with the original CGA, so they forced yellow to become white in that configuration.

It also would be nice to let the border color in graphics mode be changed independently of the background color, like the way it is in text mode, instead of having it always the same the background color -- and also the ability to change the background and border colors in hi-res 640x200 graphics mode, for that matter. Anyone who's used an Apple IIGS will know that simply being able to individually set the foreground, background, and border colors will suddenly make a monochrome display mode (e.g. Apple's text mode) become a lot more appealing on a color monitor!

Ooo yes, good thinking - that's definitely one for the list.

 

[reenigne]

Use the NEC 7220 CRTC instead of the 6845. For what could have been, take a look at the NEC APC, which was a contemporary of the 5150.

Wow, hardware commands to draw circles! This was truly a chip that was ahead of its time. The APC didn't appear until 1982 though so I'm guessing the 7220 wasn't around in 1980 when IBM started work on the CGA.

 

[k2x4b524[]

Why couldn't this fantasy CGA redesign turn into another homebrew project? One that truly maxes out CGA while keeping it functional on the CGA monitors? With the updated chips out there, perhaps a faster one could be designed, one with more hardware capability?

 

[reenigne]

Why couldn't this fantasy CGA redesign turn into another homebrew project? One that truly maxes out CGA while keeping it functional on the CGA monitors? With the updated chips out there, perhaps a faster one could be designed, one with more hardware capability?

It certainly could. Though I think it would be more interesting to use 1980 technology instead of modern chips, otherwise it's not enough of a challenge - you'd just end up with something like a clone EGA card with a composite output.

I might even build such a CGA card myself if I come up with a good design, but it'll probably be a while as I have lots of other projects on the boil.

 

[Chuck(G)]

Wow, hardware commands to draw circles! This was truly a chip that was ahead of its time. The APC didn't appear until 1982 though so I'm guessing the 7220 wasn't around in 1980 when IBM started work on the CGA.

I can't say for certain. The whole thing was part of a cross-licensing affair that involved the 8272/uPD765 and some other chips between NEC and Intel. The Intel part number for the 7220 was the 82720--and it's in the 1984 Intel databook, so Intel surely knew about it when the PC was being worked on. The APC came out at nearly the same time as the PC.

 

[k2x4b524[]

True, you'd have to use the 1980's chips, or, make a whole new CGA card with updated components, it could be a card that switched from ega to cga with a toggle switch, like some of the later mono/cga cards did *i have one*

It certainly could. Though I think it would be more interesting to use 1980 technology instead of modern chips, otherwise it's not enough of a challenge - you'd just end up with something like a clone EGA card with a composite output.

I might even build such a CGA card myself if I come up with a good design, but it'll probably be a while as I have lots of other projects on the boil.

 

[reenigne]

I can't say for certain. The whole thing was part of a cross-licensing affair that involved the 8272/uPD765 and some other chips between NEC and Intel. The Intel part number for the 7220 was the 82720--and it's in the 1984 Intel databook, so Intel surely knew about it when the PC was being worked on. The APC came out at nearly the same time as the PC.

NEC were probably designing the APC and the 7220 at the same time though, and would probably have delayed the former if the latter wasn't finished in time, whereas IBM would not have wanted to risk slipping the PC launch by designing it around a part that wasn't available yet. The second-sourcing thing sounds like something that NEC/Intel might have been doing in order to sell to IBM though. I guess after the PC took off, CGA software compatibility would have been a concern, so IBM went in the PGC and EGA directions instead.

 

[Chuck(G)]

Consider the color on the AT&T 6300. More lines, finer resolution--and possible to upgrade by adding a board--and it uses the 6845.

 

[NobodyIsHere]

Use the NEC 7220 CRTC instead of the 6845. For what could have been, take a look at the NEC APC, which was a contemporary of the 5150.

Hi,
One of the N8VEM projects was to design a NEC uPD7220 based video card. It took a while but you can see it works well. The board has many fewer chips than a CGA but I think is very capable. It is purely bitmapped graphics although I have seen designs for uPD7220 which had both text and graphics modes. It is a shame the uPD7220 never took off since it is *much* more capable than the MC6845.

The schematic, PCB layout, KiCAD design files, software, photos and other information are on the N8VEM wiki in the ECB folder.

Thanks!

Andrew Lynch

 

[reenigne]

Consider the color on the AT&T 6300. More lines, finer resolution--and possible to upgrade by adding a board--and it uses the 6845.

The AT&T 6300 came along about 3 years after the PC though, and had twice the video RAM of a CGA. In 1981 putting 32K on the video card probably would have been prohibitive. Does the AT&T 6300 use discrete logic or an ASIC for its video generation?

 

[JohnElliott]

Neither of those used the IBM CGA/MDA character ROM though - the Toshiba wouldn't have used IBM proprietary ROMs and the I don't see the character ROM inside the PC Convertible.

The Convertible's video controller doesn't use a font ROM at all; the font is generated from an extra bank of RAM, which is loaded by the motherboard BIOS (or DISPLAY.SYS).

 

[Chuck(G)]

The AT&T 6300 came along about 3 years after the PC though, and had twice the video RAM of a CGA. In 1981 putting 32K on the video card probably would have been prohibitive. Does the AT&T 6300 use discrete logic or an ASIC for its video generation?

Sold in 1983, actually, so make that 2 years. No ASICs on the display board. A couple of HALs, but that wasn't special even in 1980. And it uses VGA-compatible scan rates.

 

[reenigne]

And it uses VGA-compatible scan rates.

Are you sure about that? I thought its 400 line mode was interlaced, and the 6845 (at least the Motorola one) couldn't cope very well with VGA scan rates, having a maximum character clock of 2.5MHz.

 

[Chuck(G)]

Are you sure about that? I thought its 400 line mode was interlaced, and the 6845 (at least the Motorola one) couldn't cope very well with VGA scan rates, having a maximum character clock of 2.5MHz.

Nope, I run a VGA LCD monitor off of mine, as I have only the M24 monochrome monitor. Works just fine. See here for connector details. I get only 8 colors, as the video output is RGBI. One of these days, I'll fix that up to get the full 16.

A lot of people sell the 80's Olivetti systems short. There was some very nice engineering there.

 

[Eudimorphodon]

A lot of people sell the 80's Olivetti systems short. There was some very nice engineering there.

As a random aside, last time I went to a swap meet someone was selling a SAMS ComputerFacts folio for the AT&T 6300. I considered buying it just to see if anyone here wanted it, but ended up deciding against it. Maybe that was a mistake.

So far as the "Fantasy CGA redesign" goes, I heartily second the idea of making the palette fully adjustable. It would add hardly anything in the way of hardware cost, and the *absolutely horrible* set of colors available in the 320x200 mode always seemed to me the biggest single flaw of CGA. Soft-loadable text-mode character sets might have been nice as well, although I'm not sure how you'd be able to do that without adding a bank of SRAM to the card.

One point, though, about the 16k RAM limit: Referencing a July 1980 issue of "80 Microcomputing" it looks like a set of 16k DRAM chips was retailing for about a hundred bucks in mid-1980. By next year, still prior to the PC's official unveiling, that was down to about $45. That doesn't really seem that cost-prohibitive in the grand scheme of things. The CGA card retailed for $300; it seems like one might be able to make a case that upping the RAM to 32k to support a full 16 color 320x200 mode (and possibly also offering 640x400 monochrome high-res, either progressive or interlaced depending on the monitor connected) and upping the price to $400-$450 would have been a reasonable trade-off.

Perhaps in this alternate universe IBM could have dispensed with the separate MDA/5151 combination and simply sold the same video card with two different monitor choices: an NTSC-scan-rate color unit like the 5153, with which the video card would have behaved essentially like Plantronics ColorPlus or PCjr/Tandy graphics, and a 400-line non-interlaced monochrome monitor that enabled an alternate 8x16 high-definition character set for text modes and supported a high-res 640x400 mono graphics mode. No need for a Hercules card. Yay!