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

Elf

All gone now
Feb 4, 2019
794
264
63
Edit: With apologies, I no longer wish to have involvement with SGUG or SGI communities in general,
and have also chosen to remove all of my content. Many things have changed since I co-founded, named, and ultimately
then left SGUG. There are many good people around, to whom I apologize for frustrating by removing these things, and
also many petty people that over the years whittled down both the enjoyment as well as sense of obligation I used to
feel to anyone else regarding what was ultimately just a hobby. Unfortunately one of the latter now writes the rules
and so it is time for me to take my things and go.

This message will replace all of my previous forum posts because deleting threads that I started would have removed
other peoples' posts.
 

Attachments

  • s-l500.jpg
    s-l500.jpg
    26.7 KB · Views: 1,451
  • Screen Shot 2020-03-02 at 8.36.45 PM.png
    Screen Shot 2020-03-02 at 8.36.45 PM.png
    161.8 KB · Views: 1,282
  • DIP 13W3.jpg
    DIP 13W3.jpg
    783.8 KB · Views: 1,082
  • SI 7053.jpg
    SI 7053.jpg
    777.2 KB · Views: 1,216
  • Screen Shot 2020-03-02 at 8.53.41 PM.png
    Screen Shot 2020-03-02 at 8.53.41 PM.png
    116.9 KB · Views: 834
  • Screen Shot 2020-03-02 at 8.26.39 PM.png
    Screen Shot 2020-03-02 at 8.26.39 PM.png
    1.8 MB · Views: 843
  • Screen Shot 2020-03-02 at 8.26.51 PM.png
    Screen Shot 2020-03-02 at 8.26.51 PM.png
    1.6 MB · Views: 889
  • Screen Shot 2020-03-02 at 8.29.41 PM.png
    Screen Shot 2020-03-02 at 8.29.41 PM.png
    2.2 MB · Views: 847
Last edited:
  • Like
Reactions: bitpak and 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.
 
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
 
  • Like
Reactions: bitpak and Elf
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.
 
  • Like
Reactions: Elf
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.
 
  • Like
Reactions: callahan
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:
Code:
setenv monitor h
on bootup.

Read
Code:
man prom
for more details from within IRIX.
 
  • Like
Reactions: callahan and Elf
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
 
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.
 
Edit: With apologies, I no longer wish to have involvement with SGUG or SGI communities in general,
and have also chosen to remove all of my content. Many things have changed since I co-founded, named, and ultimately
then left SGUG. There are many good people around, to whom I apologize for frustrating by removing these things, and
also many petty people that over the years whittled down both the enjoyment as well as sense of obligation I used to
feel to anyone else regarding what was ultimately just a hobby. Unfortunately one of the latter now writes the rules
and so it is time for me to take my things and go.

This message will replace all of my previous forum posts because deleting threads that I started would have removed
other peoples' posts.
 
Last edited:
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... ?


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

Jonathan
 
Edit: With apologies, I no longer wish to have involvement with SGUG or SGI communities in general,
and have also chosen to remove all of my content. Many things have changed since I co-founded, named, and ultimately
then left SGUG. There are many good people around, to whom I apologize for frustrating by removing these things, and
also many petty people that over the years whittled down both the enjoyment as well as sense of obligation I used to
feel to anyone else regarding what was ultimately just a hobby. Unfortunately one of the latter now writes the rules
and so it is time for me to take my things and go.

This message will replace all of my previous forum posts because deleting threads that I started would have removed
other peoples' posts.
 
Last edited:
  • Like
Reactions: bitpak
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?
 
Edit: With apologies, I no longer wish to have involvement with SGUG or SGI communities in general,
and have also chosen to remove all of my content. Many things have changed since I co-founded, named, and ultimately
then left SGUG. There are many good people around, to whom I apologize for frustrating by removing these things, and
also many petty people that over the years whittled down both the enjoyment as well as sense of obligation I used to
feel to anyone else regarding what was ultimately just a hobby. Unfortunately one of the latter now writes the rules
and so it is time for me to take my things and go.

This message will replace all of my previous forum posts because deleting threads that I started would have removed
other peoples' posts.
 
Last edited:
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.
 
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.
 
Edit: With apologies, I no longer wish to have involvement with SGUG or SGI communities in general,
and have also chosen to remove all of my content. Many things have changed since I co-founded, named, and ultimately
then left SGUG. There are many good people around, to whom I apologize for frustrating by removing these things, and
also many petty people that over the years whittled down both the enjoyment as well as sense of obligation I used to
feel to anyone else regarding what was ultimately just a hobby. Unfortunately one of the latter now writes the rules
and so it is time for me to take my things and go.

This message will replace all of my previous forum posts because deleting threads that I started would have removed
other peoples' posts.
 
Last edited:
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?
 
Edit: With apologies, I no longer wish to have involvement with SGUG or SGI communities in general,
and have also chosen to remove all of my content. Many things have changed since I co-founded, named, and ultimately
then left SGUG. There are many good people around, to whom I apologize for frustrating by removing these things, and
also many petty people that over the years whittled down both the enjoyment as well as sense of obligation I used to
feel to anyone else regarding what was ultimately just a hobby. Unfortunately one of the latter now writes the rules
and so it is time for me to take my things and go.

This message will replace all of my previous forum posts because deleting threads that I started would have removed
other peoples' posts.
 
Last edited:
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.
 
  • Like
Reactions: jcarron2 and Elf

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu