🚀 go-pugleaf

In article <8909182019.AA06478@postgres.Berkeley.EDU> Matt Dillon writes:
>	As far as the serial port goes, no, a bit is not the same
>    trouble as a byte on the parallel port.  You write bytes to the
>    serial port register not bits so the trouble is the same.

I meant, in essence, "the same trouble to the hardware".  i.e. if it can
change the state of the serial data line 56K times/sec., it's pretty
reasonable that it'd be able to change ALL the parallel lines 56K/sec.
But you're saying 28K/sec. is a software limit, so hardware capability
isn't even at question.

>	The current 28KBytes/sec throughput I'm getting over the
>    parallel port is about 35uS/byte.  Most of the time is spent
>    hand-shaking between the computers.  With the Amiga you can't
>    count cycles like you could on the old C64's and PETs so you
>    have to handshake.

>	I've heard people running the serial port at 262KBaud 
>    (26KBytes/sec).  The only way this can be done that I can think
>    of is (1) The machine must have FAST memory so the video doesn't
>    interfere, and (2) Interrupts must be disabled during the transfer. 
>    That might be good for a hack file transfer but I can't make those
>    assumptions for interactive usage.

What happens if you Forbid() as the block starts, can you get away with
cycle counting?  If the blocks are short enough this should not affect
the rest of the system.  (e.g. suppose this gets it down to 15uS/byte;
at 64 bytes/block that's about 1ms, just barely short enough to not
interfere with 9600bps serial I/O -- hopefully).  You could let the
user set max. block length and whether to use handshaking or cycle
counting.  You could even have a library to allow programs to change that;
and include a user agent that lets the user directly set them with
sliders etc.  The same idea should apply to the serial port: crank it
up to 262Kbps or whatever, and transfer small packets within Forbid().
You >can< get away with these assumptions for interactive usage, if you
never stop the machine for long enough for a user to notice.  1ms is
fine.  The receiver should in general control the transfer, asking for
another block when it is given CPU time.  Transfer rate would vary a lot
according to system load, but that's normal.

Bela Lubkin     * *   filbo@gorn.santa-cruz.ca.us   CIS: 73047,1112
     @        * *     ...ucbvax!ucscc!gorn!filbo    ^^^  REALLY slow [months]
R Pentomino     *     Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945