[comp.sys.ibm.pc.hardware] video graphics cards

sxb@gibbon.inel.gov (Steve Bryan) (04/17/91)

Dear Gurus,

I am working on a (real-time) application that has fairly stringent 
requirements for graphics throughput.  Specifically, I have a 25 MHz
386 PC with a DSP32C DSP board in it.  The DSP board does audio data
acquisition, and a large amount of preprocessing on the data.  Every
10ms, The DSP board interrupts the host for upload of preprocessed data.
All of this works great, until I attempt to display the data acquired
in a presentation that makes sense for the application.  What I want is
a real-time spectrogram-type display that can transfer 25 or 30 narrow 
(2 pixel wide by 10 pixel high) rectangles in different colors (preferably
256, but can live with 16) to the video card every 10ms in 640x480 mode.  I 
_know_ that the display will not update that fast, these time slices can be 
transferred in a batch every 30ms, if that makes it easier to conceive.  

My current video hardware does not quite hack it (it appears to be 
roughly a factor of two too slow).  The video hardware that I currently
have is based on the Trident chipset (Able VGA).   I am using the Borland 
Graphics Interface fillrectangle calls to draw the rectangles.  I have
tried bitmaps, lines, and several other software approaches, as well as
speeding the bus up to 12.5 MHz.  I would appreciate any recommendations 
about other video cards (costing less than about $350) that would help 
with this problem.  I would be particularly interested if anyone has 
experience with VRAM-type cards used with BGI calls.

Also, if you know of any easy-to-implement VGA programming tricks that
could be employed to speed things up, I would like to hear from you.
I have seen some graphics done on my current board that looks fairly 
zippy, so I suspect that more can be done with software tricks.

Thanks.
 ____________________________________________________________________________ 
|Steven R. Bryan, Idaho National Engineering Lab.  INTERNET: sxb@INEL.GOV    |
|N7MPY            POB 1625 M.S. 1206               Phone: (208) 526-0338     |
|_________________Idaho_Falls,_Id._83415___________FAX:___(208)_526-1419_____|
========== long legal disclaimer follows, press n to skip ===========

Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights.  No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.

osmoviita@cc.helsinki.fi (04/21/91)

In article <1991Apr16.201903.27388@inel.gov>, sxb@gibbon.inel.gov (Steve Bryan) writes:
> Dear Gurus,
> 
> I am working on a (real-time) application that has fairly stringent 
> requirements for graphics throughput...

> a real-time spectrogram-type display that can transfer 25 or 30 narrow 
> (2 pixel wide by 10 pixel high) rectangles in different colors (preferably
> 256, but can live with 16) to the video card every 10ms in 640x480 mode.  I 
> _know_ that the display will not update that fast, these time slices can be 
> transferred in a batch every 30ms, if that makes it easier to conceive.  
..
> Also, if you know of any easy-to-implement VGA programming tricks that
> could be employed to speed things up, I would like to hear from you.
> I have seen some graphics done on my current board that looks fairly 
> zippy, so I suspect that more can be done with software tricks.
> 
> Thanks.                                                          

Perhaps Your card has hardware zoom. Tseng chip has it. with it you could
define for example 2x zoom horizontally and 5x zoom vertically and reduce
the amount of transferred data. I suppose you can define a part of the
screen to be zoomed and the rest to stay standard size with Tseng based
cards.

Kari Osmoviita			osmoviita@cc.helsinki.fi