Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!mit-eddie!killer!elg
From: elg@killer.DALLAS.TX.US (Eric Green)
Newsgroups: comp.sys.cbm
Subject: Re: Zmodem on commodores?
Message-ID: <7050@killer.DALLAS.TX.US>
Date: 6 Feb 89 04:37:48 GMT
References: <766@csd4.milw.wisc.edu>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 32

in article <766@csd4.milw.wisc.edu>, jgreco@csd4.milw.wisc.edu (Joe Greco) says:
> In comp.sys.cbm article <14246@cup.portal.com>, Brendan@cup.portal.com (Brendan P Kehoe) wrote:
>> What I've been experimenting with is using the REU...receive like 16k then
>>throw it into the reu then let the zmodem routine keep on buzzing happily
>>since a dma call takes virtually no time..hmm....any suggestions?
> First, the REU access would probably kill one or two incoming
> characters.   DMA has a nasty habit of interrupting the NMI timing
> because the processor cannot service the NMI.

Solvable. Zmodem allows flow control. Do a control-S, wait until the
flow of characters in stops, then do your DMA. Send a control-Q, then
restart. 

The reason this can't be used for everything is that Zmodem also has
strict timeout requirements for flow control. If you don't control-Q
for awhile, Zmodem will assume you barfed and will go away. The REU is
plenty fast to get around this problem. The 1541 may not be.

One problem is that the regular RS232 routines have trouble sending
and recieving at the same time, so sending a control-S could barfle an
incoming character....

> Second, one could not download files larger than {128K, 256K, 512K}.

Is that really a limitation? I rarely see files bigger than 300 blocks
(half a 1541), because most people use ARC or LYNX with a single
1541 drive and couldn't de-archive anything bigger than 80K.

--
|    // Eric Lee Green              P.O. Box 92191, Lafayette, LA 70509     |
|   //  ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg     (318)989-9849     |
| \X/              >> In Hell you need 4Mb to Multitask <<                  |