Propeller VGA-lyzer Part 1

My first computer was an Epson QX-10, which is an old monochrome green screen 8-bit machine.  The unit I had is long gone, but I picked up a replacement on E-bay some years ago.  I got a good deal partly because it lacked a monitor.  (The QX-10 monitor used a proprietary connector and proprietary signaling scheme, so you can't simply plug in a modern - or even an old - PC monitor.)  I was not too concerned about this, since I had tinkered before with video signals in Earl Martin's Industrial Electronics class at Vo-Tech, including a similar proprietary-video-to-PC-monitor adapter project that was successful, albeit with a different video signal and analog CRTs (now I would use an LCD monitor).

Having occasion to reorganize my home office / lab and to pull this among sundry other computing curios from storage, now is opportune to tackle this video conversion challenge.  Like most of my projects I started off assuming it would be easy and it has turned out not to be so, but I am also learning more than I expected to.

An obvious first step is to make a simple circuit that reconciles the merely electrical differences between the mystery signal and VGA spec, to say nothing of timing, and just hook up a VGA multisync monitor to see if it can lock onto the oddball timing.  In fact this was the approach that worked for the Vo-Tech project many years ago, so that I never had to go on to the next step of dealing with sync timings.  (I think I just had to make a passive R2R D/A circuit to integrate the colors or something, and I passed the sync signals straight through.)  Well I say "worked," actually the first CRT monitor I plugged that Vo-Tech project into self-destructed with the bang and acrid smoke of blown capacitors.  A lesser engineer might have doubted his circuit prototype, but I theorized the problem must be that the cheap, used monitor I'd tried it on couldn't handle the high resolution input and had burned itself up trying.  If I just connected my circuit to one of these brand new, large, expensive monitors that belonged to the school, surely it would work there.  Fortunately for my instructor's classroom budget, I was proven right and it did work then.

For the current project I looked at the sync signals in the scope to figure out what I'd need to do them electrically.  VGA is a positive-sync video standard and I could see in the scope that waveform pattern inverted in the QX-10 syncs, so I ran the sync signals through a TTL inverter chip before connecting them to the monitor.  (For the record you can also easily tell which sync signal is which by looking at the frequencies, but I had a wiring diagram to tell me that too.)  I don't think I'd connected the color signal(s) yet, but if I had I could have used a voltage divider between a resistor and a forward biased diode, since the QX-10 monochrome signal is 0-5V and the VGA colors are 0-0.7V, and I don't care about intermediate intensities just on and off.  However, after I hooked up the sync signals I could see it wasn't going to work; the LCD monitor I used was already displaying the message "Cannot sync to this video mode."  Perhaps LCD monitors have lost the multisync capability good CRTs had, or perhaps it's because I'd connected my prototype up to an old, second hand LCD monitor.  I decided not to bother to try connecting it to my own brand new, large, expensive LCD monitor.

Right, so, onto sync timings, frame buffering, and phase locking!  I will be designing "real" video converter hardware for this after all.  Here's the situation.  Completely opposite to that Vo-Tech project, the big problem with the resolution / sync frequencies from the QX-10 is that they are too slow.  Well actually the QX-10's screen resolution in pixels - 640x400 - is coincidentally the same as a VGA standard resolution, but it does its vertical refresh at the leisurely pace of 45 Hz.  (Normal would be about 60 Hz.)  This in turn makes the horizontal sync frequency lower, and the pixels clock out slower.  Thus even though the number of horizontal syncs per vertical sync is "right", the frequency at which they happen is too slow.

This difference in vertical sync refresh rates makes buffering the entire frame the obvious and really the only option.  See, if it were merely a problem of not enough lines (not enough HSyncs/second), I could buffer one line at a time, and sometimes play back the same line twice in a row to spoof a higher number of horizontal lines than the input really has.  But there's no way to fake it with a vsync mismatch; one can easily see mathematically (45-60=-15 and 45/|15|=3) that every three seconds you'll build up such a deficit of lines that your output will demand a line an entire frame away (and the new one hasn't been transmitted yet).  I am not really an expert on video conversion, but I think I can say if you have a v sync mismatch you must to buffer a whole frame.

That's ok.  This is what I wanted to do anyway.  I need 32K to buffer a whole QX-10 video frame, and my favorite microcontroller, the Propeller, has exactly 32K RAM.  I wanted to be sure I wasn't missing an obvious way to do it with less RAM, so that the premise of the project isn't invalid.  Once I have this working for the QX-10, the Propeller object I write for this might be useful for connecting all manner of vintage computer and video game systems to more modern monitors or televisions.  That's why I'm calling this project the VGA-lyzer.