Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!maytag!xenitec!geoffw From: geoffw@xenitec.on.ca (Geoffrey Welsh) Newsgroups: comp.sys.cbm Subject: Re: 9600 baud on the commodore Summary: Yes, it's possible! Message-ID: <1990Sep15.171530.12692@xenitec.on.ca> Date: 15 Sep 90 17:15:30 GMT References: <418@news.nd.edu> Reply-To: root@zswamp.fidonet.org (Geoffrey Welsh) Organization: XeniTec Consulting Services, Kitchener, ON, Canada Lines: 63 In article <418@news.nd.edu> treesh@bach.helios.nd.edu writes: >Is this really possible? What is the real story about this Swiftlink thing? Once again, the same question pops up. I foolishly attempt to provide a comprehensive reply for re-posting if (when) the question arises again. Comments invited. Back in the early days there was a lot of debate as to whether the C64 could do a decent job of running at 2400 bps. Since I operated a C64-based BBS, this was of concern to me. I went to great lengths to explain that, although I believed it possible, I didn't think the C64 Kernal could do a good job of it. Steve Punter had published a fudge factor that made the C64's 1200 bps timing tolerable, but the calculated factor for 2400 bps didn't take into account that the Kernal routines took awfully long to process every bit and it was possible to lock the C64's kernal drivers at 2400 bps by sending it several characters with no pauses in between. Early in '87, I decided to put my talk into code. I wrote serial drivers for the C64 that handled 4800 bps half-duplex (i.e. only one side talking at once) and 3600 bps full-duplex. I tested XMODEM and C1 transfers at 4800 bps and announced that here was the proof. Chris Smeets ported the drivers to the C128 for use in his 9600 bps ANSI terminal. I met Matthew Desmond that fall and, about a year after the original C64 drivers, we were fine-tuning the drivers to run 9600 bps on a C128 with NO ADDITIONAL HARDWARE. While Chris Smeets' ANSI terminals and the telecom overlay for Steve Douglas' PaperClip II and III also did 9600, neither was accurate enough to work well with autobaud devices such as 9600 bps modems. Matt and I decided that we would work at it until we had 'perfect' 9600. I think we did it. The SwiftLink doesn't stop at 9600. Because it has a UART on-board, the SwiftLink cuts by a factor of almost ten the overhead related to handling serial I/O at high speeds. DesTerm 2.0 will operate the SwiftLink at its highest speed setting: 38,400 bps. However, because it uses completely different hardware from the normal C64/C128 serial port, programs which have high-speed RS-232 drivers won't work unless they're specifically written to handle the SwiftLink. It is therefore possible that your favorite terminal program might not work with it unless there's a new release which takes advantage of it. The SwiftLink is a good product, but I believe that it caters to a very limited market. In fact, Keith Hope (of Batteries Included) asked me back in '87 if it would be worth it for him to develop something along the same lines. I said no. I'm not sure how Dr. Evil Labs will fare with this device, but I wish them well. I should also note that the SwiftLink is not the only UART cartridge out there. Hatronics' HART is an 8250-based device which should allow even higher baud rates. However, I was disappointed in its design, as it is more difficult to program than the SwiftLink and imposes some limits on its use, even though it uses a much more flexible chip than the SwiftLink's 6551. Geoff 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 My comments do not represent and should not obligate anyone but myself.