🚀 go-pugleaf

In article <37dpj2$agm@bosch.ecs.soton.ac.uk>,
A J Bryant <ajb92@ecs.soton.ac.uk> wrote:
>A REAL PROJECT !!

>I am attempting to design and build a video capture card for a PC.

I've done a few of these: how are you synchronizing the dot-clock?

>I want
>to transfer 8bit b&w video data from a standard ISA card directly to the
>hard disk.  The data rate will be approx 500kbytes/s which I believe is the
>maximum capability of most old IDE HDDs.  (I don't have the budget for a
>fast IDE or SCSI)

Good-luck.  16-bit hard drive controllers do not use DMA.  (Prove it to
yourself- see where the DMA request lines go to on your controller board).

>I have heard the rumour that standard IDE does not support DMA transfers.
>This seems a little strange as the ATA interface does support DMA.  Where
>does the inconsistency arise?  And what is the best way to transfer large
>amounts of data, quickly to the HDD.

DMA is very slow.  Less than 100K/sec.  When they upgraded to 386 and 486,
they didn't bother to improve the dma controller.  Take a look at the bus on
a 386SX (which actually still puts its memory traffic on the bus) during dma
transfers with an oscillicope: You'll see lots of noise (which is the normal
bus data) interspersed with wide 4us dma pulses.  Supposedly there are a few
motherboards with faster dma, but I've never seen one.

The fastest way to transfer data is to use a software loop (specifically a
'rep ins' sequence).  Another way is to use an adaptech scsi card, which
takes over the bus and reads from an address directly by generating all of
the bus signals.

>To give some background on the hardware, I plan to use dual port RAM on the
>card to buffer the data.  Control electronics on the card would control the 
>capture of the data, to one 'page' of ram, while the computer is pulling
>data from the other 'page' of ram via DMA.  At the end of a frame, the
>'pages' are swapped.  I plan to capture about 60 sec video data to a 40M
>HDD file.  The specification disallows lossy compression, making MPEG a bit
>of a non winner.  I could use compression, but that would probably need to
>be implemented in hardware on the card.

60 sec of raw video is much more than 40MB.  It's more like 200MB (64K/field
times 3600 fields).

This is a data-rate of about 4MB/sec.  It will be nearly impossible to
actually get that rate on the AT bus.  You have to be transferring 16-bit
words and the bus has to be properly synchronized to the CPU or whatever
device is going to read it.  There will be no bandwidth left for anything
else.

Another problem is that although the hard-drive's overall data rate is
500K/sec or more, you have to buffer enough data to actually get by the
seek, head-select and rotational delays.

Also the raw data rate from the A/D on a 4MHz video signal is at least 8MHz
(and you probably want it to be much more, unless you can make an impossibly
good anti-alias filter).  So to get it down to only 4MB sec, the logic on
the board has to cut off the blanking areas and properly organize the data
in the ram.  This sounds pretty complex.

You might be better off forgetting about the AT bus.  Have a SCSI hard-drive
connect directly to the video board and devise a means of controlling it.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}