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: <89Feb7.220647est.2663@godzilla.eecg.toronto.edu>
Summary: No extra hardware, just software.
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> <89Feb3.212709est.2386@godzilla.eecg.toronto.edu> <779@csd4.milw.wisc.edu>
Date: Tue, 7 Feb 89 22:06:36 EST

In article <779@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes:
>In comp.sys.cbm article <89Feb3.212709est.2386@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) wrote:
>]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.
>
>I don't intend to use a terminal program that has the sole function of
>performing Z-Modem transfers.  A Real Terminal Program would be much larger.

I agree, but since we are dealing with large transfers (whether a single
large file or multiple smaller files), we might be willing to load an
overlay that will only handle the zmodem transfer.

>]"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).
>
>write.  Load/save doesn't relate to the protocol problem (yes, I
 ...
>the use of such a device would still lock out owners of non-compatible
>equipment, which is bad bad bad.

We still agree :-).  Load and save are not good solutions if you want to be
able to deal with files that are larger than the buffer size.  The reason I
talked about load/save speedups is to demonstrate the effect fast I/O (I
know, device specific) would have on transfer efficiency (remember that I
gave some idealized equations?).  This was assuming that disk and RS-232
accesses could not be made simultaneously.  Using a large buffer just helps
us get a little closer to ideal transfer efficiency under this assumption.
Since a high-speed transfer program will require new RS-232 routines, it
seems reasonable to include new disk routines.  Read and write of sequential
files can be made faster using the same techniques as are used in fast
load/save.  If we are going to make use of a large transmit/receive buffer,
then disk accesses must be made faster than can be achieved with the ROM
routines on the C64.  At the moment, I can think of three alternatives,
depending on your configuration.

  Read/write transmit/receive buffer using:
  1) Software only:  Use custom read/write routines to speed up access to 
  1541/71/81.

  2) IEEE interface and IEEE drives.  Use the routines built into the
  interface to handle the transfer.

  3) REUs.  Owners of 1750/64/00 REUs could make use of standard ramdos
  software.  

The proper driver can be called when the receive buffer overflows (for
example).  This would require the user to select which device is to be used
when the program starts up (a default could be selected from a configuration
file).

>]You're right, you'd be S.O.L.  I wonder how many people are using IEEE-488
>]devices?
>
>I know quite a few.  Most of the serious Commodore hackers in the
>local area....

That's interesting.  Actually, no one I know has IEEE drives.  Before the
original Epyx FastLoad appeared, I knew several people who owned IEEE
drives.  When I decided (2 yrs ago) that 1571 drives didn't give me enough
storage, I considered getting an IEEE drive, but then I learned about the
new 1581 drives that had been announced.  I managed to get two from
Commodore, and I'm glad I did.  It loads much faster than IEEE drives (my
assembler LOADs include files, taking maximum advantage of load speed), and
has good storage capacity (800K vs 1M for 8250).

>We still don't give a darn about SSV4 or whatever, since it would

I'm sorry to hear that! :-)

This discussion is getting interesting-er (!).  It should be possible to
satisfy the requirements of people using vastly different storage devices,
instead of just the more common 1541/71/81.

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