Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!jgreco
From: jgreco@csd4.milw.wisc.edu (Joe Greco)
Newsgroups: comp.sys.cbm
Subject: Re: Simultaneous disk & RS-232 access
Keywords: XMODEM, fast disk I/O
Message-ID: <738@csd4.milw.wisc.edu>
Date: 2 Feb 89 23:00:08 GMT
References: <1446.23E5B7F0@isishq.FIDONET.ORG> <707@csd4.milw.wisc.edu> <89Feb1.163849est.2383@godzilla.eecg.toronto.edu>
Sender: news@csd4.milw.wisc.edu
Reply-To: jgreco@csd4.milw.wisc.edu (Joe Greco)
Organization: UW-Milwaukee Home for Out-of-date 8 bit Hackers
Lines: 60

In comp.sys.cbm article <89Feb1.163849est.2383@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) wrote:
]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.

I don't know where you pull these figures from.... my clocking of
serial has always been somewhat higher (perhaps 500cps).  However,
that does not account for the 1541's slow write time....

]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.

]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  :-) )

]possibility of simultaneous access to RS-232 and disk, but you gain a lot
]from the faster disk access.

Like limited compatibility... again :-)

]	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!  You can streaming-protocol send a
file with no problems since the receiver is always listening.  The
pauses caused by a 1541 momentarily fetching more data is irrelevant.
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).

]All right, flame away! :-)

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 might also run into some flames from the 1581 folks.
--
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)