The collected works of recondas - Page 14

3dchris wrote: I'm sure if I spent the time reading I might be able to figure it out, but I was hoping somebody has already created one that works with this configuration. I've already done many searches on this forum and on Google, but all I see are people in my situation with no resolutions, or links to a proper file/settings for this configuration.

I don't recall seeing one either, so if no one responds with a pre-made vfo, you might have try your hand at creating your own. There have been several reports of success using the VFC via the BlockSync method. I took a look at the BlockSync examples in the VFC Manual on TechPubs and tried the BlockSync template to create a VPro-specific 1600x1024_60 format. It produced a vfo file on a V12 equipped Tezro, which I unfortunately can't test because I don't have a monitor that will display 1600x1024. if you'd like to try it on your Octane, here's the command I used (run it as root and enter the entire thing as a single line):

Code: Select all

# /usr/sbin/vfc -p "-DACTIVE_LINES=1024" -p "-DACTIVE_PIXELS=1600" -p "-DFPS=60" -c
chip=VPro_Chip.def,board=VPro_Board.def -o 1600x1024_60-1600SW.vfo
/usr/gfx/ucode/vfc/vfs/BlockSync.vfs
If it also compiles on your Octane it should produce a file named "1600x1024_60-1600SW.vfo"; copy the resulting vfo into "/usr/gfx/ucode/ODSY/vof" (or run the command from within /usr/gfx/ucode/ODSY/vof).

Looks like 1600x1024_60-1600SW.vfo won't be dynamic. That means you'll have to restart the Xserver to load it, so if you aren't already familiar with setmon and single-user mode some basic knowledge of either might be useful if the new format doesn't produce a display.

If that doesn't work, then you might want to try using a modeline specific to the 1600SW to create a format that's targeted a little more directly at the 1600SW, though I'm not certain what effect, if any, the analog to digital conversion performed by the MLA might have on the process. If it might prove helpful, I ran across a set of 1600SW modelines that inludes one modeline for use with an 1600SW/MLA combination (which at least suggests the inclusion of an MLA might require a specifically tweaked vfo file).

If you'd like to try the modeline method, the info in this post by rooprob looks like it might be very helpful: viewtopic.php?f=10&t=15616&p=7329782&#p7329782
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
geo posted a very interesting photo of what appears to be a laptop running IRIX.....
lcd.JPG
lcd.JPG (25.89 KiB) Viewed 559 times
....so geo, is that one of the Linux-based 5dwm clones, or is the jumboprawn O2 laptop in China?
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
geo wrote: sorry for hiding it for a while coz i want to reveal it until i can fix the busted LCD :( yes! this was an early Christmas gift from Jesse Newcomb! the maker for jumboprawn O2 hehe he really is great guy, he even gave me just recently a two spare of the LCD and arrived last Friday here but didn't have the time yet to mount it maybe later?
Congratulations!

Considering that an working SGI laptop is at least a contender for the ranking of most mythical and/or collectable SGI system (n)ever produced , I'm sure some detailed photos along with an hinv post would be highly appreciated.

All the better if you currently have it disassembled, don't know that any detailed inside-the-case photos have ever been published.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
3dchris wrote: I also tried it out, but it's giving me a very similar effect compared to the display option in the setmon by default. One difference is that my multilink can display the video widescreen when set to widescreen. The default vfo file displays the same way whether or not the multilink is set to widescreen or standard mode. It only displays widescreen when the multilink is set to alternate timing mode.
It's possible the presence of the MLA will necessitate a custom vfo. The 1600SW modelines I linked above include one for the MLA that shows opposite values for HsSync and Vsync:

Code: Select all

Mode lines for the Silicon Graphics flat panel display:

These mode lines are required for use with the T2R4 (Rev 4) and the Silicon Graphics Flat Panel display.
Modeline "1600x1024d32" 103.125 1600 1600 1656 1664 1024 1024 1029 1030 HSkew 7 +Hsync +Vsync
Modeline "1600x1024d16" 103.125 1600 1600 1656 1664 1024 1024 1029 1030 HSkew 5 +Hsync +Vsync
Modeline "1600x1024d08" 103.125 1600 1600 1656 1664 1024 1024 1029 1030 HSkew 1 +Hsync +Vsync
Modeline "800x512d32" 54.375 800 800 840 848 512 512 514 515 HSkew 7 DoubleScan +Hsync +Vsync
Modeline "800x512d16" 54.375 800 800 840 848 512 512 514 515 HSkew 5 DoubleScan +Hsync +Vsync
Modeline "800x512d08" 54.375 800 800 840 848 512 512 514 515 HSkew 1 DoubleScan +Hsync +Vsync

These lines are required for use with the SGI Multilink Adapter and the SiliconGraphics Flat Panel display.
Modeline "1600x1024g" 108.0 1600 1616 1656 1704 1024 1027 1030 1056 -Hsync -Vsync
Option "OverridePolarity" "1"


3dchris wrote: It looks like I will have to somehow create a custom file based on the multilink, but I have no experience at all with this. Any help would be appreciated :)
Ditto on the no experience, but if you get the chance, take a look at rooprob's write up - it looks like it could be very helpful.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
Voralyan wrote: to me this is more a software topic, so maybe the thread should be moved to a better suited category?!


Done!
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
Thanks to another nekochan member I've acquired a very clean Octane2 (the incandescent portion of the lightbar even works).

The graphics carrier originally included one of the SGI XIO dual-channel FC boards, until its services are needed I pulled it to prevent the automatic fastfan mode that occurs if XIO slot 'C' is populated (the V12 uses slot(s) A/B, and the DM2 slot 'D'). The 2GB of memory is comprised of eight 256MB DIMMs (edit: now six 512MB and two 256MB DIMMs), and until I rearrange monitors the display is currently connected to the 13W3 port on the V12.
Code:
hinv -vm
Location: /hw/node
PM20400MHZ Board: barcode LKE894     part 030-1476-002 rev  B
Location: /hw/node/xtalk/15
IP30 Board: barcode KTV280     part 030-1467-001 rev  D
Location: /hw/node/xtalk/15/pci/2
FP1 Board: barcode KVJ895     part 030-0891-003 rev  G
PWR.SPPLY.ER Board: barcode AAE0210721 part 060-0035-002 rev  A
Location: /hw/node/xtalk/13
XTALKPCI Board: barcode MDS825     part 030-0952-005 rev  E
Location: /hw/node/xtalk/11
ODY128VERSIONB Board: barcode MDF834     part 030-1611-001 rev  C
Location: /hw/node/xtalk/10
XT-DIGVID Board: barcode MJX248     part 030-1653-002 rev  H
2 400 MHZ IP30 Processors
Heart ASIC: Revision F
CPU: MIPS R12000 Processor Chip Revision: 3.5
FPU: MIPS R12010 Floating Point Chip Revision: 0.0
Main memory size: 3584 Mbytes
Xbow ASIC: Revision 1.4
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
Secondary unified instruction/data cache size: 2 Mbytes
Integral SCSI controller 0: Version QL1040B (rev. 2), single ended
Disk drive: unit 1 on SCSI controller 0 (unit 1)
Disk drive: unit 2 on SCSI controller 0 (unit 2)
Integral SCSI controller 1: Version QL1040B (rev. 2), single ended
Integral SCSI controller 7: Version IEEE1394 SBP2
IEEE1394 Disk: node d0160100001dc0 port 0 lun 0 on SCSI controller 7 (unit 2)
IOC3/IOC4 serial port: tty1
IOC3/IOC4 serial port: tty2
IOC3 parallel port: plp1
Graphics board: V12
Integral Fast Ethernet: ef0, version 1, pci 2
Iris Audio Processor: version RAD revision 12.0, number 1
Iris Audio Processor: version RAD revision 13.0, number 2
PCI Adapter ID (vendor 0x10a9, device 0x0003) PCI slot 2
PCI Adapter ID (vendor 0x1077, device 0x1020) PCI slot 0
PCI Adapter ID (vendor 0x1077, device 0x1020) PCI slot 1
PCI Adapter ID (vendor 0x10a9, device 0x0005) PCI slot 3
PCI Adapter ID (vendor 0x10a9, device 0x0005) PCI slot 1
PCI Adapter ID (vendor 0x104c, device 0x8024) PCI slot 3
IIDC Video Camera: unit 0, revision 1.30, connected to DM10, unit 0
XT-DIGVID Multi-standard Digital Video: controller 1, unit 1, version 0x0
Dual Channel Display
DMediaPro DM10 FW option: unit 0, revision 1.1.0
Code:
/usr/gfx/gfxinfo -vv
Graphics board 0 is "ODYSSEY" graphics.
Managed (":0.0") 3200x1200
BUZZ version B.1
PB&J version 1
128MB memory
Banks: 4, CAS latency: 3
Monitor 0 type: Unknown
Dual Channel Display option
Monitor 1 type: VSC 4892        Monitor 2 type: VSC 4892
Input Sync: Voltage - Video Level; Source - Internal; Genlocked - False
Channel 0:
Origin = (0,0)
Video Output: 1600 pixels, 1200 lines, 60.00Hz (2@1600x1200_60_ds)
Video Format Flags:  (none)
Sync Disabled
Using Gamma Map 0
Monitor Type:  VSC-4892
Gain (all color components) - 0.000000 ; range [1,10]
Channel 1:
Origin = (1600,0)
Video Output: 1600 pixels, 1200 lines, 60.00Hz (2@1600x1200_60_ds)
Video Format Flags:  (none)
Sync Disabled
Using Gamma Map 0
Monitor Type:  VSC-4892
Gain (all color components) - 0.000000 ; range [1,10]
Code:
scsicontrol -i /dev/scsi/*
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:  16bit synch linkedcmds cmdqueing
Device is  ready
/dev/scsi/sc0d2l0:  Disk          FUJITSU MAN3184MC       5507
ANSI vers 3, ISO ver: 0, ECMA ver: 0; supports:  16bit synch linkedcmds cmdqueing
Device is  ready

scsicontrol -i /dev/scsi/1394/d0160100001dc0/lun0/c7p0
/dev/scsi/1394/d0160100001dc0/lun0/c6p0:  Disk          SCM     CAMERAMATE-CF   1394
ANSI vers 4, ISO ver: 0, ECMA ver: 0; supports:
Device is  ready
Code:
configmon -h
SEQ            NAME      LOCATION          SERIAL_NUM   PART_NUMBER  REVISION
===============================================================================
0              NA            NA                  NA            NA        NA
1             FP1            NA              KVJ895  030-0891-003         G
2            IP30            NA              KTV280  030-1467-001         D
3      PM20400MHZ            NA              LKE894  030-1476-002         B
4  ODY128VERSIONB            NA              MDF834  030-1611-001         C
5       XT-DIGVID            NA              MJX248  030-1653-002         H
6    PWR.SPPLY.ER            NA          AAE0210721  060-0035-002         A
7        XTALKPCI            NA              MDS825  030-0952-005         E
8     SCSI_CTLR_0            NA                  NA            NA        NA
9         DRIVE_1            NA  3CE14L63    Copyrigh    SX173404LC      BD13
10         DRIVE_2            NA        UFL3P1901VYE     MAN3184MC      5507
11     SCSI_CTLR_1            NA                  NA            NA        NA
12     SCSI_CTLR_7            NA                  NA            NA        NA
===============================================================================
Code:
uname -aR
IRIX64 octane 6.5 6.5.30m 07202013 IP30
Code:
xtdigvid_hinv
/hw/node/xtalk/10
XT-DIGVID (part number 030-1653-002 H), serial number MJX248
IRIX number 1
ML Device Index 1
Code:
xtdigvid_confidence
Unzipping ml reference frames...
done
Uncompressing xtdigvid reference frames...
done

*********************************************************************
*********************************************************************
****                                                             ****
***        XTDIGVID_CONFIDENCE ===== XTDIGVID_CONFIDENCE          ***
***        XTDIGVID_CONFIDENCE ===== XTDIGVID_CONFIDENCE          ***
****                                                             ****
*********************************************************************
*********************************************************************


System type is: OCTANE2
System has 2 CPUs and 2048MB of memory
Found 1 XTDIGVID board(s)


Found 1 XTDIGVID board(s)

Starting xtdigvid_confidence script ......


Total XTDIGVID boards in the system is 1 board(s).
Test will run for 1 loop(s).


Board(s) information:

XT-DIGVID plugged in /hw/node/xtalk/10
(Part number is 030-1653-002, Rev H), Serial number MJX248


>>>>> PLEASE NOTE ABOUT PART NUMBERS <<<<<
>>>>> Each part number above corresponds to an XTDIGVID board.


==> Please verify that each board information is correct.

==> Verify that the total board reporting number matches
==> the number of boards installed.  Are they matched ? (y/n): y
Continuing with the xtdigvid_confidence......




Running standard XTDIGVIDTST tests.

INSTRUCTION:
1) Connect a LVDS cable from the xtdigvid connector labelled P1
to the VBOB connector labelled P1.

2) Connect a LVDS cable from the xtdigvid connector labelled P2
to the VBOB connector labelled P2.

3) On the VBOB, connect a coax from 'HD out 1' to 'HD in 1'.
connect a coax from 'HD out 2' to 'HD in 2'.

4) On the VBOB, connect a coax from 'SD out 1' to 'SD in 1'.
connect a coax from 'SD out 2' to 'SD in 2'.

Is everything ready <y/n>?: n
....Further DM2 testing will have to wait until I acquire a VBOB and a pair of LVDS cables)

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

_________________
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
There's a template (.vfs file) posted on line that was written to take advantage of the analog connection on the 1600SW Multi-Link Adapter. The catch is it was intended for use with an O2 rather than a VPro-equipped Octane (though it doesn't contain anything that looks glaringly O2-specific). For additional details and background be sure to see the 'read me' that's included as a comment inside the .vfs file: http://dart.ncsa.uiuc.edu/slevy/o2-ster ... 1600sw.vfs ).

I took a shot at compiling it using the VPro chip and board definition files, and it compiled with only the single non-fatal error (at line 652) that all VPro template files seem to generate:

Code: Select all

"/usr/gfx/ucode/vfc/rules/VPro_Board.def", line 652: The time you specified crosses the frame boundary and is wrapped to the end of the frame.
No 1600SW or MLA here, so the resulting format is completely untested (not to mention having been originally intended for O2 graphics). As a check I did run the resulting format with the "-a" option in VFC, which performs an an analysis of the video format and outputs the results as ascii text or a postscript file:

Code: Select all

# vfc -a ascii=1600x1024_60-MLA.info -c
chip=/usr/gfx/ucode/vfc/rules/VPro_Chip.def,board=/usr/gfx/ucode/vfc/rules/VPro_Board.def -o
1600x1024_60-1600SW-MLA.vfo /usr/gfx/ucode/vfc/rules/1600x1024_60-MLA.vfs
Here's a copy of the analysis:

Code: Select all

1600x1024_60-1600SW-MLA.vfo:
Total lines per frame:   1056
Total pixels per line:   1702
Active lines per frame:  1024
Active pixels per line:  1600
Frames per second:       60
Fields per frame:        1
Swaps per frame:         1
Pixel clock:             107.839 MHz, period = 9.27311 nsec
Hardware pixel rounding:  every 1 pixels
Line analysis:
Length:                 1702 Pixels, 1 Lines, 15.7828 usec; (line 0)
Frequency:              63.36 KHz, period = 15.7828 usec
Horizontal Sync:         50 Pixels, 463.655 nsec; (line 29)
Horizontal Back Porch:   40 Pixels, 370.924 nsec; (line 29)
Horizontal Active:       1600 Pixels, 14.837 usec; (line 29)
Horizontal Front Porch:  12 Pixels, 111.277 nsec; (line 29)
Field Information:
Field Duration:           1.79731e+06 Pixels, 1056 Lines, 16.6667 msec; (line 0)
Vertical Sync:            5106 Pixels, 3 Lines, 47.3485 usec; (line 0)
Vertical Sync Pulse:      5156 Pixels, 3.02938 Lines, 47.8121 usec; (line 0)
Vertical Back Porch:      44252 Pixels, 26 Lines, 410.353 usec; (line 3)
Vertical Active:          1.74285e+06 Pixels, 1024 Lines, 16.1616 msec; (line 29)
Vertical Front Porch:     5106 Pixels, 3 Lines, 47.3485 usec; (line 1053)


If you're willing to try the otherwise untested format I've attached a copy of the one I compiled.

I'd suggest using xsetmon to examine the compiled format before you load it - xsetmon can be run from a command line or from Toolchest > System > Display Properties. As long as you don't press the "Load" button, you can open multiple xsetmon windows. Open one and click once on the new format (in the left panel), then do the same (in a second instance of xsetmon) with the SGI supplied 1600x1024_60 so you can compare the two if you like - before you attempt to use the 1600x1024_60-1600SW-MLA.vfo.

If the format leaves you with no display, the following should get you back to 1280x1024_60:
    Press and release the power button, your Octane will cleanly shut itself down;

    Once it's completely power down, restart it.

    As it boots watch for the "press escape" prompt and enter the PROM

    Select option "5" from the PROM menu to access the PROM command line;

    type the word "single" (w/o the quotes) and press enter.

    Enter the root account/password info when prompted, and run execute "/usr/gfx/setmon -x 1280x1024_60"

    reboot.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
3dchris wrote: I compiled everything on my system, but the strange this is that the MLA is showing the display as a 1280x1024 image. The image looks similar to the standard 1280x1024_60 vfo file. That is how it appears on the login screen. When I logged in though, it seemed like IRIX was thinking that it's indeed a wider screen because the toolchest is off the screen as though it was in the top left corner of a wider monitor. Also, my desktop icons are off the screen as well. It's as though the system is displaying 1600x1024, but the graphics is only showing 1280x1024. Any ideas what might cause this?
Considering that it was originally intended for an O2, it is encouraging to see that it will compile and produce a viewable display.

With the newly compiled vfo running, what resolution does the Multi-Link Adapter's On-Screeen Display indicate, and (not to belabor the obvious) have you had the opportunity to try adjusting the display with the adjustments in the MLA's Advanced Display Menu (or the "Force Detect" option in the MLA's general menu)?

This usenet post uses provides another template/.vfs file with slightly different timing values. The post also makes specific suggestions to tweak the MLA's Advanced Display settings to match the resulting format (phase to 13, clock divider to 125). So you may be able to adjust the phase and clock divider with the format you've already created or even compile another format with the values provided in the usenet post.

EDIT: I went ahead and compiled a format using the template provided by Avi Bercovich in the 2002 usenet post referenced in the previous paragraph - there's a copy attached to this post. It complied with only the usual line 652 error.
1600x1024_60-Analog_MLA.vfo
(8.48 KiB) Downloaded 82 times


If you'd like to contrast the differences between Ari's format and the first one (from Stuart Levy's site), I attached a screen shot of both analysis files in gdiff (I named Ari's format 1600x1024_60-Analog_MLA to avoid overwriting the first):
It might also be worth taking a look at the cable and/or adapter that connects the 13W3 port on your V12 to the VGA port on the MLA to make sure that's up to spec. The MLA may need to receive DDC info , which probably won't happen if you don't have a properly wired SGI 13W3 cable or adapter. See Amigo's post in this topic for confirmation of a working V10-to-Analog-MLA configuration - particularly his mention that the "VPro series actually has H/Vsync out on the 13W3 AND DDC2 pin output, which allows MLA to configure itself to compatible hardware".
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
nekonoko wrote:
Looks fantastic :)
Thanks! ;)

_________________
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
smj wrote:
That is entirely unacceptable. If I ever visit, I'm putting an Avery label on it. ;)
It did have one, but I got a little overzealous while appling low-gloss armorall.

BTW - don't you also have an V12-DCD-DM2-DM5-FC equipped Octane2 to immortalize in an hinv post? Preferably with a few photos so we can see just how pathological the Avery label fixation has become. :D

_________________
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
3dchris wrote: IWhat is this Front Porch?
http://techpubs.sgi.com/library/tpl/cgi ... /ch03.html

3dchris wrote: Another interesting thing I noticed when fiddling with the MLA adjustments is the overlapping mode. In the default mode, I get a "normal" looking picture, but the sides of the screen are black. In the Alternate mode I can actually see most of the image, but the colors are all messed up and the display is showing the left halve of the screen on the right and vice versa. You posted much earlier a link that stated " These lines are required for use with the SGI Multilink Adapter and the SiliconGraphics Flat Panel display. Modeline "1600x1024g" 108.0 1600 1616 1656 1704 1024 1027 1030 1056 -Hsync -Vsync Option "OverridePolarity" "1"" I wonder if the syncs need to be reversed and this OverridePolarity needs to be flagged.
I made another following the xorg modeline for the analog MLA as closely as possible (I have yet to find s method to explicitly specify -Hsync -Vsync). Here's the VFC analysis...

Code: Select all

1600x1024_60-analogMLA.vfo:
Total lines per frame:   1058
Total pixels per line:   1704
Active lines per frame:  1024
Active pixels per line:  1600
Frames per second:       60
Fields per frame:        1
Swaps per frame:         1
Pixel clock:             108.17 MHz, period = 9.24471 nsec
Hardware pixel rounding:  every 1 pixels
Line analysis:
Length:                 1704 Pixels, 1 Lines, 15.753 usec; (line 0)
Frequency:              63.48 KHz, period = 15.753 usec
Horizontal Sync:         40 Pixels, 369.789 nsec; (line 31)
Horizontal Back Porch:   48 Pixels, 443.746 nsec; (line 31)
Horizontal Active:       1600 Pixels, 14.7915 usec; (line 31)
Horizontal Front Porch:  16 Pixels, 147.916 nsec; (line 31)
Field Information:
Field Duration:           1.80283e+06 Pixels, 1058 Lines, 16.6667 msec; (line 0)
Vertical Sync:            6816 Pixels, 4 Lines, 63.012 usec; (line 0)
Vertical Sync Pulse:      6856 Pixels, 4.02347 Lines, 63.3818 usec; (line 0)
Vertical Back Porch:      46008 Pixels, 27 Lines, 425.331 usec; (line 4)
Vertical Active:          1.7449e+06 Pixels, 1024 Lines, 16.1311 msec; (line 31)
Vertical Front Porch:     5112 Pixels, 3 Lines, 47.259 usec; (line 1055)
.... the resulting vfo file is attached.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
3dchris wrote: What I'm still seeing is that the picture is displaying as 1280x1024 still. The MLA is detecting that as the resolution.
You've probably been there, done that, but I'll ask just in case.... The manual mentions the MLA's firmware has an overlapping modes feature that can cause a 1600x1024 input to be displayed as 1280x1024:
Silicon Graphics MultiLink Owner's Guide wrote: Overlapped Modes—Chooses the correct resolution for display in special situations. Certain combinations of timing modes are indecipherable to the MultiLink. In such cases, you may need to override the MultiLink's settings through the Overlapped Modes menu item. Consult Table A-8 for a listing of the affected timing modes.


3dchris wrote: Were you able to get the Override Polarity option set? Maybe that and the -syncs will solve the problem?
You'll have to remember that list of 1600SW modelines was acquired from and intended for Linux/Xorg, and so was the mentioned 'Override Polarity option'. If there's an equivalent setting for VFC I haven't discovered it yet.

3dchris wrote: We're close. I can feel it. So very very close.....
The MLA manual also includes a mention (in table A-7) that when correctly set in 'SGI Operating mode' with a resolution of 1600x1024_60, that mode will have a total horizontal x vertical setting of 1704 x 1056 (where 1704 represents the TotalPixelsPerLine and 1056 TotalLinesPerFrame values used by VFC). The intended-for-the-analog-MLA-port vfs examples obtained through web searches that we've tried so far have come close, but none was exactly 1704 x 1056.

I can try changing the vfs formula to the 1704 TotalPixelsPerLine and 1056 TotalLinesPerFrame later this evening, or, since it's very close, you're welcome modify the last attached vfs and try it yourself (changing either of those values will require recalculating the values inserted in to the vfs template for horizontal and vertical back porches). It'd be nice to be able to test while working on specific formats, but unfortunately I don't have a 1600SW or an MLA.

EDIT: I'm back and have attached a .vfo with the aforementioned total horizontal x vertical setting of 1704 x 1056. If you haven't done so already, I'd suggest checking the 'Overlapping Modes' menu setting in the MLA OSD first.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
There's a comment in the 1920x1080_60 format source file that indicates it was written specifically for a Sony GWM3000 24" CRT monitor. So it's possible the timing in the SGI-supplied/written-for-a-CRT 1920x1080 resolution doesn't fall into a range acceptable to your TV.

You could take a shot at using VFC to create a custom 1920x1080 resolution. A modeline would probably be the best method to get as close as possible to the timing needed by your TV. I did a cursory search and didn't turn up a modeline for your LG 42LH3010, if you can't find one either you could try to obtain EDID info from your TV (apparently not all TVs provide EDID info).

This site has some background info on using a television as a monitor, and includes a modeline calculator . Because a resolution file with timing that's way off base has the potential to damage your television, an EDID provided modeline would be my first choice, and a generic 'calculated' modeline would be my method of last choice. If all else fails you could try the using VFS Block Sync tool , but that would likely be even less TV specific than a calculated modeline.

VFC will expect you to specify a 'chip' and 'board' definition file. The chip and board definition files for InfiniteReality2 graphics sets aren't as obvious as they are for other SGI graphics sets (O2_Chip.def, O2_Board.def, or VPro_Chip.def, VPro_Board.def) - all IR graphics use voc1.def to provide the chip definition and dg4.def for the board definition (see the version of 'man vfc' on your Onyx2 for details).

Considering you have a TV as a target, I'd suggest trying rooprob's reduced blanking method . He's created a very nice perl utility that will parse modelines and auto-generate multiple versions of the source and completed resolution format files, each slightly incremented to allow fine tuning of the format timing. He wrote the perl script to use the chip and board definitions for O2 graphics, but it would be fairly easy to edit the script to use the correct IR chip and board definitions.

BetXen wrote: I'm not familiar with ircombine and this type of hardware, so I may have misunderstood something.
There's a decent Video Format Combiner Tutorial included as an appendix to the Onyx2 Deskside Owner's Guide, with the help of the tutorial it's relatively straight forward process. Once you create or obtain a resolution file suitable for your TV (and copy it into the correct location on your Onyx2), you can use ircombine to select and load that file into the eeprom on your IR graphics set. BTW, having a monitor (or TV) without sync-on-green capabilities isn't a show-stopper for InfiniteReality graphics, you can change the Sync Output at will using the ircombine 'Channel Attributes' panel.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
Thanks for posting that info jan-jaap. With the potential for that defect to sideline O350's your offer to test a non-SGI version of the Delta DPS-500EB E PSU also might be very be very helpful to an O350 owner who might not have the skills or facilities to replace the defective parts.

jan=jaap wrote: I'm curious to find out if (1) this PSU will work at all, or that the O350 will reject it. It can read part- and serial numbers so who knows...
Like you discovered with the Fuel, it looks like some early versions of L1 firmware don't report PSU info - I have an O350 that doesn't list the PSU in an L1 serial all (1.22.4 ), while the others do (1.34.8 or newer).

I also noticed that an L1 serial all (those that have PSU info) include a revision code - a quick scan of the nekochan hinv forum turned up serial all posts with revision "S1" and revision S4. All of the SGI versions of the DPS-500EB E I looked at so far, including those used in the later production Altix 350, use SGI part number 060-0178-003. No revision info is printed on the SGI part number label on any of the O350 PSUs I have here, but all of them do include the Sx revision designation on the OEM Delta label. Hopefully some of the SGI-supplied O350 PSUs with later S(number) revisions will have been manufactured with a non-defective PFC diode.

Not may of the Delta DPS_500EB examples on eBay include enough photographic detail to read the revision info on the Delta label, but at least one (a DPS-500EB G ) was label by Delta as a revision S2.

It looks like the PSUs in your O350 are reported as revision S1. I have S1 and S4 revisions, if you can tell me where to look I'm willing to open the S4 revision to check if it has the defective PFC diode. If it's possible, a photo would probably save me some time peering through a magnifying glass.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
BetXen - if you take a look at the readme file inside /usr/gfx/ucode/KONA/dg4/vfo, it contains the VFO format analysis of all of the SGI provided resolution (.vfo) files for InfiniteReality graphics.

Here's analysis segment for the SGI-provided 1920x1080_60 resolution:

Code: Select all

Format  1920x1080_60.vfo:
1920x1080_60.vfo:
Total lines per frame:   1172
Total pixels per line:   2560
Active lines per frame:  1080
Active pixels per line:  1920
Frames per second:       59.994
Fields per frame:        1
Swaps per frame:         1
Pixel clock:             180.001 MHz, period = 5.55552 nsec
Hardware pixel rounding:  every 4 pixels
Line analysis:
Length:                 2560 Pixels, 1 Lines, 14.2221 usec; (line 0)
Frequency:              70.313 KHz, period = 14.2221 usec
Horizontal Sync:         216 Pixels, 1.19999 usec; (line 89)
Horizontal Back Porch:   376 Pixels, 2.08887 usec; (line 89)
Horizontal Active:       1920 Pixels, 10.6666 usec; (line 89)
Horizontal Front Porch:  48 Pixels, 266.665 nsec; (line 89)
Field Information:
Field Duration:           3.00032e+06 Pixels, 1172 Lines, 16.6683 msec; (line 0)
Vertical Sync:            7680 Pixels, 3 Lines, 42.6664 usec; (line 0)
Vertical Sync Pulse:      7896 Pixels, 3.08437 Lines, 43.8664 usec; (line 0)
Vertical Back Porch:      220160 Pixels, 86 Lines, 1.2231 msec; (line 3)
Vertical Active:          2.7648e+06 Pixels, 1080 Lines, 15.3599 msec; (line 89)
Vertical Front Porch:     7680 Pixels, 3 Lines, 42.6664 usec; (line 1169)


EDIT: I tried the version of cvt that rooprob ported to IRIX to generate a 1920x1080_60 modeline with reduced blanking. Compared to SGI-provided 1920x1080_60 (listed above), the results of the cvt reduced blanking mode were closer to the those listed in your TV's manual:

Code: Select all

% ./cvt 1920 1080 60 -v -r
1: [V FIELD RATE RQD]         :       60.000000
2: [H PIXELS RND]             :     1920.000000
2.5: [ASPECT_RATIO]           :       16:9
2.5: [V SYNC]                 :        5.000000
3: [LEFT MARGIN (PIXELS)]     :        0.000000
3: [RIGHT MARGIN (PIXELS)]    :        0.000000
4: [TOTAL ACTIVE PIXELS]      :     1920.000000
5: [V LINES RND]              :     1080.000000
6: [TOP MARGIN (LINES)]       :        0.000000
6: [BOT MARGIN (LINES)]       :        0.000000
7: [INTERLACE]                :        0.000000
8: [H PERIOD EST]             :       15.006173
9: [Actual VBI LINES]         :       30.654051
9: [VBI LINES]                :       31.000000
10: [Minimum VBI Lines]        :       14.000000
10: [ACT VBI LINES]            :       31.000000
11: [TOTAL V LINES]            :     1111.000000
12: [TOTAL PIXELS]             :     2080.000000
13: [Non-rounded PIXEL FREQ]   :      138.652802
13: [ACT PIXEL FREQ]           :      138.500000
14: [ACT H FREQ]               :       66.586540
15: [ACT FIELD RATE]           :       59.933880
16: [ACT FRAME RATE]           :       59.933880
20: [H BACK PORCH]             :       80.000000
21: [H SYNC RND]               :       32.000000
22: [H FRONT PORCH]            :       48.000000
23: [V FRONT PORCH]            :        3.000000

# 1920x1080 @ 60.00 Hz Reduced Blank (CVT)
#   field rate 59.93 Hz; hsync: 66.59 kHz; pclk: 138.50 MHz
Modeline "1920x1080_60.00_rb"  138.50  1920 1968 2000 2080  1080 1083 1088 1111  +HSync -Vsync
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
tjsgifan wrote: I'm guessing I could probably skip the 1.32.6 update, and just run the 1.44.0 update from the machine when booting from the 1.22.0 image? I'll try that next time.
Thanks to Toby's detailed research on the topic, I was recently able to update the L1 firmware in both modules of an Onyx 350.

As an indirect confirmation (I used an O350 rather than an O300) on Toby's thoughts as to how many intermediate flash steps were needed if the L1 firmware (to be updated) was lower than version 1.32.6, I was able to update a modules from 1.22.4 and 1.34.8 directly to 1.48.1.

In case there were any problems, I flashed them one at a time, starting with the oldest revision first :

Code: Select all

electraglide 12# l2cmd l1 ver
001c01:
L1 1.22.4 (Image B), Built 07/21/2003 10:58:40    [2MB image]
001c02:
L1 1.34.8 (Image B), Built 02/07/2005 14:56:38    [2MB image]

Code: Select all

electraglide 14# flashsc --sc /usr/cpu/firmware/sysco/l1.bin.1.48.1 1.1
flashsc: (System Controller Flash Utility) - Version 1.4.1
=========== Updating 001.01 ===========
Checking current flash image status.
Updating L1 flash image A to version 1.48.1 [MIPS 2MB image]
Erasing existing flash data:        100% complete
Writing new flash image:            100% complete
Validating new flash image.
electraglide 15# flashsc --sc /usr/cpu/firmware/sysco/l1.bin.1.48.1 1.2
flashsc: (System Controller Flash Utility) - Version 1.4.1
=========== Updating 001.02 ===========
Checking current flash image status.
Updating L1 flash image A to version 1.48.1 [MIPS 2MB image]
Erasing existing flash data:        100% complete
Writing new flash image:            100% complete
Validating new flash image.
electraglide 16# l2cmd l1 reboot_l1 a

Code: Select all

electraglide 17# l2cmd l1 ver
001c01:
L1 1.48.1 (Image A), Built 01/22/2007 11:34:34    [MIPS 2MB image]
001c02:
L1 1.48.1 (Image A), Built 01/22/2007 11:34:34    [MIPS 2MB image]
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
m20003293 wrote:
Very nice.... Wow those DVI connectors are great :) Wish I could find them for my V10 card
Thank you. The DVI ports are on a Dual Channel Display option board commonly called a DCD. DCDs do make semi-rare appearances on eBay. Two nekochan members have recently had some listed on eBay, so you could also try a post in the wanted forum.

jan-jaap wrote:
That is a very nice looking Octane!
Thank you as well. The nice appearance is courtesy of the care taken by the previous owner - it's nice not have have to deal with the 'it came from surplus where it was pushed across the floor on its plastic parts because it was too heavy to lift" appearance of so much of what appears on eBay these days.

jan-jaap wrote:
Good find. I will have to try this myself.
If you happen to have a DIVO in one of your Onyx2s ( which also work in an Octane ), there are similar tools (divohinv and divotest) there too.

BTW, when you run the xtdigvid_confidence tests, please post some details.

_________________
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
BetXen, while I had VFC set up to compile a format for someone else I went ahead and made a 1920x1080 format for InfiniteReality graphics. I used the cvt-generated reduced blanking modeline from above as a template. The resulting VFC-generated format analysis of resulting format looks a little closer to the horizontal and vertical frequencies quoted from your TV manual.

In rough comparison:
  • your television manual listed 66.587KHz and 59.93Hz,
  • the SGI-provided format was 70.313KHz and 59.99Hz,
  • the cvt/vfc-generated vfo was 66.780KHz and 59.93Hz

If you'd like to try the format I complied, I've attached a copy, but the most accurate method would still be EDID info - there are a number of fairly simple methods that can be used (with something other than IRIX) to obtain EDID - check google for examples.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
SleepyRegions wrote: a Compact Flash card adapted to IDE adapted to 50-pin SCS
Never tried it - but if you'd like to try it minus an adapter or two, I have a five-slot SMC PCD-60B card reader with a no-adapter-needed SCSI interface that'll read Compact Flash, SD/MMC, Smart Media xD and PCMCIA cards that I'd swap for some other interesting bit of hardware.

I originally picked up the SCSI card reader so I could access CF camera cards from within IRIX, but ended up using a firewire card readers instead.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
BetXen wrote: Thanks for your work.
You're welcome.
BetXen wrote: I didn't have a lot of time last week, but tried anyway to grab the EDID infos. I google a bit and downloaded some applications. No success yet. They always tell me that the wil get the EDID from Windows registry.
Not all displays (or graphics boards) provide EDID info, but if you'd like to try this wiki touches on a few EDID tools . If you're using Windows I've noticed PowerStrip and EDID Viewer mentioned on several different EDID-related sites.

BetXen wrote: In the meantime, I also connected my laptop. No problem with HDMI but when I connect it via DB15, It displays the same way the Onyx2 does: two black bands... strange.
If there the black pixels are still visible with the reduced blanking format, make a note of how and where they appear. The number of black pixels drawn on the top and left of the display are controlled by the values assigned to the vertical and horizontal front porch. If EDID info isn't available it may be possible to make adjustments to the values in the cvt modeline to move the position of the image.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
Martin Steen wrote: I sometimes do pictures of vermins,
Verminity aside (had to google Kartoffelkäfer and Colorado Beetle to find out what those were), peering into their world through the looking glass can be interesting.....
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
Oskar45 wrote:
recondas wrote: PS: As moderator, could you perhaps convince Neko to set aside some gallery for such shots? Up to now, you, Martin and myself have posted a few wild-life pics - but surely others want to do it as well...
The occasional wildlife photo in the Everything Else forum is nice, but my humble opinion (humble because I don't bear the expense of the forum or the effort of the behind the scenes maintenance) would be to leave our exposure as just that - occasional.

At a resolution large enough to appreciate their beauty, I wouldn't doubt that just a small portion of the finer examples of just your work could consume gigabytes of storage space. Add in several talented photographers and it quickly becomes expensive in a number of areas, not the least of which would be hardware and administrative labor.

There are other publicly available venues that generate sufficient revenue to support photo-hosting. They probably remain the better choice.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
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 *
***********************************************************************
BetXen wrote: It works flawlessly ! My desktop completely fills the TV and the details are sharp. When I booted it up, even with the new TV firmware, the result was identical. Then I loaded you vfo file in ircombine an... wow... how impressive it is on a 42" display.
Congratulations - and nice to hear we got it on the first try.

If you ever want to try the same thing with your Fuel, there's an LCD-friendly VPro 1920x1080_60 file attached to this thread: viewtopic.php?f=3&t=16725755 If it ends up needing the same tweaks as the version you're using on your Onyx2 just let me know, but it's probably close enough as is to try safely.

BetXen wrote: I need to find good looking demos to show my friends...
If you can find a set, there are some InfiniteReality specific demos that are pretty nice: viewtopic.php?t=16719222&p=7321479#p7321479

BetXen wrote: Anyway, I will continue trying to get the EDID from my Windows notebook. It's strange that it cannot display correctly.
It might not be there - not all monitors (or HDTVs) provide accessible EDID info.

BetXen wrote: Thanks so much.
You're quite welcome.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
BetXen wrote: I've finally discovered that there is a little shift to the left. When I make a window fullscreen, the left border is hidden. After inspection, the display area does not use the 12-13 rightmost pixels. Can you easily modify this or do you agree to share the vfs ?.
I made some minor adjustments to the source file that might improve the situation. Since it sounds like we were very close, those changes were fairly small increments.

I've attached the newly adjusted format (vfo file). Here the output of a VFC analysis of the resulting microcode and source file:

Code: Select all

IR-HDTV_1920x1080_59.93rb.vfo:
Total lines per frame:   1111
Total pixels per line:   2080
Active lines per frame:  1080
Active pixels per line:  1920
Frames per second:       59.93
Fields per frame:        1
Swaps per frame:         1
Pixel clock:             138.491 MHz, period = 7.22068 nsec
Hardware pixel rounding:  every 2 pixels
Line analysis:
Length:                 2080 Pixels, 1 Lines, 15.019 usec; (line 0)
Frequency:              66.5822 KHz, period = 15.019 usec
Horizontal Sync:         32 Pixels, 231.062 nsec; (line 28)
Horizontal Back Porch:   80 Pixels, 577.655 nsec; (line 28)
Horizontal Active:       1920 Pixels, 13.8637 usec; (line 28)
Horizontal Front Porch:  48.0001 Pixels, 346.593 nsec; (line 28)
Field Information:
Field Duration:           2.31088e+06 Pixels, 1111 Lines, 16.6861 msec; (line 0)
Vertical Sync:            12480 Pixels, 6 Lines, 90.1141 usec; (line 0)
Vertical Sync Pulse:      12512 Pixels, 6.01538 Lines, 90.3452 usec; (line 0)
Vertical Back Porch:      45760 Pixels, 22 Lines, 330.418 usec; (line 6)
Vertical Active:          2.2464e+06 Pixels, 1080 Lines, 16.2205 msec; (line 28)
Vertical Front Porch:     6240 Pixels, 3 Lines, 45.0571 usec; (line 1108)

The VFC analysis puts the newer version even closer to horizontal vertical frequencies spec'd in your owner's manual:
  • 66.587KHz and 59.93Hz - as spec'd by your HDTV owner's manual
  • 66.582Khz and 59.93Hz - the newly adjusted format attached to this post
  • 66.780KHz and 59.93Hz - the first format we tried
Hopefully it'll help. Additional mode info beyond just the horizontal and vertical frequencies given by your manual (or the same model HDTV in front of me as a cause-and-effect test platform) would probably be the next step if we're still a little off.

I did run across another site that discusses HDTV modelines: http://www.gentoo-wiki.info/HOWTO_Xorg_HDTV You mentioned your laptop is running windows, perhaps one of the Linux liveCDs would allow to temporarily boot linux and some of the suggestions on the Gentoo Wiki.

If you'd like to try recalculating the values used in the source file, just remove the .txt extension (added only to allow attachment of the file) and copy the .vfs file into /usr/gfx/vfc/vfs (change the file permissions to read-only). Alternatively you could the file anywhere you like and give VFC an implicit path to the file when ever you call on it. Because I've been working on creating formats for a number of different graphics boards and resolutions, to minimize clutter in /usr/gfx/* I prefer to run VFC from within the same directory in my user account (that holds the source files I create) and implicitly call out the path to the VFC chip and board definition files:

Code: Select all

# vfc -c chip=/usr/gfx/ucode/vfc/rules/voc1.def,board=/usr/gfx/ucode/vfc/rules/dg4.def -o IR-HDTV_1920x1080_59.93rb.vfo IR-HDTV_1920x1080_59.93rb.vfs

If the image is still shifted to the left, it's possible to adjust the horizontal position of the image by changing the modeline so the values for the horizontal front and back porch are increased or decreased (so that one becomes larger and the other an equal amount smaller). These diagrams provide a very basic illustration of how some of the timing values in a VFC source file affect the resulting display: As you can see it isn't quite as simple as changing just the horizontal front and back porch. Changes should made to the overall modeline so all the all of the horizontal values remain properly balanced.

If the microcode attached above doesn't resolve the off-centered image, the source file and vfo microcode (attached to the end of this post) should shift the position of the image eight pixels to the right. This was done by changing the horizontal values in the modeline to increase the horizontal back porch (by eight pixels) and decreasing the horizontal front porch by an equal amount. Care was taken when making those changes so that HorizontalSync or TotalPixelsPerLine (called 'Total clocks per line' in the second diagram) *weren't also changed. Shifting the position of the image eight pixels to the right changes the cvt-generated modeline from:

Code: Select all

Modeline "1920x1080_59.93_rb"  138.25  1920 1968 2000 2080  1080 1083 1088 1111  +HSync -Vsync
to:

Code: Select all

Modeline "1920x1080_59.93_right"  138.25  1920 1960 1992 2080  1080 1083 1088 1111  +HSync -Vsync

If the change works as expected, but the image doesn't move enough to the right, comparing the two modelines and the attached source files give some indication where changes were made.

On the odd chance you aren't already familiar with how VFC source file data is extracted from a modeline, here's my spin.

A modeline contains four horizontal (pixel) fields, and four vertical (line) fields. Looking at the modeline posted just above

Code: Select all

Modeline "1920x1080_59.93_rb"  138.25  1920 1960 1992 2080  1080 1083 1088 1111  +HSync -Vsync
if we substitute the field names for the numerical values, the line reads:

Code: Select all

Modeline "1920x1080_59,93.rb" PixelCk HDisp HSyncStart HSyncEnd HTotal VDisp VSyncStart VSyncEnd VTotal +HSync -VSync
which we can use with the info below to calculate VFC source file data.

From the horizontal portition of the modeline (HDisp HSyncStart HSyncEnd HTotal):
    TotalPixelsPerLine = HTotal
    HorizontalBackPorch = HTotal minus HSyncEnd
    HorizontalSync = HSyncEnd minus HSyncStart
    HorizontalFrontPorch = HSyncStart minus HDisp
    ActivePixelsPerLine = HDisp

From the vertical portion of the modeline (VDisp VSyncStart VSyncEnd VTotal):
    TotalLinesPerFrame = VTotal
    VerticalBackporch = (VTotal minus VSyncEnd) minus 2 (see my note below in rule 2 of "editing vertical timing" for more on the 'minus 2')
    VerticalSync = VSyncEnd minus VSyncStart
    VerticalFrontPorch = VSyncStart minus VDisp
    ActiveLinesPerFrame = VDisp

In most cases, FieldsPerFrame will equal 1, and FramesPerSecond will be the target refresh rate.

A few of the not always so obvious ground rules to keep in mind when manually editing modelines:

Editing modeline horizontal timing values to shift the image left or right:
    1). The rule of eights. All of the horizontal values in the modeline, HDisp, HSyncStart, HSyncEnd, and HTotal (1920, 1960, 1992 and 2080 in the shifted modeline above), are expressed as multiples of eight, and that each subsequent value in the string is numerically higher than the previous.

    2). When added together, the values used in the resulting source file (vfs) for ActivePixelsPerLine, HorizontalFrontPorch, HorizontalSync, and HorizontalBackPorch equal the TotalPixelsPerLine. In the shifted modeline (quoted above) those values are 1920 pixels, 40 pixels, 32 pixels and 88 pixels, which equal 2080 pixels (the TotalPixelsPerLine value). Note that values used for ActivePixelsPerLine, HorizontalFrontPorch, HorizontalSync, HorizontalBackPorch and TotalPixelsPerLine must also follow the rule of eights.

    3). To shift an off-centered the image to the right subtract equal amounts (in multiples of eight) from both HSyncEnd and HSyncStart; add equal amounts (again in factors of eight) to shift the image to the left.

When manually editing modeline vertical timing values to shift the image up or down:
    1). Vertical values in a modeline need not comply with the rule of eights.

    2). When added together the vertical (line) values used in the source file, ActiveLinesPerFrame, VerticalFrontPorch,VerticalSync, and VerticalBackPorch should equal TotalLinesPerFrame. Note that because of (undocumented) internal calculations performed by VFC, a "shorten your format" error may appear when VerticalFrontPorch,VerticalSync, VerticalBackPorch and TotalLinesPerFrame are calculated using industry standard methodology. There are a number of methods to correct the format length error state. One method of "shorten your format" error correction is to increase the TotalLinesPerFrame value inserted into the source file. Because the TotalLinesPerFrame value is derived unchanged from the modeline, if the TotalLinesPerFrame value is changed when inserted into the source file, all of the source file values calculated from the vertical portion of the modeline - VerticalSync, VerticalBackPorch and VerticalFrontPorch would no longer equal the changed TotalLinesPerFrame value. The result can be an unstable microcode format. My preference for dealing with "shorten your format" error is a marginally lesser evil, subtract 2 from the VerticalBackPorch value before inserting into the source file, but after checking that VerticalSync, VerticalBackPorch and VerticalFrontPorch equal TotalLinesPerFrame.

    3). If the displayed image is too high, subtract (small!) equal amounts from the VSyncEnd and VSyncStart values in the modeline; if the image is too low, add small equal amounts from VSyncEnd and VSyncStart. Note: the vertical (line) values in the modeline are VDisp, VSyncStart, VSyncEnd, and VTotal. Using the same shifted modeline as an example, those values are shown as 1080, 1083, 1088, and 1111. In a similar fashion to the horizontal portion of the modeline, each of the subsequent values in the vertical value string must be numerically higher than the last.

When manually editing a modeline to resolve image size issues:
    1). If the displayed image is too narrow, subtract very small increments form HTotal, if too wide add very small increments to HTotal. There is a limited range of adjustment to HTotal available. Changing HTotal directly effects blanking, and HTotal cannot have a numerical value smaller than any of the preceding horizontal values (see rule 1 in the 'changes to horizontal timing' section).

    2). If the displayed image is too short, subtract very small increments form VTotal, if too tall add very small increments to VTotal. There is a limited adjustment available, VTotal cannot have a numerical value smaller than any of the preceding vertical values (see rule 3 in the 'editing vertical timing values' section).


I've attached the changed microcode(as IR-HDTV_1920x1080_59.93 right .vfo. Because the horizontal image adjustment was a shot in the dark I'd recommend trying the un-shifted version (IR-HDTV_1920x1080_59.93 rb .vfo *first*.


Postscript:
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
Added a gig and a half of RAM and updated the hinv.......

_________________
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
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 *
***********************************************************************
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 *
***********************************************************************
...... and a pseudo DM10. This one is the Adaptec AFW-4300B with the red PCB mentioned in the Octane Hardware Aggregator (and elsewhere in the forums). It successfully reads and writes Compact Flash media using a MicroTech FWCameraMate.

I did discover if the 32-bit PCI Adaptec AFW-4300B was installed in a numerically lower PCI slot (in the PCI card cage) than the 64-bit PCI-X GigE board I'd get PCI Bridge errors during boot and neither would function reliably after boot. Installing the PCI-X board in PCI slot 1 and the 32-bit board in slot 3 resolved the issue.

_________________
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
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 *
***********************************************************************
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 *
***********************************************************************
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 *
***********************************************************************
guardian452 wrote: I have been having delusions about doing a cross-america road trip (from canuckistan to argieland and back) next autumn on the fz6. Not sure if it can happen or not but it is fun to dream..
It'd be a great trip. If you don't already have dry storage space on the bike, it looks to be readily available: http://www.yamaha-motor.com/sport/acces ... all/1.aspx The two hardshell saddlebags and top case would give you as much carrying capacity as I have on the dresser.

If it fits your budget (and personal sense of adventure) a motorcycle-friendly GPS is a worthwhile investment (the look-ahead-and-find-gas-stations-along-the-route feature is especially nice in the spread out western states and provinces), but I made do with an analog GPS for years (analog gps as in grease pencil system). Wrote the days basic route/major turns on the windshield in grease pencil - it was easy to clean off when it was time for a new turn list, and at night just enough illumination from the headlamp was caught by the bottom edge of the windshield to very slightly backlight the directions.

With or without a GPS, I always carry a printed travel atlas. I like the Rand-McNally Deluxe Motor Carrier Road Atlas . Costs a little more, but it's heavy-duty spiral bound and each of the large detailed pages is laminated - nice if you need to reconnoiter in the rain.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
tstover wrote: Can I disable this check and just put any old fans in there to keep it cool? Thoughts?
You could disable environmental monitoring, but I wouldn't recommend it.

It is possible to use other fans, viewtopic.php?f=3&t=16718040& but I'd suggest checking that the current set are tightly connected. If the connection isn't suspect you might want to test the fans with an external power source and the fan connections in the O300 with a DMM. Having the same fans fail in both O300s seems little unusual to me. What do you know about their history?
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
If the O300 uses the same non-standard 3-pin fan connector header as the Fuel and Origin 350, there's a photo of a spliced fan wire connection at the bottom of the Fuel Hardware Aggregator (the Aggregator might be of further interest to you as the Fuel and O300 are both IP35 at the software level): viewtopic.php?t=9046&f=3#p136996

As jan-jaap already mentioned, when sourcing fans the other thing to check is the RPM rating of the replacement fan. The "Warning RPM" level for your O300s is 2160 RPM, if the replacement fans run any slower than that you'll still run into issues with the L1 controller automatically shutting down the system. I recently added some low-noise variable speed fans to an O350, even though the minimum speed rating for the variable speed fans was above the warning rpm level, they still generated fan warnings during a cold start because the replacement fans had an integral thermostat and didn't spin up until a certain temperature was reached.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
arianon wrote:
I've been searching ebay pretty heavily for IRIX software, there are a couple setup there now for around $600. Slightly outside my price range :(
Doesn't sound like you're seriously considering that $600 dollar set on eBay, but just for the record last time I asked SGI would sell a complete standalone version of IRIX 6.5.30 AWE for the same price, and the SGI supplied version included 90 days of full access to SupportFolio. Full access to SupportFolio means you could also get a complete set of the restricted-access patches that have been released since the original release of IRIX 6.5.30.
arianon wrote:
I just wanted to get a legitimate set of CDs so if I had to reinstall my system from scratch I would be able to do so. That actually leads me to another question, my system came with quite a bit of software installed on it. Is there a way me for me to back up the licenses or the local flexlm server so that I won't lose the licenses if the hard drive ever dies?

You can make a copy of the license file. Most (but not all) licenses are contained in /var/flexlm/license.dat. Not all programs follow that licensing methodology, if you're not certain you can open License Manager (from inside Toolchest > System) and compare the contents of license.dat to the list that appears in the Manager GUI. Highlight any that appear in the GUI (that aren't in license.dat) and click the "Get Info ..." button to see where those are located.

Even if you do acquire a full copy of IRIX, I'd recommend cloning the hard drive(s) in your SGI system so you have a ready-to-go bootable backup. That'd save you having to reconfigure/restore your personal settings, user files and licenses - stuff that can easily require more work that a complete reinstall. I clone at least once a month in a three-drive rotation so I always have a good fall-back copy available - more often if I've got something specific I want to protect.

There's a cloning guide in the wiki: http://www.nekochan.net/wiki/ ... ystem_Disk
and another frequently cited version at Ian Mapleson's site: http://www.sgidepot.co.uk/disksfiles.html

_________________
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
Updated gfxinfo to include the change to a 3200x1200_60 desktop:

Code: Select all

# /usr/gfx/gfxinfo -v
Graphics board 0 is "ODYSSEY" graphics.
Managed (":0.0") 3200x1200
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************