Serial Communications and the C64 Edited and Printed with Permission From an Article: THE SWIFTLINK (tm) Brief theory and practical operation by Perry Eidelbus (C) 1995 by Perry R. Eidelbus. All rights reserved. BACKGROUND: Serial Communications Over phone lines, modems pass data to each other only one bit at a time, a bit being a computer's smallest unit of information. But between a modem and computer, data is passed a full byte at a time, a byte being comprised of eight bits. Just like a bus is more efficient than a car at moving large groups, sending many bits at a time reduces overhead in transferring data. After all, merely because a phone line limits things to a single-file stream of bits, there's no reason we can't be efficient when passing bits between the modem and the computer. A circuit called a Universal Asynchronous Receiver-Transmitter (UART) is typically responsible for collecting eight bits from a modem and then sending them to the computer in one swap. Until it receives the eighth bit, the UART saves the other bits in a buffer and will not send them until it has a full byte. Or vice-versa: the computer sends a byte to the UART, which sends them one at a time to the modem. Either way, this greatly reduces the demands on the main processor, since the UART handles all the dirty work. On most computers the UART is a chip or two on an Input/Output (I/O) card that plugs inside the computer. On a Commodore 64 or 128, the 6526 CIA chips (responsible for most I/O) are the equivalent of the UART. However they are not a real UART: they send and receive single bits from the modem, but they send and receive only single bits to the 64/128. With that tremendous overhead, the 64 and 128 are simply too slow to keep up with today's higher modem speeds. A 64 cannot normally do reliable transfers with a modem above 4800 bits-per-second; a 128, twice as fast with its 8502 processor versus the 6510 in the 64, can do 9600 bps. But even a 4.77 MHz XT can reliably do 19200 bps without I/O circuitry like the CIA chips, let alone a UART. What is it that slows down a 64 or 128? Well, for every group of bits that a 64 or 128 sends or receives, the CIA chips trigger a Non-Maskable Interrupt (NMI). Any NMI is a routine that make the processor drop everything else and execute it; in this case, the NMI processes a bit from the CIA chips, which got the bit from the modem. These NMIs are extremely demanding of the 64 and 128's processors when we do one NMI for each bit: data bit/NMI, data bit/NMI, data bit/NMI, data bit/NMI, data bit/NMI, data bit/NMI, data bit/NMI , data bit/NMI -- next byte! With their inefficiency and subsequent slowness, the CIA chips are what the renowned Jim Butterfield has referred to as "old bit-bangers" when it comes to asynchronous serial communications. Since they can pass only one bit at a time to the 64/128, the CIA chips only emulate a UART; as far as the modem is concerned, it's talking to a real UART. Commodore' engineers chose this design to save money; MOS Technology chips in the early 1980s were extremely expensive to produce. It was not so much a poor design as it was a lack of foresight, but it was not really Commodore's fault; those were the days when 2400 bps, let alone 14.4Kbps, was mostly dreamed of. ALTERNATIVES: Hardware Hacking Germany's Daniel Dallman, one of the elite Commodore hackers today, has pioneered a way to achieve 9600 bps communications on a 64. The 64 and RS-232 interface are modified so that the CIA chips are linked, yielding 9600 bps receives and 6000 bps sends. No one has reported doing this to a 128, which theoretically should achieve 19200 bps receives and 12000 bps sends. There is the good chance that the user can quite easily destroy the computer and interface when attempting this; understandably, Mr. Dallman cannot assume responsibility for those who attempt his project. This technique is required for his demo of true SLIP on a 64, and Nick Rossi has supported this in a modem driver for Novaterm 9.6. It is also possible to achieve 9600 bps without hardware modifications, but the communication would be only one way, i.e. send-only or receive-only. This is useless except when transmitting or receiving files over an error-free connection or there is no need for error-checking (like with text files). Theoretically, a 128 could do 19200 bps this way. I have heard of sustained 19200 bps communications using a stock 64 and RS-232 interface, and although I have no real way to verify this, there is no reason to doubt this gentleman's credibility. It has been a few years since he had a 64 system, so he was unable to provide specifics beyond these: it involves very tricky use of timing, and to free the processor as much as possible, the VIC-II screen must be blanked. The final option is like if your car has an underpowered engine but is otherwise soundly built: you can replace the engine... MORE CARTRIDGES: Clogging Up Your Ports Why not just bypass the CIAs altogether and add a real UART? Our advantage is that one NMI is needed only for one group of bits, not just one bit (but the CIAs have forced us to use groups of one). If we used groups of two bits, we would need only one-half the NMIs; if we used groups of four, one-fourth the NMIs; or better yet, groups of eight (a full byte), requiring only one-eighth the NMIs. Conversely, then, we can use the same number of NMIs to transfer eight times the data. Since our normal max (on a 64) is 4800 bps, we can do eight times that now, or 38400 bps. So it can work, but how do we implement the circuit? The easiest way for most users is as a cartridge. It couldn't plug into the user port; we'd still be slowed by the CIA chips. The expansion port, then, is ideal: it's generally unused and has sufficient address lines to communicate with our new UART. It can also map the UART's registers into a preset area of our 64/128's memory so that we can talk to it, and the expansion port provides +5 volts to power the circuit. This is the exact idea behind the Swiftlink (tm), available from Creative Micro Designs for U.S. $39.95 plus shipping. It plugs into the expansion port and has a DB9 port for easy cabling to a standard RS-232 modem. Its brain is a 6551 Asynchronous Communications Interface Adapter (ACIA), a simple UART chip. (Believe it or not, the CIA chips emulate the 6551!!!) This ACIA was implemented into the Plus/4, B128 and some SuperPETs, and these machines can exceed the modem-speeds limitations of the stock 64 and 128 (and the VIC-20 and earlier PETs). A 6551 by itself transfers data at 19200 bps, but an added crystal can doubles its speed to 38400 bps -- exactly what our new 64/128 can handle, and its present in the Swiftlink. While a 128 can theoretically do 76800 bps, that is still limited to 38400 because of the ACIA's limit. The crystal, however, can be even higher-rated. Craig Bruce, author of the ACE operating system, Little Red Reader and many other fine programs, has done so and can successfully communicate with his modem at 115,200 bps (possible only on a 128, however, because a 64 cannot execute NMI routines fast enough to push much beyond 57600 bps). This hack requires opening the Swiftlink and soldering directly on the circuit board, so it voids any remaining warranty. Back in 1991, Perry Grodzinski felt the Swiftlink was overpriced, so after he learned it's based on the 6551, he obtained the 6551's specs and built his own Swiftlink work-alike. It is not a Swiftlink clone; he had not, in fact, even seen a Swiftlink when he built his "Datapump" cartridge, and it costs only about $20 to build it. Mr. Grodzinski has made his insructions and schematic freely available in the archive "datapump.sfx" (the instructions and schematic are in GeoWrite and GeoPaint format). Hartronics' HART cartridge is another option. A true UART based on the 8255 chip, it supports 57,600 bps on a 64 (and theoretically 115,200 bps on a 128); it is also said to be cheaper to build than buying Swiftlink. But it has limited support (to the author's knowledge, only Desterm supports it), and the chip specifications are difficult to obtain, let alone the complete schematic. Currently, the Swiftlink is the more popular choice. HOW FAST: Software Authors Contend How fast is the Swiftlink with a 14.4K modem? It all depends on your terminal program. Desterm 2.01 (128 only) maxes at 1100-1200 characters per second (true 14.4K is at least 1440 cps) using Ymodem-batch and downloading to a RAMLink; to an REU with Ymodem-batch, the inefficient RAMDOS slows transfers down to about 800 cps. The RAMDOS also slows down Novaterm 9.5 and Dialogue-128 (downloading with Ymodem-batch) to about 800 cps, but I have never tested them with a RAMLink. Dialogue's display has been clocked at over 1500 cps; Novaterm's bitmapped 80-column screen is naturally slow and is limited to about 700 cps; I haven't tested Desterm's display speed because it does not recognize my modified Swiftlink (and I am unwilling to risk modifying it back). The real star of the Swiftlink-supporting terms is Craig Bruce's ACEterm and it's custom Craig's File eXchange Protocol (now at versions 1.01 and 1.00 in ACE-15). ACEterm is the only Commodore term to support 28.8K modem speeds (only on a 128, at least, until CMD's Super64 accelerator is released), and FX is designed to be ultra-fast and highly efficient (although it works only with a Unix host). Writes Mr. Bruce, "While [FX is] non-standard, it blows the doors off of all other protocols available for Commodore computers, even though it uses a simple 'stop-and-wait' acknowledgement scheme. There are two reasons for its speed: the fast device drivers available with ACE, and its large packet size, up to about 14K (although this could be significantly larger if ACE's memory usage were reorganized)." ACEterm is not only efficient, but it is far better coded. The following is a sample comparison of transfer rates taken from the end of FX's documentation. The configuration used a USR Sportster modem over a 14.4-kbps phone connection, with a 38.4-kbps link to a modem from a C128, to a typical Unix host. The file downloaded was 141,299 bytes of JPEG image. Using FX to/from the ACE ramdisk, REU: time= 92.5 sec, rate=1528 cps Using FX to/from a CMD Hard Drive: time=118.2 sec, rate=1195 cps Using DesTerm-128 v2.00 to/from a CMD Hard Drive, Y-Modem: time=199.9 sec, rate= 707 cps Using NovaTerm-64 v9.5 to a CMD Hard Drive, Z-Modem, C64 mode: time=262.6 sec, rate= 538 cps SUMMARY: On a Par With the World Today's c64 user has many options to expand the native serial commucations capability of the c64 far beyond what it's original designers ever envisioned. Together with the newest software, the c64 no longer needs to take a back seat to any other computer platform in communicating serially with the rest of the world. ____________ "Swiftlink" is a registered trademark of Creative Micro Designs, Inc., and is (C) 1990 Dr. Evil Laboratories.