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