Date: Mon, 28 Dec 92 15:40:40 EST From: DJ Delorie To: anton AT miro DOT com Cc: djgpp AT sun DOT soe DOT clarkson DOT edu Subject: re: accounts of Trident drvier problems >Can someone be more specific about the aledged problems with Trident >SVGA support? When I started using djgpp abd libgr I did find that >the drivers provided didn't work, however, I disassebled the driver >trdnt89.grd and noticed that the code didn't match the source. I then >got the programming specs from trident and determined that neither the >source nor object code was correct for the provided libgr trident drivers. The problem is that different board manufacturers build different interfaces to the chip for each board, and no one driver can handle all boards properly. Some hang on 16-bit I/O, some don't work with 8-bit. >I expect that the cause of support problems is that Trident Microsystems, >only designs chips, they don't make the actual boards. So owners may >be at the mercy of board manufacturing quality for their unit. One of the major problems with Trident is that if you write out, say, a five to the page register and write to that page, then read it back, you don't access the same memory. To actually access what you wrote, you have to program the register with (5 xor 2), since the read logic (or write logic; it doesn't matter how you call it) inverts one of the bits and the other logic doesn't. Since Trident is the only chip to use this brain-damaged logic, I didn't worry about supporting it, as support would slow down all other chips (this is why Windows runs much slower with a Trident-based SVGA). >Since I have the specs in hand and I'm generally happy with it, I'm >going to stick with the board and improve the drivers. The 8900C >is documented to support seporate read and write page mappings so I'm going >to test that out. I've not done so yet because I don't do any screen to >screen bliting. Anything that reads the screen will not work with the Trident chips because of the damaged read/write mapping scheme, not just blits. DJ