• Please review our updated Terms and Rules here

Project: External S-Video adapter for CGA/RGBI

I've got a few devices which output a high-resolution, monochrome composite signal. I generally connect them to the component input of my TV, leaving Pb/Pr unconnected, which gets me the best image quality. Using the SCART through an adapter (S-Video without chroma) also works well.

I guess Europe was in a luxury position, at least while virtually all TVs had SCART inputs.
 
I guess Europe was in a luxury position, at least while virtually all TVs had SCART inputs.
More necessity than luxury. SCART was born in France, where they used SECAM (System Essentially Contrary to the Accepted Method), which is a pain in the neck to generate, plus everyone else in Western Europe used PAL, and rather than manufacture expensive, complex multi-system TVs, it was easier to just give everyone an RGB input.

In the mid-'80s there was an attempt to Americanize SCART as the "EIA Multiport", but it only appeared on a few high-end TVs, no American-market video equipment ever supported it, and it hit the market around the same time as S-Video, which was much more widely used, and perfectly adequate for most consumer-grade CRT TVs of the era.
 
I've got a few devices which output a high-resolution, monochrome composite signal. I generally connect them to the component input of my TV, leaving Pb/Pr unconnected, which gets me the best image quality. Using the SCART through an adapter (S-Video without chroma) also works well.

I have checked, the grayscale that comes out of the AD724’s luma port is really pretty. I imagine you could probably do the same with just a resistor ladder, but the 724 has its built-in output amp and whatnot so… if you can find the chip for $2 like I did it still might have uses for mono applications.

FWIW, I’ve gotten pretty decent mono composite conversion through those dirt-cheap composite->hdmi bricks for some of my homebrew experiments, including some things I’ve done with interlaced video. (After conversion it looks like it came from a mono VGA source, basically.) Thing is, though, for these experiments I’ve used pixel clocks that can’t be mistaken for NTSC colorburst. It seems like if you *do* use a clock that’s NTSC-ish (4x colorburst like CGA uses, for instance) they’re kind of prone to inventing color where none should be even if you’re not sending a colorburst on the porch.
 
Last edited:
Realized I hadn't posted any pictures of graphics mode, here's "Hoyle's Book of Games", Tandy 16 color mode, on both the built-in composite and through the AD724 luma/chroma:

hoyle_composite.jpg

hoyle_ad724.jpg

Here's another picture of text with the color bar program tweaked a little bit to better show just how gawdaful unreadable the 80 column text is on Composite verses S-Video. Tandy's built-in Composite:

read_this_composite.jpg

Svideo. FWIW, I know the dark blue-on-black text is kind of invisible in this shot; it's not actually a problem with the output, it's that the brightness was turned down a little too much. The Composite output from the Tandy is really "hot" and over-bright, I had the monitor set up to try to make it look as good as possible. (This actually also applies to the Hoyle's book of games video; it's possible to make the red look less washed out without impacting the clarity much, but I had things set up to try to give the Tandy's composite out its best chance.)

read_this_ad724.jpg

It actually kind of amazes me how well it manages most combinations of one color over another. I thought this would be out of bounds even for S-Video.
 
I've noticed on Tandy 1000s that the composite output brightness is noticeably reduced if you disable the color burst (type MODE BW80, or press F1 during POST).

I specifically wanted to see the color, so I don't want to disable that... ;) But that said, it's certainly possible the resistor ladder Tandy uses to tie everything together isn't balanced properly.

On the SX/EX/HX/TX series the color elements come out of the big blue on one wire that's resistor-combined with the output of a resistor ladder on the other outputs. An experiment I'm considering is replicating the grayscale ladder on an external buffer to terminate into a 75 ohm output, and sourcing the Big Blue composite output with a test clip, buffering and terminating *that*, and seeing what that looks like when rendered as split luma/chroma. In theory at least it should clear it up a lot; the colors will still be the composite set, but...

Downside of this plan is it's a *huge* PITA to get to where I can clip onto that signal in an EX. Anyone have spare SX they want to donate? ;)
 
As a side note; I'd love to find something that can convert the interlaced 1024x768 output of the IBM PS/2 8514A video card so it could be used on a common, standard VGA display. That would be sweet, and I'd love to have one before my PS/2 gathers so much dust I can't find it anymore....
 
As a side note; I'd love to find something that can convert the interlaced 1024x768 output of the IBM PS/2 8514A video card so it could be used on a common, standard VGA display. That would be sweet, and I'd love to have one before my PS/2 gathers so much dust I can't find it anymore....
IIRC most attempts at squeezing more resolution out of a standard fixed-frequency VGA monitor expanded the horizontal resolution but not the vertical, so you might get something like 1024x480.

Increasing the vertical resolution would require using interlacing and/or reducing the frame rate to below the point where flicker becomes very annoying unless you have a monitor with a long-persistence phosphor, like what Commodore sold to make the Amiga's interlaced 640x400 mode tolerable to use.
 
IIRC most attempts at squeezing more resolution out of a standard fixed-frequency VGA monitor expanded the horizontal resolution but not the vertical, so you might get something like 1024x480.

I think the ask here is something like a line doubler to let 8514A's 1024x768 interlaced to work on a "common, standard VGA display" as defined by a modern monitor with a VGA port, like most LCD monitors. I don't think I ever owned a CRT SVGA monitor that couldn't do 8514A, but yeah, it's apparently quite rare for *any* LCD, even older ones that are a little more forgiving about non-VESA frame rates, to support interlace.

In principle at least you just need something like a souped-up Retrotink, as long as you can find a monitor that's happy with what's still a non-VESA refresh rate for the doubled mode. The line rate and pixel clocks are about 3-4x what you need for a TV frequency line doubler, so you might need a bit more expensive FPGA or whatever.

Increasing the vertical resolution would require using interlacing and/or reducing the frame rate to below the point where flicker becomes very annoying unless you have a monitor with a long-persistence phosphor, like what Commodore sold to make the Amiga's interlaced 640x400 mode tolerable to use.

IBM's own 8514A monitor probably needed some long persistence phosphor tweaks because the effective 43hz refresh rate, while not quite as bad as an Amiga's 60hz, is still pretty flickery, at least to my eyes.
 
More necessity than luxury. SCART was born in France, where they used SECAM (System Essentially Contrary to the Accepted Method), which is a pain in the neck to generate, plus everyone else in Western Europe used PAL, and rather than manufacture expensive, complex multi-system TVs, it was easier to just give everyone an RGB input.
That is not true; most SCART inputs do not support RGB signals. Most TVs only had at most one (rarely two), often specially marked SCART input with RGB capability. Most video sources (VHS, camcorders, etc) did not provide RGB signals to start with, so any RGB capability went unused. From my memories, having many inputs, auto-switching, stereo audio and S-Video support were far more important.

I'm not familiar with the French side, but I've heard that after German reunification (the GDR also used SECAM, contrary to West Germany which used PAL), many existing TVs were either easily converted to take PAL inputs (as they were basically PAL TVs with a SECAM decoder to start with), or used with an external PAL decoder.

Thing is, though, for these experiments I’ve used pixel clocks that can’t be mistaken for NTSC colorburst.
I'm from PAL land, so generally not affected. :)

Realized I hadn't posted any pictures of graphics mode, here's "Hoyle's Book of Games", Tandy 16 color mode, on both the built-in composite and through the AD724 luma/chroma:
Wow, that's a huge display. Very nice!

As a side note; I'd love to find something that can convert the interlaced 1024x768 output of the IBM PS/2 8514A video card so it could be used on a common, standard VGA display. That would be sweet, and I'd love to have one before my PS/2 gathers so much dust I can't find it anymore....
Unfortunately, I don't have a good solution either. Many 512K ISA SVGA boards can generate 1024x768x4 interlaced (43 Hz), but not progressive. The Amiga world spawned lots of linedoublers, but they only work for PAL/NTSC modes...
 
That is not true; most SCART inputs do not support RGB signals. Most TVs only had at most one (rarely two), often specially marked SCART input with RGB capability. Most video sources (VHS, camcorders, etc) did not provide RGB signals to start with, so any RGB capability went unused. From my memories, having many inputs, auto-switching, stereo audio and S-Video support were far more important.

I'm not familiar with the French side, but I've heard that after German reunification (the GDR also used SECAM, contrary to West Germany which used PAL), many existing TVs were either easily converted to take PAL inputs (as they were basically PAL TVs with a SECAM decoder to start with), or used with an external PAL decoder.


I'm from PAL land, so generally not affected. :)


Wow, that's a huge display. Very nice!


Unfortunately, I don't have a good solution either. Many 512K ISA SVGA boards can generate 1024x768x4 interlaced (43 Hz), but not progressive. The Amiga world spawned lots of linedoublers, but they only work for PAL/NTSC modes...
The dumb $5 solution would be to run the 1024x768i svga into an Averkey Imicro which generates a 15khz RGBS signal that can then be scan doubled by a cheap commodity line doubler for display on an LCD.

Lots of latency but should work and all 1024 columns should be resolved.
 
Off on another side trip: I figured I did the work to make the GAL DAC, so I might as well buy one of those cheap GBS-8200 scaler boards and see if it works with that. (Somehow I've managed to go this long without banging my head seriously against that wall so I'm probably overdue.)

Short version is of course the same setup works about as well as an input for the GBS-8200 as it does for the AD724. One thing I changed is I added a 74HCT373(*) between the GAL outputs and the resistor ladder, because according to the datasheet it has about twice the drive output current, and it also claims that it should consistently run closer to the voltage rails even under load. (The GAL datasheet only promises a TTL-acceptable 2.4v level out as a minimum and doesn't even make claims for "typical".) I should probably do this same thing with the AD724 circuit; it might make it slightly easier to tune the resistor ladder should I decide it needs it.

(* I'm not using the latch functionality of the chip, LE is tied high so it's just a buffer. I happen to have a ton of them.)

Anyway, breadboard setup:

gbs_breadboard.jpg

And some screenshots. 80 column text is a little soft but pretty usable:

80_column.jpg

40 columns and graphics look pretty decent:

40_column.jpg

hoyle_gbs.jpg

FWIW, the resistor values used for the R/G/B outputs are 510k for the "base" color and 1000k for the "intense" add-on. The ratios seem about right; I think the levels might be a little hot for a by-the-book analog monitor (haven't checked with the scope), but the GBS board has trimmers to handle *even hotter* arcade boards.

Since a lot of people have messed with these things, well... there are some nits to pick, curious about other people's experience in a few areas. The big one is sync issues:

A: The board and (the terrible excuse for a) manual for these boards imply that you can supply separate H/V sync on the P11 connector; I absolutely could not get that to work. Are the markings a lie, or is there some trick that's not well documented here? Do separate syncs need to not be at TTL levels, or something goofy like that? It seems to be fine with TTL-level Csync...

B: I implemented an XNOR sync combiner in the GAL program, and that works, although it doesn't seem like it's *entirely* perfect? When in "normal" 200 line CGA modes it seems like there's a little bit of instability in the first line of pixels. (rest of the screen is solid.) Worse, and I imagine this might be a Tandy 1000-specific problem, when the Tandy's in the 225 line text mode the instability affects the top couple lines if text at the top. Is this a common problem?

C: I have the parts lying around to build a gbs-control add-on, is this likely to fix A and/or B?
 
IBM's own 8514A monitor probably needed some long persistence phosphor tweaks because the effective 43hz refresh rate, while not quite as bad as an Amiga's 60hz, is still pretty flickery, at least to my eyes.

Correct. The original 8514, 8515, and 8516 monitors had long-persistence phosphors and were reasonable to use at 43.5 hz (87 hz half-fields interlaced). Connecting an 8514/A (or, i my case, an Image Adapter/A or an XGA or XGA-2) to a more "modern" monitor, like the Ambra monitor I had at the time, was almost unbearable since the flicker was noticeable. Using a real 8514 or 8516 for hours at a time, on the other hand, was completely fine.
 
A little off topic on the S-Video portion of this thread, but fwiw, I went ahead and soldered together a perfboard with my GAL-based resistor ladder, hooked it all up with the GBS scaler board, and, just this afternoon, finished programming an ESP8266 to run gbs-control. Somehow I'm going to have to find some kind of a case for all this mess...

tandy1000exwithgbs.jpg

Anyway, all I have to say about GBS-Control is I'm officially a true believer, and if you're using a GBS scaler board without it run, don't walk, to your favorite garbage online retailer (Amazon, Aliexpress, whatever), spend less than $5 on an ESP8266 board, and deal with the hassle of getting it installed because it's absolutely amazing. I clearly need to hook it up to a better monitor to really do full justice to it, but the output is incredible compared to what it is without it; pin sharp and perfectly in sync. (The stock firmware looked terrible with the 225 line mode the Tandy boots up in by default; everything outside the core 200 lines wavered, and even that had tearing at the top and bottom.) I'm undecided whether I want to leave scanline emulation on or turn it off; in either mode it almost looks too good, like I'm running an emulator, but I'm sold either way. Should have built one of these years ago.

If anyone wants to build a DAC like mine I'll scrape together a schematic and stick it in a git repo with the GAL code at some point. If you have the dingus to program the GAL and have a selection of resistors and caps to raid lying around the BOM for building one of these is about $30, which isn't bad for a DIY CGA monitor substitute. (If you can solder surface mount and can actually find a Raspberry Pi Zero at list prices you might be able to put together a RGB2HDMI for about the same, I guess, but a preassembled one will cost you more.)

Anyway, need to get back to doing the S-Video converter the "right" way. Debating whether to also perf-board it to try to eliminate some of the noise from the breadboard, or go straight to making a PCB....
 
Last edited:
I’d like to see a schematic of this thing. I could attempt to make some boards, as I seem to have access to S-Video monitors more readily.

This would let me use a Commodore 128 VDC with the monitors I have, without a bulky HDMI adapter or the GBS-8200 hack.
 
I’d like to see a schematic of this thing. I could attempt to make some boards, as I seem to have access to S-Video monitors more readily.

This would let me use a Commodore 128 VDC with the monitors I have, without a bulky HDMI adapter or the GBS-8200 hack.
I’m pretty sure GBS control is open source with a GitHub.
Also Commodores native video mode is already svideo, in a way they invented it.

Only later did Commodores 2 rca svideo get converted into a single cable (modern svideo)

There should be adapters off the shelf from commodore to svideo
 
Also Commodores native video mode is already svideo, in a way they invented it.

A commodore 128 has two completely separate video systems; the VIC-II based C64 subsystem (that has the “svideo” output) and an 80 column system that resembles CGA, with only RGBI and mono composite options.
 
I’d like to see a schematic of this thing. I could attempt to make some boards, as I seem to have access to S-Video monitors more readily.

I’ll see if I have time to work on it this week. I was going to try a small revision to the prototype to see if I can just use the gates left over on the GAL to drive the crystal, eliminating the need for the 7404 chip.
 
Back
Top