• Please review our updated Terms and Rules here

Fantasy CGA redesign

CGA output is digital. ;)

Would be even cooler if you could program your little device with color remapping for each scanline. Then you could use all 16 colors on one screen.
 
CGA output is digital. ;)

Would be even cooler if you could program your little device with color remapping for each scanline. Then you could use all 16 colors on one screen.

Well... That would require a lot of timing and I cannot see my way down that path. The fact that CGA is digital makes the challenge much easier. An LPT port adapter with a 9 pin input and output and a programmable bit remapper is all it would take. Hmmmmm. I may know enough to be dangerous... Hmmm. I wish my darn computer didn't need a floppy disk to boot. I need a new 8 bit SCSI controller. I am so stalled.
 
Well... That would require a lot of timing and I cannot see my way down that path.

Actually, it would't - you can just count the number of hsync pulses since the last vsync pulse - if you're intercepting the CGA signal anyway, that should be pretty easy. Though of course you'd have to have much more storage to have a separate palette for each scanline.

I wish my darn computer didn't need a floppy disk to boot.

I really should get around to putting my Arduino 5150/5160 keyboard port quick boot device into a form that other people can use. The code is on my github but I haven't sorted out the schematic properly and it's not very well documented yet.
 
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.
What about using two PCBs sandwiched together? like the IBM pga graphics card and others, but put the hot ram on the daughter board for better cooling, that gives you much more space, could go to 3 boards if you used slot one, why stick to 16k why not more? Or the option for more ram later?
 
IBM should have got a head start on the SLI/Crossfire craze and made it so two CGA cards could be linked together. Most likely it would need a jumper to set one of the cards to master and the other to slave, in terms of address ranges and video sync. There are a variety of ways that the bits could be combined to generate more complex graphics. For instance, you could simply take R and G from one card and B and I from the other. That takes care of 16-color 320x200. Or maybe you could AND/OR/XOR the bits together. One card could be in 640x200 and the other in a pseudo (color) text mode. Each white pixel from card 1 would take on the color attribute from card 2. Or you could always treat the two video outputs as separate layers, with a designated transparent color. Etc., etc.
 
For instance, you could simply take R and G from one card and B and I from the other. That takes care of 16-color 320x200

This is exactly how the Plantronics Colorplus worked in the real world; it had 32k instead of 16k and the two banks were read in parallel; IE, it was a planar card like EGA. With the confusing complication that when running in the 320x200x16 mode it wasn’t four planes of 8k each for R, G, B, and I, it was two ”chunky” planes of 2 bits each with each plane having half the total color data.

You could hack a plain CGA card to do this without too much difficulty by piggybacking a second 16k and adding a few multiplexers and output latches. This makes way more sense than two full CGA cards in parallel because the second 6845 and whatnot are all redundant.
 
With such a setup, I suppose you might also cobble together a 640x400 interlaced display, with even fields coming from one 16K buffer and odd fields from the other.

As for fonts, fully redefinable charsets may be a stretch - but how about the ability to choose (in software) from a selection of predefined ROM fonts? The existing ROM can already hold four 8x8 fonts, and of course a bigger one could offer much more. Having software-controllable address lines doesn't sound like a huge deal.
As an extension of that, perhaps you could separately select the bitmaps for the lower and upper halves of the character set, for multilingual code page support.

Per-scanline color palettes have been mentioned... Since we're talking fantasy, why not take that to the next level with "display lists" (Atari/Amiga-like)? A whole set of parameters that could be preloaded for each scanline, perhaps into SRAM, and cycled through on each hsync pulse:
- Mode Select register contents
- Color Select register contents
- CRTC start address
- Some other CRTC parameters maybe (not that I can think of any others that'd be useful in such a setup)
- Font selection, if the above-mentioned mod can happen

Could free up lots of CPU time for interesting effects that currently have to be timed by software!
 
As for fonts, fully redefinable charsets may be a stretch

Enough SRAM (2k) to hold a CGA resolution character set doesn’t seem like it would have been particularly price-prohibitive in the grand scheme of things. Just parallel it to the font ROM and come up with a switching scheme.
 
With such a setup, I suppose you might also cobble together a 640x400 interlaced display, with even fields coming from one 16K buffer and odd fields from the other

It’s mildly amusing to think of how much extra confusing that would make CGA interlacing; instead of having the even lines offset 8k from the odds you’d have four level interlace where addresses would go like:

line 0: X
line 1: X+16k
line 2: X+8k
line 3: X+24k
 
It’s mildly amusing to think of how much extra confusing that would make CGA interlacing; instead of having the even lines offset 8k from the odds you’d have four level interlace where addresses would go like:

line 0: X
line 1: X+16k
line 2: X+8k
line 3: X+24k
It's hard enough as it is with regular CGA and Plantronics with the second page of 16k is confusing, at least to me. But yeah, 4 lines of interlacing doesn't sound fun to figure out how to do anything practical.
 
It’s mildly amusing to think of how much extra confusing that would make CGA interlacing; instead of having the even lines offset 8k from the odds you’d have four level interlace where addresses would go like:

line 0: X
line 1: X+16k
line 2: X+8k
line 3: X+24k
That's not too dissimilar to how many of the extended 640x400 CGA adapters mapped their scan lines. Simply create a scan line offset array to map scan line number to offset. Problem solved.
 
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?
Like a Tandy Graphics card with an onboard 3 voice and discreet ram?
 
To my mind I think the most realistic winner for bang for buck when it comes to tweaking CGA to do “more” *is* probably slapping a second bank of 16K on it, the question is really what changes to the output side would give you the most options for enhanced modes.

Instead of doing what Plantronics did I think a better way to go would be interleaving the two banks for even/odd byte addresses on the 8-bit PC interface side and redoing the output side to fetch 16 bits at a time as a linear word instead of two 16k-offset planes. This gives you double the memory bandwidth in a straightforward way and would particularly be useful in 80 column text mode; snow would no longer be a problem. It would also let you do the 16 color bitmap mode as “chunky” pixels instead of that weird half-chunk/half planar thing that Plantronics did while keeping the memory clock the same as CGA’s 4-color mode.

Of course, this is also how the PCjr and Tandy 1000 graphics modes were laid out, so we might as well also wedge in a palette register and make this SuperCGA variant fully Tandy 1000 compatible. (A single 74S189 is all you need.) With the proviso that with only 32k we just get one page of 320x200x16 or 640x200x4, not the minimum of four the Tandy machines can do with their 128k or 256k (EX/HX) of video-accessible RAM, of course.

Other obvious tweaks to throw in there would be:

Interlaced support: 640x400 mono graphics, 80x25 text with 8x16 character cells, and an 80x50 8x8 character mode would all have their uses. They would flicker badly on color screens, but IBM could have offered a long persistence green monitor (composite interface would be fine if the card had the fixed grayscales of the “new style” CGA) that would have been a perfectly usable alternative to MDA.

User-Defined Characters: The doubled memory bandwidth might make this feasible. On a homemade video system I’ve been toying with I implemented user-defined character sets from the same memory the text buffer lives in with only a couple latches. CGA doesn’t have enough bandwidth for this, at least in 80 column mode, but we could do it with this. (At the cost of snow being an issue again, unless wait state generation was implemented as well.)
 
To my mind I think the most realistic winner for bang for buck when it comes to tweaking CGA to do “more” *is* probably slapping a second bank of 16K on it, the question is really what changes to the output side would give you the most options for enhanced modes.

Instead of doing what Plantronics did I think a better way to go would be interleaving the two banks for even/odd byte addresses on the 8-bit PC interface side and redoing the output side to fetch 16 bits at a time as a linear word instead of two 16k-offset planes. This gives you double the memory bandwidth in a straightforward way and would particularly be useful in 80 column text mode; snow would no longer be a problem. It would also let you do the 16 color bitmap mode as “chunky” pixels instead of that weird half-chunk/half planar thing that Plantronics did while keeping the memory clock the same as CGA’s 4-color mode.

Of course, this is also how the PCjr and Tandy 1000 graphics modes were laid out, so we might as well also wedge in a palette register and make this SuperCGA variant fully Tandy 1000 compatible. (A single 74S189 is all you need.) With the proviso that with only 32k we just get one page of 320x200x16 or 640x200x4, not the minimum of four the Tandy machines can do with their 128k or 256k (EX/HX) of video-accessible RAM, of course.

Other obvious tweaks to throw in there would be:

Interlaced support: 640x400 mono graphics, 80x25 text with 8x16 character cells, and an 80x50 8x8 character mode would all have their uses. They would flicker badly on color screens, but IBM could have offered a long persistence green monitor (composite interface would be fine if the card had the fixed grayscales of the “new style” CGA) that would have been a perfectly usable alternative to MDA.

User-Defined Characters: The doubled memory bandwidth might make this feasible. On a homemade video system I’ve been toying with I implemented user-defined character sets from the same memory the text buffer lives in with only a couple latches. CGA doesn’t have enough bandwidth for this, at least in 80 column mode, but we could do it with this. (At the cost of snow being an issue again, unless wait state generation was implemented as well.)
If you were making a SuperCGA why wouldn't you just put the full 256k of RAM on it? (system conflict?) I think it would have to have composite out and RGB out and put out color in 80x25 even if it isn't readable. Did we already decide that in the 4 color modes you would be able to define any 4 color pal? Why wouldn't we do what the ATI Small Wonder does and support the full 640x200x16 mode? Are we just building an EGA card now???
 
If you were making a SuperCGA why wouldn't you just put the full 256k of RAM on it? (system conflict?)

I thought one of the conditions for this thread was restricting the changes to things that would have been practical to include circa 1981? 256k of RAM would not fit in that bucket. 32k of VRAM is itself a bit of a stretch, but much less so.

Are we just building an EGA card now???

… no? EGA is in some ways a fundamentally different design from CGA and, since it relies on having four separate memory planes and needed some ASICs to fit on a single card in 1984, seems completely out of scope.

Are you saying this because I suggested a palette register? Again, this is a thing you could add to a CGA card with a single chip: the 74x89/74x189 are 16x4 (64 bit) RAMs; that’s enough to map any of 16 input values to any other 4 bit value.

(If you only cared about the existing CGA’s 2 graphics modes an alternate would be a 74670, that’s a 4x4 part; the advantage it has is you don’t need a multiplexer to write it, it’s dual ported. But it seems worth it to me to pony up for the multiplexer to make the palette freely adjustable in all modes.)
 
Some might know I've been working on a clone CGA card for a while now, and I've always been curious to ask Reenigne about his fantasy redesign list. Glad that this thread has sprung alive!
In terms of present improvements to the design, I've added another six bit register to the card, responding to address 0x3DD.
Three bits of this register are used to control A11, A13 and A14 of a character ROM 28C256. This enables a greatly expanded custom character set.
The fourth bit controls a sub-circuit that fixes the colour burst in 80 column mode (forces it to be fixed width). The resulting composite output is not pretty, but might be useful.
The fifth bit controls a sub-circuit that forces a composite grayscale mode (also with an option to have this kick in only during 80 column mode).
I have one bit remaining of this register that I have no idea what to do with.
Reenigne lists the wait state modification as the least difficult (and therefore maybe the easiest for me to implement?). Could anyone share how this would work?
Are there any other features that people would want me to try and implement, hopefully balanced against the effort involved?
Would love to make this clone card as feature packed as possible for everyone to enjoy.

As an aside, I've found that making the character ROM writeable would be pretty difficult to do; the ROM I/O is on its own dedicated bus to U32. One way to do this might be to bridge the ISA data bus into that dedicated ROM bus with a latch chip or buffer of some kind. Would then have to control the address lines in a similar way, or somehow time the writes to coincide with the CRTC address locations. Not very easy, at least for me.

I still want to work on replacing the graphics RAM with a modern equivalent by driving CAS/RAS signals through latches and buffers. I think this may be possible, just need to dedicate some time to it.

Very interested to hear other people's thoughts!
 
Last edited:
I still want to work on replacing the graphics RAM with a modern equivalent by driving CAS/RAS signals through latches and buffers. I think this may be possible, just need to dedicate some time to it.

If you’re building a new card couldn’t you just omit the CAS/RAS generation in the first place and use SRAM natively? Ditching it would get rid of a performance bottleneck that could potentially open up a lot of possibilities if you used fast enough RAM. (32Kx8 SRAMs with 35ns or less access times are readily available, using one or two would work great.)

As an aside, I've found that making the character ROM writeable would be pretty difficult to do; the ROM I/O is on its own dedicated bus to U32.

Yeah, a RAM in place of the ROM would definitely require special treatment with a bus multiplexer for both the data and address lines. Also, fwiw, snow on updating it would be awkward to avoid unless you did if only during vertical refresh.

(It would be similar to the ‘DAC Snow” problem some VGA cards have.)
 
Back
Top