Orchid P9000 vs Fahrenheit (mini review)
Geoffrey Sherwood
I just purchased a Viewsonic 17 and and Orchid P9000. In short, I am happy
with the monitor and unhappy with the card. I have spent a lot more time
futzing with the card, so that is what I am going to write about. The monitor
is pretty. The moires I had under Simcity on my 17" Magnavox went away. It
isn't as heavy as I thought it would be (45 lbs, I think). So much for the
monitor. On to the bitch session and test results.
In going with the modern trend, the Orchid P9000 card only supports 16 colors
in 640x480 mode without a driver. Of course, this breaks any DOS program
which uses SVGA modes (like most of my CD-ROMs). The Compudyne Whiplash VGA,
Orchid Fahrenheit 1280, and Orchid F. VLB all share this limitation. Those
are all S3 cards, which means it is an S3 problem for them (the P9000 uses
a Weitek VGA chip which also doesn't support them). The Hercules Graphite
card does seem to have these modes, but I didn't run the same test cases as
I did on the other boards during the brief time I had it. It was able to
print the splash screen for the Grolier's Encyclopedia, though, which the S3
cards just printed as hash, which is why I suspect the SVGA modes are supported.
The supported resolutions really annoy me. You can do 1280x1024 at 75Hz if
you tell the driver you have an NEC 5FG (they only have about six monitors
listed plus 'Generic', and if you choose Generic you can't get any high
refreshes at ALL). But at 1024x768 you are limited to 70Hz. Seems to me
that the hardware should be able to support the bandwidth (if it can do 75Hz
at 1280 it sure should be able to do it at 1024!). Higher vertical resolution
was the main reason I bought the card over the Orchid F. VLB I currently have,
and it will do 1024x768x70 Hz as well.
The higher graphics modes all crash HP Dashboard. I just got off the phone
with Orchid, and with the 1.1 drivers (I don't know what I have) he was unable
to recreate the problem. On the plus side, their tech rep was as helpful as
he could be and booted up the program on his computer to verify he didn't have
the problem. He didn't know why they limited the refresh to 70 Hz either.
The board is faster that the OFVLB for most things according to the Hercules
Speedy program. This program tests various operations and reports the results
in pixels/second. I don't have the numbers for the Graphite card, but they
were close to half of the OFVLB (ie, slower) but that was running in a 20MHz
386, ISA, so the numbers aren't really comparable. The following numbers
were all obtained using a 486, 33 MHz, AIR motherboard (UMC chipset), with
8 MB memory. I give ranges because the program reports the numbers as it
computes them, and these tend to jump around a bit.
K means thousand (not 1024), M means million, pixels per second
Orchid Fahrenheit VLB Orchid P9000
Chip S3 805 Weitek 9000
DIB to Screen 182K - 190K 228K - 240K
Memory to Screen 5.9M - 6.2M 8.4M - 8.9M
Screen to Screen 14M - 14.8M 29M - 30.8M
Vector, solid 2.4M 2.8M - 2.9M
Vector, styled 55K - 58K 449K - 473K
Polygon, shaded 1.8M - 2.1M 1.6M - 1.9M
Polygon, hatched 6.9M - 7.9M 1.3M - 1.7M
Ternary Rops 1.9M - 2.4M 477K - 520K
Font 130K - 160K 46K - 55K / 1.2M
The DIB to Screen test takes a device independent bitmap of a face and transfers
it to the screen. I have no idea what is being done internally as far as
conversions go. The memory to screen takes the same face and copies it to
the screen, my guess is after it has been rasterized into a bitmap that can
just be copied to the video display. The screen to screen test copies that
face from place to place on the screen. Awesome! Interestingly, the solid
vectors and shaded polygons show no improvement, and hatched polygons (ie,
filled with cross-hatching) and Ternary Rops (whatever they are. Graphics
operations like XORs maybe????) are a dead loss on the 9000. I give two
numbers for the 9000 fonts, because I think they are caching.
When the fonts are first drawn on the screen they are done fairly slowly --
1/3 the speed of the OFVLB. Then the speed increases dramatically. Sounds
like programming to a benchmark to me....
I make no claims that these numbers mean anything at all. Its just what
I saw when I ran them on my computer. I normally don't write disclaimers,
but this time maybe I'd better. My testing is totally unconnected with my
work (I program under UNIX on Decstations) is done completely without the
knowledge, blessing, or equipment of my company.
geoff sherwood
Robert Plamondon
(Geoffrey Sherwood) writes:
>In going with the modern trend, the Orchid P9000 card only supports 16 colors
>in 640x480 mode without a driver. Of course, this breaks any DOS program
>which uses SVGA modes (like most of my CD-ROMs).
This is not the case: the ROM on the P9000 supports VESA modes of up to
1024x768 in 256 colors. VESA-compliant applications should have no trouble
setting these modes. (But I'm forwarding your posting to our Software group,
just in case. Can't be too careful.) Not that I doubt that YOUR applications
are failing to run; lots of stuff depends on figuring out which exact SVGA
they're looking at, and don't use VESA calls (VESA is still pretty new).
Every new chip set confuses them.
>The supported resolutions really annoy me. You can do 1280x1024 at 75Hz if
>you tell the driver you have an NEC 5FG (they only have about six monitors
>listed plus 'Generic', and if you choose Generic you can't get any high
>refreshes at ALL). But at 1024x768 you are limited to 70Hz. Seems to me
>that the hardware should be able to support the bandwidth (if it can do 75Hz
>at 1280 it sure should be able to do it at 1024!). Higher vertical resolution
>was the main reason I bought the card over the Orchid F. VLB I currently have,
>and it will do 1024x768x70 Hz as well.
I think we go to AT LEAST 76 Hz at 1024x768x8, and maybe more (and
it's a function of the RAMDAC speed, not the Power 9000). We need to
fix the problems you've noted (they were already on the list). If
you're really interested, though, take a look at the text file
P9000RES.DAT, which holds the data from which the choices in the
P9000 monitor installation program are built. Working by analogy,
you can build up a new monitor definition that has the right
combinations of refresh rates for your monitors. Keep a backup copy
of the file! Once you've built a new version of the P9000RES.DAT
file, run the P9000 installation program, INST, and your new choices
should show up. (This assumes you have the WEITEK v. 2.2 drivers.
You can tell the rev number by looking at the modification time of
the driver: 02:20 is version 2.20. Microsoft uses this gimmick,
too.)
>The board is faster that the OFVLB for most things according to the Hercules
>Speedy program. This program tests various operations and reports the results
>in pixels/second. I don't have the numbers for the Graphite card, but they
>were close to half of the OFVLB (ie, slower) but that was running in a 20MHz
>386, ISA, so the numbers aren't really comparable. The following numbers
>were all obtained using a 486, 33 MHz, AIR motherboard (UMC chipset), with
>8 MB memory. I give ranges because the program reports the numbers as it
>computes them, and these tend to jump around a bit.
The SPEEDY benchmark was put out by Hercules and IIT, who to my
knowledge were unencumbered by any motivations except making the
Hercules Graphite/IIT AGX014 card look really good. So I'd take the
numbers with a ton of salt. (Texas Instruments did the same thing
with WINTACH, trying to make the 34020 look good compared to the
8514, as if anyone cared.) It's safer (though not safe) to use
benchmarks from "unbiased" sources, such as testing labs, columnists,
etc.
>Interestingly, the solid
>vectors and shaded polygons show no improvement, and hatched polygons (ie,
>filled with cross-hatching) and Ternary Rops (whatever they are. Graphics
>operations like XORs maybe????) are a dead loss on the 9000.
I think you'll a large discrepancy between the results of SPEEDY and
the results of anything else in the universe on these things.
>I give two
>numbers for the 9000 fonts, because I think they are caching.
>When the fonts are first drawn on the screen they are done fairly slowly --
>1/3 the speed of the OFVLB. Then the speed increases dramatically. Sounds
>like programming to a benchmark to me....
Font caching is a perfectly legitimate optimization -- Windows has
hooks for it built right into the GDI. What's kind of silly is IIT's
use of a hardwired "The quick brown fox jumped over the lazy dog then
sat on a tack" string in their driver. Not only is it useless in
real applications, it lacks the programming elegance of the "Bart
Simpson optimization," in which you save the bitmap of the
most-recently drawn string in off-screen memory, and just do a
screen-to-screen bitblit if you happen to be given that same string a
second time in a row. (We call it the "Bart Simpson optimization"
because Bart's the only person we can see benefiting from it: he
could right "I will not cheat on benchmarks" a hundred times and be
done in half the time it would take to actually form each character.)
>I make no claims that these numbers mean anything at all. Its just what
>I saw when I ran them on my computer. I normally don't write disclaimers,
>but this time maybe I'd better. My testing is totally unconnected with my
>work (I program under UNIX on Decstations) is done completely without the
>knowledge, blessing, or equipment of my company.
We don't have any lawyers -- they're all working for Intel. There
used to be a lawyer in Montana who didn't, but he died.
-- Robert
--
Robert Plamondon, rob...@weitek.COM
"Pay no attention to the man behind the curtain. I, the Great and
Glorious Oz, have spoken!"
-- scene from a trade show