New CGA controller IP brainstorming

[Eudimorphodon]

I was thinking of using something like the AD724 or MC1377 to convert the digital RGB (would need a solution for I) into NTSC sine waves and provide the video line driver.

I posted a while back about using an AD724 to turn RGBI into S-Video. It’s trivially easy to make a resistor DAC using a GAL and a few resistors. Just be aware that I’m pretty sure this isn’t going to do remotely the “right” thing with artifact colors without special intervention.

 

[kevju]

using something like the AD724 or MC1377 to convert the digital RGB (would need a solution for I)

Unless your chosen FPGA is IO constrained, you can keep the digital and composite outputs separate. I sketched out a possible interface to the AD724 below. You can add a 4th resistor to the green channel (1.7k) if you want to get brown instead of dim yellow.

The FPGA could definitely generate the different phases, but ultimately the output would be 3.3V digital (with fast edges thanks to modern FPGA IOs) and it would still need an external line driver. I thought a dedicated chip would be easier to use and do a better job.

As long as you are using an amp with a built in filter(from what I can see, they all seem to have this), the harmonics beyond the filter cutoff will be suppressed (leaving just the sine waves under 4-5Mhz). The AD724 is relatively straightforward to use, but the MC1377 would need some buffering in front of it, since it's inputs have a relatively low impedance.

I sketched out a PDM output as well. The main advantage is that it is completely gateware defined. If you want to improve the colors, implement an "old" vs "new" CGA card or create a custom interlacing scheme to set your TV on fire, you don't need a different board.

 

[Eudimorphodon]

Unless your chosen FPGA is IO constrained, you can keep the digital and composite outputs separate. I sketched out a possible interface to the AD724 below. You can add a 4th resistor to the green channel (1.7k) if you want to get brown instead of dim yellow.

Why do you have three pins per channel? A six bit DAC (two bits per color) can produce the “CGA palette” as defined by EGA and later (which, granted, is controversial for being *not quite* accurate to the internal brown fix on the 5153… but many CGA monitors differed on the exact shade they produced as well) by knocking down the green in “dark yellow” to the lower intensity bit. See the table here:

CGA2RGBv2 - Digital RGBI to analog RGB for C128 and IBM PC MDA/CGA/EGA | gglabs.us

gglabs.us

… anyway, that said, if you have the resources of an FPGA it seems like a waste to *not* just do PWM on a pin. To be completely blunt “quality” just isn’t as much of a concern for composite video as you might think. A simple output transistor with a filter capacitor will be just about as good as any real 80’s home computer.

Again, I think the main problem I have with using the AD724 in this particular case is it would do a good job rendering a composite view of the RGBI picture/palette, that is *not* what you get on CGA from the RGB port. (The aim of my CGA to 724 dingus was to interface a Tandy 1000 to a Commodore 1702, IE, specifically get the RGBI palette over composite/svideo.)…

Is that why there’s nine (or ten?) resistors, so the FPGA can be programmed to preprocess the output to use any of the RGB, “official composite”, or “artifact composite” palettes? (Although if that were the case wouldn’t it be more straightforward to wire them as a 9-bit or 12 bit DAC instead of just getting three/four discrete values because you’re picking one and floating the others?)

 

[Eudimorphodon]

FWIW, here's a bad photo of an AD724 driving a Commodore 1702 monitor via "S-Video". (IE, separated luma and chroma.) The 1702 has a really "gray" finish to the screen and is really hard to photograph well if there's any other light in the room, and the tint was a bit off, but it gives the idea. The brown is a little light for the "canonical CGA palette" as defined by EGA and VGA, but ironically it makes a little better match for the 5153 as described here.

Here's a picture of the driving circuit, which is just a three channel 2-bit resistor ladder DAC directly driven by the outputs of a programmed GAL. (Which also combines the separate H/Vsync into composite. EDIT: I only added the composite sync thing for the GBS8200 later, the AD724 is fine with separate sync) The third chip on the board is a 7404 inverter to turn a 14.3whatever Mhz 4x colorburst crystal into a CMOS clock source for the AD724.

The 2-bit DACs are implemented with just a 1K and a 500 ohm resistor per channel (which is a little hot), that gets knocked down a little at the capacitive termination before the inputs on the 724. Obviously doing this on a circuit board with precision resistors would improve the output, and you could add trimmers if you really wanted to tune the color balance, but for what it is it's a very passable CGA. (I later used the same DAC circuit to drive a GBS8200 arcade scaler, and the output from that looks *great* on a VGA monitor.)

Anyway, as mentioned before, this palette isn't really at all like the real composite output of a CGA card. The phases are "off" compared to the RGBI representation on a real CGA, and the luma values are also kind of screwed up on the the first revision CGA. (The reason they changed it is because the grayscale looked bad on a composite monitor... which they didn't care about until IBM introduced the 5155, which uses composite for its internal monitor.) If the goal is to make an "authentic" CGA card an RGB->Composite encoder chip that does it "right" is going to give you a bum steer.

 

[MicroCoreLabs]

If the goal is to make an "authentic" CGA card an RGB->Composite encoder chip that does it "right" is going to give you a bum steer.

I will think again about using an encoder chip.

The FPGA can generate all of the phases and mux them out based on the RGBI value.

Im curious, but why not just implement the RGBI + frequency muxing exactly the same way the IBM CGA card does it? Would that limit the design in some way? (Could Tandy/PCjr/Plantronics/SuperCGA still be supported if the IBM circuit was used?)

 

[kevju]

Why do you have three pins per channel?

It's mainly to allow adjustment of the colors somewhat independently, especially brown/yellow. That circuit can be run in a 2 bit dac mode, or PWM as you mention. I'm not sure about using PWM with that encoder without filtering first, there may be issues with the RGB/YUV frontend.

here's a bad photo of an AD724 driving a Commodore 1702 monitor via "S-Video"

That's some decent 80 col!

but why not just implement the RGBI + frequency muxing exactly the same way the IBM CGA card does it?

It depends on the card you want. You can build an "old" CGA, "new" CGA, or as Eudimorphodon did, try to replicate the RGBI palette. The difference is mainly in the passives, but I think the old/new CGA did have some logic differences as well. If you want to mess around with it, I can send you Quartus projects for the Aliexpress CGA card. That card doesn't have the composite connector; the signals to run it are available but not connected to IO.

 

[Eudimorphodon]

Im curious, but why not just implement the RGBI + frequency muxing exactly the same way the IBM CGA card does it? Would that limit the design in some way? (Could Tandy/PCjr/Plantronics/SuperCGA still be supported if the IBM circuit was used?)

The IBM method is the "right" way to do it if you want your card to be useful for composite demos. Clone CGA cards (and this includes the Tandy 1000) very often (I want to say "usually") produce different artifact colors than a real CGA does. The "official" colors will be the same, or at least close, but many clone CGA implementations *fix* the broken colorburst generation of real CGA in such a way that the phasing is incorrect. You get artifact colors but it's the wrong set.

I mean, the nice thing about using an FPGA is you'd have the option to also implement clone colorburst generation and replicate their sets, but... I honestly don't think you'll find much call for it. There is a *tiny* bit of support out there for doing "136 colors" on a Plantronics using composite, but kind of the point of all these alternate cards is they had 320x200x4 bit modes that let you get "full color" with an RGBI monitor. If there's a demo out there specifically for composite PCjrs or Tandy 1000s I'm not aware of it.

FWIW, don't get your heart set on Tandy compatibility in an ISA card. Plantronics, no problem, but Tandy (and PCjr) video is more than just having 32K at B8000 and a suitable pixel output chain. A not-insigificant number of programs for Tandy video modes rely on there being more than one video page available (All Tandy 1000s support up to 128K of RAM being used for video pages as long as they have a memory upgrade beyond 128k), and PCjr-specific software also relies on being able to write to the framebuffer at its "borrowed" low memory location. These machines also have specific BIOS support for setting up the modes and allocating the RAM for them, and programs using the modes also usually rely of BIOS signatures to know what they're running on. With a *lot* of work (and 128K of video RAM) you *might* be able to make a video card that can be "mostly" as compatible with PCjr software as a Tandy 1000TX with "768k" is (IE, the "Big Blue" memory is *only* accessable above Bxxxx, it's no longer borrowed from conventional), but you'll still probably have to binary patch most software to even try to use it.

Re: the earlier discussion about video interlacing I think a better use for more video memory besides Plantronics mode (which *is* probably the way to go, it's not super well supported but programs like PC Paintbrush could use it and compatbility with it existed in third party cards like ATI Wonders and some Paradise chipsets) might be a 640x400 mono graphics mode. There was a kind of informal "SuperCGA" standard for this; the Olivetti M24/AT&T 6300 were probably the most common machines with it but it showed up a bunch of places (like Toshiba and Compaq plasma-screen laptops) and they'd usually give it the same BIOS mode number and VRAM arrangement so software happy with just asking for mode 40h would work on any of them. (They might not use the same CRTC settings, etc.) You could use a small TSR to supply the mode hook for it.

 

[Eudimorphodon]

That's some decent 80 col!

Yeah, I was kind of shocked how well it manages putting one color on top of another. It helps that CGA has that beefy font where most verticals are two pixels wide, of course, but it kind of looked like black magic to me when I got it working.

(The 1702 has a CRT dot pitch roughly the same as a screen door, of course, but so did some RGBI monitors. It really surprised me to see S-video on the 1702 is *almost* indistinguishable from a really poor CGA monitor like the Tandy CM-5.)

 

[MicroCoreLabs]

FWIW, don't get your heart set on Tandy compatibility in an ISA card.

I'm not... Just thought it would be easy to implement if I had enough video memory. An external DRAM could be added, or a larger FPGA could used, so 128 KB wouldn't be an issue.

These machines also have specific BIOS support for setting up the modes

Now that is an issue... Perhaps more trouble than it is worth... (Although as long as I supported the underlying registers and memory map maybe wouldn't be so bad)

I think a better use for more video memory besides Plantronics mode (which *is* probably the way to go,

Agreed. Especially since it does not require any BIOS support. It would be exciting if SuperCGA could be supported with its 4-bit/16 colors!

 

[Eudimorphodon]

It might be worth firing up an installer for a DOS version of PC Paintbrush 3.x (it had a lot of driver coverage for obscure video cards) and get a list of names of other video cards that look like they might be "SuperCGA" variants and research what you can about their memory layouts/mode setting requirements/etc. Plantronics is basically the best known/supported of these cards but there were a bunch of other roughly similar devices. 64K instead of 32K would open the door to a few more options; I think at least some of the ATI Wonder series cards had a 640x200 16 color mode, as did the Amstrad PC1512. (That latter at least has a GEM driver floating around.)

FWIW, what you're working on here sounds a lot like the Graphics Gremlin, an FPGA based card that emulates CGA and MDA on both the original monitors and doublescanned out a VGA port. (Or it can do composite, it can't do VGA and composite at the same time because the green channel DAC does double-duty as the composite channel.) As a trivia note, the Graphics Gremlin had *very partial* Tandy support; someone came along later and improved it, but to really use the Tandy modes requires homebrewing a machine (like around a NuXT) that has the normal BIOS replaced by a Tandy 1000 BIOS, which then has knockon effects that require a bunch of software patches...

The TL;DR is that to really be "tandy compatible" you kind of have to build the whole machine, not just an ISA card.

 

[MicroCoreLabs]

I'm familiar with that CGA card - it was integrated with my MCL86 core in the MiSTer PCXT project. I believe its architecture was to replicate the 6845 and a majority of the IBM CGA card logic. I doubt I will go that route. In fact, I'll probably call it the MCL_CGA_Max: "We break all your demos"

 

[Eudimorphodon]

I'm familiar with that CGA card - it was integrated with my MCL86 core in the MiSTer PCXT project. I believe its architecture was to replicate the 6845 and a majority of the IBM CGA card logic. I doubt I will go that route. In fact, I'll probably call it the MCL_CGA_Max: "We break all your demos"

I guess it goes without saying that if you don't care if you're able to run demos like Area5150 you're going to make your life a lot easier. (Although I suppose it's a classic case of the old 80-20 rule; you can take a *lot* of liberties with exact cycle/register compatibility if you're happy with running 80% of CGA software, it's that last 20% that's going to be 80% of the work.) I guess the only question that arises there is, well, what advantage does this have over just stuffing a VGA card in instead? EGA/VGA isn't fully CGA register compatible and it shows in spades for demos and a few old games, but other than that it works fine.

For my own homebrew project video project that uses a dinky little Atmel 8 bit microcontroller as a CRTC I've pondered a strategy to emulate a CGA-like video card where I'd just send CRTC and CGA hardware register writes to a small block of memory (a small scrap of logic would remap everything into a flat register file) that the MCU would read once a frame during the vertical blanking interval and set up the hardware to do whatever mode the register settings added up to for the next frame. This would work *perfectly fine* for almost any piece of business/productivity software... but obviously it'd completely fail for anything that tried to play tricks that involve reprogramming the CRTC or whatever mid-frame. Some less-compatible PC clones used NMI handlers to basically do something similar to intercept writes to a CRTC or whatever that wasn't even there and, based on what was being accessed, make an educated guess at translating it to the machine's real hardware. It's a strategy that can work surprisingly well but, yeah, it's gonna break your demos. Or, more accurately, demos are going to break *it*.

 

[resman]

Having a new CGA that only outputs NTSC RGBI and composite would not be all that exciting, IMHO. It isn't a lack of CGA cards that makes retro enthusiast want to upgrade to VGA, but the lack of working NTSC CRTs. If your CGA were to output to DVI/HDMI and add emulation for NTSC color artifacting, I think that would be an intriguing product. You could take a page from the Compaq CGA and add the ability to display MDA quality text and 640x400 graphics mode already supported by a Windows driver. I would take that over the ability to run Area5150 on a color NTSC CRT any day.

 

[Eudimorphodon]

It isn't a lack of CGA cards that makes retro enthusiast want to upgrade to VGA, but the lack of working NTSC CRTs.

A sad punchline to my fooling around with an AD724 to convert RGBI to S-Video was the realization that nobody puts S-Video ports on TVs anymore. 20 years ago an RGBI to S-Video adapter that works as well as the one I tinkered together does on the 1702 would have been *awesome*, but even my ~2014-ish living room TV doesn't have S-Video. The port is practically extinct.

 

[MicroCoreLabs]

I guess it goes without saying that if you don't care if you're able to run demos like Area5150 you're going to make your life a lot easier.

This project would actually be more interesting if it intentionally prohibited running these demos - which would also make my life a lot easier.

 

[Eudimorphodon]

This project would actually be more interesting if it intentionally prohibited running these demos - which would also make my life a lot easier.

Maybe you should rebase this project specifically around making a card that emulates oddball SuperCGA cards that were built for “serious” work, like the M24 (and the various other 400 line systems compatible with it), Plantronics, crazy hi-res stuff like the Wyse WY-700, etc. Maybe see if you can put your head together with @JohnElliott (I THINK I’m tagging the right person) who’s documented and even written drivers for some of these oddballs. Build a card that can emulate these but scale the output to display on modern monitors framed in VESA standard resolutions and it would be an interesting “metal” way for someone to experience truely unobtainium hardware. (For which the matching monitors are all dead.)

 

[MicroCoreLabs]

Maybe you should rebase this project specifically around making a card that emulates oddball SuperCGA cards that were built for “serious” work, like the M24 (and the various other 400 line systems compatible with it), Plantronics, crazy hi-res stuff like the Wyse WY-700, etc. Maybe see if you can put your head together with @JohnElliott (I THINK I’m tagging the right person) who’s documented and even written drivers for some of these oddballs. Build a card that can emulate these but scale the output to display on modern monitors framed in VESA standard resolutions and it would be an interesting “metal” way for someone to experience truely unobtainium hardware. (For which the matching monitors are all dead.)

So you are saying make the controller compatible with CGA, SuperCGA, and Plantronics modes, and rather than output to CGA and composite it would output to VGA (or better)?

 

[Eudimorphodon]

So you are saying make the controller compatible with CGA, SuperCGA, and Plantronics modes, and rather than output to CGA and composite it would output to VGA (or better)?

Per @resman’s point, there’s a lot fewer working CGA monitors than CGA cards in the world. The selling point of something like the Graphics Gremlin was mostly the line doubling VGA port being built in instead of needing a separate RGB2HDMI or whatever. Plantronics cards are rare-ish, sure (although ATI Graphics Solutions/Wonders are far less so), but there’s still that monitor problem.

So… yeah, I don’t really see there being a lot of need out there for a “premium” composite/RGBI card. I mean, maaaaybe if it were perfectly cycle-accurately switchable between old/new CGA the demo fiends might want it, but even in that case it’d be a big bonus if it could play said demos on a modern monitor without an external upscaler.

 

[MicroCoreLabs]

I occasionally wonder what would be involved in developing an actual VGA card. I am curious if the VGA chips from back in the 1980's all written in RTL or was there a combination of hardware and microcode. If VGA is as complicated as I think it is then my guess is that they were microcoded.

I think a modern FPGA architecture could be quite simple. A little RTL for the ISA bus and VGA DMA&Timing leaving the bulk of the VGA protocol to be handled by the embedded microcontroller. The Artix-7 FPGA, for example, has a 600 Mhz ARM core which should be enough to handle the protocol and memory modification operations. If this SOC FPGA is too expensive then a soft CPU core like MicroBlaze could also be used in a regular non-SOC FPGA. Dedicated RTL controllers could be added to handle memory-intensive operations to offload the CPU...

I could handle the hardware but would need help with the software.

 

[JohnElliott]

Maybe you should rebase this project specifically around making a card that emulates oddball SuperCGA cards that were built for “serious” work, like the M24 (and the various other 400 line systems compatible with it), Plantronics, crazy hi-res stuff like the Wyse WY-700, etc. Maybe see if you can put your head together with @JohnElliott (I THINK I’m tagging the right person) who’s documented and even written drivers for some of these oddballs. Build a card that can emulate these but scale the output to display on modern monitors framed in VESA standard resolutions and it would be an interesting “metal” way for someone to experience truely unobtainium hardware. (For which the matching monitors are all dead.)

I think you've tagged the right person. I've mentioned before, I think, that it would be interesting if a WY-700 clone existed that displayed its output on a modern LCD. 1280x800 resolution, with a choice of two 16x16 fonts in text modes. Fairly good support for the 1280x800 mono graphics mode in GEM and Windows. The original WY-700 was a mono card so everything was in shades of grey, but I don't think it would break anything if the clone had the same colour model as a real CGA.