Newsgroups: comp.sys.cbm
Path: utzoo!utgpu!jarvis.csri.toronto.edu!godzilla.eecg.toronto.edu!leblanc
From: leblanc@eecg.toronto.edu (Marcel LeBlanc)
Subject: Re: Simultaneous disk & RS-232 access
Message-ID: <89Feb3.212709est.2386@godzilla.eecg.toronto.edu>
Summary: use large RAM buffer, response to flamefest
Keywords: custom serial I/O, RS-232, zmodem
Organization: EECG, University of Toronto
References: <738@csd4.milw.wisc.edu> <7023@killer.DALLAS.TX.US> <765@csd4.milw.wisc.edu>
Date: Fri, 3 Feb 89 21:26:59 EST

[]
Gadzooks!  I leave for a while to get some skiing done, and I return to a
Flamefest!  Rather than respond to every article, I've compiled my responses
into one article.  Here it is:

Ray Moody writes:
>     Writing faster serial routines is not the right way to speed up a
> communications protocol.  Even with super-fast serial I/O, 100% efficiency
> cannot be obtained.  In order to reach 100% efficiency, it is necessary to
> write serial routines that are not affected by the RS-232 interrupts.

This is why I'm suggesting the use of a RAM buffer.  Then you only have to
deal with the disk when the buffer overflows (on receive).  More about this
in another paragraph.

Geoffrey Welsh writes:
>    Yeah, we spent a bit of time thinking about that one. We were going to use
> the 1750 RAM expander such that the first 512K of the download went straight 
>  ...
>    However, the #1 driving force behind our software was that it work with no 
> extra hardware (we could just as easily have resuired that you install the 
> UART board I designed). Thus depending on extra RAM isn't practical.

Please read the paragraph below.

Joe Greco writes:
> ]So your scheme (if you can make it work) would be useful to about a maximum
> ]of 2900bps.  This would probably be worthwhile, but let's look at the other
> ]obvious solution:  read from/save to a RAM buffer, and use fast disk I/O
> 
> RAM buffers are limited in size.  RAMdisk has potential problems with
> interrupting RS232 interrupts because of DMA processing.

I'm not talking about using 1750/1764 REU.  Just unused memory in the C64.
I think it's quite reasonable to expect that a term program with a moderate
number of features would fit in 12K (If you write it in assembler), leaving
up to 50K free for buffer space.

> > ]routines to read/write the file.  Using these disk routines eliminate the
> 
> What is a "fast disk I/O"?  No such thing, unless you wish to limit a
> given application to a certain drive.  (flame flame flame... both the
> concept of device specific programming and the 1541  :-) )

"Fast I/O" limits you to a fixed number of drive types, but most good
software load/save speedup cartridges will work with a number of different
drive types (another subtle plug for SS V4, which will speedup 1541/71/81).

> ]	The latest SOFTWARE ONLY load speedups (subtle plug: such as those
> ]in Super Snapshot V4 & V3) can load 202 blocks (50K) in about 8 secs.  Thats
> ]about 6.4 Kbytes/sec.  If you load the file to be transmitted into RAM first
> ](50K at a time max), then you can transmit without any delays between
> ]packets.
> 
> Transmission isn't a real problem! ...
> The REAL problem is that a streaming protocol would mean that the 64
> must be able to receive data constantly, even while performing disk
> accesses, and that has been the entire point of this discussion (as I
> see it).

Why doesn't the same apply to receive?  If the file you are sending is less
than 50K (40K if you have a full featured term program), then there's no
problem (and how often do you send/receive files that are larger than 200
blocks?).  If the file is larger than the buffer size, then you loose a few
packets while you are saving the buffer to disk.  Zmodem will recover.  It's
not a very pretty solution (for LARGE files), but it should work.

> The only thing I don't like is device specific programming.  I use CBM
> 8050 drives nearly exclusively, with a BusCard II, and nasty tricks
> like fast disk I/O won't work.  Somebody who wrote Z-Modem using a
> fast disk I/O would earn my eternal hate... hehehe

You're right, you'd be S.O.L.  I wonder how many people are using IEEE-488
devices?

> You might also run into some flames from the 1581 folks.

Eric Green came to my rescue on this one (thanks Eric!), read on...

Joe Greco writes:
> Eric Green writes:
> ]He won't run into flames from the 1581 folks, because his product
> ]already supports the '81 ;-). I just wish that "burst mode" wouldn't
> 
> If he's on the 128, yes.  If he's using device-specific programming on
> the 64 designed for the 1541, no.

No, Super Snapshot V4 (& V3 & V2) supports load and save speedups on
1541/71/81.  Each time a load or save must be done, SS figures out which
drive type is being used (limited, of course, to those it can handle, namely
1541/71/81).  This takes an insignificant amount of time.

Geoffrey Welsh writes:
>  > So the usage efficiency of the RS-232 connection is:
>  > (M is modem speed, D is disk speed).
>  >
>  >         Efficiency =     size/M                   D
>  >                         -----------------  =    -----
>  >                          size/M + size/D        D + M
>  
>    That set of equations assumes that disk transmission must be stopped to 
> handle the RS-232 port and vice-versa.

Since I was suggesting fast disk routines, this would be necessary.

>  > Modem speed     Efficiency              Efficiency
>  >                 (slow disk)             (fast disk)
>  > 2400               290                     6400
>  >                 --------- = 0.55        ---------- = 0.96
>  >                 290 + 240               6400 + 240
>  
>    In these calculations, you assume that the modem achieves its ideal 
> throughput. If that is the case, them simultaneous disk & RS-232 access would 
> mean that the net throughput was merely the slower of the two, such that 2400 
> bps transfer would take place at 240 bytes/second (100%), 1200 at 120 b/s, 300 
> at 30 b/s.

Yup, that the upper limit.

I hope this clears up my original posting.  If not, I'd be happy to reply to
any more comments in a few days when I return from my next trip (isn't
February GREAT!).

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)
ARPA:	leblanc%eecg.toronto.edu@relay.cs.net  CDNNET: <...>.toronto.cdn

