Nekochan Net

Hi folks. I've been working to get my old Apple 22" ADC (plastic bezel) Display working as _the_ display for my KVM'd machines, including my Octane2.

When I first started this whole project I had no idea idea that the old ADC display would be such a PITA to use. But dang-it... it is just so purdy looking. So, one Apple ADC-DVI adapter later, and then one DVI-D-VGA adapter even later... I was ready to start trying to get some visual output from yay-old-Octane2.

So I i've been looking for a display setting to feed into my V6 that would make the display usable. Out of the box, the V6 1280x1024_60 mode(s) work to at least drive the display, but the porch calcs are all skewed, such that the image on screen is shifted so far right and down that the right/bottom 100-200px of the display are hidden.

The native resolution of the display, as some may know, is 1600x1024. As some may also have found, this resolution requires a pixel clock inside the black hole for the v6/v8 boards, so the built-in VFO for that resolution will not actually work (why did they even ship it?).

I am still working on the right settings to accomplish the native display resolution, and may or may not ever get them. I know I can get close, but I won't accept an image with any portion cut-off. So, that is on-going. But I did find that the display will work fine enough at a resolution of 1344x1008. It gets some extra width over the 1280x1024, while sacrificing a little of the height. After _much_ toying around with SwitchResX on my Mac, I was able to get working porch settings, frequencies, etc. for this resolution that put it splat in the middle of the screen (or, well, darn close) and do not crop any edges.

Here are those settings.


In theory, with reduced blanking, and with an accepted slight hit to refresh rate (maybe 56hz or 57hz instead of 60hz) I should be able to get a working 1600x1024 resolution. I have one that is mighty close on the Mac, but it still needs tweaking before I try to compile for the SGI.

I am still experiencing an unrelated issue where it appears the monitor or one of the adapters is not happy about SoG... the display color is all green tinted. I know it is not the KVM (NTI ST-4U) - it has worked fine with other displays. I have sorted out custom gamma settings that fix this, but I am not sure how to load them at login... or before...

If anybody has any war stories about these displays, I'd be interested to hear.

_________________

To cut them a little slack, lcd's were not common then and the good crt's all refreshed at much higher rates than 60 ...

Will the Apple display synch at 50 hz ? And does that get you out of the V6 hole ? If so, 50 hz is fine, you won't even notice the difference. I ran my 1600sw at that for years and now using 48 hz refresh, can't tell it's a slow refresh rate, shows video fine, etc etc.

I wasn't quite sure if you needed a 1344x1008 format for your V6. So if you already compiled your own you can stop here.

If you don't already have a 1344x1008 format for your V6, I extrapolated a modeline directly from your SwitchResX numbers and made one. As you noted, the resulting pixel clock is 108.5, so the format will be right on the cusp of your V6's forbidden 109-193MHz pixel clock range. I don't have a suitable monitor to test against, but hopefully the format will be usable with your V6 - it compiled without complaint and the VFC generated analysis looks OK and seems to match up against your SwitchResX info fairly well: There's a very basic outline of how to correct for vertically or horizontally shifted display formats towards the bottom of this post.

*IF* the 1344x1008 format works, if you'd like I'd be happy to try again with whatever you can workout with SwitchResX or VFC with a 1600x1024 format.

_________________
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

I don't know for sure which Apple 22" display you have, but as long as the build environment was still set up for the VFC Makefile, thought I'd take a shot at making a 1600x1024 format for your Apple display.

Managed to turn up an ancient xFree86 modeline for an Apple 22" Cinema Display at 1600x1024 (with no refresh rate implicitly mentioned, but *with* a Pixel Clock just under the V6 Black Hole): That modeline turned up in a number of places, if we're lucky it won't be an example of the internet's Achilles Heel (self-replicating bad info).

Used that to generate two 1600x1024 formats, one at the 50Hz refresh rate mentioned by hamei, and the other with a 60Hz refresh rate. The format with the 50Hz refresh rate has a Pixel clock of just 89.9712 MHz (well below the V6 black hole). if the Apple Display seems not to like the 89.9712 MHz clock rate, the 60Hz version has a Pixel Clock of 107.965 MHz, much closer to the 108 MHz specified in the Modeline (but still below the 109 MHz to 193MHz range denied to the V6).

VFC Analysis of the 50Hz format: VFC Analysis of the 60Hz version:

_________________
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

Sorry for the silence here - I've been too sick to look at my computers. I'll be trying out these VFO attempts and let y'all know what happens.

_________________

If none of 'em work out (who knows if that xFree86 modeline is accurate or not), if you can grab the SwitchResX parameters for a stable 1600x1024 display, we can try dumping that info into a vfc source file. Something with a pixel clock of less than 109MHz would be nice, but barring that we can always try tweaking the refresh rate.

_________________
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

as a side-issue... I noted before that the display is tinted green suggesting some part of the whole thing is not SoG compatible (I wonder if it is the display... or maybe just the analog to digital converter box?). So I found that by adjusting the color channel gamma settings in the display properties control panel of the Octane, I could compensate and make the picture appear correctly coloured (or close to).

What I am not clear on is how to load those gamma settings whenever the machine logs in, or better yet, when it boots? I can save the display properties to a file, and re load manually... but can I just load that file automatically?

Thanks,
Z

_________________

Hiho!

So, the 60Hz VFO ~mostly~ works. Image displays and is useable. However, the picture does not fit on the display - the sides are cropped off, and I'm not sure but the bottom might be cropped. Meanwhile, the top of the picture does not reach the top of the screen. I believe at this point I need to futz with the 'porches' and see if I can squeeze the picture onto the display. Would you mind posting the VFS files for the VFOs you put up? I have successfully hacked together VFS files before, but I'm still not 100% of what the syntax is because I can't find any documentation other than the sample files themselves. So if I have your VFS files it should be easier to go about tweaking.

To those other owners of old ADC Apple 22" displays, note that you should try the VFO above first. I think that my display's picture issues are partially caused by the KVM and Analog-Digital converter between the Octane and the DVI-ADC converter... and then the display. In other words, too many boxes are mucking up the signal from one end to the other. But if you, for example, take the KVM out, the one above might work fine.

_________________

Sure - the values in the VFC source file are derived from the modeline. Here's that xFree86 modeline again - the second line identifies each of the values and how they're used to calculate what's needed to complete a VFC source file (Hn are horizontal values, Vn are Vertical values):

The values needed to complete a video format source file (.vfs) are:
Using the values from the xFree86 modeline (listed above) gives: The resulting VFC source file is attached as "Vpro_4Apple-22inch_1600x1024_60.vfs.txt. The text extension was added so the nekochan interface would allow the file as an attachment. To use the file remove the ".txt" portion.
To decrease the width of the display image (where the image extends off both sides of the monitor), increase the TotalPixelsPerLine by values of 8 (adding to the overall (total) number of pixels on the LCD panel "squeezes" the visible active pixels, decreasing the width of the display image); to shift the image up increase the vertical front porch and decrease the vertical back porch (by increasing the numerical value of V2 and V3 *equal* amounts.

Unfortunately it isn't always as simple as changing just the sync or porch values. To avoid fundamental coding errors and subsequent display anomalies, the values expressed in the modeline *must* remain balanced. As seen in the above examples, because of the underlying calculations each of individual horizontal or vertical values has an effect on the value of the others. So if the combined horizontal or vertical values exceed the total pixels or lines, VFC will stop with a "shorten your format" error, if the combined horizontal or vertical values are less than the total pixels or lines, VFC will fill the frame with valueless transitions that may have an undesired effect on the resulting display format.

To avoid head-scratching issues with compiled formats, I'd suggest following a few basic rules:

• Each subsequent value in the horizontal or vertical portions of the modeline (H1 though H4 or V1 through V4) must be numerically higher than the previous value.
  
• The horizontal values ActivePixelsPerLine, HorizontalFrontPorch, HorizontalSync and HorizontalBackPorch must equal] the TotalPixelsPerLine, and each of the horizontal values (H1 through H4) must be multiple of 8;
  
• the vertical values ActiveLinesPerFrame, VerticalFrontPorch, VerticalSync and VerticalBackPorch must equal the TotalLinesPerFrame.

I went ahead and took a shot at adjusting your image by editing the modeline:

The original:and the editied version:


Using the values from the modified modeline gives: The resulting VFC format and source are attached as "Vpro_4Apple-22inch_1600x1024_60-shifted.vfo" and "Vpro_4Apple-22inch_1600x1024_60-shifted.vfs.txt (see my previous note about dealing with the .txt extension on the source file). If the format needs additional tweaking or if you have questions I'd be happy to help.

_________________
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

Okey dokey! Thanks for the input Recondas! Using your VFS, and modifying it to 'squeeze' the pixels as you mentioned, I finally (after many tries) got a perfect fit for the picture. It actually fits better than the display on my G5 Mac also connected to the display via KVM... so I can now use this info to go back and try to change the settings on the Mac with SwitchResX.

I still don't fully understand how non-SGI employees figure out the full details of the VFS syntax. I'm not talking about what TotalPixelsPerLine means, for example, but rather how do we know that it is TotalPixelsPerLine and not totalPixelsPerLine... or why do we define the horizontal sync and porch values straight-up but then have separate sections for each vertical porch and the sync? And what does the dump edge post process thing at the end mean? I can't find documentation for this file format anywhere... aside from the example VFS files SGI shipped. What am I missing?

Thanks again!
Z

_________________

Very nicely done!

Looks like the xFree86 modeline I found for your 22" ACD wasn't terribly accurate - or at least not well suited to your analog-to-DVI-to-ADC conversion. You had to do more tweaking to get a centered display than any modeline-to-vfo conversion I'm familiar with. What that comparison doesn't show is the amount of trial and error work that went into your working format - recalculating, recompiling and reloading each format between the xFree86-based format and your working format on the 7th(?) try.
The VFC manual from TechPubs is probably as detailed as it gets, which means a lot of reading between the lines.

_________________
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

yeah ... actually that was file #7 ... I saved after each time I made any useful progress. Each of the 7 files was probably edited 2-10 times, recompiled, etc. So as you said, there is a lot of trial and error.

I had read the man page for vfc... on the octane. It does not seem to be nearly as complete as the techpubs entry. Odd. Thanks for that pointer! Also - your instructions were really helpful... others who are dealing with this should definitely be following your lead.

_________________

You're more than welcome. Started a couple of time to consolidate a couple of posts into a guideline on how to create custom display resolutions, but the provided-with-an-irix-install vfos work well enough that there doesn't seem to be much interest in doing it the hard way.

_________________
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************