VFO: Video Format Object Files

SGI hardware problems, solutions, tips, hacks, etc.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
Posts: 51
Joined: Wed Sep 01, 2010 7:20 am

Re: VFO: Video Format Object Files

Unread postby rooprob » Thu Oct 20, 2011 3:59 am

On the subject of the O2 display. I found that whilst 1600x1200 and 1680x1050 do render, something isn't quite right.
1600x1200 you end up with a small part of the toolchest in the bottom right.
1680x1050 doesn't like anything using openGL - my screen pixels shunt left and right 100px as I rotate an object in blender and the toolchest menus stripe in across the screen. After that the gfx often crash and, if not, the mouse pointer point is no longer under the mouse's point.

The best I've been able to get is 1600x1000_60 which you don't list, so here it is again in the hope it's useful.
http://tamasi.org/irix/O2/vfc/1600/tama ... __1031.vfo
http://tamasi.org/irix/O2/vfc/1600/tama ... __1031.vfs

This one strikes the right balance between higher res, and low 108.87Mhz pixel clock which I think is respectfully low so as not tax the hardware. There might be some more to get out of it as I did just guestimate the numbers. My screen is a HP LP2475w.
:O2: r12 400 mapleleaf
New Zealand

User avatar
Posts: 5251
Joined: Sun Jun 06, 2004 5:55 pm
Location: NC - USA

Re: VFO: Video Format Object Files

Unread postby recondas » Thu Oct 20, 2011 4:42 am

rooprob wrote:On the subject of the O2 display. I found that whilst 1600x1200 and 1680x1050 do render, something isn't quite right.
Thanks for the feedback. I don't have monitors in a number of the resolutions offered, nor an O2 to test with.

I'm not at all surprised that neither mode would work with your HP 2475w. I used the the version of CVT you so kindly ported to IRIX to generate the modelines I used, so we most likely built identical formats. I'll take them down if I don't soon hear they'll work different model monitors (other than the L2475w).

In any case, thank you for porting CVT, and I've previously recommended your modelines script as an excellent VFC resource.

It's possible that the analog port on the O2 may be running into a hardware limitation with display resolutions wider than 1600 active pixels per line. I'm sure rooprob has seen it, but for those who haven't, VFC errors out if there are more than 2160 TotalPixelsPerLine in an O2 VFC source file. The CVT reduced blanking 1680x1050 modeline was enough to reduce the TPPL to less than 2160 limit, but may have introduced other timing issues. rooprob, If you haven't already tried you might see if changing the accumulation buffer setting in xsetmon to 'software only' (16 bits-per-component) helps with OpenGL visuals.

On the slim chance that you haven't already seen (or tried) it, SGIFanLongTime posted a 1920x1080_59.95 VFC source file that apparently worked with his O2 (he didn't mention what monitor it was intended for): viewtopic.php?f=3&t=13591&start=30#p7276037

If you can get relatively close to a usable display, the position of the viewable portion of the display can be tweaked by manually adjusting the values in the modeline. There's a brief description of the process about halfway down in this post: viewtopic.php?f=3&t=16725716#p7343498

EDIT: @rooprob - In this post schleusel mentioned a workaround for getting 1680x1050 working with an analog-friendly pixel clock (which is probably more suitable suitable for the analog O2 CRM graphics than a intended-for-DVI reduced blanking modeline). The vfo files schleusel created and hosted on line aren't there any more, but I followed his mention of reducing the TPPL to 2160 by reducing the HBP by 80 pixels. The resulting format source compiled without error, I've added it to the list at the beginning of the thread. If you try it let me know if it works.

Here's the VFC analysis:

Code: Select all

 Total lines per frame:   1089
 Total pixels per line:   2160
 Active lines per frame:  1050
 Active pixels per line:  1680
 Frames per second:       60
 Fields per frame:        1
 Swaps per frame:         1
 Pixel clock:             141.134 MHz, period = 7.08544 nsec
 Hardware pixel rounding:  every 1 pixels
 Line analysis:
  Length:                 2160 Pixels, 1 Lines, 15.3046 usec; (line 0)
  Frequency:              65.34 KHz, period = 15.3046 usec
 Horizontal Sync:         176 Pixels, 1.24704 usec; (line 36)
 Horizontal Back Porch:   200 Pixels, 1.41709 usec; (line 36)
 Horizontal Active:       1680 Pixels, 11.9035 usec; (line 36)
 Horizontal Front Porch:  104 Pixels, 736.886 nsec; (line 36)
 Field Information:
  Field Duration:           2.35224e+06 Pixels, 1089 Lines, 16.6667 msec; (line 0)
  Vertical Sync:            15120 Pixels, 7 Lines, 107.132 usec; (line 0)
  Vertical Sync Pulse:      15296 Pixels, 7.08148 Lines, 108.379 usec; (line 0)
  Vertical Back Porch:      62640 Pixels, 29 Lines, 443.832 usec; (line 7)
  Vertical Active:          2.268e+06 Pixels, 1050 Lines, 16.0698 msec; (line 36)
  Vertical Front Porch:     6480 Pixels, 3 Lines, 45.9137 usec; (line 1086)
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *

User avatar
Posts: 3982
Joined: Thu Jun 17, 2004 11:35 am
Location: Wijchen, The Netherlands

Re: VFO: Video Format Object Files

Unread postby jan-jaap » Tue Nov 01, 2011 2:12 pm

recondas wrote: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).
The attachment 2@1280x1024_60rb.vfo is no longer available

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.

Gave it a try -- and it didn't work :(

One screen (SGI F180, DVI connected) reported 'out of sync 'and went into powersaving. The other (some Iiyama screen, HD15 connected) barely hung on. OSD reported H=62.8kHz, V=60Hz.

The default 2@1280x1024_60 mode reports H=63.9kHz, V=60Hz (and works fine with both screens)

Hope this helps -- I don't have a 1920x1080 capable screen, never mind two of them ;)
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi

Currently in commercial service: Image :Onyx2:(2x) :O3x02L:
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)

Return to “SGI: Hardware”

Who is online

Users browsing this forum: Bing [Bot] and 1 guest