jsgn3@fel.tno.nl (Jos Groot) (04/03/91)
I have to pick one of the next two SVGA cards: - Mentor card based on Tseng's ET4000 Turbo MegaVGA Chip and BIOS - Trident card Both have 1 Mb RAM and support a 1024*768 pixels non-interlaced display. Can anyone recommend one of these cards on ground of capabilities, speed, compatibility, etc. ? As always, thanks in advance. -- Jos Groot (jos.groot@fel.tno.nl) Physics and Electronics Laboratory FEL-TNO P.O.box 96864 2509 JG the Hague
woan@nowhere (Ronald S Woan) (04/03/91)
In article <1991Apr3.071713.6290@fel.tno.nl> jsgn3@fel.tno.nl (Jos Groot) writes: >- Mentor card based on Tseng's ET4000 Turbo MegaVGA Chip and BIOS > >- Trident card > >Both have 1 Mb RAM and support a 1024*768 pixels non-interlaced display. >Can anyone recommend one of these cards on ground of capabilities, speed, >compatibility, etc. ? Software support is about even but the Trident cards are dogs when it comes to Windows 3.0 use at the higher resolutions. Go with the ET4000 based card... -- +-----All Views Expressed Are My Own And Are Not Necessarily Shared By------+ +------------------------------My Employer----------------------------------+ + Ronald S. Woan woan@cactus.org or woan@austin.vnet.ibm.com + + other email addresses Prodigy: XTCR74A Compuserve: 73530,2537 +
pjv@fct.unl.pt (Pedro Jorge Veiga) (04/04/91)
In article <3725@d75.UUCP> woan@nowhere (Ronald S Woan) writes: > In article <1991Apr3.071713.6290@fel.tno.nl> jsgn3@fel.tno.nl (Jos Groot) writes: > >- Mentor card based on Tseng's ET4000 Turbo MegaVGA Chip and BIOS > > > >- Trident card > > > >Both have 1 Mb RAM and support a 1024*768 pixels non-interlaced display. > >Can anyone recommend one of these cards on ground of capabilities, speed, > >compatibility, etc. ? > > Software support is about even but the Trident cards are dogs when it > comes to Windows 3.0 use at the higher resolutions. Go with the ET4000 > based card... I strongly disagree as I have one and currently work with Windows 3 under 1024x768x256. So far it hasn't bit me nor has it said anything to provoke my anger, mainly because they don't have mouths but specially because they can't talk! Anyway, back to the issue, call 1024x768x256 low resolution or what? :-) I must add that with the card I found an amazing array of drivers for all sorts of software (yes, Win3.0 included) on earth and some stuff only seen in the products of Douglas Adam's vivid immagination... 42 to ye all -- -?- /- -\ / = \ | V | / ___ \ / \ ||||_____|||| Pedro Veiga - pjv@fct.unl.pt
pjv@fct.unl.pt (Pedro Jorge Veiga) (04/04/91)
Ooops, when I am not fully in control of my brain (as it has happened
during my previous postings) I forget about things. Where am I?
So there, I have a Trident 8900 and all the comments are related to
it...
Hasta sometime
How did I get here?
--
-?-
/- -\
/ = \
| V |
/ ___ \
/ \
||||_____|||| Pedro Veiga - pjv@fct.unl.ptfangchin@leland.Stanford.EDU (Chin Fang) (04/07/91)
In article <PJV.91Apr4121841@fogo.fct.unl.pt> pjv@fct.unl.pt (Pedro Jorge Veiga) writes: >In article <3725@d75.UUCP> woan@nowhere (Ronald S Woan) writes: >> In article <1991Apr3.071713.6290@fel.tno.nl> jsgn3@fel.tno.nl (Jos Groot) writes: >> >- Mentor card based on Tseng's ET4000 Turbo MegaVGA Chip and BIOS >> > >> >- Trident card >> > >> >Both have 1 Mb RAM and support a 1024*768 pixels non-interlaced display. >> >Can anyone recommend one of these cards on ground of capabilities, speed, >> >compatibility, etc. ? >> >> Software support is about even but the Trident cards are dogs when it >> comes to Windows 3.0 use at the higher resolutions. Go with the ET4000 >> based card... > >I strongly disagree as I have one and currently work with Windows 3 >under 1024x768x256. So far it hasn't bit me nor has it said anything >to provoke my anger, mainly because they don't have mouths but >specially because they can't talk! >Anyway, back to the issue, call 1024x768x256 low resolution or what? :-) >I must add that with the card I found an amazing array of drivers for >all sorts of software (yes, Win3.0 included) on earth and some stuff >only seen in the products of Douglas Adam's vivid immagination... > But for X11R4, Trident chipset is not so good anymore. Thomas Roell, the creator of the famous X386 X11R4 port PD server, considers the memory manage- ment of Trident chipset braindamaged so he decided not to support it. ET4000 was instead chosen. This does not mean that Trident could not be made to work fast for MSDOS apps. Just for UNIX graphics applications, Trident is not the first choice per a first rate X expert (T.R. of course). X386 allows a user use res up to 1024x728x256 and 1152x900x16, for those who are curious about it's capability. On a 33Mhz w/o 387, it shows BETTER performance than a SUN SPARCstation 1.! Note, this is achieved without using a coprocessor assisted board like WD8514! Just a plain ET4000 card. I would like to know if any MS Windows 3.0 driver is so fast and flexible, allowing it's users select and design a prefered resolution, like now I am using 832x600 on my NEC Multisync II. If a MSW3 driver can do so, I may consider using MSDOS sometime. Please note this is just my personal preference only and not construe it as a flame to MSDOS. I fully aware it's VERY useful to millions people. Just would like to bring in some new perspective to the discussion. I know PC Mag editor Davrok was wrong when he claimed in his Inside Track column that X can be used only on a 486. I use it all the time on a 3 yrs old 20Mhz 386 w/o cache and it's definitely faster than my friend's 33Mhz MSDOS box running MSW3 when screen update is compared. All resolutions mentioned in my writing ARE NONINTERLACED. I think ET4000 is better if you don't want to just ran MSDOS stuff. Sorry Bill Gates. Hopefully bought in nteresting info for yow. Regards, Chin Fang Mechanical Engineering Department Stanford University ps. for those who are more curious, I have 640x480x256 68Hz screen refresh rate 704x528x256 65Hz screen refresh rate 752x564x256 63Hz screen refresh rate 832x600x256 60Hz screen refresh rate I can switch among them using Alt-Cntl-Keyboard +- + for up, - for down. Nothing in the MSDOS world can offer this kind flexibility. And I have virtual resolution up to 1152x900 on my humble NEC Multisync II! Correct me if my claim is wrong.
rreiner@yunexus.YorkU.CA (Richard Reiner) (04/07/91)
>But for X11R4, Trident chipset is not so good anymore. Thomas Roell, the >creator of the famous X386 X11R4 port PD server, considers the memory manage- >ment of Trident chipset braindamaged so he decided not to support it. ET4000 >was instead chosen. Not quite right. In a recent posting, Roell did call the Trident memory management brain damaged, but he stated that he *does* plan to support it. All he concluded from the brain-damagedness was that the Trident 8900 would not be as fast running his server as the Tseng ET4000. //richard
vanmick@hpsgm2.sgp.hp.com (Van Der Beek Michael-Leo) (04/08/91)
Hi, I too have a trident 8900 1Mb card, I don't have any problems with it only that it has problems with a SCSI card, solved this with a switch on the card. No graphics problems so far, I run Windows 3.0, Newwave, OrCad, Word for Windows and tons of other games no problems. The only grip I have about the card is that the ROM is 32K (don't know about other cards), when I shadow it (using AMI video shadow option) it uses up another 32K of I think Himem, so less memory for drivers and TSR, not that I have many TSR programs to load. There are many drivers for many packages. I think there are about 4-5 drivers for windows 3 alone. This means that there are several resolutions to choose from. Windows 2.x has another set of drivers. I am not using any driver from this range for my windows and still windows works fine. Though I think 1024x768x256 is a wee bit to small to comfortably use on a 14" monitor. Maybe a 16" or greater would be better. Well, I hope that helps. If you need more info on this card, please feel free to ask me. Michael
erik@westworld.esd.sgi.com (Erik Fortune) (04/09/91)
The ET4000 allows you to map the entire 1-meg frame buffer in
high memory somewhere, which means you don't have to fool around
with segment registers to use the memory intensive modes. On
the other hand, doing so eats a meg of high memory.
I don't have specs in front of me, but I assume the ET4000 has
distinct read and write segments (most do), so you can do
screen to screen copies directly if you decide to stick with
64k segments. If I want to copy from scanline 64 (in segment 1)
to scanline 63 (in segment 0), I can simply set my read segment to 1,
my write segment to 0 and copy the bytes.
The Trident 8900 can do 128k segments which is good for 1024x768x16
because it eliminates the need to switch segments (assuming you have
the memory space available). Segment and mode switching is a little
arcane, but once you get past your disbelief it's not too hard to make
it work.
The 8900's worst misfeature is that is has a single segment register
for both read and write. If I want to copy from scanline 64 (in segment 1)
to scanline 63 (in segment 0), I have to set my segment register to 1,
read the data I want into temporary memory, set my segment register to 0
and finally copy the data from temporary memory back into the frame buffer.
These extra steps slow down screen to screen copies (like scrolling)
substantially.
Summary:
In 4 plane (16 color) modes, the trident and tseng chips should be
comparable. I haven't measured them, but I'd expect things like
clock and memory speed to affect performance at least as much as the
chipset does -- probably more.
In 8 plane (256 color) modes, the ET4000 is a pretty clear winner
in terms of amount of overhead and code complexity. I don't know
the relative speeds of the two chipsets, but all of the extra segment
messiness has to slow you down on the 8900.
I run X on a trident vga card at home (in 1024x768x16 colors), and
it's pretty speedy and reliable. When I get around to porting a full
256 color server for the VGA, I'll probably buy a Tseng-based adapter to
avoid all of that segment garbage.
Hope this helps,
Erikmarkb@unix386.Convergent.COM (Mark Beyer) (04/09/91)
vanmick@hpsgm2.sgp.hp.com (Van Der Beek Michael-Leo) writes: >Hi, > I too have a trident 8900 1Mb card, I don't have any problems with >it only that it has problems with a SCSI card, solved this with a switch >on the card. Has anyone had this problem with and Orchid Pro II ? I've got one and it doesn't work in any of the nice high res modes (800x600 +). The only thing I can think of is that it somehow conflicts with my Adaptec 1542, which I currently can't boot without... I've got enough memory, a monitor that works at 1024x768x256 noninterlaced and I've removed all other adapters from the bus. None of the "compatibility" switches or junpers on the Orchid helps. I'm wondering if the Adaptec memory conflicts with the frame buffer memory address or something like that. Thanks in advance. Mark -- Mark Beyer markb@convergent.com {uunet,sun,decwrl,hplabs}!pyramid!ctnews!markb
roell@informatik.tu-muenchen.de (Thomas Roell) (04/10/91)
>The ET4000 allows you to map the entire 1-meg frame buffer in >high memory somewhere, which means you don't have to fool around >with segment registers to use the memory intensive modes. On >the other hand, doing so eats a meg of high memory. I know the ET400 *very* well but I don't know of any VGA board that uses this feature (if it really exists). But on the other hand the overhead of band- switch in less than 1% (if you have two segments). >I don't have specs in front of me, but I assume the ET4000 has >distinct read and write segments (most do), so you can do >screen to screen copies directly if you decide to stick with >64k segments. If I want to copy from scanline 64 (in segment 1) >to scanline 63 (in segment 0), I can simply set my read segment to 1, >my write segment to 0 and copy the bytes. Exactly right. >The Trident 8900 can do 128k segments which is good for 1024x768x16 >because it eliminates the need to switch segments (assuming you have >the memory space available). Segment and mode switching is a little >arcane, but once you get past your disbelief it's not too hard to make >it work. There is also a 64k banking mode, which is much easier to handle. The 128k segments would break applications that use a VGA and a monochrome adapter. In this mode you have only to modify one register for segment switching instead of two for the 128k segments. >The 8900's worst misfeature is that is has a single segment register >for both read and write. If I want to copy from scanline 64 (in segment 1) >to scanline 63 (in segment 0), I have to set my segment register to 1, >read the data I want into temporary memory, set my segment register to 0 >and finally copy the data from temporary memory back into the frame buffer. Yes but the problem is ONLY with scrolling. Perhaps with some chaching tricks the overhead could be reduced. For example with the ET4000 you have one read operation followed by one write operation. This means the processor has to wait for getting videomemory access. The ET4000 reads one line (32 bits) at once and buffers it. But cause of the following write this buffer is once again flushed. But the write will be buffered in a write-buffer internally. If the TVGA8900 has the same architecture the sequenece of reads and writes will make full use of such internal buffers. And if you read only small blocks of data that fit into one line of the 386 cache there might be an additional improvement. Concluding I assume that the overhead of the TVGA8900 of the ET4000 in scrolling would be about 40 to 60%. All other operations shounld have the same speed. >These extra steps slow down screen to screen copies (like scrolling) >substantially. If you do normal working with xterms and so on scrolling uses up to 60/75% of the time spent for graphics i/o. > In 8 plane (256 color) modes, the ET4000 is a pretty clear winner >in terms of amount of overhead and code complexity. I don't know >the relative speeds of the two chipsets, but all of the extra segment >messiness has to slow you down on the 8900. This statement is INEXACT. If the ET4000 & TVGA8900 WOULD support a 8 plane mode they would be equally fast. But they both (?) use a 8 bit packed pixel mode for displaying 256 colors. BTW, the TVGA8900 will indeed be supported in the next release of X386. I'm just waiting for someone to donate me a TVGA8900 board. - Thomas -- _______________________________________________________________________________ E-Mail (domain): roell@lan.informatik.tu-muenchen.de UUCP (if above fails): roell@tumult.{uucp | informatik.tu-muenchen.de} famous last words: "diskspace - the final frontier..."
erik@westworld.esd.sgi.com (Erik Fortune) (04/11/91)
In article <1991Apr10.100931.27295@Informatik.TU-Muenchen.DE>, roell@informatik.tu-muenchen.de (Thomas Roell) writes: >I know the ET400 *very* well but I don't know of any VGA board that uses this >feature (if it really exists). But on the other hand the overhead of band- >switch in less than 1% (if you have two segments). Hmm. I'll try to dig up my reference for it. I think it was in the "programmers guide to ega, vga, and svga" published by Brady. I'll look for a more complete reference. It's too bad that nobody uses the feature (if it exists) -- it was the ET4000 feature that most leapt out at me as I scanned the book. >There is also a 64k banking mode, which is much easier to handle. The 128k >segments would break applications that use a VGA and a monochrome adapter. >In this mode you have only to modify one register for segment switching instead >of two for the 128k segments. Agreed. The only time I'd recommend using the 128k segment register mode is for a 4-bit mode that needs more than 64k. In other words, for any mode that doesn't require you to touch the segment registers. The part that I thought was particularly bizarre was the way you switch between 64k and 128k mode. I don't remember exactly which register it is, but writing to one register sets it to 128k mode, and reading from the register toggles the mode (or the other way around). >Yes but the problem is ONLY with scrolling. Perhaps with some chaching tricks >the overhead could be reduced. For example with the ET4000 you have one >read operation followed by one write operation. This means the processor has >to wait for getting videomemory access. The ET4000 reads one line (32 bits) >at once and buffers it. But cause of the following write this buffer is once >again flushed. But the write will be buffered in a write-buffer internally. >If the TVGA8900 has the same architecture the sequenece of reads and writes >will make full use of such internal buffers. And if you read only small blocks >of data that fit into one line of the 386 cache there might be an additional >improvement. Concluding I assume that the overhead of the TVGA8900 of the >ET4000 in scrolling would be about 40 to 60%. All other operations shounld >have the same speed. I agree that we could play some games to minimize the overhead of the register swapping, but it annoys me that we'd have to. It means a moderately large amount of special-purpose code which could have been easily avoided. >This statement is INEXACT. If the ET4000 & TVGA8900 WOULD support a 8 plane >mode they would be equally fast. But they both (?) use a 8 bit packed pixel >mode for displaying 256 colors. Oops. When I said "8 plane" I meant "8 bit" (in X terms 8-bit Z format). I don't deal with too many XY format devices (in fact, the vga is the only XY device I've used). -- Erik
erik@westworld.esd.sgi.com (Erik Fortune) (04/11/91)
Re: linear addressing mode on the ET4000 Aha. Found it! Reprinted without permission from: Programmer's Guide to the EGA and VGA cards, Second Edition. by Richard E. Ferraro Published by Addison-Wesley p. 932 ----- beginning of excerpt 20.2.3 Linear or Segmented Addressing The VGA can be configured to access memory in a linear or in a segmented fashion through the SLS field. The linear addressing mode forces all display memory to be continuous. This is a much more efficient way to utilize the ET4000. If the SLS Field is 1, this linear mapping scheme is enabled. If 0, the standard VGA segmented memory mapping scheme is enabled. In extended DOS or OS/2 applications, it is possible to place the VGA into high memory where there is room t place one Megabyte of display memory into a contiguous address space. This allows the ET4000 to ignore the bank selection registers. There are two advantages to this approach. The first ensures faster programs; the second ensures continuous high-speed operation from a hardware perspective. The software advantage requires and extended operating system and access to the memory through the 80286, 80386 or 80486 processors. The software advantage becomes pronounced when 32-bit instructions can handle the one megabyte without segment registers. The hardware advantage is primarily aimed at video frame-grabbers where the hardware has a continuous stream of data coming at the ET4000 display memory, and the ET4000 cannot afford to perform bank switching. ---- end of excerpt One advantage of the ET4000 I forgot to mention before is the ability to use VRAM (which allows for much faster access to the frame buffer). Of course, this advantage is purely theoretical unless the VGA card you buy is engineered for VRAM and it's extremely unlikely that any of the inexpensive ET4000 based clones would be. Does the prodesigner II use vram? Does anyone know of any (ET4000 based) vga cards that do? On the topic of vram-based vga adapters -- does anyone know anything about the video-7 VRAM-II? I claims to support 1 meg using a video-7 proprietary chip (at least the ASIC is labelled "headland technologies"). I double checked the trident info. Old mode is 128k segments (with ugly segment registers), and new mode is 64k segments (with a single less ugly segment register). You get into old mode by writing to the hardware version register (a read-only register!) and toggle modes by reading the version register. How bizarre. I also forgot about the inverted page bit in one of the trident segment registers. Also bizarre and apparently pointless. All in all, I think the ET4000 just feels "cleaner" to me than the T8900. -- Erik
roell@informatik.tu-muenchen.de (Thomas Roell) (04/11/91)
>Yes but the problem is ONLY with scrolling. Perhaps with some chaching tricks >the overhead could be reduced. For example with the ET4000 you have one >read operation followed by one write operation. This means the processor has >to wait for getting videomemory access. The ET4000 reads one line (32 bits) >at once and buffers it. But cause of the following write this buffer is once >again flushed. But the write will be buffered in a write-buffer internally. >If the TVGA8900 has the same architecture the sequenece of reads and writes >will make full use of such internal buffers. And if you read only small blocks >of data that fit into one line of the 386 cache there might be an additional >improvement. Concluding I assume that the overhead of the TVGA8900 of the >ET4000 in scrolling would be about 40 to 60%. All other operations shounld >have the same speed. Ok, I think this was a little bit to abstract, so lets fill in some numbers. Assume we do a simple bitblit, only 32bit words, all correctly aligned, no shift necessary. Under this assumptions a ET4000 makes about 1.7 MBytes/sec. This was measured on a 33MHz 386. Thus one movsl I used for blitting too about 78 cpu cycles. Thus the raw VGA accesses took about 74 cycles. Now to the TVGA8900. I assume that a read and a following write are as fast as for the ET4000, 74 cycles. But here we have first to buffer the stuff: 74 VGA read/write 4 movsl for buffering 5 storing the buffered data into memory 4 movsl for bltting from memroy into VGAs. 0 reading data from cache -- 87 cycles This means that the TVGA8900 is at least 12% slower. At an average I assume about 20% slower performance than the ET4000 is they have the same memory troughput. But if you really need speed, forget about VGA. Buy a 8514. Benchmarks: VGA 640x480x256 6600 xstones ET4000 VGA 1024x768x256 4800 xstones 8514 1024x768x256 26300 xstones WD9510 - Thomas -- _______________________________________________________________________________ E-Mail (domain): roell@lan.informatik.tu-muenchen.de UUCP (if above fails): roell@tumult.{uucp | informatik.tu-muenchen.de} famous last words: "diskspace - the final frontier..."
erik@westworld.esd.sgi.com (Erik Fortune) (04/12/91)
In article <1991Apr11.095521.26017@Informatik.TU-Muenchen.DE>, roell@informatik.tu-muenchen.de (Thomas Roell) writes: > (lots of good analysis of vga speed omitted) > 74 VGA read/write > 4 movsl for buffering > 5 storing the buffered data into memory > 4 movsl for bltting from memroy into VGAs. > 0 reading data from cache > -- > 87 cycles > >This means that the TVGA8900 is at least 12% slower. At an average I assume >about 20% slower performance than the ET4000 is they have the same memory >troughput. Of course, the number you *really* want to reduce is that VGA read/write number. Using VRAM or clever VGA design (like the high(er)-speed cache on the video-7 fastwrite) should be able lower that number substantially. Of course, the cleverly designed VGAs aren't going to sell for US$130 any time soon. >But if you really need speed, forget about VGA. Buy a 8514. Benchmarks: > > VGA 640x480x256 6600 xstones ET4000 > VGA 1024x768x256 4800 xstones > 8514 1024x768x256 26300 xstones WD9510 The 8514 is nice, but if you really need speed, forget about the PC:-). I'm from the workstation world, and most PC-based servers I've seen are slow compared to even the typical workstation. The machine on my desk can do solid fills at something like 140 million pixels per second. Of course the machines I'm talking about have many times the horsepower and bus bandwidth of the PC, but who ever said we had to make fair comparisons:-). -- Erik
roell@informatik.tu-muenchen.de (Thomas Roell) (04/15/91)
> 74 VGA read/write > >Of course, the number you *really* want to reduce is that VGA read/write >number. Using VRAM or clever VGA design (like the high(er)-speed cache on >the video-7 fastwrite) should be able lower that number substantially. >Of course, the cleverly designed VGAs aren't going to sell for US$130 >any time soon. Ok thats right. But I think you cannot reduce is much. Say you use a 33MHz 386, reads take as long as writes, (74/2) and you use 32bit access (same as the numbers were computed for). Now you have the fact that a VGA (the newer ones) are accessed 16bit wise. This means one access takes about 18 Cycles. That is equal to 545ns. The normal system ram has about 200ns. How should that be improved ??? a) 32 bit bus => expensive EISA machine b) Using VRAM => very expensive VGA Thus it's just wise to buy a 8514a which is much faster through the use of VRAM and a special graphics processor who eleminates the remaining cpu cycles. BTW, the VideoSeven VRAM is only half fast as a ET4000 cause the latter one uses 16bit accesses and then V7VRAM only 8bit ones. >The 8514 is nice, but if you really need speed, forget about the PC:-). >I'm from the workstation world, and most PC-based servers I've seen >are slow compared to even the typical workstation. The machine on >my desk can do solid fills at something like 140 million pixels per >second. Sorry that I strongly disagree. I'm also using a SPARC2. This one is in the overall performance SLOWER than my 386 box. The mips numbers you read are rediculus !!! But the SPARC is a RISC and the 386 is CISC. Anyway the compilers run faster on the 386, so I much more like the 386. Also the graphics are faster (through the use of a 8514a). And all for less than half of the price. And don't forget one fact: If you have a workstation, you have to share it with other users. Most 386 boxes are used by just one person !! 140 million pixels !!!! Wow. But since pixelfilling is not all one uses normally in GUIs lets talk about the overall performance. Whats the xstones ? Ok, we all dislike benchmarks, but they tell us aproximately how fast a Xserver is. Doing this fast filling is easy. Just use VRAMs and a graphics processor that uses a floodfill alorithm utilizing the shift-registers of a VRAM. - Thomas -- _______________________________________________________________________________ E-Mail (domain): roell@lan.informatik.tu-muenchen.de UUCP (if above fails): roell@tumult.{uucp | informatik.tu-muenchen.de} famous last words: "diskspace - the final frontier..."