Discussion:
SNAP and 1920x1200 resolution...
(too old to reply)
Dariusz Piatkowski
2009-02-20 04:55:33 UTC
Permalink
Raw Message
I've got myself a fairly strange problem here.

I picked up a brand new Samsung 245T LCD monitor the other day. The native
resolution of this 24" panel is 1920x1200.

I have been using the last free SNAP driver (3.1.8) for quite some time now to
drive my Matrox G450 video card (32 Meg) in 1600x1200 mode on my previous LCD -
Samsung 214T w/o any problems.

Now with the bigger monitor I wanted to move up to the 1920x1200 mode...however,
even though SNAP allows me to do it, when the display comes up the monitor is
interpretting it to actually be a weird 960x1200 resolution...subsequently it
attempts to stretch the display and gets it all distored.

The additional weird part in all of this is that the actual screen resolution
does increase to the new 1920x1200 - I see that my Desktop did get bigger and
there are more pixels available - but it's like the signalling coming out of the
video card has the WRONG info going to the monitor.

Just to rule out that it's NOT the monitor that's the problem I yanked the G450
card out of my OS2 box and ran it in my test Win2K machine...sure enough,
1920x1200 came up NO problem. I then switched to an ATI FireGL 8800 card on that
Win2K machine and that came up fine too.

So...it looks like I can't get 1920x1200 on my OS2 box...I've tried a bunch of
different things (including using the centering options of SNAP) and nothing is
working for me.

Any ideas?
Heikki Kekki
2009-02-20 09:17:08 UTC
Permalink
Raw Message
On Fri, 20 Feb 2009 04:55:33 UTC, "Dariusz Piatkowski"
Post by Dariusz Piatkowski
I've got myself a fairly strange problem here.
I picked up a brand new Samsung 245T LCD monitor the other day. The native
resolution of this 24" panel is 1920x1200.
I have been using the last free SNAP driver (3.1.8) for quite some time now to
drive my Matrox G450 video card (32 Meg) in 1600x1200 mode on my previous LCD -
Samsung 214T w/o any problems.
Now with the bigger monitor I wanted to move up to the 1920x1200 mode...however,
even though SNAP allows me to do it, when the display comes up the monitor is
interpretting it to actually be a weird 960x1200 resolution...subsequently it
attempts to stretch the display and gets it all distored.
The additional weird part in all of this is that the actual screen resolution
does increase to the new 1920x1200 - I see that my Desktop did get bigger and
there are more pixels available - but it's like the signalling coming out of the
video card has the WRONG info going to the monitor.
Just to rule out that it's NOT the monitor that's the problem I yanked the G450
card out of my OS2 box and ran it in my test Win2K machine...sure enough,
1920x1200 came up NO problem. I then switched to an ATI FireGL 8800 card on that
Win2K machine and that came up fine too.
So...it looks like I can't get 1920x1200 on my OS2 box...I've tried a bunch of
different things (including using the centering options of SNAP) and nothing is
working for me.
Did you run gamode.exe?

[e:\snap]gamode add 1920 1200 32 0
Mode 1920 x 1200 x 32 successfully added.

I have to do it to get BenQ 20" 1680x1050 working.
--
Hessu
Dariusz Piatkowski
2009-02-20 23:55:30 UTC
Permalink
Raw Message
Post by Heikki Kekki
On Fri, 20 Feb 2009 04:55:33 UTC, "Dariusz Piatkowski"
Post by Dariusz Piatkowski
I've got myself a fairly strange problem here.
I picked up a brand new Samsung 245T LCD monitor the other day. The native
resolution of this 24" panel is 1920x1200.
I have been using the last free SNAP driver (3.1.8) for quite some time now to
drive my Matrox G450 video card (32 Meg) in 1600x1200 mode on my previous LCD -
Samsung 214T w/o any problems.
Now with the bigger monitor I wanted to move up to the 1920x1200 mode...however,
even though SNAP allows me to do it, when the display comes up the monitor is
interpretting it to actually be a weird 960x1200 resolution...subsequently it
attempts to stretch the display and gets it all distored.
The additional weird part in all of this is that the actual screen resolution
does increase to the new 1920x1200 - I see that my Desktop did get bigger and
there are more pixels available - but it's like the signalling coming out of the
video card has the WRONG info going to the monitor.
Just to rule out that it's NOT the monitor that's the problem I yanked the G450
card out of my OS2 box and ran it in my test Win2K machine...sure enough,
1920x1200 came up NO problem. I then switched to an ATI FireGL 8800 card on that
Win2K machine and that came up fine too.
So...it looks like I can't get 1920x1200 on my OS2 box...I've tried a bunch of
different things (including using the centering options of SNAP) and nothing is
working for me.
Did you run gamode.exe?
[e:\snap]gamode add 1920 1200 32 0
Mode 1920 x 1200 x 32 successfully added.
I have to do it to get BenQ 20" 1680x1050 working.
I did NOT need to ADD the mode, it was already visible in the Screen object...so
it does NOT seem to be an issue surrounding the availability of the screen
resolution itself.

But..this does give me an idea...I will 'drop' that mode and add it back it...

Thanks!
Heiko Nitzsche
2009-02-20 14:17:30 UTC
Permalink
Raw Message
Post by Dariusz Piatkowski
So...it looks like I can't get 1920x1200 on my OS2 box...I've tried a bunch of
different things (including using the centering options of SNAP) and nothing is
working for me.
Are you using DVI port or Sub-D ?

If DVI is in use, I think 1920x1200 is beyond the normal DVI Single
Link capabilities the SNAP supported cards are usually equipped with.
In standard configuration with 60Hz the required data rate is exceeded.
The limit is at around 1600x1200 at 60Hz.

But in SNAP you can try the reduced timing mode via gaoption.exe.
This reduces the refresh rate to 50Hz which also reduces the data
rate for the DVI port and then it should be sufficient, at least
for 1920x1200. More is not possible with Single Link DVI.

Alternatively you can of course try the Sub-D connection if it
is good enough and does not smear the display.
Paul Smedley
2009-02-20 22:04:07 UTC
Permalink
Raw Message
Hi Heiko,

On Fri, 20 Feb 2009 14:17:30 UTC, Heiko Nitzsche
Post by Heiko Nitzsche
Post by Dariusz Piatkowski
So...it looks like I can't get 1920x1200 on my OS2 box...I've tried a bunch of
different things (including using the centering options of SNAP) and nothing is
working for me.
Are you using DVI port or Sub-D ?
If DVI is in use, I think 1920x1200 is beyond the normal DVI Single
Link capabilities the SNAP supported cards are usually equipped with.
In standard configuration with 60Hz the required data rate is exceeded.
The limit is at around 1600x1200 at 60Hz.
I use SNAP with an ATI X300 @ 1920x1200 with a single DVI & a 28"
viewsonic flat panel.....
--
Cheers,

Paul.
Dariusz Piatkowski
2009-02-21 00:11:39 UTC
Permalink
Raw Message
Paul,

On Fri, 20 Feb 2009 22:04:07 UTC, "Paul Smedley"
Post by Paul Smedley
Hi Heiko,
On Fri, 20 Feb 2009 14:17:30 UTC, Heiko Nitzsche
Post by Heiko Nitzsche
Post by Dariusz Piatkowski
So...it looks like I can't get 1920x1200 on my OS2 box...I've tried a bunch of
different things (including using the centering options of SNAP) and nothing is
working for me.
Are you using DVI port or Sub-D ?
If DVI is in use, I think 1920x1200 is beyond the normal DVI Single
Link capabilities the SNAP supported cards are usually equipped with.
In standard configuration with 60Hz the required data rate is exceeded.
The limit is at around 1600x1200 at 60Hz.
viewsonic flat panel.....
How is the image quality in 2D (typical OS/2 application)?

To be exact I'm curious how it compares to a Matrox G400/450, etc?

Thanks!
Heiko Nitzsche
2009-02-21 17:06:09 UTC
Permalink
Raw Message
Post by Paul Smedley
viewsonic flat panel.....
I was referring to single link DVI, not a single DVI port.
Earlier graphic cards had a single TMDS transmitter (which
is responsible for the data transfer). Current graphic cards
are equipped with dual link DVI which means that one DVI port
carries 2 data ports. This increases the possible data rate
and allows really big resolutions.

A single link DVI port can theoretically support 1920x1200 at
24bpp and 60Hz with reduced blanking (VESA CVT-RB -> Coordinated
Video Timing-Reduced Blanking - means shorter data window per bit).

But this is already close to the spec limits and as we all know,
being close limits usually means it may work or not ;), depending
on how good the mechanical design of the card is.

You can find more details about DVI specification for instance here:
http://en.wikipedia.org/wiki/Digital_Visual_Interface
Dariusz Piatkowski
2009-02-20 23:59:38 UTC
Permalink
Raw Message
Post by Heiko Nitzsche
Post by Dariusz Piatkowski
So...it looks like I can't get 1920x1200 on my OS2 box...I've tried a bunch of
different things (including using the centering options of SNAP) and nothing is
working for me.
Are you using DVI port or Sub-D ?
If DVI is in use, I think 1920x1200 is beyond the normal DVI Single
Link capabilities the SNAP supported cards are usually equipped with.
In standard configuration with 60Hz the required data rate is exceeded.
The limit is at around 1600x1200 at 60Hz.
But in SNAP you can try the reduced timing mode via gaoption.exe.
This reduces the refresh rate to 50Hz which also reduces the data
rate for the DVI port and then it should be sufficient, at least
for 1920x1200. More is not possible with Single Link DVI.
Alternatively you can of course try the Sub-D connection if it
is good enough and does not smear the display.
I am using Sub-D port for the very reason you mentioned....SNAP will only do up
to 1280x1024 with the Matrox G450 driver through DVI.

I'm trying to source another card to try a few things. So far I have tried the
Matrox P650 and G400...all show EXACTLY the same behaviour. I will look for a
decent AGP card next, sounds like ATI Radeon 9800 series get decent reviews.

Boy, sure is frustrating though...brand spankin' new hardware and no way to use
it...grrh...LOL.
Heiko Nitzsche
2009-02-21 17:23:17 UTC
Permalink
Raw Message
Post by Dariusz Piatkowski
I'm trying to source another card to try a few things. So far I have tried the
Matrox P650 and G400...all show EXACTLY the same behaviour. I will look for a
decent AGP card next, sounds like ATI Radeon 9800 series get decent reviews.
Try to get a SNAP supported ATI card (e.g. X300, X600, X800, X850) with at
least one DVI port. For these chipsets SNAP supports native panel programming
which removes the VESA BIOS restrictions. To my knowledge you can also mix DVI
and Sub-D port for dual screen setup or of cause use 2 DVI ports.

With DVI (digital) the image quality should be always the same. For Sub-D
(analog) the Matrox cards provided often better signal quality but with
DVI this no longer a differentiator.

I have a ATI X850XT with 2 CRTs connected running at 2980x1100x32bpp with Sub-D
and even with Sub-D the image quality is similar to my old Matrox G400. But
performance has dramatically increased, so don't stuck at the old Matrox!
Even my old ATI 9600XT was several times faster than the G400.
Dariusz Piatkowski
2009-02-22 15:20:25 UTC
Permalink
Raw Message
Heiko,
Post by Heiko Nitzsche
Post by Dariusz Piatkowski
I'm trying to source another card to try a few things. So far I have tried the
Matrox P650 and G400...all show EXACTLY the same behaviour. I will look for a
decent AGP card next, sounds like ATI Radeon 9800 series get decent reviews.
Try to get a SNAP supported ATI card (e.g. X300, X600, X800, X850) with at
least one DVI port. For these chipsets SNAP supports native panel programming
which removes the VESA BIOS restrictions. To my knowledge you can also mix DVI
and Sub-D port for dual screen setup or of cause use 2 DVI ports.
With DVI (digital) the image quality should be always the same. For Sub-D
(analog) the Matrox cards provided often better signal quality but with
DVI this no longer a differentiator.
I have a ATI X850XT with 2 CRTs connected running at 2980x1100x32bpp with Sub-D
and even with Sub-D the image quality is similar to my old Matrox G400. But
performance has dramatically increased, so don't stuck at the old Matrox!
Even my old ATI 9600XT was several times faster than the G400.
Thanks, that's excellent information.

I have been eye-balling the 9800 series cards on eBay...but it looks like the
X800 stuff is better performing, and if the SNAP support is of same quality for
both I might as well pick up the X800 stuff.

How 'complete' is the SNAP support for the X800 stuff??? Have you run into any
problems, issues?

Out of curiosity, have you done any benchmarks on your X850XT? I used SNAP's
gaperf utility to benchmark my Matrox cards and the G400 came out on top, even
in comparison to the G450 & P650...apparently no further optimizations were done
beyond the original G400 engine.
Heiko Nitzsche
2009-02-22 16:53:03 UTC
Permalink
Raw Message
Post by Dariusz Piatkowski
I have been eye-balling the 9800 series cards on eBay...but it looks like the
X800 stuff is better performing, and if the SNAP support is of same quality for
both I might as well pick up the X800 stuff.
The 9800 series is still a good choice if you just need 2D and no
powerful 3D support. Please see below where I also added Sysbench
results from my previous 9600XT card which is performance wise
relatively close to the 9800.
Post by Dariusz Piatkowski
How 'complete' is the SNAP support for the X800 stuff??? Have you run into any
problems, issues?
The X850 is fully supported except some minor issue. DOS boxes and WinOS/2
do no longer work because of a driver timing issue (probably the card is
too fast ;) ). Don't know if this also applies to the X800. For me its not
an issue as I don't need WinOS/2 (I even disabled it in config.sys).
If I need some DOS, I use DosBox/2 which also provides sound while standard
DOS box does not anymore.

My previous 9600XT did not have any limitation of this kind, so I guess
the 9800 would work similar.

You should check for reviews about the card in focus to validate analog
signal quality. It might differ significantly between manufacturers.
I you just need DVI, this doesn't matter.
Post by Dariusz Piatkowski
Out of curiosity, have you done any benchmarks on your X850XT? I used SNAP's
gaperf utility to benchmark my Matrox cards and the G400 came out on top, even
in comparison to the G450 & P650...apparently no further optimizations were done
beyond the original G400 engine.
Yes, I did some benchmarks. The tables below are captured with Sysbench 0.9.5
on Athlon64 3000+ So754 and VIA K8T800 chipset. I only have the Matrox results
from older Sysbench release and older SNAP SE driver. So you need to measure
yourself to get reasonable results for comparison. Initially my Matrox was on
an old Athlon 700 mainboard but after buying the Athlon64 board I also tried
it there. There was no measurable improvement. So either the chipsets didn't
like each other or the Matrox is just slow. I was not able to activate AGP
fastwrites on the G400 which may have contributed to the problem.


Resolution for the test below: 1456x1100x32 bits/pixel (1 display active)


This list is for Radeon 9600XT (Sapphire) with SNAP 3.1.3:
==========================================================
Graphics
BitBlt S->S copy : 910.453 Million pixels/second
BitBlt M->S copy : 247.681 Million pixels/second
Filled Rectangle : 2786.156 Million pixels/second
Pattern Fill : 2635.718 Million pixels/second
Vertical Lines : 101.567 Million pixels/second
Horizontal Lines : 1314.699 Million pixels/second
Diagonal Lines : 24.738 Million pixels/second
Text Render : 402.641 Million pixels/second
-----------------------------------------------------------------------
Total : 465.442 PM-Graphics-marks

Direct Interface to video extensions - DIVE
Video bus bandwidth : 1006.153 Megabytes/second
DIVE fun : 3433.300 fps normalised to 640x480x256
M->S, DD, 1.00:1 : 3434.581 fps normalised to 640x480x256
-----------------------------------------------------------------------
Total : 1283.628 DIVE-marks


This list is for Radeon X850XT (XpertVision) with SNAP 3.1.8:
=============================================================
Graphics
BitBlt S->S copy : 1600.103 Million pixels/second
BitBlt M->S copy : 247.636 Million pixels/second
Filled Rectangle : 3445.512 Million pixels/second
Pattern Fill : 3292.939 Million pixels/second
Vertical Lines : 169.984 Million pixels/second
Horizontal Lines : 1643.227 Million pixels/second
Diagonal Lines : 26.313 Million pixels/second
Text Render : 404.941 Million pixels/second
-----------------------------------------------------------------------
Total : 583.189 PM-Graphics-marks

Direct Interface to video extensions - DIVE
Video bus bandwidth : 1004.032 Megabytes/second
DIVE fun : 3426.706 fps normalised to 640x480x256
M->S, DD, 1.00:1 : 3428.264 fps normalised to 640x480x256
-----------------------------------------------------------------------
Total : 1281.181 DIVE-marks


As you can see, 2D performance did increase from 9600 to X850 but not that
much. Important is that you get the AGP Fast Write mode active (info can
be found in SNAP's graphics.log). If it is not active performance will
significantly drop. If it is not active by default you can enable it with
gaoption.exe. After a reboot you should the see in the log file if it was
activated.

A X800/X850 as PCI Express version probably is even faster for DIVE.
But the above is more than enough. I can look TV with HW-Overlay in Emperoar
TV, play a DVD and surf the internet in parallel without any big slowdown.
With the G400 I was only able to play a DVD but I couldn't work much beside,
also I had to reduce color depth to 16bpp to get 2D performance somehow snappy.
Steve Wendt
2009-02-23 00:28:11 UTC
Permalink
Raw Message
Post by Heiko Nitzsche
The X850 is fully supported except some minor issue. DOS boxes and WinOS/2
do no longer work because of a driver timing issue (probably the card is
too fast ;) ).
It's not a timing issue, it's due to an incompatibility with IBM's
VSVGA.SYS. ATI changed their cards numerous times, and IBM never did a
very good job keeping up (they eventually got most ATI cards working
with DOS boxes, but it took many bug reports).
Post by Heiko Nitzsche
Don't know if this also applies to the X800.
For what it's worth, DOS boxes work fine on my X800.
Rich Wonneberger
2009-02-23 03:44:11 UTC
Permalink
Raw Message
Steve,

Does it work for both windowed and full screen?
How about sound in both?

TIA
Rich W.
Post by Steve Wendt
Post by Heiko Nitzsche
Don't know if this also applies to the X800.
For what it's worth, DOS boxes work fine on my X800.
Steve Wendt
2009-02-23 04:38:01 UTC
Permalink
Raw Message
Post by Rich Wonneberger
Post by Steve Wendt
For what it's worth, DOS boxes work fine on my X800.
Does it work for both windowed and full screen?
Yes.
Post by Rich Wonneberger
How about sound in both?
That's a function of the sound driver. I'm currently using UniAud,
which doesn't offer anything in that area.
Peter Brown
2009-02-23 14:34:48 UTC
Permalink
Raw Message
Hi
Post by Rich Wonneberger
Steve,
Does it work for both windowed and full screen?
How about sound in both?
TIA
Rich W.
Post by Steve Wendt
Post by Heiko Nitzsche
Don't know if this also applies to the X800.
For what it's worth, DOS boxes work fine on my X800.
If using Uniaud as the sound driver the only chance you have of sound
with DOS sessions is not to run the IBM DOS window/fullscreen sessions
but to use DOSBox instead.

That works so well here that for my eCS2.0RC6a installations I did Not
install Dos/Win3 support and use DOSBox for those functions.

I must admit that I only run a few old DOS games from time to time but
it is nice to have game sounds :-)


Regards

Pete
Allan
2009-02-24 00:43:37 UTC
Permalink
Raw Message
Post by Steve Wendt
Post by Heiko Nitzsche
The X850 is fully supported except some minor issue. DOS boxes and WinOS/2
do no longer work because of a driver timing issue (probably the card is
too fast ;) ).
It's not a timing issue, it's due to an incompatibility with IBM's
VSVGA.SYS. ATI changed their cards numerous times, and IBM never did a
very good job keeping up (they eventually got most ATI cards working
with DOS boxes, but it took many bug reports).
Post by Heiko Nitzsche
Don't know if this also applies to the X800.
For what it's worth, DOS boxes work fine on my X800.
Doesn't X800 use the dreaded ATOM bios from ATI ?
My X700 with ATOM bios doesn't work with window'ed
DOS sessions. Now fullscreen doesn't work either, because
of ACPI driver, so I guess we never gets DOS back again.

But I am surprised, if your X800 has ATOM bios and works.
--
Allan.

It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Steve Wendt
2009-02-24 05:07:05 UTC
Permalink
Raw Message
Post by Allan
Post by Steve Wendt
For what it's worth, DOS boxes work fine on my X800.
Doesn't X800 use the dreaded ATOM bios from ATI ?
Yes, it uses the ATOM BIOS. What makes it "dreaded?" The windowed DOS
session failures are unrelated to that.
Post by Allan
Now fullscreen doesn't work either, because
of ACPI driver, so I guess we never gets DOS back again.
Some people talk about the ACPI driver as a panacea, but I sometimes
wonder if it doesn't cause more problems than it solves.
Doug Bissett
2009-02-24 18:08:32 UTC
Permalink
Raw Message
Post by Steve Wendt
Post by Allan
Post by Steve Wendt
For what it's worth, DOS boxes work fine on my X800.
Doesn't X800 use the dreaded ATOM bios from ATI ?
Yes, it uses the ATOM BIOS. What makes it "dreaded?" The windowed DOS
session failures are unrelated to that.
I am not sure what BIOS it uses, but the ATI video adapter on my new
Asus M3A78-EM motherboard, works with DOS, and Win16, in full screen
mode (SNAP 3.18, as supplied by eCS 2.0 RC6a, running in VESA VBE 2.0
mode). If I attempt to open a DOS window, it complains that the system
doesn't support the video mode in a window. If I open a Win16 window,
I see the same message as for DOS, but the Win16 window opens, and
seems to be completely operational. I haven't bothered to try to
figure out what the DOS window is complaining about. I also haven't
got around to trying it with the Panorama driver. I don't use that,
simply because it will not allow Doodle's Screen Saver to power off
the screen. That bug needs to be fixed in Panorama, before it will be
well accepted.
Post by Steve Wendt
Post by Allan
Now fullscreen doesn't work either, because
of ACPI driver, so I guess we never gets DOS back again.
Some people talk about the ACPI driver as a panacea, but I sometimes
wonder if it doesn't cause more problems than it solves.
I am using the ACPI driver, known as 3.14, with APM at 1.28. I agree
that the ACPI driver is not all that it is supposed to be.
Unfortunately, the manufacturers are removing a lot of older BIOS
code, and some things just won't work without ACPI support. SMP is not
one of those things, since the older OS2APIC.PSD will run SMP, in a
lot of (if not all) cases. The old APM support will also work
(sometimes not correctly, since it seems to be no longer maintained),
as long as the APM support code is still in the BIOS (becoming less
common).

The main problem, with ACPI, seems to be, that the specification is so
poorly written, that nobody can figure it out. That means that every
company, and every model, has a different set of rules, which means
that the ACPI code needs to be customized to handle what is in each
model. That is never going to be possible, because there are too many,
and the coders cannot get their hands on every model, to see what
needs to be doe to make it work. It appears that both Windows, and
Linux, have totally ignored what the manufacturers put into BIOS
(which doesn't encourage them to fix the problems), and do it all
themselves. In OS/2, they are trying to use the defective junk, that
is found in the BIOS. There is little doubt about why they are having
problems with it.

To reinforce your theory, that ACPI causes more problems than it
solves: I just got an update, known as ACPI-APIC-BAT.ZIP. It is a test
version of the 3.14 ACPI. It seems to work, exactly the same as the
official 3.14 version, for me, with one exception. If I try to open a
windows 2000 system, in Virtual PC (5.1), I get a Trap008 (which I
can't get information for, because, shortly after the trap message
shows, the screen displays some meaningless junk, and freezes. Going
back to the "official" v3.14, and VPC works again. I didn't try
anything except win2K, but the failure is so early in the sequence,
that I doubt if it matters. I still need to get around to reporting
that to the developers.
--
From the eComStation 2.0 RC6a of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
Steve Wendt
2009-02-25 03:00:30 UTC
Permalink
Raw Message
Post by Doug Bissett
If I attempt to open a DOS window, it complains that the system
doesn't support the video mode in a window.
You (and others with such problems) can try experimenting with some of
the switches for vsvga.sys:

/PCITRAP=08-0F /PCITRAP=10-2F /PCITRAP=E0-F3 /PCITRAP-F8-FB /PCITRAP=100-113

Try them individually and/or all together, and hopefully you'll find
something that works.
Post by Doug Bissett
I also haven't got around to trying it with the Panorama driver.
It won't behave any differently, as long as it is the same vsvga.sys.
Post by Doug Bissett
Linux, have totally ignored what the manufacturers put into BIOS
(which doesn't encourage them to fix the problems), and do it all
themselves. In OS/2, they are trying to use the defective junk, that
is found in the BIOS. There is little doubt about why they are having
problems with it.
The fact that the OS/2 code is closed source, and unnecessarily
restricted to eComstation, are both inhibitors. They tried claiming
that it was closed source because of the Intel license, but that is a
bogus argument - Intel licenses it under the GPL for Linux.
Doug Bissett
2009-02-25 16:24:27 UTC
Permalink
Raw Message
Post by Steve Wendt
Post by Doug Bissett
If I attempt to open a DOS window, it complains that the system
doesn't support the video mode in a window.
You (and others with such problems) can try experimenting with some of
/PCITRAP=08-0F /PCITRAP=10-2F /PCITRAP=E0-F3 /PCITRAP-F8-FB /PCITRAP=100-113
Try them individually and/or all together, and hopefully you'll find
something that works.
I am not really sure, that I care, but I will give it a try, just to
see what happens. My install of eCS 2.0 GA will, likely, be without
DOS and Win16, enabled...
Post by Steve Wendt
Post by Doug Bissett
I also haven't got around to trying it with the Panorama driver.
It won't behave any differently, as long as it is the same vsvga.sys.
Okay, that saves me a lot of time...
Post by Steve Wendt
Post by Doug Bissett
Linux, have totally ignored what the manufacturers put into BIOS
(which doesn't encourage them to fix the problems), and do it all
themselves. In OS/2, they are trying to use the defective junk, that
is found in the BIOS. There is little doubt about why they are having
problems with it.
The fact that the OS/2 code is closed source, and unnecessarily
restricted to eComstation, are both inhibitors. They tried claiming
that it was closed source because of the Intel license, but that is a
bogus argument - Intel licenses it under the GPL for Linux.
I think that Mensys is paying them to do the code, so that is probably
the main reason why ACPI is eCS only, and it would be closed source
because of that , and the desire of the coders to make a few bucks off
of it. I suspect that somebody should be looking at porting the Linux
version, since it seems to be working, and there is actually little
hope that the current ACPI for eCS will ever work properly.
--
From the eComStation 2.0 RC6a of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
Doug Bissett
2009-02-26 01:44:00 UTC
Permalink
Raw Message
On Wed, 25 Feb 2009 16:24:27 UTC, "Doug Bissett"
Post by Doug Bissett
Post by Steve Wendt
/PCITRAP=08-0F /PCITRAP=10-2F /PCITRAP=E0-F3 /PCITRAP-F8-FB
/PCITRAP=100-113
Post by Doug Bissett
Post by Steve Wendt
Try them individually and/or all together, and hopefully you'll find
something that works.
I am not really sure, that I care, but I will give it a try, just to
see what happens.
I tried all together. No difference, at all.

I also tried DOS on my Acer Aspire 4720 laptop. DOS starts, the window
opens, and it says something about Divide by zero error, a few million
times, before I stopped it. That was without ACPI.PSD. I am using
OS2APIC.PSD in that thing, so I can use the wired NIC.
--
From the eComStation 2.0 RC6a of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
Allan
2009-02-25 16:57:53 UTC
Permalink
Raw Message
Post by Steve Wendt
You (and others with such problems) can try experimenting with some of
/PCITRAP=08-0F /PCITRAP=10-2F /PCITRAP=E0-F3 /PCITRAP-F8-FB /PCITRAP=100-113
Try them individually and/or all together, and hopefully you'll find
something that works.
Thanx for this idea to test.
I tried all individually, and all together.
Result was the same - windowed DOS box hangs.

If I use a debug kernel, I get a TRAP 0 instead:

Trap 0 - Divide Error Exception
eax=0000c350 ebx=00000000 ecx=000000ff edx=00000000 esi=0000bd62 edi=00000000
eip=000027cc esp=000002d4 ebp=000002d8 iopl=0 rf vm -- nv up ei pl zr na pe nc
cs=c000 ss=9f0c ds=c000 es=0000 fs=0000 gs=0000 cr2=000bf000 cr3=0021f000 p=00
c000:000027cc 66f7f7 div edi
c000:fff40000 gradd:SEG2:_StartInitCode + c27cc
--
Allan.

It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Allan
2009-02-25 18:07:37 UTC
Permalink
Raw Message
Post by Steve Wendt
Post by Doug Bissett
If I attempt to open a DOS window, it complains that the system
doesn't support the video mode in a window.
You (and others with such problems) can try experimenting with some of
/PCITRAP=08-0F /PCITRAP=10-2F /PCITRAP=E0-F3 /PCITRAP-F8-FB /PCITRAP=100-113
Just tried to start a fullscreen DOS, and then switch it to Window mode.
This actually works, to my surprise.
--
Allan.

It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
James J. Weinkam
2009-02-25 21:01:13 UTC
Permalink
Raw Message
Post by Allan
Post by Steve Wendt
Post by Doug Bissett
If I attempt to open a DOS window, it complains that the system
doesn't support the video mode in a window.
You (and others with such problems) can try experimenting with some of
/PCITRAP=08-0F /PCITRAP=10-2F /PCITRAP=E0-F3 /PCITRAP-F8-FB /PCITRAP=100-113
Just tried to start a fullscreen DOS, and then switch it to Window mode.
This actually works, to my surprise.
I get the same behavior here. The last few new computers I have acquired have
been unable to run DOS (or WIN) windowed sessions. Regardless of how a DOS
windowed session is launched, A normal sized window appears briefly then
disappears and reappears as a 1 line window. A pop up message window then
appears with the message that the system is unable to support the session's
video mode in a window. Upon dismissing the message, the one line window gets
focus. Attempting to type appears to do nothing, but Alt-Home switches to
fullscreen and anything that was typed appears on the command line. It had
never occurred to me to try switching back to windowed mode.

The fact that the windowed session works fine after going through these
maneuvers shows that there is nothing fundamentally wrong with the video
device or its drivers; rather there must be some sort of configuration problem
in the windowed DOS object or a bug in the code that launches windowed DOS and
WINOS2 sessions. Once the windowed session is working, the DOS settings that
can be examined and changed dynamically are still the same as those of the DOS
window object.

Additional experiments revealed that the time it takes to switch from
fullscreen to windowed using Alt-Home varies depending on what else is on the
desktop at the time. If there is nothing else on the desktop or only open
folders, the switch is virtually instantaneous; however if there are any open
sessions, even minimized, then the switch requires about 10 seconds.
Marty
2009-02-25 22:00:15 UTC
Permalink
Raw Message
Post by James J. Weinkam
The fact that the windowed session works fine after going through these
maneuvers shows that there is nothing fundamentally wrong with the video
device or its drivers; rather there must be some sort of configuration
problem in the windowed DOS object or a bug in the code that launches
windowed DOS and WINOS2 sessions. Once the windowed session is working,
the DOS settings that can be examined and changed dynamically are still
the same as those of the DOS window object.
My guess would be that the video BIOS starts up the video hardware in a
really weird mode. OS/2 will call the BIOS routine and emulate as many
functions and modes as it supports in VSVGA.SYS when you start the DOS
session. If during this process, an unsupported video mode or video
BIOS call is used, OS/2 will halt the DOS session until you switch to
full screen mode. When you do, the video BIOS is free to run on real
hardware, and probably transitions through this unsupported mode back
into the standard 80x25 text mode. Once you reach this standard mode,
it's ok to switch back to windowed mode because OS/2 can support it.

A similar thing happens when you play some old DOS games which do some
strange programming directly to the video hardware, or some SVGA games.
The unusual thing here is that the strange mode is encountered before
you even get out of the initial base video handler.
Post by James J. Weinkam
Additional experiments revealed that the time it takes to switch from
fullscreen to windowed using Alt-Home varies depending on what else is
on the desktop at the time. If there is nothing else on the desktop or
only open folders, the switch is virtually instantaneous; however if
there are any open sessions, even minimized, then the switch requires
about 10 seconds.
Is your CPU pegged during this time? Is the DOS window itself
constantly consuming CPU time? It sounds like your DOS priority and
idle sensitivity settings may need to be adjusted.
--
[Reverse the parts of the e-mail address to reply.]
James J. Weinkam
2009-02-25 23:56:14 UTC
Permalink
Raw Message
Post by Marty
Post by James J. Weinkam
The fact that the windowed session works fine after going through
these maneuvers shows that there is nothing fundamentally wrong with
the video device or its drivers; rather there must be some sort of
configuration problem in the windowed DOS object or a bug in the code
that launches windowed DOS and WINOS2 sessions. Once the windowed
session is working, the DOS settings that can be examined and changed
dynamically are still the same as those of the DOS window object.
My guess would be that the video BIOS starts up the video hardware in a
really weird mode. OS/2 will call the BIOS routine and emulate as many
functions and modes as it supports in VSVGA.SYS when you start the DOS
session. If during this process, an unsupported video mode or video
BIOS call is used, OS/2 will halt the DOS session until you switch to
full screen mode. When you do, the video BIOS is free to run on real
hardware, and probably transitions through this unsupported mode back
into the standard 80x25 text mode. Once you reach this standard mode,
it's ok to switch back to windowed mode because OS/2 can support it.
I don't see why this should be a problem. As I understand it, there is a
component of OS/2 called a virtual DOS machine that emulates a standalone PC
running some version of DOS. It is reenterable allowing several DOS sessions
to run simultaneously. Each VDM instance can be in either fullscreen or
windowed mode. It seems to me that it would be instances running in fullscreen
mode that would get into trouble trying to deal directly with the latest
hardware, while the windowed sessions would only have problems if other OS/2
VIO sessions also had similar trouble since the emulator displays in the
window using the same standard os/2 API calls that other VIO sessions use. Is
this true or am I missing something?
Post by Marty
A similar thing happens when you play some old DOS games which do some
strange programming directly to the video hardware, or some SVGA games.
The unusual thing here is that the strange mode is encountered before
you even get out of the initial base video handler.
Post by James J. Weinkam
Additional experiments revealed that the time it takes to switch from
fullscreen to windowed using Alt-Home varies depending on what else is
on the desktop at the time. If there is nothing else on the desktop or
only open folders, the switch is virtually instantaneous; however if
there are any open sessions, even minimized, then the switch requires
about 10 seconds.
Is your CPU pegged during this time? Is the DOS window itself
constantly consuming CPU time? It sounds like your DOS priority and
idle sensitivity settings may need to be adjusted.
Can't tell because in fullscreen mode the CPU meter doesn't appear. However,
investigation revealed that that was the reason for the slow switch from
fullscreen to windowed. I forgot to set idle seconds and idle sensitivity
after installing RC6a. I hadn't noticed until now since I normally launch the
few DOS applications that I still use from ZTree using startd, and idle
seconds and idle sensitivity are properly set for those sessions from startd's
DOS.INI file. For the current round of experiments I was clicking on the
objects in the command prompts folder which I don't normally do.
Marty
2009-02-26 19:23:55 UTC
Permalink
Raw Message
Post by James J. Weinkam
Post by Marty
Post by James J. Weinkam
The fact that the windowed session works fine after going through
these maneuvers shows that there is nothing fundamentally wrong with
the video device or its drivers; rather there must be some sort of
configuration problem in the windowed DOS object or a bug in the code
that launches windowed DOS and WINOS2 sessions. Once the windowed
session is working, the DOS settings that can be examined and changed
dynamically are still the same as those of the DOS window object.
My guess would be that the video BIOS starts up the video hardware in
a really weird mode. OS/2 will call the BIOS routine and emulate as
many functions and modes as it supports in VSVGA.SYS when you start
the DOS session. If during this process, an unsupported video mode or
video BIOS call is used, OS/2 will halt the DOS session until you
switch to full screen mode. When you do, the video BIOS is free to
run on real hardware, and probably transitions through this
unsupported mode back into the standard 80x25 text mode. Once you
reach this standard mode, it's ok to switch back to windowed mode
because OS/2 can support it.
I don't see why this should be a problem. As I understand it, there is a
component of OS/2 called a virtual DOS machine that emulates a
standalone PC running some version of DOS. It is reenterable allowing
several DOS sessions to run simultaneously. Each VDM instance can be in
either fullscreen or windowed mode. It seems to me that it would be
instances running in fullscreen mode that would get into trouble trying
to deal directly with the latest hardware, while the windowed sessions
would only have problems if other OS/2 VIO sessions also had similar
trouble since the emulator displays in the window using the same
standard os/2 API calls that other VIO sessions use. Is this true or am
I missing something?
My understanding, which may be mistaken, is that the video BIOS is
called whether you're in a windowed or full screen session. Direct
hardware access is trapped by OS/2, which conditionally provides its own
windowed emulation of the function attempted (if such an emulation of
the function exists in OS/2) or allows access to the hardware if the
session is full screen. If there is no emulation of the function
attempted provided within OS/2, and the session is in windowed mode, the
session will be frozen and you will receive the message that you
received. Not an issue in full screen since direct hardware access is
granted there. But the main issue is that in the process of
initializing a new session, some non-emulated access is attempted by
some piece of code that is running. My guess is that it is actually in
the video BIOS code itself, which I believe does execute in the new
session, albiet with direct hardware access trapped by the OS.

(Am I close on this, Steve?) :-)
Post by James J. Weinkam
Post by Marty
A similar thing happens when you play some old DOS games which do some
strange programming directly to the video hardware, or some SVGA
games. The unusual thing here is that the strange mode is encountered
before you even get out of the initial base video handler.
Post by James J. Weinkam
Additional experiments revealed that the time it takes to switch from
fullscreen to windowed using Alt-Home varies depending on what else
is on the desktop at the time. If there is nothing else on the
desktop or only open folders, the switch is virtually instantaneous;
however if there are any open sessions, even minimized, then the
switch requires about 10 seconds.
Is your CPU pegged during this time? Is the DOS window itself
constantly consuming CPU time? It sounds like your DOS priority and
idle sensitivity settings may need to be adjusted.
Can't tell because in fullscreen mode the CPU meter doesn't appear.
However, investigation revealed that that was the reason for the slow
switch from fullscreen to windowed. I forgot to set idle seconds and
idle sensitivity after installing RC6a. I hadn't noticed until now since
I normally launch the few DOS applications that I still use from ZTree
using startd, and idle seconds and idle sensitivity are properly set for
those sessions from startd's DOS.INI file. For the current round of
experiments I was clicking on the objects in the command prompts folder
which I don't normally do.
Glad that seems to be sorted at least.
--
[Reverse the parts of the e-mail address to reply.]
Steve Wendt
2009-02-26 19:37:26 UTC
Permalink
Raw Message
Post by Marty
My understanding, which may be mistaken, is that the video BIOS is
called whether you're in a windowed or full screen session. Direct
hardware access is trapped by OS/2, which conditionally provides its own
windowed emulation of the function attempted (if such an emulation of
the function exists in OS/2) or allows access to the hardware if the
session is full screen.
(Am I close on this, Steve?) :-)
That sounds right to me, but I'm no expert on that.
Allan
2009-02-24 18:47:21 UTC
Permalink
Raw Message
Post by Steve Wendt
Post by Allan
Post by Steve Wendt
For what it's worth, DOS boxes work fine on my X800.
Doesn't X800 use the dreaded ATOM bios from ATI ?
Yes, it uses the ATOM BIOS. What makes it "dreaded?"
Well, basicly that most people seems to have problems with
SNAP for all the newer ATI cards using ATOM bios.
Post by Steve Wendt
The windowed DOS session failures are unrelated to that.
Well, the DOS window failuers only happens for this card, not
any of my older ones.
Post by Steve Wendt
Post by Allan
Now fullscreen doesn't work either, because
of ACPI driver, so I guess we never gets DOS back again.
Some people talk about the ACPI driver as a panacea, but I sometimes
wonder if it doesn't cause more problems than it solves.
Well, that is the punishment for running in apic mode - but at least they
are trying to create a solution for this. Anyway, I can remove ACPI
driver if I needed a DOS fullscreen; but I have to change videocard
to get a DOS window :-/
--
Allan.

It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Steve Wendt
2009-02-25 03:03:38 UTC
Permalink
Raw Message
Post by Allan
Well, the DOS window failuers only happens for this card, not
any of my older ones.
That's only because of numerous updates to VSVGA.SYS; see how many times
you can find "DOS windows" next to "ATI" or "Radeon" in this:
http://www.scitechsoft.com/snap2_changes.txt
Post by Allan
but I have to change videocard to get a DOS window :-/
See my other post, if you want to experiment. Otherwise, DOSBox is one
option already mentioned. ;-)
Ilya Zakharevich
2009-02-27 03:10:53 UTC
Permalink
Raw Message
[Sorry, can't answer older postings...]

Just one reference point: yesterday ATI Radeon 9600se arrived. With
DVI, it was immediately recognized as supporting 1920x1200, and I did
not need any tinkering with "reduced DVI timing". (SNAP still has
some problems, but none so far with DOS boxes...)

(I do not know how to QUERY the current state of "reduced DVI
timing"; neither by gaoption, nor by looking in the graphics
LOG....)

Yours,
Ilya
Heiko Nitzsche
2009-03-01 16:30:25 UTC
Permalink
Raw Message
Post by Ilya Zakharevich
(I do not know how to QUERY the current state of "reduced DVI
timing"; neither by gaoption, nor by looking in the graphics
LOG....)
Try: gaoption show

Here is what I get (2 CRTs connected):

Options for ATI Radeon X850 Series (device 0):

Invert .................. Off
Rotation ................ Off
Flipped ................. Off
Reduced DVI Timings...... Off <- look here
Prefer 16 bit per pixel.. On
Prefer 32 bit per pixel.. On
Compressed Framebuffer... On
Allow DDC BIOS........... On
PCI bus mastering........ On
Video memory packets..... On
Hardware acceleration.... Full
Multi Head Display....... Yes
0: 1456 x 1100 ( 0, 0,1456,1100)
1: 1456 x 1100 (1456, 0,2912,1100)
VESA DPVL Mode........... Off

Global options for all devices:

Force VBE Fallback ...... Off
Force VGA Fallback ...... Off
Allow non-certified ..... Off
Disable write combining . Off
Use BIOS for LCD panel... Auto
Video Memory Limit....... 64 Mb
Shared AGP memory size... 4096 Kb
Use system memory driver. Off
Disable DDC detection.... On
Enable AGP FastWrite..... On
Maximum AGP data rate.... 8X
Virtual Display.......... Off
Ilya Zakharevich
2009-03-02 07:48:49 UTC
Permalink
Raw Message
Post by Heiko Nitzsche
Post by Ilya Zakharevich
(I do not know how to QUERY the current state of "reduced DVI
timing"; neither by gaoption, nor by looking in the graphics
LOG....)
Try: gaoption show
Result: complete freeze of the video. (Mouse pointer just "shakes"
around the current location when I move [USB] mouse; reboot succeded,
no disk cleanup needed on restart.)

Fortunately, all multi-days jobs I was running at the moment were
restartable... ;-)

Thanks,
Ilya
Ilya Zakharevich
2009-03-15 05:40:38 UTC
Permalink
Raw Message
Post by Ilya Zakharevich
Post by Heiko Nitzsche
Post by Ilya Zakharevich
(I do not know how to QUERY the current state of "reduced DVI
timing"; neither by gaoption, nor by looking in the graphics
LOG....)
Try: gaoption show
Result: complete freeze of the video.
(I got a couple more freezes that day before REAL power-cycle, so it
may be not directly related to SNAP, but an intermittent hardware problem.)

I rechecked it now, and it does not need reduced timing to serve
***@60Hz. I seriously doubt your statement that one needs
something special to run 1920x1200. IIRC, double-feed is needed only
for something like 2560x1440 or some such...

Options for ATI Radeon 9600 Series (device 0):

Invert .................. Off
Rotation ................ Off
Flipped ................. Off
Reduced DVI Timings...... Off
...

Hope this helps,
Ilya
Dariusz Piatkowski
2009-03-15 15:03:16 UTC
Permalink
Raw Message
Post by Ilya Zakharevich
I rechecked it now, and it does not need reduced timing to serve
something special to run 1920x1200. IIRC, double-feed is needed only
for something like 2560x1440 or some such...
Invert .................. Off
Rotation ................ Off
Flipped ................. Off
Reduced DVI Timings...... Off
...
Hope this helps,
Ilya
See my response to Heiko, I think the problem seems to stem from either the
WRONG EDID info the Samsung 245T LCD is returning, or the SNAP driver
incorrectly decoding the info.

I agree with you, I do not think that anything special is required to get
1920x1200 running. Win2k/XP is doing it just fine...so they are able to either
deal with the incorrect EDID panel info, or those drivers are interpreting the
info correctly as opposed to SNAP.
Steve Wendt
2009-03-15 19:52:15 UTC
Permalink
Raw Message
Post by Ilya Zakharevich
I rechecked it now, and it does not need reduced timing to serve
something special to run 1920x1200. IIRC, double-feed is needed only
for something like 2560x1440 or some such...
There's some good info on reduced blanking here:
http://www.playtool.com/pages/dvicompat/dvi.html

I'm pretty sure the old Matrox cards can't do DVI output at 1920x1200,
although they can do analog output at that resolution.
Ilya Zakharevich
2009-03-16 09:33:25 UTC
Permalink
Raw Message
Post by Steve Wendt
Post by Ilya Zakharevich
I rechecked it now, and it does not need reduced timing to serve
something special to run 1920x1200. IIRC, double-feed is needed only
for something like 2560x1440 or some such...
http://www.playtool.com/pages/dvicompat/dvi.html
Note that according to them, one needs a dual link for 1920x1080!
Hmm, maybe dual link is "just implemented" in my Radeon (and monitor)?
Do not expect so... Linked from your reference is

http://www.extremetech.com/article2/0,2845,1367923,00.asp

where they say that 9600 is good at 162MHz (and 193MHz is needed for
1920x1200)...

Thanks,
Ilya
Heiko Nitzsche
2009-03-16 20:34:27 UTC
Permalink
Raw Message
Post by Ilya Zakharevich
Post by Steve Wendt
http://www.playtool.com/pages/dvicompat/dvi.html
Note that according to them, one needs a dual link for 1920x1080!
Hmm, maybe dual link is "just implemented" in my Radeon (and monitor)?
Do not expect so... Linked from your reference is
http://www.extremetech.com/article2/0,2845,1367923,00.asp
where they say that 9600 is good at 162MHz (and 193MHz is needed for
1920x1200)...
Please have again a look at the description Steve sent.
There is a table showing the possibilities for 1920x1200 at 60Hz:

Dual Link @ 193 MHz (2 links, each at 96.5 MHz)
1920 X 1200 Standard blanking DVI pixel clock

Single Link @ 154 Mhz
1920 X 1200 Reduced blanking DVI pixel clock

The limit frequency according to the spec is 165 MHz per DVI link.
So your setup must run in reduced blanking mode.

Good driver should automatically detect this. As it works
fine for most of you, SNAP obviously does it right most
of the time ;) .

According to the article there are differences between cards and
their DVI implementation which may or may not reach the 165 MHz.

So be happy that it works fine for you ;)
Ilya Zakharevich
2009-03-16 23:31:39 UTC
Permalink
Raw Message
Post by Heiko Nitzsche
Please have again a look at the description Steve sent.
1920 X 1200 Standard blanking DVI pixel clock
1920 X 1200 Reduced blanking DVI pixel clock
As I said, SNAP shows:

Reduced DVI Timings...... Off

If "timing" is the same as "blanking", this would exclude the second
possibility. And a cursory look on google shows double-link present
on Radeon 9600 only in "Pro" variant. And mine IIRC is SE.

Checking.... Yes, the order says SE, and a search for

dvi dual-link radeon 9600SE OR 9600/SE

returns nothing...
Post by Heiko Nitzsche
According to the article there are differences between cards and
their DVI implementation which may or may not reach the 165 MHz.
AFAIU, the article contradicts the experience. I would just ignore it
(unless proven otherwise).

Hope this helps,
Ilya
Steve Wendt
2009-03-17 03:31:45 UTC
Permalink
Raw Message
Post by Ilya Zakharevich
Hmm, maybe dual link is "just implemented" in my Radeon (and monitor)?
Could be.
Post by Ilya Zakharevich
http://www.extremetech.com/article2/0,2845,1367923,00.asp
where they say that 9600 is good at 162MHz
Under 'Testbed Setup' they say they are testing 1600x1200, which is near
the upper limit for a single TMDS (165MHz). They are saying it passes
their testing for that resolution, not that 162MHz is the upper limit.
Ilya Zakharevich
2009-03-17 05:53:51 UTC
Permalink
Raw Message
Post by Steve Wendt
Post by Ilya Zakharevich
http://www.extremetech.com/article2/0,2845,1367923,00.asp
where they say that 9600 is good at 162MHz
Under 'Testbed Setup' they say they are testing 1600x1200, which is near
the upper limit for a single TMDS (165MHz). They are saying it passes
their testing for that resolution, not that 162MHz is the upper limit.
Well understood here. But thanks for making it more clear to people
who did not read the actual report!

Yours,
Ilya

Rich Wonneberger
2009-02-23 03:41:59 UTC
Permalink
Raw Message
Heiko,

Where do you use 3D?

TIA
Rich W.
Post by Heiko Nitzsche
Post by Dariusz Piatkowski
I have been eye-balling the 9800 series cards on eBay...but it looks
like the X800 stuff is better performing, and if the SNAP support is
of same quality for both I might as well pick up the X800 stuff.
The 9800 series is still a good choice if you just need 2D and no
powerful 3D support. Please see below where I also added Sysbench
results from my previous 9600XT card which is performance wise
relatively close to the 9800.
Heiko Nitzsche
2009-02-23 21:18:36 UTC
Permalink
Raw Message
Post by Rich Wonneberger
Where do you use 3D?
I have a dual boot system with Windows XP for some games.
But I gave up on HW upgrading for games and recently moved
to a PS3 which now simplifies getting an energy efficient
and silent system :)
Heiko Nitzsche
2009-02-22 17:02:17 UTC
Permalink
Raw Message
Post by Dariusz Piatkowski
Out of curiosity, have you done any benchmarks on your X850XT? I used SNAP's
gaperf utility to benchmark my Matrox cards and the G400 came out on top, even
in comparison to the G450 & P650...apparently no further optimizations were done
beyond the original G400 engine.
Here are the gaperf results at 1456x1100x32:


Profiling results for mode 1456x1100 16777216 color.

Hardware accelerated functions:

Integer lines (solid) => 422537.88 lines/s
Bresenham lines (solid) => 49678.36 lines/s
Integer lines (patterned) => 421076.41 lines/s
Bresenham lines (patterned) => 49639.24 lines/s
Clears (solid pattern) => 6287.89 MB/s
Clears (mono pattern) => 6287.82 MB/s
Clears (transparent mono pattern) => 6329.67 MB/s
Clears (color pattern) => 6290.33 MB/s
Clears (transparent color pattern) => 472.84 MB/s
BitBlt screen->screen (scrolls) => 6055.63 MB/s
BitBlt memory->screen => 999.47 MB/s
Mono image memory->screen (text) => 1454.01 MB/s

CPU Direct to Video Memory functions:

CPU copies to VRAM => 1002.31 MB/s
CPU copies from VRAM => 11.32 MB/s
CPU reads from VRAM => 11.37 MB/s
CPU clears => 1002.27 MB/s
CPU reverse clears => 1003.17 MB/s

Baseline values for system memory:

clears (REP STOSD) => 1236.19 MB/s
reverse clears => 1231.42 MB/s
reads (MOV EAX,[EDI]) => 2015.83 MB/s
copies (REP MOVSD) => 792.99 MB/s

Overall GA-Mark: 833.42
Dariusz Piatkowski
2009-02-23 02:12:48 UTC
Permalink
Raw Message
Post by Heiko Nitzsche
Post by Dariusz Piatkowski
Out of curiosity, have you done any benchmarks on your X850XT? I used SNAP's
gaperf utility to benchmark my Matrox cards and the G400 came out on top, even
in comparison to the G450 & P650...apparently no further optimizations were done
beyond the original G400 engine.
Profiling results for mode 1456x1100 16777216 color.
Integer lines (solid) => 422537.88 lines/s
Bresenham lines (solid) => 49678.36 lines/s
Integer lines (patterned) => 421076.41 lines/s
Bresenham lines (patterned) => 49639.24 lines/s
Clears (solid pattern) => 6287.89 MB/s
Clears (mono pattern) => 6287.82 MB/s
Clears (transparent mono pattern) => 6329.67 MB/s
Clears (color pattern) => 6290.33 MB/s
Clears (transparent color pattern) => 472.84 MB/s
BitBlt screen->screen (scrolls) => 6055.63 MB/s
BitBlt memory->screen => 999.47 MB/s
Mono image memory->screen (text) => 1454.01 MB/s
CPU copies to VRAM => 1002.31 MB/s
CPU copies from VRAM => 11.32 MB/s
CPU reads from VRAM => 11.37 MB/s
CPU clears => 1002.27 MB/s
CPU reverse clears => 1003.17 MB/s
clears (REP STOSD) => 1236.19 MB/s
reverse clears => 1231.42 MB/s
reads (MOV EAX,[EDI]) => 2015.83 MB/s
copies (REP MOVSD) => 792.99 MB/s
Overall GA-Mark: 833.42
Hmm...I couldn't figure out how to get gaperf to run ALL the tests in one
shot...probably missed something obvious...but here are the results I got from
my G400 (keep in mind, different resolution, but still...yeah...the new stuff
blows the old stuff away eh LOL...always fun to benchrace a bit, in this case my
G400 is the Model-T...) :

Profiling results for mode 1600x1200 16777216 color.

Hardware accelerated functions:

Integer lines (solid) => 35897.57 lines/s
Bresenham lines (solid) => 35936.98 lines/s
Integer lines (patterned) => 35888.19 lines/s
Bresenham lines (patterned) => 35857.02 lines/s
Clears (solid pattern) => 1396.60 MB/s
Clears (mono pattern) => 1396.48 MB/s
Clears (transparent mono pattern) => 1597.08 MB/s
Clears (color pattern) => 931.50 MB/s
Clears (transparent color pattern) => 935.54 MB/s
BitBlt screen->screen (scrolls) => 680.57 MB/s
BitBlt memory->screen => 214.70 MB/s
Mono image memory->screen (text) => 400.68 MB/s

CPU Direct to Video Memory functions:

CPU copies to VRAM => 214.87 MB/s
CPU copies from VRAM => 6.74 MB/s
CPU reads from VRAM => 6.79 MB/s
CPU clears => 216.53 MB/s
CPU reverse clears => 199.24 MB/s

Baseline values for system memory:

clears (REP STOSD) => 1028.90 MB/s
reverse clears => 957.64 MB/s
reads (MOV EAX,[EDI]) => 954.14 MB/s
copies (REP MOVSD) => 526.95 MB/s

Overall GA-Mark: 0.00
Dariusz Piatkowski
2009-03-10 22:26:12 UTC
Permalink
Raw Message
Post by Heiko Nitzsche
Post by Dariusz Piatkowski
I'm trying to source another card to try a few things. So far I have tried the
Matrox P650 and G400...all show EXACTLY the same behaviour. I will look for a
decent AGP card next, sounds like ATI Radeon 9800 series get decent reviews.
Try to get a SNAP supported ATI card (e.g. X300, X600, X800, X850) with at
least one DVI port. For these chipsets SNAP supports native panel programming
which removes the VESA BIOS restrictions. To my knowledge you can also mix DVI
and Sub-D port for dual screen setup or of cause use 2 DVI ports.
<snip>

Alright folks, it's FRUSTRATION city here...big time!!!

My latest eBay find showed up the other day, an ATI X800 XT 256MB card. SNAP
recognizes it with the following entry in the graphics.log file:

======== START ===========

AGP device capabilities: AGP Bridge AGP Card
Max AGP texturing rate ... AGP 8X AGP 8X
AGP side band addressing . Yes Yes
AGP fast write ........... Yes Yes
AGP 4GB enable ........... No No
AGP request queue max .... 31 255

AGP device features: AGP Bridge AGP Card
AGP enable ............... On On
AGP texturing rate ....... AGP 8X AGP 8X
AGP side band addressing . On On
AGP fast write ........... On On
AGP 4GB enable ........... Off Off
AGP request queue depth .. 0 0

GA_enumerateDevices: Found 1 PCI/AGP display devices

Global options for all devices:
Force VBE Fallback ...... Off
Force VGA Fallback ...... Off
Allow non-certified ..... Off
Disable write combining . Off
Use BIOS for LCD panel... Auto
Shared AGP memory size... 4096 KB
Use system memory driver. Off
Disable DDC detection.... Off
Virtual Display.......... Off

Loading driver for device 0 (radeon.drv.Sep.25.2006.13.01.08)
---------------------------------------------------------

Video memory limited to user supplied value of 64MB

Attempting to enable write combining, base = 0xD0000000, length = 0x04000000 ...
Success!
Attempting to disable caching for MMIO, base = 0xE5000000, length = 0x00004000
.. Success!
Loading chipset filters...done.
Loading splash screen...done.

Graphics device configuration:
Manufacturer......... ATI
Chipset.............. Radeon X800 Series
Bus Type............. AGP bus
Memory............... 65536 KB
DAC.................. ATI Internal 24 bit DAC
Clock................ ATI Internal Clock
Memory Clock......... 400 MHz
Default Memory Clock. 400 MHz
Maximum Memory Clock. 400 MHz
Driver Revision...... 3.2, Build 29
Driver Build......... Sep 25 2006
Certified Version.... 1.60
Certified Date....... Sep 25 2006

Graphics device options:
Invert .................. Off
Rotation ................ Off
Flipped ................. Off
Prefer 16 bit per pixel.. On
Prefer 32 bit per pixel.. On
PCI bus mastering........ On
Hardware acceleration.... Full

BIOS header information:
'U.n.+.........................IBM5..............'
' 761295520......??..............07/07/04,13:42:1'
'9...............D.87...... .....113-A26104-102..'
'....R420.AGP.DDR3...RADEON X800 XT VIVO.....YOU '
'HAVE NOT CONNECTED THE POWER CABLE TO YOUR VIDEO'
' CARD.PLEASE REFER TO THE 'GETTING STARTED GUIDE'

Configuration for head 0:

Monitor configuration:
Manufacturer... Samsung
Model.......... SyncMaster
Max Resolution. 1920x1440
Max HScan...... 81 KHz
Max VScan...... 75 Hz
Features....... DPMS Wide

======== END ===========

OK, so with D-SUB 1920x1200 is still NO GO. I am getting exactly the same
behaviour as with all the MATROX cards.

Problem is that DVI is a NO GO as well, basically, the top resolution is
1280x1024, which appears to be the old BIOS limit. Now...I was under the
impression that this ATI Radeon X800 chipset is specifically supported to
directly drive the digital LCDs...so what am I missing here?

Judging by the BIOS dump that SNAP shows the card appears to be using a fairly
old version...I will see if I can get that updated and re-try.

But to be honest, and maybe it's just the frustration that's getting to me, I'm
simply stumped.

The ATI X800 appears to be no different then my old Matrox cards as far as the
1920x1200 resolution through D-Sub or DVI is concerned.

What I did notice, by chance actually, is that the LCD reports itself as
supporting max resolution of 1920x1440...this of course is NOT the case as the
top resolution is 1920x1200....but could this be throwing off the SNAP driver
timing somehow? Any idea how the driver actually calculates these values?

One piece of good news in all this is that the ATI card is FAST...I mean
screaming fast. It is about 5x faster in 1600x1200x32 then my Matrox cards.

Alright...so any other ideas???

Thanks as always!
Heiko Nitzsche
2009-03-10 23:14:09 UTC
Permalink
Raw Message
Post by Dariusz Piatkowski
OK, so with D-SUB 1920x1200 is still NO GO. I am getting exactly the same
behaviour as with all the MATROX cards.
Try to select the generic SNAP monitor. Maybe the timing information
for the specific monitor is wrong. Using the SNAP monitor it should
be well defined.
Post by Dariusz Piatkowski
Problem is that DVI is a NO GO as well, basically, the top resolution is
1280x1024, which appears to be the old BIOS limit. Now...I was under the
impression that this ATI Radeon X800 chipset is specifically supported to
directly drive the digital LCDs...so what am I missing here?
Are you using latest SNAP Pro 3.1.8? It is meanwhile freely available.
If the resolution is not automatically detected via DVI try to add
the required resolution with the gamode tool for 60Hz and afterwards
select it in monitor configuration notebook.

BTW, did you check the resolutions listed by SNAP in graphics.log?
Post by Dariusz Piatkowski
Judging by the BIOS dump that SNAP shows the card appears to be using a fairly
old version...I will see if I can get that updated and re-try.
If it works (and it does according to your SNAP log), a BIOS update
should be the last option. First try manual setting of the resolution.
Post by Dariusz Piatkowski
The ATI X800 appears to be no different then my old Matrox cards as far as the
1920x1200 resolution through D-Sub or DVI is concerned.
What I did notice, by chance actually, is that the LCD reports itself as
supporting max resolution of 1920x1440...this of course is NOT the case as the
top resolution is 1920x1200....but could this be throwing off the SNAP driver
timing somehow? Any idea how the driver actually calculates these values?
Yeah, the monitor seams to be wrongly detected. Maybe this is a bug in
the database. As said try with the generic SNAP monitor. The real monitor
type is just for restricting the analog signal frequency for old CRTs
to not overdrive them.

If you have Windows inf file for the monitor, you may try to import it
in case the generic monitor selection does not work.
Dariusz Piatkowski
2009-03-15 15:00:26 UTC
Permalink
Raw Message
Post by Heiko Nitzsche
Try to select the generic SNAP monitor. Maybe the timing information
for the specific monitor is wrong. Using the SNAP monitor it should
be well defined.
Yup, did that already...I picked a GENERIC monitor (Standard Monitor Type -
Unknown Monitor) which shows just about ALL the video modes.
Post by Heiko Nitzsche
Are you using latest SNAP Pro 3.1.8? It is meanwhile freely available.
If the resolution is not automatically detected via DVI try to add
the required resolution with the gamode tool for 60Hz and afterwards
select it in monitor configuration notebook.
Yes, using the latest version as you stated above...
Post by Heiko Nitzsche
BTW, did you check the resolutions listed by SNAP in graphics.log?
And this is exactly where I found the root cause of my problem...as far as the
DVI output is concerned anyways...maybe this has an impact on D-sub as
well...not sure yet.

Anyways, I find the following entry in my graphics.log file:

===== LOG START =========
Loading driver for device 0 (radeon.drv.Sep.25.2006.13.01.08)
---------------------------------------------------------

Attempting to enable write combining, base = 0xD0000000, length = 0x08000000 ...
Success!
Attempting to disable caching for MMIO, base = 0xE5000000, length = 0x00004000
.. Success!

Flat Panel EDID is not valid, attempting other methods.
Loading chipset filters...done.
Loading splash screen...done.
===== LOG END =========

As you can tell the EDID info the Samsung 245T panel is returning appears to be
'faulty' in some way. The LCD is apparently using version 1.3 of that standard,
which the SNAP driver is unable to decode OR is decoding incorrectly.

This would make sense given that in D-sub mode the 'Advance Control' option
reads the EDID but decodes the LCD panel capability as 1920x1440...which it
obviously is NOT capable of.

So...I'm going to do some poking around in WinXP which I have installed on this
machine as well. There are some utilities on the net to read/write LCD EDID as
required...if I can figure out exactly what the panel is returning and can set
it up so that the OS2 SNAP driver interprets the results correctly I may be able
to get this issue resolved.

I am guessing that this may be affecting not just DVI but D-sub modes as
well...any ideas how to debug the SNAP drivers in OS2?
Post by Heiko Nitzsche
Yeah, the monitor seams to be wrongly detected. Maybe this is a bug in
the database. As said try with the generic SNAP monitor. The real monitor
type is just for restricting the analog signal frequency for old CRTs
to not overdrive them.
If you have Windows inf file for the monitor, you may try to import it
in case the generic monitor selection does not work.
I have tried importing the INF file but SNAP just complains that the import
fails...no reasons given why, etc, etc....
Steve Wendt
2009-03-15 19:39:25 UTC
Permalink
Raw Message
Post by Dariusz Piatkowski
What I did notice, by chance actually, is that the LCD reports itself as
supporting max resolution of 1920x1440...this of course is NOT the case as the
top resolution is 1920x1200....
One more thing to try, from the changelog:

. Improved support for 16:10 widescreen displays. The default mode
profile now contains the common display sizes (1280x800, 1440x900,
1680x1050, and 1920x1200), and DDC monitor detection automatically
sets the "Wide" flag (previously 16:9) when appropriate. Most of
the 16:9 modes have been dropped from the default mode profile,
since they aren't commonly used. In order to benefit from the new
automatic configuration, the old crtc*.dat and mon*.dat configuration
files must be removed, so that they get regenerated with the new data.
Dariusz Piatkowski
2009-03-16 02:01:27 UTC
Permalink
Raw Message
Post by Steve Wendt
Post by Dariusz Piatkowski
What I did notice, by chance actually, is that the LCD reports itself as
supporting max resolution of 1920x1440...this of course is NOT the case as the
top resolution is 1920x1200....
. Improved support for 16:10 widescreen displays. The default mode
profile now contains the common display sizes (1280x800, 1440x900,
1680x1050, and 1920x1200), and DDC monitor detection automatically
sets the "Wide" flag (previously 16:9) when appropriate. Most of
the 16:9 modes have been dropped from the default mode profile,
since they aren't commonly used. In order to benefit from the new
automatic configuration, the old crtc*.dat and mon*.dat configuration
files must be removed, so that they get regenerated with the new data.
Gave it a try...no go. The panel is capable of switching between Widescreen,
16:9 and 4:3. I believe it does the 1:1 pixel mapping, because as I'm currently
using the 1600x1200 resolution I can tell that the display is very sharp, no
pixels are interpolated and the OSD selection is set to 4:3. When I flip this to
WIDE or 16:9 the display quality suffers, as expected. This is all done using
the D-sub input.

But having done a bit more investigation using Win utilities (Monitor Asset
Manager, EnTech Taiwan) decoded the EDID and got the following result:

======= START =========
Monitor #1 [Real-time 0x0021]
Model name............... SyncMaster
Manufacturer............. Samsung
Plug and Play ID......... SAM02F4
Serial number............ 254
Manufacture date......... 2008, ISO week 23
-------------------------
EDID revision............ 1.3
Input signal type........ Analog 0.700,0.000 (0.7V p-p)
Sync input support....... Separate, Composite
Display type............. RGB color
Screen size.............. 580 x 360 mm (26.9 in)
Power management......... Active off/sleep
Extension blocs.......... None
-------------------------
DDC/CI................... Supported
MCCS revison............. 2.0
Display technology....... TFT
Controller............... Not supported
Firmware revision........ 2.1
Firmware flags........... 0xFFFF
Active power on time..... Not supported
Current frequency........ 0.74kHz, 6.00Hz

Color characteristics
Default color space...... Non-sRGB
Display gamma............ 2.60
Red chromaticity......... Rx 0.662 - Ry 0.329
Green chromaticity....... Gx 0.205 - Gy 0.684
Blue chromaticity........ Bx 0.146 - By 0.077
White point (default).... Wx 0.313 - Wy 0.329
Additional descriptors... None

Timing characteristics
Horizontal scan range.... 30-81kHz
Vertical scan range...... 56-75Hz
Video bandwidth.......... 170MHz
CVT standard............. Not supported
GTF standard............. Not supported
Additional descriptors... None
Preferred timing......... Yes
Native/preferred timing.. 1920x1200p at 60Hz (16:10)
Modeline............... "1920x1200" 154.000 1920 1968 2000 2080 1200 1203
1209 1235 +hsync -vsync
Detailed timing #1....... 960x1200p at 60Hz
Modeline............... "960x1200" 96.500 960 1032 1128 1296 1200 1203 1213
1245 -hsync +vsync

Standard timings supported
720 x 400p at 70Hz - IBM VGA
640 x 480p at 60Hz - IBM VGA
640 x 480p at 67Hz - Apple Mac II
640 x 480p at 72Hz - VESA
640 x 480p at 75Hz - VESA
800 x 600p at 56Hz - VESA
800 x 600p at 60Hz - VESA
800 x 600p at 72Hz - VESA
800 x 600p at 75Hz - VESA
832 x 624p at 75Hz - Apple Mac II
1024 x 768p at 60Hz - VESA
1024 x 768p at 70Hz - VESA
1024 x 768p at 75Hz - VESA
1280 x 1024p at 75Hz - VESA
1152 x 870p at 75Hz - Apple Mac II
1600 x 1200p at 60Hz - VESA STD
1280 x 1024p at 60Hz - VESA STD
1280 x 960p at 60Hz - VESA STD
1152 x 864p at 75Hz - VESA STD

Report information
Date generated........... 15/03/2009
Software revision........ 2.30.0.793
Operating system......... 5.1.2600.2.Service Pack 2

Raw data

00,FF,FF,FF,FF,FF,FF,00,4C,2D,F4,02,FE,00,00,00,17,12,01,03,6C,3A,24,A0,2A,98,75
,A9,54,34,AF,25,

13,50,54,BF,EF,80,A9,40,81,80,81,40,71,4F,01,01,01,01,01,01,01,01,28,3C,80,A0,70
,B0,23,40,30,20,

36,00,06,44,21,00,00,1A,B2,25,C0,50,31,B0,2D,40,48,60,3A,00,03,44,11,00,00,1C,00
,00,00,FD,00,38,

4B,1E,51,11,00,0A,20,20,20,20,20,20,00,00,00,FC,00,53,79,6E,63,4D,61,73,74,65,72
,0A,20,20,00,B8

======= END =========

Now, here is the coincidental part: when I attempt to invoke the 1920x1200
resolution the LCD does switch mode, and even though I can tell that physically
the display is made up of 'more' pixels the screen is rather garbled b/c the
panel thinks it's actually running in the 960x1200 mode. What is strange about
it is that in the EDID decode above 2 resolution modes are listed:

Native/preferred timing.. 1920x1200p at 60Hz (16:10)
Modeline............... "1920x1200" 154.000 1920 1968 2000 2080 1200 1203
1209 1235 +hsync -vsync
Detailed timing #1....... 960x1200p at 60Hz
Modeline............... "960x1200" 96.500 960 1032 1128 1296 1200 1203 1213
1245 -hsync +vsync

It appears to me that for whatever reason the LCD actually thinks it's being
told to use the 'Detailed timing #1 mode' which is the 960x1200p at 60Hz when in
fact the SNAP driver and the card itself (I think/suspect) are actually putting
out 1920x1200.

So...does anyone know the difference between these 2 modes, or specifically
when/why one would use one over/instead the other?

I am considering modifying the panel EDID by either removing the 'Detailed
timing #1' record, or replacing it with the values specific to the 1920x1200
mode. Of course the scary part here is attempting to re-program the EDID on the
panel...so I will attempt to get a hold of Samsung tech support...although given
my previous experience I am not holding out much hope here.

In addition to the above, when I experimented with the Advanced Controls
selection (through the Screen properties notebook) I found that selecting the
default ***@32 mode produced the garbled 960x1200 response from the
LCD...however using a CUSTOM resolution of 1920x1200 and a lower refresh rate of
58Hz did show the LCD recognized 1920x1200 reoslution, but the screen now was
severly narrowed with a visible 'scan' line to the left and I could NOT correct
the sizing/placement with the provided built-in controls.

For now, that's all I've got...
Shmuel (Seymour J.) Metz
2009-02-26 18:00:02 UTC
Permalink
Raw Message
Post by Dariusz Piatkowski
Now with the bigger monitor I wanted to move up to the 1920x1200
mode...however, even though SNAP allows me to do it, when the display
comes up the monitor is interpretting it to actually be a weird 960x1200
resolution...subsequently it attempts to stretch the display and gets it
all distored.
I'm running 64K color 1600x1200 @ 60Hz using build 505, monitor Viewtronic
Q241WB, chip type VESA VBE 3.0 and 256 MiB of memory. The video adapter is
a Radion X1650 Pro.

Have you tried importing an INF file?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to ***@library.lspace.org
Loading...