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: Re: Zmodem on commodores?
Message-ID: <1497.23E905F8@isishq.FIDONET.ORG>
Date: 2 Feb 89 20:23:39 GMT
Sender: ufgate@isishq.FIDONET.ORG (newsout1.25)
Organization: FidoNet node 1:221/171 - Izot's Swamp, Kitchener ON
Lines: 48


 > From: mat@emcard.UUCP (W Mat Waites)
 > Message-ID: <6482@emcard.UUCP>
 
 > What ever happened to the joker who posted a couple of months ago about
 > building a real UART board?
 
   I believe there was some discussion on building boards based on the 6850 (a 
primitive ACIA) or the 6551 (a more integrated ACIA). I designed (but never 
built) a board that would allow one to use an Intel 8250 or compatible UART 
with the C64/C128. Best of all, the 8250 could be replaced by a National 
Semiconductor 16550A, which has 16-byte FIFO buffers on the input and output 
hold registers (meaning that delaying interrupt recognition for whatever 
reason would not cause bytes to be lost, and that overhead per byte could be 
reduced by writing/fetching more than one byte to/from the buffers at a time.
 
 > Surely the NMI routines run fast enough to allow response to a uart, i.e.
 > 1 interrupt per character.
 
   But the NMIs that react to each bit are no longer (in fact I'd be willing 
to bet shorter) than the NMI to pack away the byte. The difference is in how 
often they come up (i.e. how much CPU time BETWEEN interrupts, not how much 
time is spent executing them). If a UART interrupt has time to pack a byte 
into a buffer, then my routines have time to flag in one bit and shift it into 
a byte. The quesiton is, how much do we reduce the disk's speed (400 CPS on a 
good day, following a full moon, if your dinner digested well last night - Jim 
Butterfield) by stopping all the time to deal with incoming bits?
 
 > That would allow you to cut zmodem loose for 20k bytes
 > worth of data or so, and then hold up zmodem and write it all out.
 > You wouldn't acheive the max throughput of zmodem, but it would be much,
 > much better than xmodem or punter.
 
   Although ZMODEM can technically be implemented as a windowing or normal 
block-handshake protocol, I have yet to find a single implementation of ZMODEM 
that mentioned this abilility. I suspect that most existsing ZMODEM drivers 
were written to be streaming (non-stop) and would choke if any attempt was 
made to stop them (especially generating timeouts while waiting for a 1541 to 
write 20K to the disk!).
 
   Geoff ( watmath!isishq!izot )
 


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