izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (01/28/89)
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.
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.
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
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
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.
Geoff
uucp: watmath!isishq!izot
internet: Geoffrey.Welsh@f171.n221.z1.FIDONET.org
"I've posted my full sig to this newsgroup enough this week"
--
Geoffrey Welsh - via FidoNet node 1:221/162
UUCP: ...!watmath!isishq!171!izot
Internet: izot@f171.n221.z1.FIDONET.ORGleblanc@eecg.toronto.edu (Marcel LeBlanc) (02/02/89)
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
jgreco@csd4.milw.wisc.edu (Joe Greco) (02/02/89)
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)
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (02/03/89)
> From: leblanc@eecg.toronto.edu (Marcel LeBlanc) > Message-ID: <89Feb1.163849est.2383@godzilla.eecg.toronto.edu> > ... 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. 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 into RAM; any data received after the 512K was full would result in the OLDEST data block in RAM being written out. This overcame the problem of not being able to download files larger than your available RAM (i.e. we thought of your solution, and even refined it slightly). 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. > 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. But that is exactly the barrier that I am suggesting to break. You are saying that, asuming that the status quo is unchangeable, the status quo cannot be changed. You miss the point of the suggestion. > 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. > If you want to transfer files at 4800bps, you would have no choice > but to speed up disk access to get any real benefit. That is inevitable at baud rates above 2400. > All right, flame away! :-) I think I did enough, a couple of paragraphs back. Geoff ( watmath!isishq!izot ) -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
jgreco@csd4.milw.wisc.edu (Joe Greco) (02/03/89)
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)
ray@maxwell.physics.purdue.edu (Ray Moody) (02/03/89)
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. Ray
elg@killer.DALLAS.TX.US (Eric Green) (02/03/89)
in article <738@csd4.milw.wisc.edu>, jgreco@csd4.milw.wisc.edu (Joe Greco) says: > In comp.sys.cbm article <89Feb1.163849est.2383@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) wrote: > ]about 10 mins. Thats 173K/10mins, or about 290 bytes/sec. If we assume > 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.... I informally clocked it at around 360-380cps, doing a "load" using normal Kernel routines (which is just calling the normal serial get-a-char routine). As for the 1541's slow write time, I have NOT clocked that recently, but would assume it's slower than the read times, especially considering its design. > ]obvious solution: read from/save to a RAM buffer, and use fast disk I/O This is, certainly, an obvious solution (you might remember, Marcel, that I suggested this as a way of speeding up sequential file access). It needn't be a large RAM buffer. Even buffering just 1 block at a time would be worthwhile. Just compare C-128 Burst Mode speeds with C-128 Fast Mode speeds.... Burst Mode transfers the bytes at the same rate, but blows off per-byte negotiations (uses per-block negotiation), and is considerably faster (4 or 5 times so on reads, much less so on writes because of the design of the 1541/1571). Another solution to the disk drive speed problem would be to use a 128 with a 1581 ;-). If you're really wanting to use your 64 to do it, there should be products out there that add fast serial to your 64. Note: "burst mode" is NOT a software product. People who say they give you "burst mode" with a software cartridge that plugs into your computer are LYING. Burst mode requires hardware, whether via hacking the insides of your 64, or adding an external CIA (fast mode & burst mode use the internal shift register of a CIA to shift data in and out under hardware control, at 256kbps or 1 bit per every 4 clock cycles). I don't know whether advertisers are simply ignorant, or are trying to decieve, but that's something to think about. Of course, hardware burst mode isn't cheap... I once estimated that it would cost at least $100 for a company to make money off the easiest-to-install setup (external CIA, buffers, & bank-switching ROM, with only two jumpers into the internals of your computer). > > 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. 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 be used in conjunction with such software speedups... because true burstmode is at least twice as fast as anything you can do with software (256kbps, 25 kbytes/second, but that's slowed slightly because you do have to toggle the clock after each byte transfer, fetch the byte out of memory, etc.). -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ >> In Hell you need 4Mb to Multitask << |
jgreco@csd4.milw.wisc.edu (Joe Greco) (02/03/89)
In comp.sys.cbm article <1939@pur-phy>, ray@maxwell.physics.purdue.edu (Ray Moody) wrote: > 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. That's what Geoff and I are talking about. Geoff suggested that his "FASTERM" drivers might be able to exist within the timeout limits of the serial bus, which would mean that it just might be possible! (theory and real life are different things, of course) :-) . 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)
jgreco@csd4.milw.wisc.edu (Joe Greco) (02/04/89)
In comp.sys.cbm article <7023@killer.DALLAS.TX.US>, elg@killer.DALLAS.TX.US (Eric Green) wrote: ]> 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.... ]I informally clocked it at around 360-380cps, doing a "load" using ]normal Kernel routines (which is just calling the normal serial ]get-a-char routine). That still requires that the drive catch up with the serial bus. That's like telling me how fast a sports car can go by driving it behind a bus.... you are limited by the speed of the bus (1541). ]Another solution to the disk drive speed problem would be to use a 128 ]with a 1581 ;-). If you're really wanting to use your 64 to do it, ]there should be products out there that add fast serial to your 64. But it shouldn't have to require such a product! Or a 128/1581. That's a nonsolution. ]> 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. ] ]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. -- 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)
leblanc@eecg.toronto.edu (Marcel LeBlanc) (02/04/89)
[] 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
jgreco@csd4.milw.wisc.edu (Joe Greco) (02/05/89)
In comp.sys.cbm article <89Feb3.212709est.2386@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) wrote: ]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. I don't intend to use a terminal program that has the sole function of performing Z-Modem transfers. A Real Terminal Program would be much larger. RAM buffers are STILL limited in size... more on this in a minute. ]> 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). We don't give a darn about load/save speedup, we are talking read and write. Load/save doesn't relate to the protocol problem (yes, I realize that it is possible to use SAVE to append to a file, but most fast-save cartridges probably do not have that ability.) Requiring the use of such a device would still lock out owners of non-compatible equipment, which is bad bad bad. ]> ] 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 ^^^ BobsTerm is full featured. 28,500 bytes free :-) ]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. Then you've lost the point. First, with short files, one doesn't GIVE a darn whether X-Modem or Z-Modem is used. There isn't a lot of difference. Saving even a 28K buffer to disk takes minutes, and most protocols will TIME OUT and abort (Z-Modem can resume a transfer, of course, but I doubt I will live to see even a half baked CBM implementation). I don't use Z-Modem for multiple file transfer, which is possibly the only use it would have with such a "buffering" method. I'm used to packing the files into one archive anyways. ]> 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? I know quite a few. Most of the serious Commodore hackers in the local area.... ]> 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. We still don't give a darn about SSV4 or whatever, since it would require something besides a basic setup (it would require the cartridge), and it would force one to use a "compatible" drive. I don't know about everyone else, but I get real ticked when I find out I have to downgrade to 1541 to do file transfers. I prefer the storage capacity of my 8050's.... Ray Moody, please fix Kermit so that it works correctly with IEEE! :-) ]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. What about "slow" disk routines and fast RS232? Geoff is the god of RS232 software (grin)! ]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!). P.S. This isn't a flame war, or isn't meant as one, but I want to get the point through to you that basing a program on something like SSV4 is a little limiting. -- 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)
leblanc@eecg.toronto.edu (Marcel LeBlanc) (02/08/89)
In article <779@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes: >In comp.sys.cbm article <89Feb3.212709est.2386@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) wrote: >]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. > >I don't intend to use a terminal program that has the sole function of >performing Z-Modem transfers. A Real Terminal Program would be much larger. I agree, but since we are dealing with large transfers (whether a single large file or multiple smaller files), we might be willing to load an overlay that will only handle the zmodem transfer. >]"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). > >write. Load/save doesn't relate to the protocol problem (yes, I ... >the use of such a device would still lock out owners of non-compatible >equipment, which is bad bad bad. We still agree :-). Load and save are not good solutions if you want to be able to deal with files that are larger than the buffer size. The reason I talked about load/save speedups is to demonstrate the effect fast I/O (I know, device specific) would have on transfer efficiency (remember that I gave some idealized equations?). This was assuming that disk and RS-232 accesses could not be made simultaneously. Using a large buffer just helps us get a little closer to ideal transfer efficiency under this assumption. Since a high-speed transfer program will require new RS-232 routines, it seems reasonable to include new disk routines. Read and write of sequential files can be made faster using the same techniques as are used in fast load/save. If we are going to make use of a large transmit/receive buffer, then disk accesses must be made faster than can be achieved with the ROM routines on the C64. At the moment, I can think of three alternatives, depending on your configuration. Read/write transmit/receive buffer using: 1) Software only: Use custom read/write routines to speed up access to 1541/71/81. 2) IEEE interface and IEEE drives. Use the routines built into the interface to handle the transfer. 3) REUs. Owners of 1750/64/00 REUs could make use of standard ramdos software. The proper driver can be called when the receive buffer overflows (for example). This would require the user to select which device is to be used when the program starts up (a default could be selected from a configuration file). >]You're right, you'd be S.O.L. I wonder how many people are using IEEE-488 >]devices? > >I know quite a few. Most of the serious Commodore hackers in the >local area.... That's interesting. Actually, no one I know has IEEE drives. Before the original Epyx FastLoad appeared, I knew several people who owned IEEE drives. When I decided (2 yrs ago) that 1571 drives didn't give me enough storage, I considered getting an IEEE drive, but then I learned about the new 1581 drives that had been announced. I managed to get two from Commodore, and I'm glad I did. It loads much faster than IEEE drives (my assembler LOADs include files, taking maximum advantage of load speed), and has good storage capacity (800K vs 1M for 8250). >We still don't give a darn about SSV4 or whatever, since it would I'm sorry to hear that! :-) This discussion is getting interesting-er (!). It should be possible to satisfy the requirements of people using vastly different storage devices, instead of just the more common 1541/71/81. 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
jgreco@csd4.milw.wisc.edu (Joe Greco) (02/09/89)
In comp.sys.cbm article <89Feb7.220647est.2663@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) wrote:
]In article <779@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes:
]>In comp.sys.cbm article <89Feb3.212709est.2386@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) wrote:
]>I don't intend to use a terminal program that has the sole function of
]>performing Z-Modem transfers. A Real Terminal Program would be much larger.
]
]I agree, but since we are dealing with large transfers (whether a single
]large file or multiple smaller files), we might be willing to load an
]overlay that will only handle the zmodem transfer.
and clobber my buffer, like as in BobsTerm Pro 64? Barf ick....
well, it IS a reasonable suggestion.
] Read/write transmit/receive buffer using:
] 1) Software only: Use custom read/write routines to speed up access to
] 1541/71/81.
]
] 2) IEEE interface and IEEE drives. Use the routines built into the
] interface to handle the transfer.
]
] 3) REUs. Owners of 1750/64/00 REUs could make use of standard ramdos
] software.
]
]The proper driver can be called when the receive buffer overflows (for
]example). This would require the user to select which device is to be used
]when the program starts up (a default could be selected from a configuration
]file).
That sounds fine, 'cept there's no reason that you'd need to buffer
with IEEE, and sending a block to the REU would cause a bad Z-Modem
block. RAMDOS (or any REU access) will momentarily suspend the CPU's
operations to perform the transfer.
]>I know quite a few. Most of the serious Commodore hackers in the
]>local area....
]
]That's interesting. Actually, no one I know has IEEE drives. Before the
]original Epyx FastLoad appeared, I knew several people who owned IEEE
Local PunterNet SysOps, a few local C-Net SysOps.... I have three
8050's and two 4040's myself.... (consider it a "serious investment"
and maybe you will begin to see my side a little more clearly)
]drives. When I decided (2 yrs ago) that 1571 drives didn't give me enough
]storage, I considered getting an IEEE drive, but then I learned about the
]new 1581 drives that had been announced. I managed to get two from
]Commodore, and I'm glad I did. It loads much faster than IEEE drives (my
]assembler LOADs include files, taking maximum advantage of load speed), and
]has good storage capacity (800K vs 1M for 8250).
IF you're on a 128, or IF you're on a 64 with some sort of fastloader.
Which is still only a marginal speedup, considering that file based
operations are not enhanced by such devices. (Since that's the major
type of operation I need around here, that's what I look at.) BLITZ!
isn't speeded up at all by FastLoad... hehehe
by the way, 2M for 8250. It's a dual drive unit.
]>We still don't give a darn about SSV4 or whatever, since it would
]
]I'm sorry to hear that! :-)
Well, how does it help me? Does SSVx have anything desirable that
either a BusCard II, ISEPIC, and/or SysRes doesn't? I'm open minded..
]This discussion is getting interesting-er (!). It should be possible to
]satisfy the requirements of people using vastly different storage devices,
]instead of just the more common 1541/71/81.
That would please me immensely... :-)
--
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)