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.
I wish my darn computer didn't need a floppy disk to boot.
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?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.
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
As for fonts, fully redefinable charsets may be a stretch
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 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.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
Like a Tandy Graphics card with an onboard 3 voice and discreet ram?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?
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???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.)
Does a CGA monitor support 640x400?Go all the way to 640x400. Why stop at EGA when double CGA is within reach and VGA is only a tiny step away?
If you were making a SuperCGA why wouldn't you just put the full 256k of RAM on it? (system conflict?)
Are we just building an EGA card now???
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.
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.