Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!husc6!think!ames!haven!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!portal!cup.portal.com!Brendan
From: Brendan@cup.portal.com (Brendan P Kehoe)
Newsgroups: comp.sys.cbm
Subject: Re: Zmodem on commodores?
Message-ID: <14349@cup.portal.com>
Date: 5 Feb 89 21:40:59 GMT
References: <10978@s.ms.uky.edu> <14095@cup.portal.com> <683@csd4.milw.wisc.edu> <6482@emcard.UUCP> <14246@cup.portal.com> <766@csd4.milw.wisc.edu>
Distribution: usa
Organization: The Portal System (TM)
Lines: 29

In comp.sys.cbm article <766@csd4.milw.wisc.edu>, jgreco@csd4.milw.wisc.edu
   writes:
>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.
>
>Second, one could not download files larger than {128K, 256K, 512K}.

 The reason I thought of using the REU was because of their capacity; I don't
often download programs larger than, say, 500 blocks (approx 124k)...the
1750 would more than do for this..anyway...can you think of a way to
shield the rs232 incoming line and the triggering of the nmi from the
dma call without a break in tempo? If we could figure out a way to keep
the dma from slamming the nmi's, we may be on to something here.

>
>Nice idea, otherwise.
>--
>jgreco@csd4.milw.wisc.edu		Joe Greco at FidoNet 1:154/200
>USnail: 9905 W Montana Ave			     PunterNet Node 30 or 31
>	West Allis, WI  53227-3329	"These aren't anybody's opinions."
>Voice:	414/321-6184			Data: 414/321-9287 (Happy Hacker's BBS)

Brendan@cup.portal.com