> Given that the 6Mhz, a bus cycle is .166us.
> Read requests to the memory require 4/5 cycle (?)
> so the time to read each word will be about .8us
> The total read time is is going to be 3500*.8us =  2.8ms

OK.

> What is the relationship between motherboard clock cycles
> (486 dx2/66) and ISA bus cycles?

Whatever is convenient for the designer.  :-)  The ISA bus is not supposed
to be clocked faster than 8MHz.  Some boards supply an 8Mhz oscillator,
and run it completely asynchronous.  Other designers would take the 66MHz
clock, divide it by 8, and count on your not knowing their home phone number
when your board that won't work at 8.25MHz fails.  :-)

> for a memory to memory move from memory on the ISA bus to
> memory on the motherboard 4 cycles at 33Mhz + 4 cycles at 6 Mhz
> or are they overlapped somehow??

If you're doing programmed I/O, there will be essentially no overlap (other
than what caching causes (and we just went over what a horror show write-
back caching is on many x86 boxes :-) )).

> The disk controller is a VLB controller, if there are DMA tranfers
> to the disk in progress will this slow the transfers from the ISA bus?

I would certainly hope so :-).  Actually, the DMA transfers from the VLB to
memory shouldn't slow the ISA bus transfers (except by getting in the way of
instruction fetches) but they will obviously slow the writes into main memory.

> Let's assume a total memory to memory transfer time of 5ms/frame
> and that frames are arriving every 36ms, is this a reasonable rate
> for a PC to handle? If not what is a good upper boundry.

You're talking about averaging 200KB/sec, which even a PC can handle.
The only question is how to make it handle it.

> Are other drivers going to get upset that one ISR is taking so much time?

Locking out interrupts for 2.8ms?  Don't plan on having a high-speed PPP link
going at the same time, one entire 16650 FIFO worth of characters at 57600
takes less time than that!  (Thanks for reminding me that I want to look into
instrumenting spl() to find out why I can't handle 57600 ppp with the default
FIFO settings...)

What I would personally recommend is to design the board to do DMA.  DMA
just isn't that hard to get right, and the PC even offers a set of built-in
DMA channels to do half the work.  (Do it wrong, probably, but at least they
tried. :-)  That way, all your ISR has to do is say "thanks for the data,
here's the next buffer" and be on its merry way.  (Or possibly freeze the
DMA channel, copy out of the buffer, and thaw it again.  That potentially
requires deep FIFOs on the board, which hardware guys seem to like but I've
become severely allergic to in years past :-)

If you put some serious intelligence on the board, you can even have the
board do scatter/gather DMA directly into mbufs.  I'm a little leery of that,
since you need to have a piece of "hardware" understand the layout of a 
software structure, which might change -- unless part of your initialization
dance is describing the mbuf layout to the firmware, or even downloading the
firmware to the board.