CGA / HGC (Hercules Graphics Card) emulation object

KeithMc

I still have some old CGA monochrome monitors, with the DB9 (9 pin) connector
(vs the high density 15 pin, as on VGA monitors). It would be nice to reuse them
with my Propeller boards with either a CGA or HGC emulation.

If anyone remembers it a Hercules Graphics Card (HGC) emulation set may also
be worth exploring, above and beyond emulating the IBM CGA set.
That would allow us to have some nice graphics on those old monitors, too...
... http://en.wikipedia.org/wiki/Color_Graphics_Adapter
... http://en.wikipedia.org/wiki/Hercules_Graphics_Card

Has anyone ever written a Propeller Object (and designed the interface wiring) to support THAT monitor?
If so, where would I find it? I couldn't find one on OBEX.
If it takes an extra RAM chip hanging off the side to do it, that's still OK with me.

Thanks!
- Keith Mc.

kwinn

As far as I know there is no driver specifically for CGA monitors. CGA could be displayed on TV sets using an RF modulators so one of the TV drivers could probably be modified to support that. Modifying the VGA 640x480 might also be possible.

The Hercules cards and monitors had a resolution of 720x350 and a 50Hz refresh rate. This is certainly something the prop can handle but afaik there is no driver specifically for this.

Perhaps you should view this as an opportunity to become familiar with PASM and the propeller video system by creating the drivers for these monitors.

potatohead

Wish I had one of those monitors. Also wish I had a older composite high-resolution monitor. IMHO, both of those are great Prop targets. Low sweep rates and high resolution capability...

KeithMc

potatohead wrote: »

Wish I had one of those monitors. Also wish I had a older composite high-resolution monitor. IMHO, both of those are great Prop targets. Low sweep rates and high resolution capability...

Where do you live? If there's an experienced Prop Video Guru in the SE Michigan area that wishes to take a crack at writing a CGA/HGC driver, I'd be happy to provide the CGA monitor to use for debugging. (I will also be attending the Ohio UPENE in August, and could bring one with me then for loan as well.)

Mainly, I'm in a cleanout mode, and was curious what to do with my collection of old CGA monitors when it dawned on me it OUGHT to be a GREAT vehicle for a Propeller project. Given a driver, I could put a few on the workbench and use them for debugging et al, without tying up any of my more modern monitors. (Give 'em a bit more life, rather than recycling them. :-)

... and to answer 'kwinn' - Video drivers are a VERY tricky thing, and are typically NOT an ideal beginner's project. There's a lot of isochronous issues to deal with, that can fry a monitor if done incorrectly. That's why I was hoping there might either be a OBEX CGA/HGC object already out there, or maybe a Prop Video Guru that has DONE video drivers before who's itching for a new challenge, and may wish to take a crack at this problem.
(Besides, I already have another prop driver project in the works, tying me up... :-)

*IF* there isn't an object out there already, is there anyone interested in taking a crack at writing one?

- Keith Mc.

Cluso99

I am sure you could get a cheap/free old working VGA monitor easier than modifying an older CGA monitor.

potatohead

Well, agreed on that Cluso.

Sadly, I'm in Portland Oregon. Shipping on one of these beasties would be ugly, I would imagine.

I don't have a PC that can drive either one. I've done better when I've a reference signal to look at. Unlike doing the picture frames like local_roger did, where there are lots of potential users and frames to be had, these two formats might not see any real use at all. Anyone out there have interest?

A TV driver running S-video is going to nicely approach what one would get out most older CGA monitors. Pretty easy to get TVs, and there are lots of drivers already done, the biggest problem is just sorting out which one makes sense.

kwinn

Re: "Video drivers are a VERY tricky thing, and are typically NOT an ideal beginner's project. There's a lot of isochronous issues to deal with, that can fry a monitor if done incorrectly."

No arguments with that. Having said that though the TV video drivers already have the right timing as far as V & H sync goes for CGA. All that remains as far as timing goes is to decrease the number of scan lines by 1 to make it an even number so you have 60 non interlaced frames per second rather than 60 interlaced half frames per second.
The other change required is to the output signal to change it from the phase modulated color signal to a digital RGB signal.

KeithMc

Cluso99 wrote: »

I am sure you could get a cheap/free old working VGA monitor easier than modifying an older CGA monitor.

Uh... Who said anything about MODIFYING an old CGA monitor??? I just want to wake one UP, under a Propeller! <grin>

I *have* a big STACK of CGA monitors on hand now (at least 6 or more), both color and monochrome,
that I wish to use with some Propeller chips (vs recycling them). Why buy yet another VGA monitor
(or even a multiline serial LCD panel) JUST for text, when you have a bunch of these CGA monitors
under foot collecting dust now? <grin>

All we'd need is a CGA driver object, and the DB9 connector & resistor wiring specs figured out for it.

I feel having a CGA/HGC emulation object would be a GREAT addition to the OBEX library,
but I'm not a video driver writer. I'm sure there are lots of others like me out there, with CGA
monitors kicking around their place. It would bring some more useful life out of them.
(Talk about greening up - use them again, vs making them yet more toxic landfill... :-)

It would be very handy for any time you only wish to display a text block, or SIMPLE graphics.
Ex: A free CGA would be GREAT as as a propeller diagnostic text terminal for the bench...
(This is EXACTLY what I wish to do with it, at first...)

Other uses:
- emulate an "old school" text terminal,
- do simple "old school" low res color animated graphics (like a home brew process control or CNC
monitor app),
- if you just want to make a good old "vintage" display wake up for a retro student film, an historical era video,
or to whip up some simple graphic screen effects for your next time travel / science fiction cult film. <wink>

Personally, I'm an old serial terminal fan, esp DEC VT100s, and ADM3s... I think it would be
VERY cool to emulate an old VT100 graphics terminal on a CGA monitor with the Propeller.

But, I first need some help to at least get the CGA monitor up (80x24 text is OK to start,
but preferably with the basic CGA or Herc graphics set), before I can even contemplate
going the next step to make (or port) an ansi.sys or ADM3 front end interpreter for it.

So again, are there any video driver gurus out there, that may wish to take a crack at it?

<edit>
Seeing kwinn's latest post, it sounds like a good part of this is already written...
So let me rephrase it... Is there anyone out there with prop video driver experience
willing to try to hack one of the existing OBEX objects to drive the CGA monitor,
and figure out the DB9 wiring to interface it?
</edit>

Thanks!
- Keith Mc.

potatohead

TTL signals.

Are they analog at all? In other words, the original display adapters just slammed in logic signals. On or off. But, what if the signal varies some? Does that translate onto the display, or is it just on or off there as well?

kwinn

Here is the pinout of the connector with the functions. All signal levels were 5V TTL. The 3 color pins (RGB) provided 8 colors and the Intensity signal made the color high or low intensity.

Pin Function
1 Ground
2 Ground
3 Red
4 Green
5 Blue
6 Intensity
7 Reserved
8 Horizontal Sync
9 Vertical Sync

Here is the basic signal timing and display resolution

Signal
Type Digital, TTL
Resolution 640h

potatohead

Here's the datasheet for the CRT controller

http://pdf1.alldatasheet.com/datasheet-pdf/view/229420/ETC2/C6845.html

localroger

Both CGA and analog RGB should be considerably simpler to drive than TV, since they don't have the chroma hack and are more like VGA with TV timing. It might be easier to start with a VGA driver and modify it to TV frequencies than with the TV driver though, as there is a lot of code in the TV driver that simply isn't necessary if you aren't doing the whole chroma sync thing.

KeithMc

potatohead wrote: »

Here's the datasheet for the CRT controller
http://pdf1.alldatasheet.com/datasheet-pdf/view/229420/ETC2/C6845.html

This brings up an interesting question... How do we break down and approach this problem?
From the comments, it sure looks like this SHOULD be simpler than the VGA driver. (Right?)

AFAICD, there's really several issues in play here:
1) Generating the waveforms to display something stored in RAM somewhere.
2) Coming up with a simple terminal front end for it (chat to it like a terminal.
It would be nice to use already existing propeller objects for that, if possible!)
3) Coming up with a graphics front end for it (some kind of a graphic R/W
system, to build the old style graphics images - again, can we tap already
existing objects for this, from the VGA arena?)

For reference, I was assuming we'd shoot for a "minimum hardware" solution, even it if takes
more than one COG to pull it off (Ex: Use one COG for generating waveforms, and another for
a front end...) IOW, I was hoping we'd try to emulate SOME kind of CRT controller with a COG,
a DB9 connector, and maybe a few resistors (like with the VGA object), vs attempting to
do something like interface a copy of the old 6845 CRT chip to the Propeller, chat with
ITS registers, and have to replicate and wire ITS DB9 output driver circuit as well (ick...)

<edit>
BTW... Do we even WANT to emulate the 6845, or come up with a SIMPLER I/O R/W model,
(like make a block of RAM that another COG just writes to, and it automagically appears)???
</edit>

But, we'll probably also need a front end, to chat with it (terminal emulation, etc.),
so getting smart NOW about how we define it (even if it is DIFFERENT from the
original CGA software approach) may be good to contemplate.

So... What does everyone suggest, as an overall approach to breaking up this problem,
and approaching it? CAN the waveforms AND a front end be done in one COG?
What should the front end be like, to talk to this? Try to stay with the old CGA model,
make it a simple monochromatic terminal for now, bite the bullet and make it feel
like the HGC command set, or what?

Personally, as a first step (so we're not paralyzed) I'd like to "start small" as a
proof of concept. It we can at least get a RAM block "smartly" defined (looking
ahead) and come up with the code to copy it to a CGA monitor screen, I think
we can worry about WHAT talks to it later.

So... Let's get smart here, and start fleshing out some "specs" for this...
Should the internal model look SOMETHING like either the original CGA
RAM and/or register map (so you can tap old CGA style software)? OR...
should it borrow from the more modern VGA command set (and consider this
a "lower res VGA driver")? Thoughts?

Which will allow us to tap the most from the existing OBEX library, and/or minimize
having to write additional front ends for it, so OVERALL it will be done with the
least amount of effort?

<edit>
Remember... The overall goal here is to make a CHEAP display by tapping the old
CGA monitor HARDWARE that people already HAVE. I really don't care if Version 0.1
of the driver "looks and feels" like the ORIGINAL CGA software I/O system or not.
(IOW, even writing a simple CGA monitor "80x24 character terminal" would be a wonderful thing! :-)
</edit>

- Keith Mc.

potatohead

I think it's a bad idea to emulate the 6845. All that complexity doesn't give us much, unless the goal is to run CGA programs against it.

Honestly, I am confused as to what the sync pulses look like, and when they occur. If we get that info, a existing TV or VGA driver would be fairly easy to do.

For a font, the most efficient is 8x8, which isn't quite the old IBM 9x12, but there are a lot of 8x8 fonts out there.

Graphics and text modes could just be simple too, again, why worry about the CGA modes? It's a 16 color monitor, with 640x200 resolution, and maybe 640x400, if the thing will interlace. Beyond that, it's simply a matter of doing bitmaps, tiles, text, etc... as we would see fit.

I linked the datasheet, thinking there would be easy to understand sync pulse info... Well, I was wrong. I'm very familiar with TV signals, and to some degree VGA ones. I don't know what the older TTL devices did for sync.

KeithMc

potatohead wrote: »

I think it's a bad idea to emulate the 6845. All that complexity doesn't give us much, unless the goal is to run CGA programs against it. [...] For a font, the most efficient is 8x8, which isn't quite the old IBM 9x12, but there are a lot of 8x8 fonts out there.
Graphics and text modes could just be simple too, again, why worry about the CGA modes? It's a 16 color monitor, with 640x200 resolution, and maybe 640x400, if the thing will interlace. Beyond that, it's simply a matter of doing bitmaps, tiles, text, etc... as we would see fit.[...]

I agree. We really don't NEED to emulate anything, including old fonts.

Remember, the overall purpose here is to simply reuse existing CGA monitors with a Propeller (instead of making them landfill, or investing in new monitors), either for text, or simple color images. Once THAT is running, we can progress to emulating anything we wish (specific old terminal brands, 6845s, etc.) with a second COG.

If I'm hearing things correctly it appears the CGA monitors use simple logic levels vs analog. To me that makes is sound more and more like these displays OUGHT to be EASY to talk to, if we can figure out the right interface and if someone is up for writing the driver.

Let's drop back to the basics, to start. What's the EASIEST path to get ANY kind of a running display out of these old CGA monitors, with ANY font, or at least a bitmap? For starters, I'd be happy with either (a) a simple text terminal, or (b) a color bitmap display, that we can poke at. (Given at least a bitmap display, a font based terminal can then be the second step.)

Just to see if it will wake up... can someone that has done monitor drivers please start with suggesting at least the interface wiring spec and a simple video timing routine (maybe extracted and tweaked from something already existing in the library), that maps some memory to the display? We can at least then poke at it, and start to see things appear on the monitor. That will verify we have the basic wiring and video timing right.

Not having worked with CRT interface wiring before, my first concern with blind experimenting is the possibility of blowing up my monitors with my ignorance, by doing something stupid (like leaving some line in the wrong state for too long while the Propeller is idle or booting up).

Does anyone know where I can at least get ahold of a schematic of the old IBM CGA monitors to examine,
and some old docs on designing your own IBM PC video driver boards from that era? Those old docs might at least help me better understand the monitor design, its "vulnerabilities to stupidity" electrically, and its waveform philosophy.

(BTW... I'm new here and am still trying to figure out this forum's controls... Quick question: How do I get the forums to email me, whenever someone responds to a thread I'm in???)

Thanks!
- Keith Mc.

potatohead

Eric sent me some timings. They are basically TV timings, so a TV driver will be a best fit to start.

To get a driver, this is what needs to happen:

1. Nail down the signal specifics. IMHO, the active area and porches isn't all that difficult. What sync pulses actually look like is. So, for example, the vertical sync. Is this just one pulse, or a few of them? The when is going to be a lot like a TV driver, it's the what we are missing. I've never driven a TTL device before, and have no CGA to scope.

If we get a scope and a CGA together, that makes the project a whole lot easier. Would only take a few readings to understand the driver.

2. Design circuit for output.

3. Modify TV driver, or VGA driver to output with that circuit.

4. Test!

The risk is in the test. If the frequencies are off, misplaced sync, that's where the monitor could be damaged.

For the test, it's either get a CGA monitor to somebody who could write code, or... write some code, and exchange photos, and or data via forum.

My text drivers are probably a good fit. The one in my blog being completed right now is basically a 16 color driver, which matches well with the monitor. It's at or near the timings too. The Parallax Reference driver is another good fit, as are the NTSC templates Eric did. So we've got code to work from. Existing VGA code is at higher timings, adding one more variable. From what I can tell so far, TV timings work for CGA.

One question remains unanswered, and that is the actual signal. Is the monitor really just 16 colors, hard wired, because of the TTL input? Or is it still analog, in that varying the input levels varies the color output? The older cards just output the logic states, but they could have output other states, and I could find no examples of where that's done.

The very simplest driver would be a color bar output, just 16 color strips on the screen, nothing else. Once that one is written, doing graphics, text, tiles, whatever is a matter of adding that code to the video loops like any other driver. Once a core signal path is worked out, coding various video modes is kind of fun, and fairly easy to do. Because of that, a focus on just the signal, with the color bars should be primary. Existing graphics code for bitmaps, tiles and such can be re-used once a signal is up and running proper.

ericball

From an arcade monitor datasheet:
HORIZONTAL
frequency: 15.725kHz
period: 63.594us
front porch: 2.187us
sync pulse: 4.688us
back porch: 6.719us
active video: 50.00us
sync polarity negative
VERTICAL
frequency: 60.018Hz
period: 16.662ms (262 lines)
front porch: 0.190ms (3 lines)
sync pulse: 0.191ms (3 lines)
back porch: 1.018ms (16 lines)
active video: 15.263ms (240 lines)
sync polarity: negative

The easiest conversion is probably VGA.spin, modified to only output 262 lines at 15.725kHz.

Edit: the reason I say to start with VGA.spin instead of TV.spin is the sync logic in TV.spin is ..umm.. hairy.

CGA monitors are pure TTL devices: RGB+I colors.

ericball

Looking at VGA.spin, I'm wondering if all that's required is the right parameters (for 320x240):

vga_mode[2] := 0 ' non-interlaced
vga_mode[1] := 0 ' negative horizontal sync
vga_mode[0] := 0 ' negative vertical sync
vga_hd := 407 ' horizontal display ticks
vga_hf := 14 ' horizontal front porch ticks
vga_hs := 30 ' horizontal sync ticks
vga_hb := 43 ' horizontal back porch ticks
vga_vd := 262 ' vertical display lines
vga_vf := 3 ' vertical front porch lines
vga_vs := 3 ' vertical sync lines
vga_vb := 16' vertical back porch lines
vga_rate := 6_400_000 ' tick rate in Hz

davidsaunders

Keith Mc

I am a bit confused. You say CGA then you say they are Monochrome? CGA monitors are color RGB devices capable of millions of colors given a sufficient video adapter, and only MDA and some Herc monitors are monochrome. Remember that CGA used standard (at the time) RGB Color monitors.

If you are talking about the monochrome monitors common with early IBM PC, PC/XT, PC/AT and compatibles these are MDA monitors (MDA = Monochrome Display Adapter) they are basically just monochrome monitors with the same timing as the RGB monitors.

Tubular

Keith Mc,

Interesting project. I might be able to help measure some stuff for you - we have a 1983 vintage clone here that has been working continuously. It has a green Thomson monitor (hercules ttl driven I believe). We don't dare touch it (ie drive with a prop), but I'm sure I could measure the waveform timing and levels if that would help. We also have other monitors and things - genuine hercules cards, original ibm monitors, nec multisyncs etc.

I think testing the prop based driver with the multisyncs should be easy. They had a switch on the top to select CGA, EGA, Analog etc, on a single 9 pin connector. PM me if you want me to check anything specific.

ericball

davidsaunders wrote: »

I am a bit confused. You say CGA then you say they are Monochrome? CGA monitors are color RGB devices capable of millions of colors given a sufficient video adapter, and only MDA and some Herc monitors are monochrome. Remember that CGA used standard (at the time) RGB Color monitors.

CGA is HV+RGB+I TTL, so only 16 colors. It wasn't until VGA that the color inputs became analog and capable of thousands/millions of colors. But back in the CGA days monochrome (typically green or orange, sometimes white) monitors were common. They would display shades of "grey" for the various colors.

Bill Henning

Nice summary of old PC graphics standards:

https://ipggi.wordpress.com/tag/vesa/

kwinn

I am pretty sure that Eric Ball is correct in suggesting that all that may be needed to get the correct timings is the right parameters for VGA.spin.

With regard to fonts, keep in mind the aspect ratio of each pixel is far from square. That calls for a custom font.

Interlace is fairly simple as far as generating the signals go. All that is required is to go from 262 lines to 263 lines. It is a small enough change that none of the other parameters need to be touched. Generating the video signal is a bit more complicated since you have to alternate between generating odd and even frames every 16.66mSec. The main problem is that most CGA monitors had a fast decay phosphor to avoid ghosting when the display changed rapidly. The result was that text and some images seemed to bounce up and down one scan line with interlaced displays. Very hard on the eyes.

Ale

kwinn are the odd/even frames different ? I thought they had the same data... after all you only get some 200 usable lines out of it...

kwinn

Ale wrote: »

kwinn are the odd/even frames different ? I thought they had the same data... after all you only get some 200 usable lines out of it...

Usually the odd/even frames contain different data. The idea in this case would be to have 640 x 400 resolution by drawing all the even lines in the space between the odd lines and vice-versa. For example, on a terminal displaying the letter "T" only one scan line (odd or even) would have the horizontal pixels for the top of the T. Otherwise you end up with the horizontal portions of a character being thicker and brighter than the vertical ones.

PS This required a custom font for the CGA adapter, and even so the text was less than appealing.

KeithMc

davidsaunders wrote: »

Keith Mc

I am a bit confused. You say CGA then you say they are Monochrome? CGA monitors are color RGB devices capable of millions of colors given a sufficient video adapter, and only MDA and some Herc monitors are monochrome. Remember that CGA used standard (at the time) RGB Color monitors.

If you are talking about the monochrome monitors common with early IBM PC, PC/XT, PC/AT and compatibles these are MDA monitors (MDA = Monochrome Display Adapter) they are basically just monochrome monitors with the same timing as the RGB monitors.

I have a stack of the monitors. Several of them are True Blue (original IBM branded) green monochrome displays (MDA). I BELIEVE some of the others are full color, but it's been a LOT of years since I fired ANY of them up (and I'll need a working driver to do that!), so I'd have to go through them all to verify what they all are.

(BTW... I'm also worried about firing them up after sitting for years, but that's another bridge to cross...)

Now, as they MDAs are supposed to be "CGA compatible", I would assume any CGA driver we come up with would ALSO talk to the MDA (monochrome) monitors. IIRC, aren't they simply the RGB signals weighted together, to give a Pseudo Grayscale value for each color combo? (Can someone please verify that's how the MDA monitors worked?)

OOC... I don't want to complicate things, but if MDAs ARE different, what also needs to happen to detect and use MDAs with the same driver?

- Keith Mc.

kwinn

Here is some video information I collected and put into a spreadsheet a while back. I am a little suspicious of the pixel frequencies for ega and cga. I suspect they should be about twice what is listed. It may be these were from one of the lower resolution graphics mode.

As for MDA monitors being compatible with CGA, well they are...sort of. The ground and sync signals are the same, but the video signals are not. An mda adapter can drive the green and blue cga pins to produce an image on a cga monitor. A cga adapter will only produce an image on an mda monitor if the green and blue intensity signal is used.

As far as I know there was no "gray scale" analog input for mda. The signals were TTL levels and pin 7 on the mda connector turned the beam on or off, while pin 6 made it high or low intensity. Same was true for the cga monitor and adapter.

potatohead

http://techblog.vsza.hu/posts/Arduino_vs._CGA_part_1_-_flag_PoC.html

Coupla interesting notes here. One is he's got the monitor displaying something, and it's not broken (yet). The other is those pesky interrupts are currently adding to the difficulty. (sorry, can't resist that)

I'm struggling to find the page I visited this weekend that described how to just modify the CGA monitor for RGB analog input. The gist of it is injecting a signal just past where the TTL drives the analog monitor. Presumably, the sync could be left digital, with a hybrid analog input to exceed 16 colors.

ericball

Based on the BIOS listing from the IBM PC/XT Technical Reference and the 6845 datasheet the following are the correct values for CGA 320/640x200 for VGA.spin. (For x240 reduce both the number of vertical front porch & back porch values by 20.)

vga_mode[2] := 0 ' non-interlaced
vga_mode[1] := 1 ' positive horizontal sync
vga_mode[0] := 1 ' positive vertical sync
vga_hd := 912 ' horizontal display ticks
vga_hf := 80 ' horizontal front porch ticks
vga_hs := 80 ' horizontal sync ticks
vga_hb := 112' horizontal back porch ticks
vga_vd := 262 ' vertical display lines
vga_vf := 24 ' vertical front porch lines
vga_vs := 16 ' vertical sync lines
vga_vb := 22' vertical back porch lines
vga_rate := 14_318_182 ' tick rate in Hz

And the MDA/Hercules 720x350 settings for VGA.spin (again based on the IBM PC/XT Technical Reference, the 6845 datasheet and that the MDA has an 16.257MHz crystal):

MDA/Hercules 720x350
vga_mode[2] := 0 ' non-interlaced
vga_mode[1] := 1 ' positive horizontal sync
vga_mode[0] := 1 ' positive vertical sync
vga_hd := 882 ' horizontal display ticks
vga_hf := 162 ' horizontal front porch ticks
vga_hs := 135 ' horizontal sync ticks
vga_hb := 9 ' horizontal back porch ticks
vga_vd := 370 ' vertical display lines
vga_vf := 20 ' vertical front porch lines
vga_vs := 16 ' vertical sync lines
vga_vb := 4 ' vertical back porch lines
vga_rate := 16_257_000 ' tick rate in Hz

Tubular

Ok - took some readings off the working MDA Thomson monitor here. See photos below.

Keith, my memory is that you *couldn't* drive CGA into the MDA monitors, hence the ATi "emulation" board (see attached) which would display 16 shades on monochrome monitors. But I didn't have much to do with CGA. We made up an Elektor circuit that let us drive a SCART tv from CGA card I think. Then we kind of skipped from Hercules to EGA.

Tubular

And the video manuals used to be so much more interesting... here's some 6845 data from MDA and ATi Graphics Solution manuals...