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
Message-ID: <707@csd4.milw.wisc.edu>
Date: 1 Feb 89 17:05:26 GMT
References: <1446.23E5B7F0@isishq.FIDONET.ORG>
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: 74

In comp.sys.cbm article <1446.23E5B7F0@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) wrote:
]Joe:
] 
]   When the C64 first came out and Steve Punter's simple terminal was ported 
]from Pet to 64, the only change was that the printer log option was removed 
]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.

Correct, this has always been my point.  That's why I prefer IEEE, and
that's one reason Steve INSISTS on IEEE (grin)....  I suspect that
ZMODEM could easily be written for the IEEE bus.

]   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 
]same effect in one or two less clock cycles), and I have a theory:
] 
]   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! 
]Serial port timing specs show that the most stringent handshaking requirement 
]is 200 microseconds, and I think that my NMI code runs under 100 clock cycles 
]for the most part. Thus, an interrupted handshake would be resumed and 
]completed before the timeout caused hanging problems.

Perhaps.  Perhaps not.  Both still are picky in the timing
requirements, and it would need to be totally reliable.

]   I have yet to test this theory, but high-throughput protocols could be 
]a real boon to C64 and C128 users trying to download long files at 2400, 1200, 
]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 :-)
This has always been an argument of mine favoring use of X-MODEM on
the Commodore [people are always trying to convince me that C1 is
faster and their faces drop when I prove them wrong]

]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 
]transfer rate. With ZMODEM, which never stops transmitting, near-100% 
]efficiencies are possible at ANY baud rate (assuming that the transmaiiting 
]computer can fetch the data as fast as it can transmit it; when uploading from 

AND THE RECEIVING COMPUTER CAN HACK IT!  With such slowwwwwww 1541
transfer rates, I wonder if this is feasible at 2400 baud.  Nice
concept, and it could well work at 1200, but I'd bet that it would be
unreliable at best at 2400.  I would just LOVE to be proved wrong
(don't get me wrong, I'm all for it if it can be done).

]a C64 using XMODEM, 4800 bps isn't much faster than 2400 bps because of the 
]time it takes to open a channel to the 1541, read the data, and then close the 
]channel again).
] 
]   Comments welcome.

Comments?  Who, me?  ;-)

]   Geoff

.									JG
--
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)