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: custom serial I/O, RS-232, zmodem
Message-ID: <779@csd4.milw.wisc.edu>
Date: 5 Feb 89 01:48:15 GMT
References: <738@csd4.milw.wisc.edu> <7023@killer.DALLAS.TX.US> <765@csd4.milw.wisc.edu> <89Feb3.212709est.2386@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: 127

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)