🚀 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]]);}

ajb92@ecs.soton.ac.uk (A J Bryant) writes:

>A REAL PROJECT !!

Ohh, mummy, look! 8)

>I am attempting to design and build a video capture card for a PC.  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)

That's also pretty much beyond the sort of sustained data rate that you can
expect to move around inside an ISA PC.  How do you arrive at this number?

>I know that it is possible to setup a DMA transfer from a port to a chunk
>of memory, but what I really need is to setup a transfer directly from a
>port to disk.  Is this possible?  If I have to DMA from the port to memory,
>and then out again to disk, I suspect that the system will not be fast
>enough.

You're absolutely correct.

>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.

The ATA spec offers DMA as an option.  Most "old IDE harddisks" are actually
emulations of the WD1003 (which is where IDE comes from, says it all really)
and don't support DMA.  The fastest way to transfer data to the HD is via
programmed IO. (ie. copying it through yourself.)

>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.

You would also need to implement a DMA busmaster on the card to do what you 
want to do, and then look for a new and expensive IDE harddisk that will
understand when you try to DMA to it.  What's the need for DP ram if
you're only talking to it once?

>I would like to dump the data to a standard file, but I could try just
>dropping the data onto a particular chunk of disk.  (very carefully!)

That's even worse 8) - are you planning on implementing a minimalist FAT
filesystem in firmware on your card?

>If anyone is interested in following this project, email me and I will
>start a distribution list, otherwise please comment.

I'd be interested to hear what other people have to say, but my experience
says you're short about 50% of the bandwidth you need.

>Thanks, Andy.

--
# mike smith : miff@apanix.apana.org.au - Silicon grease monkey        #
# "The question 'why are the fundamental laws of nature mathematical'  #
# then invites the trivial response 'because we define as fundamental  #
# those laws which are mathematical'". Paul Davies, _The_Mind_of_God_. #