Newsgroups: comp.sys.ibm.pc.hardware
Path: cantaloupe.srv.cs.cmu.edu!rochester!rochester!udel!bogus.sura.net!news-feed-1.peachnet.edu!umn.edu!csus.edu!netcom.com!netcomsv!weitek!robert
From: robert@weitek.COM (Robert Plamondon)
Subject: Re: Orchid P9000 vs Fahrenheit (mini review)
Message-ID: <1993Apr20.210255.2296@jetsun.weitek.COM>
Sender: news@jetsun.weitek.COM
Organization: WEITEK Corporation, Sunnyvale CA
References: <1993Apr16.173120.19289@adobe.com>
Date: Tue, 20 Apr 93 21:02:55 GMT
Lines: 102

In article <1993Apr16.173120.19289@adobe.com> sherwood@adobe.com 
(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, robert@weitek.COM
"Pay no attention to the man behind the curtain. I, the Great and
Glorious Oz, have spoken!"
				-- scene from a trade show
