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: <89Feb3.212709est.2386@godzilla.eecg.toronto.edu> Summary: use large RAM buffer, response to flamefest 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> Date: Fri, 3 Feb 89 21:26:59 EST [] Gadzooks! I leave for a while to get some skiing done, and I return to a Flamefest! Rather than respond to every article, I've compiled my responses into one article. Here it is: Ray Moody writes: > Writing faster serial routines is not the right way to speed up a > communications protocol. Even with super-fast serial I/O, 100% efficiency > cannot be obtained. In order to reach 100% efficiency, it is necessary to > write serial routines that are not affected by the RS-232 interrupts. This is why I'm suggesting the use of a RAM buffer. Then you only have to deal with the disk when the buffer overflows (on receive). More about this in another paragraph. Geoffrey Welsh writes: > Yeah, we spent a bit of time thinking about that one. We were going to use > the 1750 RAM expander such that the first 512K of the download went straight > ... > However, the #1 driving force behind our software was that it work with no > extra hardware (we could just as easily have resuired that you install the > UART board I designed). Thus depending on extra RAM isn't practical. Please read the paragraph below. Joe Greco writes: > ]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. 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. > > ]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 :-) ) "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). > ] 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! ... > 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). Why doesn't the same apply to receive? If the file you are sending is less than 50K (40K if you have a full featured term program), then there's no problem (and how often do you send/receive files that are larger than 200 blocks?). If the file is larger than the buffer size, then you loose a few packets while you are saving the buffer to disk. Zmodem will recover. It's not a very pretty solution (for LARGE files), but it should work. > 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're right, you'd be S.O.L. I wonder how many people are using IEEE-488 devices? > You might also run into some flames from the 1581 folks. Eric Green came to my rescue on this one (thanks Eric!), read on... Joe Greco writes: > Eric Green writes: > ]He won't run into flames from the 1581 folks, because his product > ]already supports the '81 ;-). I just wish that "burst mode" wouldn't > > If he's on the 128, yes. If he's using device-specific programming on > the 64 designed for the 1541, no. No, Super Snapshot V4 (& V3 & V2) supports load and save speedups on 1541/71/81. Each time a load or save must be done, SS figures out which drive type is being used (limited, of course, to those it can handle, namely 1541/71/81). This takes an insignificant amount of time. Geoffrey Welsh writes: > > 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 > > That set of equations assumes that disk transmission must be stopped to > handle the RS-232 port and vice-versa. Since I was suggesting fast disk routines, this would be necessary. > > Modem speed Efficiency Efficiency > > (slow disk) (fast disk) > > 2400 290 6400 > > --------- = 0.55 ---------- = 0.96 > > 290 + 240 6400 + 240 > > In these calculations, you assume that the modem achieves its ideal > throughput. If that is the case, them simultaneous disk & RS-232 access would > mean that the net throughput was merely the slower of the two, such that 2400 > bps transfer would take place at 240 bytes/second (100%), 1200 at 120 b/s, 300 > at 30 b/s. Yup, that the upper limit. I hope this clears up my original posting. If not, I'd be happy to reply to any more comments in a few days when I return from my next trip (isn't February GREAT!). 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