Newsgroups: comp.sys.cbm
Path: utzoo!utgpu!jarvis.csri.toronto.edu!godzilla.eecg.toronto.edu!leblanc
From: leblanc@eecg.toronto.edu (Marcel LeBlanc)
Subject: ZMODEM using REUs
Message-ID: <89Apr24.010003edt.2376@godzilla.eecg.toronto.edu>
Summary: replace disk with REU
Keywords: REU, disk, RS-232
Organization: EECG, University of Toronto
Date: Mon, 24 Apr 89 00:59:58 EDT

[]

Not that long ago, a discussion about the difficulties of implementing
ZMODEM on the C64/C128 was side-tracked by a discussion of fast disk I/O
:-).  The discussion centered around the requirement for simultaneous disk
and RS-232 processing when a file is being received.  For IEEE-488 interface
owners, this isn't too much of a problem, but the rest of us might still
have to accept droping a few packets while saving the receive buffer to
disk.  Somebody made a suggestion about REAL simultaneous disk (standard
serial) and RS-232, but I don't remember the details.  The problem with
using an REU is that the time required for the DMA transfer could cause a
few incoming RS-232 bits to be lost.  I'd like to suggest another REU
alternative:

 - use a small ZMODEM receive buffer (say 256 bytes).  When it fills, set a
flag indicating that it must be saved to the REU.
 - add a little extra code at the end of the NMI (RS-232) routine to
initiate a DMA transfer of the receive buffer to the REU.

The DMA transfer must be initiated when it is certain that no bits are about
to arrive.  The most convenient "safe" time that I can think of is at the
end of the NMI processing.  At 2400 NMIs/sec, this only allows about 400
cycles per bit.  I'm not sure if this is enough to transfer a 256 byte
buffer (400-256 cycles only leaves 144, comments Geoff?), but for higher bit
rates, the buffer size would probably have to be reduced.

Since I have no intention of ever writing these routines, they will remain
just ideas.  Any comments are welcome.  (within reason :-) )

Marcel A. LeBlanc	  | University of Toronto -- Toronto, Canada
leblanc@eecg.toronto.edu  | also: LMS Technologies Ltd, Fredericton, NB, Canada
-------------------------------------------------------------------------------
UUCP:	uunet!utai!eecg!leblanc    BITNET: leblanc@eecg.utoronto (may work)