Path: utzoo!utgpu!watserv1!maytag!xenitec!zswamp!root
From: root@zswamp.fidonet.org (Geoffrey Welsh)
Newsgroups: comp.sys.cbm
Subject: Re: DesTerm 2.00
Message-ID: <294.2713A6A0@zswamp.fidonet.org>
Date: Wed, 10 Oct 90 12:29:56 EDT
Organization: Izot's Swamp BBS - Kitchener, Ontario

 > From: md41@cunixb.cc.columbia.edu (Marcus  Dolengo)
 > Message-ID: <1990Oct10.025545.15627@cunixf.cc.columbia.edu>
 
 > I'd like to see new overlays, ie something with Zmodem protocol, or other
 > nice deatures that could be placed in an Overlay
 
   I have argued over ZMODEM implementation with more people than I can count.
 
   The main advantage of ZMODEM is the ability to transmit non-stop. This 
requires that the receiver be able to continue RS-232 input while writing to 
disk. In the vast majority of Commodore configurations, this is not possible; 
the timing of both the serial bus and the RS-232 port is to sensitive to allow 
them to coexist at useful speeds (i.e., 2400 or 9600).
 
   Two ways around this could exist.
 
   *SOME* configurations, specifically those with very fast or relatively 
timing-insensitive drives (REUs, hard drives, IEEE-488 devices) and with an 
NS16550AFN buffered UART installed, might be able to write the data to the 
drive while the serial chip lets the incoming data pile up. While it is 
possible to replace the 8250 in a Hatronics "HART" with an NS16550AFN, I don't 
know of any people who have done so, and the fraction of C64/C128 owners who 
even have a UART cartridge in the first place is very small.
 
   The ZMODEM specification allows for some flow control, i.e. XOFF/XON.
However, this would take away from ZMODEM its most attractive feature: its 
throughput efficiency. I submit that ZMODEM, if implemented with the pauses 
necessary to make it work with common drives, would offer *NO SIGNIFICANT 
ADVANTAGES* over YMODEM.
 
   To top it off, ZMODEM is a complex protocol. Unlike XMODEM (which was a 
"quick hack") and its derivatives (which retain most of its simplicity), 
ZMODEM requires a lot of code and would require a hell of a lot of work to 
debug.
 
   Therefore, in summary:
 
(1) ZMODEM's main advantage doesn't apply to 99% of Commodore computer 
configurations;
(2) Any claims to support ZMODEM would apply to such a small segment of the 
market that they would be likely to confuse many users;
(3) If we use a workaround, we end up no better off than we are now;
(4) Creating the situations in (2) or (3) above would require a lot of work.
 
   Given the above, WHY BOTHER?
 
   Frankly, I don't love hacking so much that I'd dedicate months of hard work 
to achieve something truly pointless. Monetarily, even the time that Matt and 
I spent working on reliable 9600 bps drivers was not very well remunerated.
 
   I'm not saying that ZMODEM is impossible - I know that it can be done. 
However, no one has yet invested the time to do it and I suspect that no one 
with the smarts to succeed would also be foolish enough to consider the task 
worthwhile.
 --  
UUCP:     watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent
Internet: root@zswamp.fidonet.org     | Kitchener, Ontario
FidoNet:  SYSOP, 1:221/171            | N2M 5E6 CANADA
Data:     (519) 742-8939              | (519) 741-9553
No one pays me enough to represent any opinions but my own.