joe@proto.com (Joe Huffman) (03/29/91)
bpz4r@holmes.acc.Virginia.EDU (Bernard Paul Ziegler) writes: >I'm looking for help on how to directly write to the VGA's palette >registers, in order to do quick color scrolling. Using the BIOS >functions is too slow. Does anyone know of some references for this? >I have a paradise VGA card. All VGA cards that I know of are the same in this regard. If you wait a month or so the next release of Flash Graphics for Zortech C/C++ will use direct writes to the registers with fg_setpalette() (the SCO UNIX version already does). Other than that you can get any one of various technical reference manuals from the graphics board vendors. Call up tech support and ask for a technical reference manual. Cost is from free to $50.00 (that was several years ago -- the same vendor last year was asking $10.00). I have manuals for ATI, Video 7 (Headland Technology), Trident, Genoa, etc. My preference is for the Video 7 manuals but that could be just because that was the first one I got. -- joe@proto.com
nyet@nntp-server.caltech.edu (n liu) (03/29/91)
joe@proto.com (Joe Huffman) writes: >bpz4r@holmes.acc.Virginia.EDU (Bernard Paul Ziegler) writes: >>I'm looking for help on how to directly write to the VGA's palette >>registers, in order to do quick color scrolling. Using the BIOS >>functions is too slow. Does anyone know of some references for this? >>I have a paradise VGA card. Actually, the hard part here is getting the screen updates to sync with the damn register writes so you don't get a flickering black band across the middle of your screen... I tried to write a simple one a while ago, and biffed some of the palette rotation machine code from Fractint source - it ran pretty poorly, since i'm no assembly coder. Does anybody have some good stand-alone source or object code that can be used with MSC 600 which rotates the palette quickly? I know the basics of the palette registers, so i'm more interested in the timing. From looking at the Fractint code, it seemed that after every write to the registers, they checked on the status of the screen update, and if it was incomplete, they cut the size of the block updated at once into smaller blocks - change a block, wait for update, change next block, etc., until all registers are updated. Is this an accurate guess? Or are non-bios functions fast enough to not worry about this? nye