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: <89Feb1.163849est.2383@godzilla.eecg.toronto.edu>
Summary: Just speed up the disk
Keywords: XMODEM, fast disk I/O
Organization: EECG, University of Toronto
References: <1446.23E5B7F0@isishq.FIDONET.ORG> <707@csd4.milw.wisc.edu>
Date: Wed, 1 Feb 89 16:38:37 EST

In article <707@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes:
>In comp.sys.cbm article <1446.23E5B7F0@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) wrote:
 ...
>]because the C64 couldn't run the serial printer/disk bus reliably while 
>]receiving on the RS-232 port. This has also prevented C64 implementations of 
>]high-throughput streaming protocols like ZMODEM.
 ...
>]   On the other hand, my RS-232 drivers were written to execute as quickly as 
>]possible (to the point where obscure code was used because it acheived the 
 ...
>]   Given the new, much briefer NMI interruptions caused by the RS-232 I/O, it 
>]might be possible to run the serial port while receiving on the RS-232 port! 

 ... extra details given ...

>]or even 300 bps. Here is a POSSIBLE chart of improvements for downloading a 
>]10K file to a 1541:
>] 
>]           XMODEM          ZMODEM
>]Speed   % eff.  time    % eff.  time
>] 
>]2400    60%     1m 10s  95%     0m 45s
>]1200    70%     2m      95%     1m 30s
>]300     75%     7m 25s  95%     5m 50s
>] 
>]   You'll notice that XMODEM efficiency decreases with increasing speed; that 
>
>Of course.... the same reason that C1 really falls apart at 9600 :-)
 ...
>]is because, although the data transfer goes faster, the disk writes and 
>]handshaking delays do not, meaning that doubling the speed does not double the 
 ...
>AND THE RECEIVING COMPUTER CAN HACK IT!  With such slowwwwwww 1541
>transfer rates, I wonder if this is feasible at 2400 baud.  Nice
						 ^^^^^^^^^
		Just barely, read on...
 ...
>]   Comments welcome.
>]   Geoff

OK, here goes.  Your idea about simultaneous RS-232 and serial port access
is quite interesting, but this scheme would limit the effective transfer
rate to the disk transfer rate.  First let's try to figure out what that
really is:

A disk copier using standard serial communications can read a 1541 disk in
about 10 mins.  Thats 173K/10mins, or about 290 bytes/sec.  If we assume
that 10 bits are required for each byte sent over an RS-232 connection
(let's not get too picky :-)), then 2400bps works out to about 240 bytes/sec.

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
routines to read/write the file.  Using these disk routines eliminate the
possibility of simultaneous access to RS-232 and disk, but you gain a lot
from the faster disk access.
	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.

	Transfer time (t) = size/(Tx speed)

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

Modem speed	Efficiency		Efficiency
		(slow disk)		(fast disk)
2400		   290			   6400
		--------- = 0.55	---------- = 0.96
		290 + 240		6400 + 240

1200		   290			   6400
		--------- = 0.71	---------- = 0.98
		290 + 120		6400 + 120

This effectively eliminates disk transfers from the transmission time.  If
you want to transfer files at 4800bps, you would have no choice but to speed
up disk access to get any real benefit.

All right, flame away! :-)

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

