Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!ira.uka.de!fauern!NewsServ!!roell From: roell@informatik.tu-muenchen.de (Thomas Roell) Newsgroups: comp.sys.ibm.pc.hardware Subject: Re: Mentor & Trident VGA cards - which one is the best ? Message-ID: <1991Apr10.100931.27295@Informatik.TU-Muenchen.DE> Date: 10 Apr 91 10:09:31 GMT References: <1991Apr3.071713.6290@fel.tno.nl> <3725@d75.UUCP> <1991Apr6.192215.29729@leland.Stanford.EDU> <1991Apr9.004129.20991@odin.corp.sgi.com> Sender: news@Informatik.TU-Muenchen.DE Organization: Inst. fuer Informatik, Technische Univ. Muenchen, Germany Lines: 72 In-Reply-To: erik@westworld.esd.sgi.com's message of 9 Apr 91 00: 41:29 GMT >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..."