I'm getting one of these http://www.old-computers.com/museum/computer.asp?st=1&c=446
I'm planning to build a server inside it. And I was thinking of using the built in CGA-monitor as a statusdisplay (LCDInfo style, or whatever the cool geeks use nowadays).
The screen is monochrome amber so it would probably look a bit like the Planar EL-screens some have been using in their mods. And I want to use an Arduino (or something like it) as a middleware solution… PC -> Arduino -> Screen
I have been checking up a bit, and CGA is a RGBI signal using TTL-communications. 4 lines (RGB + Intensity), combined with HSYNC (15.75KHz) and VSYNC (60Hz).
The 4 "color-inputs" are logic on or off. The combination of these generates up to 16 colors. However, as this is an amber screen, it would probably be easiest to start with "all-high" or "all-low"… White and Black.
So the problem is the following… I could probably both wire and code the arduino to flip the TTL-lines on and off, but I'm not sure what I do with the HSYNC and VSYNC inputs. And how to time the TTL-flips to correspond to pixels on the screen. (The standard CGA resolution is 320×200).
I'm not very good at electronics, but I'm very good at following instructions, and taking hints
Has anyone tried this before?
EDIT:
Could I maybe use a modified version of this? http://www.eosystems.ro/deogen/deogen_en.html
EDIT2:
I don't need to use an Arduino. But I want to keep it as simple as possible.
EDIT3:
It might seem that the monitor in question actually is a composite monitor, and not a "real" CGA input monitor. So that probably makes things a bit easier. But I'm still interested in how to generate a pure CGA signal using a microcontroller…
Best Answer
The hsync and vsync signals are just relatively short, negative pulses that reset the CRT's electron beam to the left and top of the screen respectively.
Since CGA was basically just NTSC (AKA RS-170) with separate sync and components, the timing of the pulses should be the same. The hsync would occur about every 63.5 microseconds, and the vsync about every 16.7 milliseconds. The vertical timing should be well within the capabilities of an arduino, but the horizontals might be more challenging.
During the active horizontal scan you'd need to update the luminance according to the horizontal resolution you're designing to. To get 640 pixels, assuming you use about 53 us of the horizontal trace time to allow for HS duration, and margins to make sure your output doesn't run off the edges of the CRT, you need to output a new pixel about every 82 nanos,. Now, 82 ns is (probably) way to fast to get directly from an arduino, but if you employ an external 8-bit shift register, you only have to load that about every 660 ns, i.e., order of half a microsecond. Of course you could opt for 320 pixels and ease the timing further.
If meeting that kind of timing sounds reasonable to you, the exact numbers could easily be had via some light googling. For example, this looks like a pretty good example.