dhinds@portia.Stanford.EDU (David Hinds) (11/25/89)
I have an ATI VGA Wonder card, and I'm confused about what the 16-bit bus actually does for me. I have set the card to enable 16-bit ROM access, but is this all the extra bus width is good for? I've read up on the programming details of normal VGA controllers, and it seems that they are inherently limited to byte-wide accesses to display memory. There doesn't seem to be any simple or downward-compatible way to perform 16-bit accesses. If there isn't any way around this for bit-mapped graphics modes, is there at least a way to do 16-bit accesses in text modes? - David Hinds dhinds@portia.stanford.edu
plim@hpsgpa.HP.COM (Peter Lim) (11/27/89)
That doesn't sound right. As far as I know, the 16-bit access thing
is done totally in hardware. When a 16-bit card is plugged into an
AT-bus, it tells the AT bus system that it it 16-bit and the system
will read/write in 16-bit. Whereas, if you plug an 8-bit card into the
AT bus system, any 16-bit read/write will be converted in hardware to
two consecutive 8-bit access. You can find this info in the latest BYTE
magazine (the one with the HP-486 and EISA bus stories).
Hope that helps.
Regards,
Peter Lim.
HP Singapore IC Design Center.
E-mail address: plim@hpsgwg.HP.COM
Snail Mail address: Peter Lim
Hewlett Packard Singapore,
(ICDS, ICS)
1150, Depot Road,
Singapore 0410.
Telephone: (065)-279-2289dhinds@portia.Stanford.EDU (David Hinds) (11/28/89)
In article <340030@hpsgpa.HP.COM>, plim@hpsgpa.HP.COM (Peter Lim) writes: > That doesn't sound right. As far as I know, the 16-bit access thing > is done totally in hardware. When a 16-bit card is plugged into an > AT-bus, it tells the AT bus system that it it 16-bit and the system > will read/write in 16-bit... For the ATI VGA Wonder card, the bus width seems to be at least partially under software control. There is an option in the 'VSETUP' program to enable or disable 16-bit ROM accesses. The card is actually supposed to work in either 16-bit or 8-bit slots; in the 8-bit slot, the extra pins just hang in space, and the card configures itself for the shorter bus. Aside from the ROM accesses, it is not obvious that any software would use 16-bit accesses to video memory, or what they would actually do. In the true VGA graphics modes, at least, almost all video memory accesses are indirect, and data is churned through a series of arithmetic units on the VGA controller before being put in video memory. These steps map a 32-bit internal VGA memory bus onto an external 8-bit bus, using various VGA registers to control different kinds of rotating, masking, and logical operations. It would not be trivial to redesign these units to map to a 16-bit bus. For one thing, lots of VGA graphics control registers would need to be 16 bits long to be useful. There is no obvious way to make these extensions transparant and compatible with existing VGA software. And certainly, all existing VGA graphics software uses 8-bit accesses. I can see that there would be a speed improvement for 16-bit direct writes to video memory, in modes where the VGA is emulating a direct-memory-mapped display like CGA or Herc. But the indirect VGA modes are designed to cut down on the amount of host CPU effort and CPU-to-Video memory transfers. Proper VGA software should never do direct accesses to video memory, so as far as I can see, a wider bus won't do anything. I would like to be wrong, though (?). - David Hinds dhinds@portia.stanford.edu
toma@tekgvs.LABS.TEK.COM (Tom Almy) (11/29/89)
In article <6980@portia.Stanford.EDU> dhinds@portia.Stanford.EDU (David Hinds) writes: > > I have an ATI VGA Wonder card, and I'm confused about what the 16-bit >bus actually does for me. Well it can be a sure win for character modes since characters are actually represented as 16 bit entities (8 bits of f/b color and 8 bits for the character). My NNANSI.SYS driver takes advantage of that. And if the card happens to be an 8 bitter then the bus hardware conveniently does the two 8 bit accesses for me (but slower, of course). Yes, the benefit is fuzzier for 16 color graphic modes. Use of the graphics controller is limited to 8 bit operations, but for applications that want to read and write to each individual bit plane directly 16 bit operation is possible and works faster. I worked on an application for which graphic operations were done in memory to a "shadow" display, then the information was copied from the shadow display to the real display memory (in regions that had changed). Not only did using a 16 bit card help, but it turned out using the shadow display offered a several times performance improvment compared to similar programs that didn't use the shadow display -- on an 80386 you can access system RAM over 10 times faster than display memory, therefore *avoid* all display memory accesses. In fact, the display memory is treated write-only, even when XORing pixels to the screen! Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply (And even if I could, I'd never want credit for any of these turkey display controller designs!)
chasm@attctc.Dallas.TX.US (Charles Marslett) (11/29/89)
In article <7025@portia.Stanford.EDU>, dhinds@portia.Stanford.EDU (David Hinds) writes: <> In article <340030@hpsgpa.HP.COM>, plim@hpsgpa.HP.COM (Peter Lim) writes: <> > That doesn't sound right. As far as I know, the 16-bit access thing <> > is done totally in hardware. When a 16-bit card is plugged into an <> > AT-bus, it tells the AT bus system that it it 16-bit and the system <> > will read/write in 16-bit... <> <> For the ATI VGA Wonder card, the bus width seems to be at least partially <> under software control. There is an option in the 'VSETUP' program to enable <> or disable 16-bit ROM accesses. The card is actually supposed to work in <> either 16-bit or 8-bit slots; in the 8-bit slot, the extra pins just hang in <> . . . Aside from the <> ROM accesses, it is not obvious that any software would use 16-bit accesses <> to video memory, or what they would actually do. In the true VGA graphics <> modes, at least, almost all video memory accesses are indirect, and data is <> churned through a series of arithmetic units on the VGA controller before <> being put in video memory. These steps map a 32-bit internal VGA memory bus <> onto an external 8-bit bus, using various VGA registers to control different <> kinds of rotating, masking, and logical operations. It would not be trivial <> to redesign these units to map to a 16-bit bus. For one thing, lots of VGA <> graphics control registers would need to be 16 bits long to be useful. There <> is no obvious way to make these extensions transparant and compatible with <> existing VGA software. And certainly, all existing VGA graphics software <> uses 8-bit accesses. Actually, I agree so long as we are refering to 16-color modes. The VGA (and SuperVGA) 256-color graphics modes and the text modes cannot take advantage of the latches and internal EGA/VGA logic box, so they can run (and in the case of the text modes, are almost certainly programmed in the BIOS to run) in 16-bit mode. So standard software CAN benefit from 16-bit video memory accesses -- it just has to be in modes 0-3, 7 or 19 (though sometimes modes 4-6 benefit, the controller chip is a factor here). <> . . . Proper <> VGA software should never do direct accesses to video memory, so as far as I <> can see, a wider bus won't do anything. I would like to be wrong, though (?). Of course, someone has to access video memory directly (I've written drivers that don't, and the screen remains remarkably bland when I run them ;^). I would say that the only real benefit 16-bit video access provides shows up when you run 256-color software (especially in the high resolution modes). Text is fast enough already, and I never use the CGA modes (almost never?). But a 2:1 speedup is nice when a screen clear takes a significant fraction of a second. <> - David Hinds <> dhinds@portia.stanford.edu Charles Marslett STB Systems, Inc. <-- apply all standard disclaimers