SGI: Hardware

1920x1080_60Hz with Onyx2

Hi !

Due to the birth of our child, I had to move the Onyx2 out of his room to the living room. Fortunately, my TV syncs on green (it is a LG 42LH3010). Thus I opened ircombine and tried different resolutions. No problem to display 1680x1050_60Hz, but I can't successfully display 1920x1080_60. My desktop appears on the lower right part of the screen, with two large black bands on the left and top regions of the TV (around 15cm on the left and 5 on top). Moreover, I can't see the whole managed area (for instance iconbar is only half visible) and it is slightly squeezed horizontally.

I'm not familiar with ircombine and this type of hardware, so I may have misunderstood something. Do you have any ideas that would help me resolve this problem ? It would be nice to use the whole surface at the highest resolution :D

Thanks in advance.


BetXen

P.S.: If needed I can include pictures, but I'm at work now.
:Onyx2: : oxygen (4xR12k400) / :A3504L: :A3504L: : neon (16xI2 1.6, 9MB L2) / :O200: :O200: : beryllium (4xR12k270)
:Fuel: : nitrogen (R16k800) / :Octane2: : carbon (2xR14k600) / :Octane: : lithium (R10k400) / :Octane: : fluorine (2xR12k300) / spare 2xR12k360
:O2: : hydrogen (R10k195) / :O2: : sodium (R5k180) / :O2: : R5k180->200 MB and PM only
:Indigo2IMP: : helium (R10k195, HighImpact) / :Indigo2IMP: : boron (R4k250)/ :Indigo: : magnesium (R4k100) / :Indy: : aluminium (R5k180)
:4D70GT: 4D70GT : my very first one (now property of musée bolo and the foundation mémoires informatiques )
See the hinv/gfxinfo posts here .
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 a lot recondas. I will have a look at your links during the week-end. Unfortunately, I will be in the chalet and have to try later on next week.

In the meantime, I've found this table in the manual of my TV:
display resolutions (LG42LH3010 RGB PC).JPG
LGLCD TV 42LH3010 Supported Display Resolutions
display resolutions (LG42LH3010 RGB PC).JPG (54.62 KiB) Viewed 1680 times


Have a good week-end.

BetXen
:Onyx2: : oxygen (4xR12k400) / :A3504L: :A3504L: : neon (16xI2 1.6, 9MB L2) / :O200: :O200: : beryllium (4xR12k270)
:Fuel: : nitrogen (R16k800) / :Octane2: : carbon (2xR14k600) / :Octane: : lithium (R10k400) / :Octane: : fluorine (2xR12k300) / spare 2xR12k360
:O2: : hydrogen (R10k195) / :O2: : sodium (R5k180) / :O2: : R5k180->200 MB and PM only
:Indigo2IMP: : helium (R10k195, HighImpact) / :Indigo2IMP: : boron (R4k250)/ :Indigo: : magnesium (R4k100) / :Indy: : aluminium (R5k180)
:4D70GT: 4D70GT : my very first one (now property of musée bolo and the foundation mémoires informatiques )
See the hinv/gfxinfo posts here .
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 *
***********************************************************************
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 *
***********************************************************************
Recondas,

Thanks for your work. 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. I thought ther would be a way to ask the monitor directly... Yesterday I also upgraded my TV with the latest firmware and will try to get the EDID again today. It seem I will have too google a bit more, as you say there are simple methods to do it.

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. Didn't check with the noew firmware for the moment.

I will also try your file this evening. Thanks a lot.


BetXen
:Onyx2: : oxygen (4xR12k400) / :A3504L: :A3504L: : neon (16xI2 1.6, 9MB L2) / :O200: :O200: : beryllium (4xR12k270)
:Fuel: : nitrogen (R16k800) / :Octane2: : carbon (2xR14k600) / :Octane: : lithium (R10k400) / :Octane: : fluorine (2xR12k300) / spare 2xR12k360
:O2: : hydrogen (R10k195) / :O2: : sodium (R5k180) / :O2: : R5k180->200 MB and PM only
:Indigo2IMP: : helium (R10k195, HighImpact) / :Indigo2IMP: : boron (R4k250)/ :Indigo: : magnesium (R4k100) / :Indy: : aluminium (R5k180)
:4D70GT: 4D70GT : my very first one (now property of musée bolo and the foundation mémoires informatiques )
See the hinv/gfxinfo posts here .
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 *
***********************************************************************
Recondas... you're a genius :D 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. I need to find good looking demos to show my friends...

Anyway, I will continue trying to get the EDID from my Windows notebook. It's strange that it cannot display correctly.

Thanks so much. Best regards.
:Onyx2: : oxygen (4xR12k400) / :A3504L: :A3504L: : neon (16xI2 1.6, 9MB L2) / :O200: :O200: : beryllium (4xR12k270)
:Fuel: : nitrogen (R16k800) / :Octane2: : carbon (2xR14k600) / :Octane: : lithium (R10k400) / :Octane: : fluorine (2xR12k300) / spare 2xR12k360
:O2: : hydrogen (R10k195) / :O2: : sodium (R5k180) / :O2: : R5k180->200 MB and PM only
:Indigo2IMP: : helium (R10k195, HighImpact) / :Indigo2IMP: : boron (R4k250)/ :Indigo: : magnesium (R4k100) / :Indy: : aluminium (R5k180)
:4D70GT: 4D70GT : my very first one (now property of musée bolo and the foundation mémoires informatiques )
See the hinv/gfxinfo posts here .
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 *
***********************************************************************
Hi.

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 will try on my fuel too (currently @1920x1200 on 24" CRT), but not for the moment. My living room is already full of things, mainly children toys (including mine :) ).

Concerning the EDID, I've seen in the options menu of my TV an EDID "paragraph". Have to look at this.

Yes, I have a set of the IR demos CDs. I would also like to find more modern demos or applications. Yesterday evening, I connected the Onyx2 to my home cinema and ran different things: demoscene demos (like dr.fungi etc.), mplayer full screen, DiePlaneten and QuakeIII (Wowww !). Still have to install and configure FlightGear etc.

Have a good day.
:Onyx2: : oxygen (4xR12k400) / :A3504L: :A3504L: : neon (16xI2 1.6, 9MB L2) / :O200: :O200: : beryllium (4xR12k270)
:Fuel: : nitrogen (R16k800) / :Octane2: : carbon (2xR14k600) / :Octane: : lithium (R10k400) / :Octane: : fluorine (2xR12k300) / spare 2xR12k360
:O2: : hydrogen (R10k195) / :O2: : sodium (R5k180) / :O2: : R5k180->200 MB and PM only
:Indigo2IMP: : helium (R10k195, HighImpact) / :Indigo2IMP: : boron (R4k250)/ :Indigo: : magnesium (R4k100) / :Indy: : aluminium (R5k180)
:4D70GT: 4D70GT : my very first one (now property of musée bolo and the foundation mémoires informatiques )
See the hinv/gfxinfo posts here .
neverball/neverputt are fun, as are the screensavers in the rss-glx package.
Google: Don't Be Evil. Apple: Don't Be Greedy. Microsoft: Don't Be Stupid.
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 *
***********************************************************************
Wow, what an impressive post. It's very interesting. I think I begin to understand now how and what to do.
I will try the new files this evening and maybe even try to optimize if needed. I will be on holidays from tomorrow since next sunday. I will give you news after that, because I will not be at home.

I would like to go home NOW. Why do I need to stay at work...?


BetXen
:Onyx2: : oxygen (4xR12k400) / :A3504L: :A3504L: : neon (16xI2 1.6, 9MB L2) / :O200: :O200: : beryllium (4xR12k270)
:Fuel: : nitrogen (R16k800) / :Octane2: : carbon (2xR14k600) / :Octane: : lithium (R10k400) / :Octane: : fluorine (2xR12k300) / spare 2xR12k360
:O2: : hydrogen (R10k195) / :O2: : sodium (R5k180) / :O2: : R5k180->200 MB and PM only
:Indigo2IMP: : helium (R10k195, HighImpact) / :Indigo2IMP: : boron (R4k250)/ :Indigo: : magnesium (R4k100) / :Indy: : aluminium (R5k180)
:4D70GT: 4D70GT : my very first one (now property of musée bolo and the foundation mémoires informatiques )
See the hinv/gfxinfo posts here .
I've finally had time to test the "rb" and "right" vfs. They both work well, but there still is a need for 8 pixels shift that I will do when I return home. I'm not completely sure, but it seemed that the upper left corner was slightly blinking. Have to check later too.

Good holidays to those who also have some. See you.
:Onyx2: : oxygen (4xR12k400) / :A3504L: :A3504L: : neon (16xI2 1.6, 9MB L2) / :O200: :O200: : beryllium (4xR12k270)
:Fuel: : nitrogen (R16k800) / :Octane2: : carbon (2xR14k600) / :Octane: : lithium (R10k400) / :Octane: : fluorine (2xR12k300) / spare 2xR12k360
:O2: : hydrogen (R10k195) / :O2: : sodium (R5k180) / :O2: : R5k180->200 MB and PM only
:Indigo2IMP: : helium (R10k195, HighImpact) / :Indigo2IMP: : boron (R4k250)/ :Indigo: : magnesium (R4k100) / :Indy: : aluminium (R5k180)
:4D70GT: 4D70GT : my very first one (now property of musée bolo and the foundation mémoires informatiques )
See the hinv/gfxinfo posts here .
Hi again !

Tried yesterday evening to modify the vfs to shift the display area 8 more pixels to the right. Unfortunately, you (recondas) removed the "*.vfs.txt" file in the meantime and I only had them at work ;-) I downloaded then the file mentionned in this post and modified it.
The "shorten your format" message appeared and it took me half an hour to remember that you wrote something about that (if only I had read your post once more before !). Removing 2 from the VerticalBackPorch was the solution, as you suggested.

Everything works perfectly well now. So, I'll share with all of you the latest and working vfs/vfo files. I hope it would be usefull for someone. There are some instructions summary in the header of the vfs... because I'm sure I will have forgotten everything next time I would need it :-)

IR_LG42LH3000_1920x1080_5993.vfs.txt
(1.83 KiB) Downloaded 89 times

IR_LG42LH3000_1920x1080_5993.vfo
(17.59 KiB) Downloaded 34 times

Regards
:Onyx2: : oxygen (4xR12k400) / :A3504L: :A3504L: : neon (16xI2 1.6, 9MB L2) / :O200: :O200: : beryllium (4xR12k270)
:Fuel: : nitrogen (R16k800) / :Octane2: : carbon (2xR14k600) / :Octane: : lithium (R10k400) / :Octane: : fluorine (2xR12k300) / spare 2xR12k360
:O2: : hydrogen (R10k195) / :O2: : sodium (R5k180) / :O2: : R5k180->200 MB and PM only
:Indigo2IMP: : helium (R10k195, HighImpact) / :Indigo2IMP: : boron (R4k250)/ :Indigo: : magnesium (R4k100) / :Indy: : aluminium (R5k180)
:4D70GT: 4D70GT : my very first one (now property of musée bolo and the foundation mémoires informatiques )
See the hinv/gfxinfo posts here .