Silicon Graphics / IRIX 13W3 and Sync on Green (SoG) solutions

[Elf]

The first thing that people often come across when using older SGIs is the 13W3 video output. The one and only solution I recommend to this is the famous "DIP switch" cable that adapts from 13W3 to a standard HD-15 VGA connector. This cable is in current production by cablesonline.net, and can be found on eBay here (for $20): 6 ft. 13W3 Male to SVGA (HD15) Male Universal Cable w/ 12 Dip Switches - W3-606. Note that via the DIP switches it supports configurations for SGI, Sun, and IBM (and presumably others), so if you own other old UNIX workstations with 13W3 outputs this will be a very flexible cable for you.

​

The cable itself appears to connect through different pins based on the DIP switch setting, and has some ability to route sync around to use either composite, H/V, or Sync-on-Green (SoG) outputs. It is not clear to me whether there are any active electronics in the cable and whether it is performing full SoG conversion or simply duplicating signals to other pins to get a SoG capable monitor to do its thing.

Although the easiest thing to do from here is simply to use a SoG capable monitor (with DIP switches set as per the SGI H/V sync out column), people will occasionally run into (or simply already have) monitors that they like that do not handle Sync on Green properly. I have come across something that seems to be a decent solution to this as well.

"Sync stripping" equipment can be used to separate the sync signal from a Sync on Green output and also remove it completely from the green channel. Sync stripping devices can range from small and cheap to large and professional. I've been playing around with the Software Integrators 7053 Sync Separator. Some of these can currently be found for fairly cheap (less than $20) on eBay, so if you want one, snap one up while you still can!

The 7053 Sync Separator will translate a sync-on-green RGB analog video signal to a standard separate sync (VGA) signal.
Sync-on-green is typically output from all DEC, NeXT, HP, SGI, APOLLO, and IBM workstations.
[...]
Green Video

• Output pin 2
• Sync signal removed
• 75 Ohm Source Impedance
• 0.0 to 0.7V DC Coupled

I have paired up this device with the 13W3 cable (with DIP switches set to SoG output) and it does appear to output proper H/V sync with no more SoG signal, as advertised.

Note that the 7053:

• Requires a center positive 6V 5.5x2.1mm DC barrel jack power input (missing from the current eBay listing)
• Has a male input and a female output. This leaves it the wrong way around for connecting on the end of the 13W3 adapter cable, and you will need both M/M and F/F gender changers to reorient it. If you do not, you will simply not see any signal!

​

 

[LarBob]

Awesome! I've been thinking about trying this for a while in order to be able to screen capture SGI machines much more cheaply as well.

 

[callahan]

My Dell monitors work just fine with a standard Sun 13W3->DB15 (VGA) adapter along with the cut all non-ground pin trick (https://phaq.phunsites.net/2006/08/25/using-a-sun-13w3-vga-adaptor-on-a-sgi-indy/).

This should work with most modern monitors (most of which are SOG compatible).

 

[ghost180sx]

I got this exact cable working plug n' play with my SOG compatible SHARP LCD monitor on my octane. However I was in a bind when I recently received two Indys in the mail in my covid-safe shack in the woods. I had brought my cable with me, as I was expecting them to arrive. After reading thru SGIs docs and man pages, I figured out that you can get composite or H/V sync to work with the Indy (and probably all SGIs) this way:

1. Set the DIP switch setting on the cable to H/V sync (second column)
2. Connect crappy PC monitor like usual. It's hip to be square but rad to be wide!
3. Oh look it works, but my screen is weird, and the monitor is reporting the wrong resolution! Why does the monitor think this is 1024x800? *scratch head*
4. man setmon. Eureka! Pay special attention to all the exceptions and weird idiosyncracies of all the different gfx boards
5. cd /usr/gfx/;./gfxinfo to get current resolution and settings
6. setmon -w <format>
7. disconnect any external serial console cable used for debugging. My Indy had PROM v. 6 and I found a bug where unless you disconnect this, the graphics are so wacky and weird
8. reboot
9. enjoy awesome graphics with H/V sync

YMMV

 

[callahan]

I just picked up one of these cables and the results were odd. Background here, which I won't fully repeat in this thread.

At least on MGRAS cards, I am having a lot of odd issues with higher resolutions on modern LCD displays.

In particular, when trying to troubleshoot a 1600x1024 format (intended for use in someone else's MLA setup), I had the following problems:

1. Using my Dell U2412, the monitor sensed 1280x1024 and cut off the leftmost 320 pixels of the image.
2. Using a BenQ XL2730Z (a 1440p/144FPS gaming monitor), the leftmost pixels were visible, but the monitor reported 1280x1024 despite clearly drawing an image more than 1280 pixels wide. There was also substantial tearing and visual artifacts on the left side of the image.
3. Using the same BenQ, the 1920x1200 resolution I use every day with the Dell U2412 displayed as 1600x1200. So odd.

I did all of this testing with one of the fancy dip-switch cables, and found that none of the settings (all, H/V synv, SOG) substantially changed how either monitor handled any signal.

I did not mess around with the setmon settings, as it appears there are few usable options with MGRAS cards (primarily an option to output sync on any/all colors besides green).

It appears that there is a lot of (1) black magic in the SGI side that determines how images are rendered and (2) variability among modern digital displays that dominate the user experience.

 

[ghost180sx]

Callahan, i would agree. During boot, my Indy puts out 1024x768, but my monitor falsely thinks it's 1024x800 and leaves a black bar at the bottom. I really can't understand why that's happening, but it might be something to do with the monitor. Clearly, higher end monitors seem to handle SGI output better... I want to do more testing and maybe even try some PROM upgrades on this thing to see if it helps.

 

[ghost180sx]

Callahan, I fixed my weird issue with the Indy and the cutoff 1024x768 boot screen. It is a workaround for the lower-res mode, but I'm happy with it!
The PROM has a setting to force the monitor into hi-res (1280x1024@60Hz) mode on boot! To use it, type:

setenv monitor h

on bootup.

Read

man prom

for more details from within IRIX.

 

[gmcenroe]

Looks interesting. I bought this same 13w3 to vga adaapter cable from ebay with dip switches that you showed in your post. Since it has male VGA I forgot to buy the female to female VGA coupler so I can connect my older viewsonic flat screen monitor. I am reviving my Indigo 2 solid impactfrom 15 years of boxed hibernation in my garage to break up the COVID stay at home boredom. I hope it works. I guess all I have to do is set the #6 switch on. If I don't do it correctly is there any risk of damage to the Indigo 2 graphics card? I don't feel like hauling down the 50lb SGI monitor from storage. Thanks

 

[weblacky]

I have these same cables (bought like 5 of them, would love to buy more..but money). Used on Indigo2s so far. No problems...However I also use SOG compatible/tolerant LCD models (Samsung SyncMasters and Dell 170x models). From what I've read, most SGI systems with separate H/V Sync pins still output SOG over Green and won't stop. So tolerance is a thing. Striping the SOG is needed even with the right pin out if the monitor you are using doesn't tolerate a SOG signal. I just prefer to collect many compatible LCD screens to just use on my SGIs. Gone are the days where I'd exert money and time making some brand new, huge, PC LCD monitor on my main system work with an SGI. Each SGI isn't like every other, generationally , yes. But over time, no. After 20+ years I can say, tailoring the Monitor to the SGIs works better than the other way around.

 

[Elf]

I have been working a lot with analog video signals lately with my console projects; AC coupled video vs. DC coupled video, various types of sync, sync on green, etc. and I think it is increasingly apparent to me why some monitors have a green tint but still show an image when an SoG signal is used...

I should put some SGIs on the scope and confirm

 

[jcarron2]

Do you think something like this work to separate the sync signal from a Sync on Green output - uses a LM1881 and 74LS04 and a couple caps, resistors... ?

[Arcade PS2] Sync on Green - Simple Way to Remove the Greenish

[Arcade PS2] Sync on Green - Simple Way to Remove the Greenish: There are monitors that natively support SOG (sync-on-green), and others that don't, the others that don't support it, they need some extra components to separate the video sync from the green channel, and that can be done with a...

www.instructables.com

Haven't been able to find a used 7053 sync separator, and $130 is just too much for that...

Jonathan

 

[Elf]

It's a good find and one I have seen before, but it has several issues unfortunately... I think the person who made the circuit has some fundamental misunderstandings about electronics and video signals, because their design has a few significant issues which manifest in some of the behaviors they later describe. The explanation below is technical, but if you don't want to or can't parse through that I would just say that I don't recommend using that design.


The LM1881 is an appropriate sync separator for video usage where the sync rate is fixed (e.g. 15kHz NTSC SD video), which is its intended application. If you are not feeding it 15kHz video it requires an external resistor and capacitor to set the expected sync rate (pin 6). See the LM1881 datasheet:

The resistor on pin 6 (that is, Rset) allows the LM1881 to be adjusted for source signals with line scan frequencies differing from 15.734 kHz.

I expect the Playstation RGB output has a fixed sync rate which is where they get the 680K resistor from in their diagram, but this is not true of the various VESA video standards when you have a wide variety of resolutions/refresh rates. These can range from 31kHz (bare minimum VGA) to 120kHz+ at higher resolutions and refresh rates. For more detail see the VESA General Timing Formula Standard. The important part to emphasize is that there is nothing in the LM1881 (or its derivatives) that will automatically detect the sync rate or automatically adjust between different sync rates as your resolution changes, e.g. between PROM and booting into X or if you change resolution on your own or for different displays. Circuits based on the LM1881 without significant additional smarts are only good for one sync rate (only good for one resolution/refresh rate combination). This does not affect the Playstation application but it does affect your application.

Further to that though they are (naively) using a diode to try and strip the sync pulse off of the green channel. This can be tempting, because the voltage drop of the diode allows you to chop off some section of the green channel below a certain voltage (the sync pulse), in a naive ideal world and with the ideal on-paper diode that doesn't actually exist. Diodes are not ideal though; they have a forward voltage drop and that voltage drop is non-linear based on the current being drawn through the diode. The author of the piece erroneously terms the diode's forward voltage drop an "internal resistance" and says he has added a potentiometer to "increase the wave" (sic) to correct for this. He appears to be using this potentiometer to DC bias the green channel input to overcome the diode's forward voltage drop, although I'm not sure he knows this. This could potentially be damaging to different types of equipment (e.g. your SGI's video card) depending on how well they tolerate DC current being applied directly to their video output. Presumably the PS2 doesn't seem to care, but your equipment may.

That aside the output of the green channel going through the diode is now going to be non-linear. You can see this in the author's own text where he describes having to adjust the DC bias (potentiometer) even based on what game he is playing because he keeps noticing more or less green. This is not normal. Both the DC floor of the signal and the linearity of the green color channel (color accuracy) will just not be there no matter how it is adjusted.

The solution the author provides is overly simplistic, even for the PS2 application. The correct way of restoring 0-100 IRE signals to the 0V line and removing the sync pulse involves "DC Clamping," and implementing it is more complex. Research the applications of DC Clamping in video, if interested

FWIW I think someone could design a solution that costs significantly less than $130 and might be simple enough for hobbyists to make. If I had any time I might be able to do it! But unfortunately I don't really have free time anymore, so if anyone is interested hopefully the above is at least enough to get someone pointed in the right direction.

 

[weblacky]

Yo Elf,
Quick question, what about modifying the SGI hardware to prevent injection of the SOG? I obviously don't know enough on the topic but if we assume that there is some chip that breaks out the H/V on most systems eventually, then might it be possible to simply find a resistor to remove or a trace to gently cut through that cuts the input of the sync to whatever places it on the green to begin with?

They are a lot of chips, so I assume this is a like a workflow and all this isn't integrated into a single step. Perhaps we could simply prevent the sync signal from being "mixed" into the green originally...but preserve the sync signal being feed to where it needs to come out as H/V sync?

 

[Elf]

I would guess what inserts sync on the green channel is probably buried somewhere in a RAMDAC (or similar) chip rather than a discrete component, but you could certainly explore it! However in all these discussions it's probably worth pointing to @ghost180sx 's post #4: https://forums.sgi.sh/index.php?threads/silicon-graphics-irix-13w3-and-sync-on-green-sog-solutions.187/post-1189

He seems to have gotten true H/V sync output (with no SoG) from his Indy, so it would probably be worth testing that on other machines as well prior to hardware modification

 

[ghost180sx]

Exactly. Cutting pins is super ghetto. Don't do it unless you're desperate, and even then, probably don't do it. SGIs were made to make nice video pictures. There's likely a way to get this done without hacking stuff up.

 

[weblacky]

I already use the DIP switch cables, old news. Still doesn’t remove SOG. Sync separator has been out for awhile. Another AC adapter and device to burn out while being left on. Great. Right now I use all SOG tolerant 17” LCD screens. So I’m fine for about 20 years until they wear out. Then we’re back at this discussion.

The question in this post is about removing SOG.

Who the heck mentioned cutting pins? I didn’t, so why bring it up? No I don’t cut pins, these connectors aren’t available anymore. I said traces. Way different and much easier to reverse.

And no cutting a trace is correct if you need to sever a signal (unless component removal can accomplish it). There’s nothing ghetto about disabling a feature that’s hindering usage because it’s essentially unsupported by modern displays.

People add rgb interfaces and hdmi upscalers to old game consoles, how is that so different then suggesting you disable a signal which is essentially interference by today’s standards?

I don’t care enough to look into it because that’s why I own 6-7 screens that work with SGIs (to not have to deal with this problem). I’m just surprised no one has bothered to look at altering the source of the signal.

Someone who’s motivated may have better luck getting rid of the source of the problem instead of attaching an adapter/filter.

 

[Elf]

The post by @ghost180sx isn't as explicit I guess but a lot of the detail is buried in the part about using setmon rather than just the use of the DIP switch cable. I have not tried this myself, but see the setmon man page: https://nixdoc.net/man-pages/IRIX/man1/setmon.1.html

     -ssyncselect
      Specifies the    source of the sync signal.  syncselect is any
      combination of r, g, b, and a    to represent the sync signal on    the
      same combination of the red, green, blue, and    alpha video cables.
      If  syncselect is n, the sync    signal will be generated on the    sync
      cable.  If syncselect    is not specified, the sync signal will default
      to the green cable.

Later in the examples it shows different sync configurations:

     /usr/gfx/setmon -x    -s b 640x480_180q

      sets a RealityEngine or InfiniteReality to run 640 x 480 x 180 Hz
      color    field sequential output    with sync on blue when graphics    is
      next initialized.

     /usr/gfx/setmon -g    -s rgb vof3

      sets the video output    format to the VOF contained in the file    vof3.u
      found    in the appropriate /usr/gfx/ucode/vof subdirectory.  The
      format is genlocked and with sync-on-red/green/blue.

I am not sure what machines or what graphics cards all those options are supported on, but it is worth a try by anyone interested, in any case. It seems that at least on some cards the sync options are rather flexible.

 

[weblacky]

Yeah, I've heard that said back in the nekochan days (Setmon remove SOG), but I thought that was Onyx video outputs only? It wasn't generally applicable to all SGIs (even workstations). Unless someone found a new hidden gem? Also I assume this still doesn't affect PROM? So it's like the old reverse fixed frequency monitor with Windows 9X trick, no BIOS/POST screen, but once windows starts it works?

 

[Elf]

Yep I assume it would not affect the PROM, so your experience would be green until it boots. But again, I haven't tried it; it would be interesting if people gave some feedback on what models/cards it does or doesn't work on. Supposedly it works on at least one combination of Indy, according to @ghost180sx?

 

[ghost180sx]

Yeah sorry I wrote my post in the irreverant style of Phrack or old eZines. In any case, I basically poked around the Indy's /usr/gfx/ucode/vof subdirectory and found a command line option that worked. I had a serial cable handy just in case. And also found a bug in my PROM version as stated in my OP that threw me for a loop for a good hour or so. The man page is quite clear about which graphic system has which specialty options. The second command line option is closer to what you want. Just look around the directory of the machine you want to change vid modes on and have at'er.