🚀 go-pugleaf

In article <48pko1$63g@unidhp.uni-c.dk>, Rask Lambertsen writes:

> I think it is a good idea to use the floppy port, but it is not easy:
> 
> Start and stop bits.

A byte can begin anytime (indicated by the start bit).  To stay in sync
with the sender, our expansion has to be handle them in hardware.

> Unknown DMA lengths (how do we know how much to transfer?)

The expansion could send a length information in front of the data.  The
computer could always read a fixed length buffer, and afterwards discard
unwanted data.

The hardware fifo buffer must have a certain size.  A DD floppy drive reads
about  12K/sec,  one  track  holds about 6K of data.  One can safely assume
that  normal  floppy  drive operation blocks the DMA channel for reading AT
LEAST  one  track in one go.  This means our hardware fifo buffer must hold
minimum 0.5sec of serial data, or 1 sec if HD drives are installed.

At  115,200bps  this  requires  5,760 bytes (11,520 for HD) of fifo buffer!
Assuming  there's  an  OS  legal  way to split up multitrack (or -diskside)
floppy drive operations - which I didn't verify.

Unfortunatly, on low-end computers floppy and serial operations always
appear simultanously (downloading a file to disk).


Possibly our device, can talk to the computer by the INDEX (FLAG) signal to
inform  it  about  incoming  data.  It causes an CIA-B interrupt.  I didn't
check  however,  whether we can share it with trackdisk.device, and whether
it  is active all the time (maybe AND'ed with SELx?).  Otherwise the driver
software  would have to read the hardware buffer regularily in certain time
intervals - slowing down floppy drive operation.


Less complex, it think, is my first proposal:  plug the hardware into the
internal serial/parallel port, and decouple the bps rate.