Path: utzoo!utgpu!watmath!isishq!f171.n221.z1.FIDONET.ORG!izot
From: izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh)
Newsgroups: comp.sys.cbm
Subject: ZMODEM using REUs
Message-ID: <2177.24553F58@isishq.FIDONET.ORG>
Date: 25 Apr 89 13:48:54 GMT
Sender: ufgate@isishq.FIDONET.ORG (newsout1.25)
Organization: FidoNet node 1:221/171 - Izot's Swamp, Kitchener ON
Lines: 33


 > From: leblanc@eecg.toronto.edu (Marcel LeBlanc)
 > Message-ID: <89Apr24.010003edt.2376@godzilla.eecg.toronto.edu>
 
 > 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.
 
   Your calculations are accurate. I'm pretty sure that none of our routines 
run longer than 144 clock cycles (ironically, the last bit takes the longest 
to process because the byte has to be placed in an indexed buffer that might 
be full). Your idea is worth a look, but not for ZMODEM, which is frankly too 
complex to code from scratch in 6502, given the small monetary advantage it 
might offer.
 


--  
 Geoffrey Welsh - via FidoNet node 1:221/162
     UUCP: ...!watmath!isishq!171!izot
 Internet: izot@f171.n221.z1.FIDONET.ORG