SGI: Hardware

VFO: Video Format Object Files

VFO: Video Format Object Files
Video format objects are microcode images loaded into SGI graphics display hardware to generated the timing signals required to produce display images at specific resolutions and refresh rates. Video format object (vfo) microcode is typically generated using SGI's Video Format Compiler (VFC) and end-user prepared video format source (vfs) files.

As mentioned in the vfc man page , vfo files are hardware specific:
The vfc man page wrote: Video format object microcode is not binary compatible between different hardware types. Although vfc is independently re-targetable to a number of different hardware types, video format objects that were compiled to run with one hardware architecture will not necessarily run on another. For example, video format objects created for Infinite Reality will not work properly on Impact.
Generally speaking, video format objects (vfos) can be created using one of two methods:
  • By use of a block sync template: Because no user-defined format source file is needed, this method is quick and easy to use. Because it the lacks specific monitor, resolution and format timing details that can be included in a source file, it produces the most generically targeted microcode.

  • By creating a video format source (vfs) file: Video format source files offer the ability to tailor the microcode for specific resolutions, refresh rates and even monitors. Monitor specific format values can be obtained from the (monitor) manufacturer, or in the case of some more recent displays, extracted from the monitor firmware in with EDID reader/decoder software (EDID information or manufacturer provided modelines can sometimes be found with a web search). If neither of those methods is available, then there are a number of display modeline generators that offer all of the timing values needed to complete a video source file. Generated modelines won't necessarily contain the same values as provided by the manufacturer or EDID information for a particular monitor, but should still provide microcode that is reasonably well targeted to specific resolutions and refresh rates.

SGI includes a number of video format source code files with the installation of the Video Format Compiler. The comments section of those source files indicate most were written specifically for use with some of the CRT monitors marketed by SGI. This includes all of the wide-format for which source files are available. As a result some of the SGI vfo microcode provided for wide-screen displays does not always produce a stable displays when used with more recent LCD monitors.

Reduced Blanking : Modern LCD monitors that don't work well with the CRT-targeted vfo microcode supplied by SGI may see improvement if used with a format that includes reduced blanking. Reduced blanking lowers display format overhead needed to allow CRT screen redraws, overhead that doesn't benefit and may adversely affect LCD monitors . Reduced blanking is primarily intended for use with DVI-connected LCD monitors, but any LCD monitor new enough to take advantage of reduced blanking *may* also benefit when connected via the VGA port.

Graphics hardware errata:
  • The first generation of Octane VPro graphics boards, the V6 and the V8, can not generate display resolutions that have a pixel clock between 109MHz and 193MHz. This limits the ability of the V6 and V8 to use a number of common display resolutions, a situation that can be at least partially over come with the use of reduced blanking. As an example, a CVT-generated 1600x900@60Hz modeline without reduced blanking would have a Pixel Clock of 118.25MHz, which falls in the unusable 109-193MHz Pixel Clock range

    Code: Select all

    Modeline "1600x900_60.00" *118.25* 1600 1688 1856 2112 900 903 908 935 -HSync +Vsync
    while a modeline with reduced blanking would have a Pixel Clock of only 97.75MHz, which could be used by V6 or V8 graphics boards.

    Code: Select all

    Modeline "1600x900_60.00rb" *97.75* 1600 1648 1680 1760 900 903 908 926 +HSync -Vsync
  • VPro graphics have a maximum screen height of 2048 pixels. Exceeding that amount will generate a VFC error:

    Code: Select all

    Screen height is greater than 2048.000000 pixels. Decrease ActiveLinesPerFrame
  • DCD-equipped VPros require dual channel display modes (2@) with a horizontal resolution that is a multiple of 64. 1440x900 and 1680x1050 are relatively a common wide-screen formats with horizontal resolutions that aren't multiples of 64; attempting to compile dual channel microcode in either format will generate the following error message:

    Code: Select all

    DualHead Formats must have a screen boundary at a multiple of 64.  Make ActivePixelsPerLine a multiple of 64.


  • O2 graphics have a limitation of 2160 TotalPixelsPerLine. VFO microcode generated from a reduced blanking modeline will typically lower the TotalPixelsPerLine value. As an example, a CVT-generated modeline for 1680x1050@60Hz without a reduction in blanking results in 2240 TotalPixelsPerLine, which would generate a VFC error rather than usable microcode;

    Code: Select all

    Modeline "1680x1050_60.00" 146.25 1680 1704 1960 *2240* 1050 1053 1059 1089 -HSync +Vsync
    while a CVT modeline with reduced blanking would have only 1840 TotalPixelsPerLine

    Code: Select all

    Modeline "1680x1050_60.00rb"  119.00  1680 1728 1760 *1840*  1050 1053 1059 1080  +HSync -Vsync
    which would successfully generate O2-usable microcode.

If anyone would like advice or assistance with creating custom microcode display files, just post a request in this thread.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
Wiki'ed with attribution back to this thread:
VFO topic.

R.
死の神はりんごだけ食べる

開いた括弧は必ず閉じる -- あるプログラマー

:Tezro: :Tezro: :Onyx2R: :Onyx2RE: :Onyx2: :O3x04R: :O3x0: :O200: :Octane: :Octane2: :O2: :O2: :Indigo2IMP: :PI: :PI: :1600SW: :1600SW: :Indy: :Indy: :Indy: :Indy: :Indy:
:hpserv: J5600, 2 x Mac, 3 x SUN, Alpha DS20E, Alpha 800 5/550, 3 x RS/6000, Amiga 4000 VideoToaster, Amiga4000 -030, 733MHz Sam440 AmigaOS 4.1 update 1.

Sold: :Indy: :Indy: :Indy: :Indigo: Tandem Himalaya S-Series Nonstop S72000 ServerNet.

Twitter @PymbleSoftware
Current Apps (iOS) -> https://itunes.apple.com/au/artist/pymb ... d553990081
(Android) https://play.google.com/store/apps/deve ... +Ltd&hl=en
(Onyx2) Cortex ---> http://www.facebook.com/pages/Cortex-th ... 11?sk=info
(0300s) Minnie ---> http://www.facebook.com/pages/Minnie-th ... 02?sk=info
Github ---> https://github.com/pymblesoftware
I've never successfully gotten 1440x900 to work on my Octane V6. I tried the attached file and it works for the most part except when you scroll a window or do something graphic intensive. Here is what it looks like http://www.youtube.com/watch?v=XoTCPfyx1KI
astouffer wrote: I've never successfully gotten 1440x900 to work on my Octane V6.
What monitor are you using?

My suggestion would be to use EDID info to make a vfo customized for your monitor. Second best would be a web search for the specific model name/number of monitor model info and the words modeline and or EDID to see if someone else has posted that info. If you can get a modeline for your monitor I'll try making you a custom vfo (or if you'd like to try yourself, there's a defacto VFC how-to in this thread ).
astouffer wrote: Here is what it looks like http://www.youtube.com/watch?v=XoTCPfyx1KI
Next time I fire up something other than an IRIX box I'll take a look. :D
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
recondas wrote: Next time I fire up something other than an IRIX box I'll take a look. :D

There's a youtube downloader in /nekoware. I haven't used it for a long time but worked okay in the past. Irix Mplayer will then play the vid, no need for no steenkin' peecee crap :)

Since you seem to be becoming the current vfc go-to guy, have you tried any double your pleasure dcd formats yet ?
hamei wrote: Since you seem to be becoming the current vfc go-to guy, have you tried any double your pleasure dcd formats yet ?
Unfortunately, it looks like the crew at SGI responsible for developing VFC got spirited away by digital gypsies/corporate raiders before they had the chance to leave even the slightest bread-crumb trail as to how those parts of VFC worked. The absolute lack of documentation on how to use the VPro DCD definition file (VPro_DCD.def) has been the show-stopper for every other mention of VPro-DCD.def I can find on-line. That seems to leave the compiled-by-SGI 2@ dual-channel video format microcode objects as the best resource for hints on what's involved.

It is possible to extract some background information on the composition of VFC micro-code objects using Stuart Levy's "vfoinfo" script . For instance, vfoinfo run in "quick" mode returns:

Code: Select all

./vfoinfo -q /usr/gfx/ucode/ODSY/vof/2@1920x1200_60p.vfo
/usr/gfx/ucode/ODSY/vof/2@1920x1200_60p.vfo     1920x600_29 ("1920 x 1200 @ 60Hz Odyssey Dual Channel for SGI Flat Panel")
or (since I'm guessing you're particularly interested in 2@1920x1200 formats):

Code: Select all

# ./vfoinfo -q /usr/gfx/ucode/ODSY/vof/2@1920x1200_60_ds.vfo
/usr/gfx/ucode/ODSY/vof/2@1920x1200_60_ds.vfo   1920x600_30 ("1920 x 1200 @ 60Hz Skew Mode for Odyssey Dual Channel Display board")
Doing the same thing with vfoinfo in verbose mode returns a couple hundred lines of potentially useful format parameters (due to length these are just the first few lines):

Code: Select all

./vfoinfo -v /usr/gfx/ucode/ODSY/vof/2@1920x1200_60p.vfo
== /usr/gfx/ucode/ODSY/vof/2@1920x1200_60p.vfo ==
AchievedFramesPerSecond         29.99999614 <17>[0]
AchievedFrequency               153.7113402 <17>[0]
ActiveLinesPerFrame             1200 <2>[0]
ActivePixelsPerLine             1920 <2>[0]
BeginTime                       0 <17>[0]
CSync                           0 <2>[0]
CorrespondingPolarity           2 <2>[0]
DACRateMaximum                  240000000 <17>[0]
DACRateMinimum                  13000000 <17>[0]
DCB_Freq                        33.25 <17>[0]
DCDHorizontalBackPorch          104 <2>[0]
DCDHorizontalFrontPorch         40 <2>[0]
DCDHorizontalSync               48 <2>[0]
DCDSupport                      1 <2>[0]
DCDTotalPixelsPerLine           2112 <2>[0]
DesiredFrequency                153.71136 <17>[0]
DisplayArchitecture             "ODY_VTG" <15>[0]
Enable_Stereo                   0 <2>[0]
EndTime                         0.03333333763 <17>[0]
FetchExtraClocks                0 <2>[0]
FieldColor                      [2]{ 7 7 } <2>[0]
FieldCountMaximum               16 <2>[0]
FieldEye                        [2]{ 3 3 } <2>[0]
FieldLineCount                  [2]{ 1200 1200 } <2>[0]
FieldLineOffset                 [2]{ 0 0 } <2>[0]
FieldLineSkip                   [2]{ 0 0 } <2>[0]
FieldSwap                       [2]{ 1 1 } <2>[0]
FieldsPerFrame                  2 <2>[0]
FormatInfo_DigitalSkew          0 <2>[0]
FormatInfo_DualHead             1 <2>[0]
FormatInfo_F_0_ActiveLineCount  1200 <2>[0]
FormatInfo_F_0_V_Active         2534400 <2>[0]
FormatInfo_F_0_V_BackPorch      8448 <2>[0]
FormatInfo_F_0_V_FrontPorch     6336 <2>[0]
FormatInfo_F_0_V_Sync           12672 <2>[0]
FormatInfo_F_0_V_SyncPulse      12672 <2>[0]
FormatInfo_F_1_ActiveLineCount  1200 <2>[0]
FormatInfo_F_1_V_Active         2534400 <2>[0]
FormatInfo_F_1_V_BackPorch      14784 <2>[0]
FormatInfo_F_1_V_FrontPorch     6336 <2>[0]
FormatInfo_F_1_V_Sync           6336 <2>[0]
FormatInfo_F_1_V_SyncPulse      6336 <2>[0]
FormatInfo_FieldSequential      0 <10>[0]
FormatInfo_FullScreenStereo     0 <10>[0]
FormatInfo_H_Active             1920 <2>[0]
FormatInfo_H_BackPorch          104 <2>[0]
FormatInfo_H_FrontPorch         40 <2>[0]
FormatInfo_H_Sync               48 <2>[0]
FormatInfo_Interlaced           0 <10>[0]
FormatInfo_PixelClock           153711340 <2>[0]
FormatInfo_Stereo               0 <10>[0]
FormatInfo_UnbalancedSwaps      0 <10>[0]
FormatName                      "1920 x 1200 @ 60Hz Odyssey Dual Channel for SGI
If we're lucky there'll be enough info there to figure out how to reverse engineer VPRo_DCD.def and/or create a working DCD microcode source file.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
recondas wrote: What monitor are you using?

My suggestion would be to use EDID info to make a vfo customized for your monitor. Second best would be a web search for the specific model name/number of monitor model info and the words modeline and or EDID to see if someone else has posted that info. If you can get a modeline for your monitor I'll try making you a custom vfo (or if you'd like to try yourself, there's a defacto VFC how-to in this thread ).


The monitor in question is a Gateway FPD1975W. Thanks for the offer but I tried doing a custom vfo with the EDID numbers and got a similar clock frequency to the one you posted. Its a problem with the V6. I ended up buying a 4:3 ratio Sony LCD for a good price on ebay. Heres an mpeg video of what 1440x900 looks like http://www.bittermen.net:808/VID00086.mpg
astouffer wrote: The monitor in question is a Gateway FPD1975W. Thanks for the offer but I tried doing a custom vfo with the EDID numbers and got a similar clock frequency to the one you posted. Its a problem with the V6. I ended up buying a 4:3 ratio Sony LCD for a good price on ebay. Heres an mpeg video of what 1440x900 looks like http://www.bittermen.net:808/VID00086.mpg
The vfo I posted above uses reduced blanking, the modeline I used was:

Code: Select all

# 1440x900 @ 60.00 Hz Reduced Blank (CVT)
#   field rate 59.90 Hz; hsync: 55.47 kHz; pclk: 88.75 MHz
Modeline "1440x900_60.00_rb"  88.75  1440 1488 1520 1600  900 903 909 926  +HSync -Vsync
As was briefly touched upon in the same post, reduced blanking was primarily intended for DVI-attached LCD monitors. A CVT generated modeline without reduced blanking has a 106.5Mhz pixel clock, which would still fall outside the 109-193MHz pixel clock black hole for your V6:

Code: Select all

# 1440x900 @ 60.00 Hz (CVT)
#   field rate 59.89 Hz; hsync: 55.93 kHz; pclk: 106.50 MHz
Modeline "1440x900_60.00"  106.50  1440 1520 1672 1904  900 903 909 934  -HSync +Vsync
If you think a format without reduced blanking is worth a shot, there's a copy attached.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
That last vfo produces artifacts on the screen constantly. What makes me wonder about this bug is how the modes with the 89Mhz clock still act buggy. 89Mhz should be safe but its not. Has anyone else done 1440x900 on a V6 or is it just me?

Attached are all the 1440x900 modes I've tried but without success. All were compiled by me except for the Acer monitor. Please feel free to use/edit or pass them along.
recondas wrote:

Code: Select all

./vfoinfo -q /usr/gfx/ucode/ODSY/vof/2@1920x1200_60p.vfo
/usr/gfx/ucode/ODSY/vof/2@1920x1200_60p.vfo     1920x600_29 ("1920 x 1200 @ 60Hz Odyssey Dual Channel for SGI Flat Panel")
or (since I'm guessing you're particularly interested in 2@1920x1200 formats):

Code: Select all

# ./vfoinfo -q /usr/gfx/ucode/ODSY/vof/2@1920x1200_60_ds.vfo
/usr/gfx/ucode/ODSY/vof/2@1920x1200_60_ds.vfo   1920x600_30 ("1920 x 1200 @ 60Hz Skew Mode for Odyssey Dual Channel Display board")
.


Hmmm. Interesting. What I'm more interested in to start out will be two outputs of 1920 x 2400 @ 33.72 hz refresh tho ..... luckily, my monitor will work down at 13 hz so too-low a refresh should not be a problem.

Apparently a dcd output for dual 1920 x 1200 @ 60 is really two 1920 x 600 @ 30 each ? Understanding the exact workings of the dcd might be in order ... :(
hamei wrote: What I'm more interested in to start out will be two outputs of 1920 x 2400 @ 33.72 hz refresh tho ..... luckily, my monitor will work down at 13 hz so too-low a refresh should not be a problem. Apparently a dcd output for dual 1920 x 1200 @ 60 is really two 1920 x 600 @ 30 each ? Understanding the exact workings of the dcd might be in order ... :(
In that case it might be a good thing if the DCD does use 1920x600. Regardless of refresh rate the maximum screen height for a VPro graphics is 2048 pixels.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
recondas wrote:
hamei wrote: Since you seem to be becoming the current vfc go-to guy, have you tried any double your pleasure dcd formats yet ?
Unfortunately, it looks like the crew at SGI responsible for developing VFC got spirited away by digital gypsies/corporate raiders before they had the chance to leave even the slightest bread-crumb trail as to how those parts of VFC worked. The absolute lack of documentation on how to use the VPro DCD definition file (VPro_DCD.def) has been the show-stopper for every other mention of VPro-DCD.def I can find on-line. That seems to leave the compiled-by-SGI 2@ dual-channel video format microcode objects as the best resource for hints on what's involved.

UPDATE: After some serious head-scratching/banging/ache I managed to figure out the secret incantations needed to compile 2@ VFC microcode for DCD-equipped VPro boards. Since hamei asked, the format I tested was the 1920x1200_33.72 he mentioned.

The output of a VFC analysis of the [email protected] is quoted below:

Code: Select all

/usr/sbin/vfc  -a ascii=2@1920x1200_33.72DCD.info -c chip=/usr/gfx/ucode/vfc/rules/VPro_Chip.def,board=/usr/gfx/ucode/vfc/rules/VPro_Board.def  -o 2@1920x1200_33.72DCD.vfo

2@1920x1200_33.72DCD.vfo:
Total lines per frame:   2434
Total pixels per line:   2080
Active lines per frame:  1200
Active pixels per line:  1920
Frames per second:       33.72
Fields per frame:        2
Swaps per frame:         2
Pixel clock:             170.715 MHz, period = 5.85772 nsec
Hardware pixel rounding:  every 1 pixels
Line analysis:
Length:                 2080 Pixels, 1 Lines, 12.1841 usec; (line 0)
Frequency:              82.0745 KHz, period = 12.1841 usec
Horizontal Sync:         32 Pixels, 187.447 nsec; (line 11)
Horizontal Back Porch:   80 Pixels, 468.617 nsec; (line 11)
Horizontal Active:       1920 Pixels, 11.2468 usec; (line 11)
Horizontal Front Porch:  48.0001 Pixels, 281.171 nsec; (line 11)
Field 0 Information:
Field Duration:           2.52512e+06 Pixels, 1214 Lines, 14.7914 msec; (line 0)
Vertical Sync:            10400 Pixels, 5 Lines, 60.9203 usec; (line 0)
Vertical Sync Pulse:      12432 Pixels, 5.97692 Lines, 72.8232 usec; (line 0)
Vertical Back Porch:      12480 Pixels, 6 Lines, 73.1043 usec; (line 5)
Vertical Active:          2.496e+06 Pixels, 1200 Lines, 14.6209 msec; (line 11)
Vertical Front Porch:     6240 Pixels, 3 Lines, 36.5522 usec; (line 1211)
Field 1 Information:
Field Duration:           2.5376e+06 Pixels, 1220 Lines, 14.8645 msec; (line 1214)
Vertical Sync:            10400 Pixels, 5 Lines, 60.9203 usec; (line 1214)
Vertical Sync Pulse:      12432 Pixels, 5.97692 Lines, 72.8232 usec; (line 1214)
Vertical Back Porch:      18720 Pixels, 9 Lines, 109.656 usec; (line 1219)
Vertical Active:          2.496e+06 Pixels, 1200 Lines, 14.6209 msec; (line 1228)
Vertical Front Porch:     12480 Pixels, 6 Lines, 73.1043 usec; (line 2428)
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
recondas wrote: In that case it might be a good thing if the DCD does use 1920x600. Regardless of refresh rate the maximum screen height for a VPro graphics is 2048 pixels.

Ka rap. Are you sure ? I know I've seen photos of a Fuel running a T221.

The T221 is a little compllicated due to bandwidth.

With one dvi connection you can run anywhere from 1920 x 1200 at 48 hz (monitor will automatically downscale from 60 hz input, but internally it's always running 48 hz which is FINE, the 1600 sw would run at 50 hz and you couldn't tell it wasn't a crt at 83 hz) to 3840 x 2400 at 13hz (which also looks fine but the mouse lags a little and videos are pretty jerky.)

Two dvi connections can do two stripes of 1920 x 2400 @ 33 hz (which should be fine, movies refresh at what, 25 hz or so ?) or possibly 41 hz. This would seem to be ideal except you say the dcd cannot create resolutions higher than X_x_2048 ? Ka ka ka rap :( I wonder if Compositor can turn it sideways then rotate the screen back to the true position ?

Four dvi inputs can do four 1920 x 1200 tiles or four 960 x 2400 stripes at 48 hz refresh. Bit that's a project for the distant future ...

recondas wrote: UPDATE: After some serious head-scratching/banging/ache I managed to figure out the secret incantations needed to compile 2@ VFC microcode for DCD-equipped VPro boards. Since hamei asked, the format I tested was the 1920x1200_33.72 he mentioned.


First, thank you.

Second, you've gone where few men have gone before. Looking through all the threads here and googling like heck has not turned up anyone outside SGI who's been successful at creating dualling dcd formats. Woo-hoo :)

But third, try try again. 1920 x 1200 won't work on a T221. It wants 2400 in Y. Just for fun, I'm wondering if 2400 x 1920 is possible ? I'm not sure what SGI did - certainly hope it isn't strictly a single connection at 13 hz :( . But I have seen photos of the Fuel running a T221. So they did something ....

Grazie grazie tho, you've increased the pool of SGI knowledge in a signifcant area. The abilitiy to create more dcd formats will be a useful useful thing.
hamei wrote: Two dvi connections can do two stripes of 1920 x 2400 @ 33 hz (which should be fine, movies refresh at what, 25 hz or so ?) or possibly 41 hz. This would seem to be ideal except you say the dcd cannot create resolutions higher than X_x_2048 ? Ka ka ka rap
Exceeding a height of 2048 results generates an error message:

Code: Select all

Screen height 2400 is greater than 2048.000000 pixels. Decrease ActiveLinesPerFrame
which in turn leads to:

Code: Select all

Compilation completed with errors.  No video format created.
Looks like your lucky day tho (or maybe unlucky after we try a few), when the DCD definition file is included VFC ignores its own advice and creates a format anyway.
hamei wrote: Four dvi inputs can do four 1920 x 1200 tiles or four 960 x 2400 stripes at 48 hz refresh. Bit that's a project for the distant future ...
That was schleusel's take on how a VPro/T221 should be configured (start here and read down a few posts): viewtopic.php?f=3&t=16719068&p=7284690&#p7284690

hamei wrote: First, thank you.
You're welcome. Problem solving can be gratifying - if you actually solve anything. We'll see how this goes.
hamei wrote: Second, you've gone where few men have gone before. Looking through all the threads here and googling like heck has not turned up anyone outside SGI who's been successful at creating dualling dcd formats. Woo-hoo :)
The solution was too obvious - once I found it. Logged five pages of trial-n-error/cause-n-effect notes before I had my doh! epiphany.

hamei wrote: But third, try try again. 1920 x 1200 won't work on a T221. It wants 2400 in Y. Just for fun, I'm wondering if 2400 x 1920 is possible ?
As...you...wish..... :D

Figuring out how to get VFC to include the DCD definition file was the first part of the puzzle. The second part will be providing the data needed by the DCD definition file. I used vfoinfo to explore all of the SGI-provided VPro 2@ fromats. In each case it appears SGI built the 2@ formats at half the target refresh rate, and half the target Y resolution:
./vfoinfo -q /usr/gfx/ucode/ODSY/vof/2@1024x768_60.vfo
/usr/gfx/ucode/ODSY/vof/2@1024x768_60.vfo 1024x384_29 ("1024 x 768 @ 60Hz for Odyssey Dual Channel Display")

./vfoinfo -q /usr/gfx/ucode/ODSY/vof/2@1280x1024_60.vfo
/usr/gfx/ucode/ODSY/vof/2@1280x1024_60.vfo 1280x512_29 ("1280 x 1024 @ 60Hz Dual Channel for Odyssey")

./vfoinfo -q /usr/gfx/ucode/ODSY/vof/2@1920x1200_60p.vfo
/usr/gfx/ucode/ODSY/vof/2@1920x1200_60p.vfo 1920x600_29 ("1920 x 1200 @ 60Hz Odyssey Dual Channel for SGI Flat Panel")

I followed that lead and created a 2@1920x2400_20uvf format. The 20Hz refresh rate comes from the T221 modeline SGI provides for the Onyx4 UltimateVision (look in section for "1/2 screen 3840x2400"): http://techpubs.sgi.com/library/tpl/cgi ... 137-PARENT I chose 20Hz to keep the pixel clock as low as possible - even at that the pixel clock needed for two displays at 1920x2400 may be be too high unless that situation is helped by the DCD circuitry. In the same thread linked above schleusel mentions the (single?) DVI port on a V12 tops out at 165Mhz. The combined pixel clock of the attached 2@ format is 197.777MHz (for both DVI ports on the DCD).

vfoinfo for the resulting format follows that of the SGI-generated 2@ formats:
./vfoinfo -q 2@1920x2400_20uvf.vfo
2@1920x2400_20uvf.vfo 1920x1200_10 ("2@1920x2400_20uvf")
- we'll have to see what effect, if any, ignoring the screen height error has on the compiled format.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
Attached are a couple dual-channel 2@ vfo files (with reduced blanking) for DCD-equipped VPro boards.

This one is 2@1280x1024 because I happen to have two 1280x1024 LCD monitors for testing (two SGI F180s - which have worked flawlessly with the format since I created it this morning).
And this one is 2@1920x1080_60rb because there have been some previous requests for a dual-channel 1920x1080 VPro format. I don't have any 1920x1080 capable monitors, so it hasn't had a trial run yet. If you try it some feedback would be appreciated.


If you have a DCD-equipped VPro and would like a dual-channel vfo created in a different resolution just post a request. VFC requires the horizontal resolution of dual-channel displays be multiples of 64, so some formats (like 2@1440x900 or 2@1680x1050) would be problematic in dual-channel mode.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************