SwiftLink-232 Serial Cartridge

"A modem? What's that?" my kids asked me. Roll back the years and read about the development, production, and promotion of the SwiftLink-232, which enabled C-64s and C-128s to utilize 2400+ baud modems.

UPDATE 2013-09-21: Added partial CMD sales figures.

UPDATE: 2013-09-22: Added more Turbo232 info, from Commodore World.

UPDATE: 2014-05-24: Added info on GLink232.

UPDATE: 2017-02-26: Clarified info on Color64 BBS.

UPDATE: 2017-06-12: Added info on DB-9 connector.

UPDATE: 2017-06-21: Added YouTube video of SL-232 talk at PaCommEx 2017.

Background

The roots of the SwiftLink-232 Serial Cartridge are in both the C-64/128 Kermit project and the SID Symphony Stereo Cartridge. While roommates at Purdue, Ray Moody, Craig Barnhart, and I had a great mix of Commodore equipment in our room—two C-64 setups, a C-128, and eventually, an Amiga. All three of us took programming classes and we liked to work from our room at times, especially during the winter or other bad weather. Ray’s first version of C-64/128 Kermit (2.0), released in May, 1987, enabled support for the C-128’s 80-column mode and emulated a DEC VT-100 terminal, so working from our room was pretty sweet—except for the sloooow connection speed. 1200 baud was the maximum speed our lowly Commodore 8-bit equipment could manage. Ray tweaked some things for version 2.2 and we were able to double the speed to 2400 baud (on a C-128 in 80-column mode), just in time to use with the relatively-inexpensive 2400 baud modems that were appearing. However, 2400 baud was still four times slower than the terminals we were using in the various computer labs around campus, and I also began to get wind of a new generation of 9600 baud modems through my part-time job at Von’s Computers.

Given our emerging success with the SID Symphony and the well-known fact that Commodore cut corners in the C-64’s design by leaving out the 6551 Asynchronous Communications Interface Adapter (ACIA) for serial communications, we were pulled in the direction of looking into providing the 6551 in plug-in cartridge form. We could have instead taken on the task of re-writing the Kernal serial routines to improve their performance, and Agent Friday’s work on V-1541 for the Comet64 Internet Modem indicates that would have been a viable path. Neither happened during the 1988-89 school year, because we had our hands full with classes and the SID Symphony.

As described in part 2 of the SID Symphony Stereo Cartridge post, our time together at Purdue ended in the summer of 1989 when I moved to the Seattle area. Ray Moody and Rick Washburne became very busy with finishing school and beginning their careers, as did Roy Riggs. Meanwhile, I met Bryan Minugh and Noel Nyman at a University of Washington Commodore Users’ Group (UWCUG) meeting. I quickly learned that Bryan was a talented circuit designer and Noel enjoyed working with hardware and figuring out how to control it with software. Given the people and skills on the scene, for what was essentially the second generation of Dr. Evil Labs, the 6551 path was the obvious choice, instead of re-writing the Kernal routines.

And, if my memory is correct, Fred Bowen at Commodore also nudged us in the hardware direction. He sent us an official 6551 data sheet and pointed out that the 6551 was part of the Plus/4 series (introduced in 1984, quite a few years ahead of affordable 2400 baud modems). Much later, we learned that the original releases of CP/M for the C-128 (prior to December 6, 1985) expected to find a 6551 chip for RS-232 serial communications, which is why the RS-232 portion of those versions didn't work. No expansion card with a 6551 was ever introduced by Commodore, of course, and the socket was repurposed for use by an optional internal function ROM.

While our experience with the SID Symphony taught us valuable lessons about designing and producing memory-mapped hardware for the C-64/128, the SwiftLink-232 was a substantially-more complex project. The 6551 is a type of UART (Universal Asynchronous Receiver / Transmitter) supporting the RS-232 standard but it does not produce or consume RS-232-compatible voltages. Supporting hardware would be needed for that task. Another big difference between the SID Symphony and SwiftLink-232 was end-user software support. In the former case, the software (StereoPlayer, Enhanced Sidplayer) preceded Dr. Evil Labs’ involvement and the resulting combination was relatively self-contained. In the latter case, there was a plethora of modem communication (aka “terminal”) programs but all of them would need to be retrofitted to use the 6551. Finally, a working combination of computer + modem + terminal program was only half of the equation to successful communication—there was always another computer at the other end of the connection and a myriad of settings could cause communication problems.

At the same time, Rick Washburne floated the idea of faster communication speeds on Q-Link. He was investigating ideas for a higher-speed modem. He gathered some valuable feedback from potential customers that indicated some people were quite happy with 300 to 1200 baud. Rick remembers, “While a couple of friends responded with such comments as ‘Cool idea!’ and ‘That would be great!’ most of the responses were extremely negative. There were a lot that simply-stated ‘That isn't possible’ and/or ‘Your [sic] an idiot.’ One, however, was so scathing that I realized, if these were the type of users who were going to respond to innovative ideas, we weren't ever going to sell anything. The posting was very lengthy, as I recall, but can be summed up in just a few words (especially when all the profanity is removed): ‘9600 Baud??? Why??? NO ONE CAN TYPE THAT FAST!!!’”

With all of these challenges, it’s a wonder that we ever got the SwiftLink-232 to market, especially since Bryan, Noel, and I were all employed full-time (and within a couple of years of meeting each other, all of us were at Microsoft, where we were kept extremely busy). Ah, youth… and, also, a fair amount of Dr. Evil Labs’ trademark “Wouldn't it be cool if...?” spurred us on.

Rick explained the epiphany he had, which describes well the attitude Bryan, Noel, and I developed from receiving some similar feedback, “In hindsight, I realized that a single posting in a music forum was possibly the worst market research on record. But I also realized that, just as a business owner can expect calls from almost no satisfied customers, few will post a reply in support of an idea, and many will support an argumentative point of view. The key point was, of course, if someone didn't even understand the purpose and advantage of faster modems, they weren't going to be a customer anyway, and moreover, had no useful information to offer.” Damn the torpedoes. Full speed ahead!

Development

Bryan and I discovered a schematic by Devon Bowen that used a 6551 for ham radio communication. That schematic featured the Maxim MAX232 chip, which Bryan had heard about but not yet had the opportunity to use. Bryan sketched a schematic, which I then converted to digital form using Aldus FreeHand on my then-new Mac SE/30. For each design iteration, Bryan laid out the circuit board with OrCAD on a PC (DOS), which he purchased from the back of Nuts and Volts magazine. This budget version of OrCAD did not include hi-resolution printing, so I transferred the layout to FreeHand, printed onto a special Mylar film with a laser printer, ironed the image onto a copper blank, and etched the board.

The three of us first often worked together in my small apartment. At one gathering, Bryan provided Noel with a very thick printout of a public domain 6502 machine language terminal program that initialized and used the 6551. Bryan and I had already constructed the first prototype, which Noel recently re-discovered. We worked through the printout and made notes on how to use the chip, which was not easy, because the authors had their routines scattered all over the place in "spaghetti" code.

Here are some pictures of Noel’s prototype cartridge:

Interior, showing top side of circuit board and permanently-mounted cable

Interior, showing close-up of top side of circuit board

Noel recalls, “I took the prototype and notes home and eventually came up with a working program that initiated handshaking with another computer via a phone line and sent characters back and forth. I used 300 baud for connections to the outside world; I had only a 300 baud modem at the time. My wife has a Xerox 820-II with an RS-232 port. (Yes, she still has it. Actually, we have two of them now, along with the Diablo 17” daisy wheel printers they came with.) The Xerox allowed me to also test at a blazing 1200 baud using a null modem cable.”

Bryan recalls how the SwiftLink-232 name was born during one of our working sessions: “One of the names we liked was Fast Link, but it seemed a little generic. I think Kent looked up some synonyms for ‘fast’ and we all liked ‘swift’. We then added the ‘-232’ to make it clear that it was a serial communication product.” Simple as that!

The schematic and board design went through three iterations, based on testing done by Bryan, Noel, and me, at least some of which was done face-to-face. Noel recalls at least one meeting at Bryan’s house. He reported that he still owns the wire strippers that Bryan sold him that night. Noel did exceptional work to boot-strap the project by writing code that enabled the SwiftLink-232 to come to life and be tested in real-world situations. His work resulted in a comprehensive set of application notes (with sample code) for third-party developers and a free program distributed with the cartridge, simply called the SwiftLink-232 File Transfer Program. If you peruse the application notes, you’ll notice “Geoduck Developmental Systems” listed. Noel’s story about his company is very entertaining—I recommend reading it!

By the way, Craig Bruce corrected a couple of bugs in one of Noel’s sample code routines in C= Hacking Issue 10. The application notes linked to above have those bugs fixed, along with some other minor improvements in wording and formatting.

Noel also reminded me of the difficulty I had getting his SwiftLink-232 FTP copyrighted. I submitted the copyright application and assumed it would be no big deal, since I had previously done it for Imagery! and the Imagery! Adventure Designer. I was quite surprised when we received a rejection letter. I called Noel and he happened to have a copy of How to Copyright Software by Nolo Press, specifically the version with an “update for 1990—new Berne copyright rules.” We looked up each item that they rejected in the application and the book told us exactly what phrases to use in place of what I'd reasonably assumed would work. The copyright office approved the revised application. It seemed at the time that they wanted trivial wording changes rather than substantive new information. Noel said that the process reminded him of something he read many years ago in an engineering magazine about needing the most appropriate terms in a résumé: “If you want a job with a company that plans to heat aquariums with laser beams, your résumé had better mention ‘red lights’ and ‘fish!’”

Speaking of third-party developers, we eventually had 24 people / companies / programs engaged, spanning the range from C-64 to C-128 to CP/M and from terminal programs to BBS software. Matt Desmond (DesTerm 128), Gary Farmaner (Dialogue 128), Nick Rossi (NovaTerm), Phil Kemp (Terminal 1) and David Goodenough (Q-Term) joined the program in April, 1990, and were the first to get their programs up and running with the SwiftLink-232. They (and others) provided much critically-important feedback about both the prototype hardware and software application notes. Ironically, SwiftLink-232 support in Kermit had to wait for quite some time due to Ray being swamped with his full-time career. Eventually my friend Matthew Sorrels volunteered his time to do the work to Kermit. We even asked developers to sign a non-disclosure agreement—one for before we released and one for after. My memory about why we bothered to do this was due to rumors of a competing product that used the 8250 UART.

Noel remembers helping Nick Rossi get NovaTerm working with the SwiftLink-232. Nick thought the cartridge was a great idea and was very enthusiastic, but he couldn’t get it to work using Noel’s application notes. He and I exchanged at least one phone call then he and Noel talked at least twice. Noel recalls conferencing me in on at least one call, and I pointed out that Gary Farmaner had Dialogue 128 up and running, at which point Nick exasperatedly apologized for not being Gary! Nick sent Noel his program and source code on floppy disk and, wonder of wonders, it didn’t work for Noel either! Noel remembers, “As it turned out, I’d ‘cleaned up’ my application notes before sending them out and I’d changed one of the zero page addresses to make all of the addresses contiguous. It looked neater that way. However, the C-64 used that address for its own purposes. I told Nick that using the original zero page address got his program up and running for me, but I don’t think he sounded very happy when I called and told him!”

With all of this great feedback pouring in, Bryan iterated on the schematic and board twice. Let’s take a look at v1.0, 1.1, and 2.0. (Refer to this table for descriptions of the RS-232 signal lines.)

Features shared across all three schematic and circuit board layout versions

• Used an on-board crystal at two times the speed assumed in the data sheet (3.6864 Mhz.). This eliminated 50 baud on the low end but added 14,400 baud and 38,400 baud on high end. The user-selectable baud rate (16x crystal speed) was also doubled, to 230,400 baud.
• 2 Mhz. “A” version of 6551 chip chosen, to ensure it could keep up with doubled switching rate of the crystal.
• Of the many available configurations of the RS-232 chip, the version with four transmitters and no receivers was chosen (Maxim MAX234 / Sipex SP234) to maximize the number of signal lines supported in a cost-effective fashion. Receivers were handled by the far-cheaper MC1489 chip.
• DSR / DCD swapped at 6551A chip. The 6551’s receiver is disabled when DCD is inactive – probably to cut down on garbage characters and spurious interrupts. But, this meant we couldn’t get an echo for Hayes AT commands when the modem was not connected (unless it could do AT&C to set DCD to always enabled—not all modems could at that time). Mapping DCD to DSR allowed us to still check a bit to see if there was carrier. Hayes commands always had echo because DSR was always active while a modem was attached and turned on.
• Ring Indicator line not connected – no input on 6551A chip for it.
• Pads on circuit board to allow I/O memory location to be changed from $DExx to $DFxx.
• Pads on DSR trace to allow it to be severed easily. This was done specifically for the Practical Peripherals PM2400SA MNP modem.
• Slide switch provided to change interrupt line from NMI to IRQ, to enable C-128 CP/M mode operation.

Schematic v1.0 / circuit board v1.0 features

View the schematic in PNG format.

CTS, DCD, and DSR each had a pull-up resistor, tying the DB9 connector pins to the +10V supply on the MAX234 charge pump.

Schematic v1.1 / circuit board v1.1 changes

View the schematic in PNG format.

RTS / CTS are now connected in a loopback via a resistor, to mimic the design of popular low-cost cables. This has the effect of asserting the CTS input only when the RTS output is asserted by the 6551.

Schematic v2.0 / circuit board v2.0 changes

View the schematic in PNG format.

1. DCD now also has its pull-up resistor replaced with a loopback resistor to DTR. When a cable or device does not supply a DCD signal, the DTR now provides a "fake" DCD signal. (Note: since DCD and DSR are swapped at the 6551 inputs, this effectively ties DSR to DTR.)
2. The input for the fourth, previously unused, transmitter on the MAX234 chip is now grounded.  Allowing an unused input to float can cause the output to fluctuate wildly, introducing noise and possibly using a lot of power. Since a low input on the driver causes a high (+10 V) output, the one remaining pull-up resistor, (DSR pin, which feeds the 6551's DCD input) could now be attached to the driver's output instead of the charge pump capacitor. This was done to eliminate any possible disruption to the chip's voltage supply, and also to accrue benefits from the over-current protection that is built into the drivers' outputs.

As you can probably derive from the changes, we found many devices and cables that did not support all of the RS-232 signal lines, so some “creative” solutions were in order, to prevent sub-par performance for customers, and to stay away from Dr. Evil Labs having to tell customers, “Your modem or cable is junk—buy something else.” The changes were explained in an update we sent to developers on May 5, 1990.

The final change, however, resulted from trying to solve a much more complicated issue. The Maxim line of chips was the industry standard for RS-232 signal conversion, and as such, the chips were fairly expensive. We learned of a competing chip made by Sipex that claimed 100% compatibility at close to half the price. We followed their design specs exactly, in terms of usage and supporting electronics (capacitors) but a few chips died during early testing. Sipex’s analysis of a sample of the failed chips blamed too much supply voltage for the transmitters, even though we were following their design specs. Our own analysis was that their manufacturing tolerance was too wide, because almost all of the chips worked fine using the specified capacitor values. Using smaller-than-spec capacitors caused the output voltage to wilt, which might have protected marginal chips but caused problems with devices connected to the SwiftLink-232. The current-limiting change in the v2.0 schematic and board layout was an attempt to prevent all possible causes of the over-voltage condition. Some of the Sipex chips died in the field after this change, so too much current on the DSR line clearly was not the root cause.

Production

Dr. Evil Labs manufactured only 211 SwiftLink-232 cartridges (and sold just 163 of those to customers) before selling the remaining inventory, parts, and design to Creative Micro Designs barely six months after production started, making an original SwiftLink-232 cartridge quite a rare commodity today in the retro 8-bit CBM community. Here is a picture of #00002, #00211, and a CMD-produced unit:

Exterior, showing product labels

The SwiftLink-232 was introduced at $29.95 and the first cartridges shipped to customers on June 23, 1990, with setup and use instructions, a couple of important notes (in the form of a paper wrapper around the cartridge), and separate instructions for the file-transfer program. And, of course, every cartridge had a product label on the outside.

Here are some pictures of Noel’s cartridge, #00002:

Interior, showing top side of circuit board and serial number label (note many extra zeros!)

Interior, showing bottom side of circuit board

Here are some pictures of the last one Dr. Evil Labs made, #00211, which I own:

Interior, showing top side of circuit board and serial number label

Interior, showing bottom side of circuit board

Unlike the 6582 SID chip, which was fairly obscure and only available from Commodore Semiconductor Group, the 6551 was readily available from a few manufacturers. We chose Unicorn Microelectronics (UMC).

We offered all third-party developers free distribution of their terminal programs (or demos, for commercial software), and over time, this grew to three double-sided “flippy” disks:

1.       DesTerm 128 v2.0 program

2.       DesTerm 128 v2.0 docs

3.       NovaTerm v9.1 program

4.       NovaTerm v9.1 docs, BellTerm promo, SwiftLink-232 FTP, Software Notes #3

5.       Terminal 1 v8.18

6.       Q-Term v4.2g

D&D Services, Inc., the distributor of BellTerm, proposed an arrangement whereby the first 30 customers to redeem a coupon received a free BellTerm v5.1 package. In return, Dr. Evil Labs would give them three SwiftLink-232 cartridges. It seemed like good deal for our customers, so we agreed to it and included BellTerm flyers with the first batch of SwiftLink-232s sold. This document shows the agreement and the flyer. BellTerm v5.1 was announced in the April, 1991 Compute!’s Gazette and RUN, which included mentions of SwiftLink-232 support. (Oddly, the same issue of RUN announced Dialogue 128 v2.2, which had a special SwiftLink-232 version, but this was not mentioned.)

Kermit v2.2 (76) also supports the SwiftLink-232, as does Dialogue 128 (eventually released as freeware) and a new arrival (2010) on the scene, ZTerm.

Concerning BBSes, C*Base, Color64 (v8.0 for C-64, v7.37 for C-128), and Omni 128 were in the developer program and released versions with SwiftLink-232 support. At least two others, DTJ-BBS and Image BBS, also support the SwiftLink-232.

Craig Bruce’s Alternative Computing Environment (ACE) supports the SwiftLink-232. Craig also created SwiftLib, a library of public-domain assembly language routines for developers wishing to add support for the SwiftLink-232 or for CMD’s later product, the Turbo232, to their software.

The Software Notes text files provide a record of how software support for the SwiftLink-232 progressed. There were three versions. The third is included in PETSCII format on disk #4 above. Here are all three in ASCII format:

1.       Software Notes #1 (July 7, 1990)

2.       Software Notes #2 (August 8, 1990)

3.       Software Notes #3 (November 11, 1990)

We saved the first three serial numbers for ourselves: Bryan got #1, Noel received #2, and I kept #3. We sold approximately 115 units at $29.95, and then the price increased to $34.95, which was part of a general price increase for most of Dr. Evil Labs products. We sold 47 more cartridges at this price, and sold the remaining 48 assembled cartridges to CMD at cost. We also offered DB-9 to DB-25 modem cables at cost, to make sure there were no barriers to customers using their SwiftLink-232 cartridges.

All SwiftLink-232 circuit boards were produced to the v1.0 schematic but all cartridges were manufactured to the v2.0 schematic by making a fairly-simple set of component-mounting changes during cartridge manufacturing. Like the SID Symphony cartridge, we ordered the circuit boards in batches of 100, but we elected to not put the v2.0 board layout into production, due to the impending sale to CMD and the desire to avoid another $200 setup charge with the board manufacturer. With the SID Symphony, we tried to amortize setup charges across at least 200 units sold, and we sold just about that number of SwiftLink-232 units. We gave CMD camera-ready artwork for the v2.0 circuit board but I don’t know whether they put it into production.

Below are some pictures of one of the CMD-produced units. Like with the SID Symphony cartridge, CMD did not assign serial numbers, so we don’t have any way of knowing how many they made or where in the production sequence this one falls, although the presence of a Rockwell 6551 instead of a UMC 6551 implies it was after the initial 48 completed units we sold them. It appears to use the same v1.0 circuit board design though:

Interior, showing top side of circuit board

Interior, showing bottom side of circuit board

CMD improved the setup and use instructions by providing more information on how to change the I/O memory location and how to sever the DSR jumper for the Practical Peripherals PM2400SA MNP modem. Note: I would like to recognize the person who let me photograph his cartridge at CommVEx 2013, but I can’t remember his name! Please leave a comment if you can help identify the owner.

The first 158 SwiftLink-232 cartridges used the Sipex chip, and we replaced the few chips that died at no cost (including Noel's #00002, pictured above). The remaining cartridges used the Maxim chip. Even with their analysis, Sipex allowed us to return all of the unused chips (plus 15 dead ones) for a full refund, so it all worked out eventually.

Here are some pictures comparing Dr. Evil Labs’ #00211 and the CMD unit:

Interior, showing top side of circuit boards

Interior, showing bottom side of circuit boards

For each batch of 100 cartridges, Bryan, Noel and I assembled 33 of them (with one person doing 34). Noel remembers Bryan and me descending on his house with a box of cartridge shells, to figure out how cut openings for the DB-9 connector for the first 100 units. Noel set up his Sears router table on top of the clothes dryer in the basement. His wife had given him the router and table for Christmas and he had used it only once or twice. As Noel remembers, “I’d seen Norm Abrams use routers on ‘This Old House’ so I figured I knew what to do. I did, sort of. We got openings cut in all 100 cartridge shells at least large enough to allow the DB-9 connector to peek through. I don’t think any of the openings came out exactly the same shape, and most probably had enough room for small rodents to squeeze in alongside the connector! We probably drilled the holes for the NMI / IRQ slide switches that night too, but I don’t remember for sure.”

Concerning the DB-9 connector itself, Bryan remembers that the type of connector designed for circuit board mounting had 90-degree pins, and the connector, when mounted, was taller than the thickness of the cartridge shell. What to do? He noticed that a connector with straight pins could be modified with a file, opening up just a bit more space between the two rows of pins, so that it could "hug" the circuit board. So, Bryan designed the board to have solder pads for one row of the connector on each side. This worked great and was at least as sturdy as the 90-degree method would have been.

Unlike with the SID Symphony, Dr. Evil Labs provided all of the seed money to bootstrap the SwiftlInk-232 project. Bryan, Noel, and I received an assembly fee that amounted to about $2.58 per cartridge, averaged over the 211 cartridges.

Publicity

We announced the SwiftLink-232 Serial Cartridge via letters sent to eight publications, all with significant 8-bit Commodore coverage, during the last week of April and first week of May in 1990:

• The Australian Commodore and Amiga Review
• Commodore Computing International
• Commodore Disk User/YC
• Compute!'s Gazette
• Datormagazin
• INFO
• RUN
• Twin Cities 128

The publications were located in the US, England, Sweden, and Australia. The letters also announced the v2 SID Symphony and provided information on the Enhanced Sidplayer book and disk combo plus Stereo Editor.

Compared to previous coverage of the SID Symphony Stereo Cartridge, magazine promotion of the SwiftLink-232 happened more slowly. The two situations are a little bit of an apples vs. oranges comparison though, due to the unhealthy situation most of the magazines found themselves in by the latter part of 1990. Also, the SwiftLink-232 was a product aimed at an emerging trend—high-speed online communication, so magazines may have felt the immediate audience appeal to have been lower. The increase in SwiftLink-232 publicity roughly seems to match the uptake of higher-speed modems. The known coverage, in chronological order, is:

“Price & Progress Report” (a short review) in Twin Cities 128, September, 1990

“SwiftLink cartridge lets C-64 communicate at high speeds” INPUT, November, 1990

“News & Notes” (a brief mention) in Compute!'s Gazette, February, 1991

“Commodore Connection” (a brief mention) in RUN, April, 1991

“Commodore Corps” (a partial review) in Computer Monthly, June, 1991

“Sätt fart på ditt C64-modem (Speed up your C64 modem)” in Datormagazin, October, 1991

“Online Solutions” (review in sidebar article) RUN, June, 1992

“Telecommunications: Modems, Interfaces, & Online Networks” in Commodore World, September, 1994

“Cross-Platform File Transfers: Part One: Null-Modem Transfers” in Commodore World, April, 1996

“The Great Cartridge Expanse” (a brief mention) in Commodore World, June, 1996

Commodore World was published by CMD and often featured their products, naturally.

To demo the SwiftLink-232 at local user groups, I set up a terminal program on my Mac SE/30 to send a Commodore bitmap at 300 baud over a null modem cable, and Noel modified our file-transfer program on the C-64 to use the SwiftLink-232 to receive the bitmap at 300 baud, then store it bit by bit in hires screen memory. The audience watched the bitmap slowly paint onto the monitor. Then we switched both machines to the fastest baud rate the Mac supported (38.4k) and sent ten different bitmaps in succession. They painted on the monitor, one over the other, and Noel remembers that all ten came through faster than the first one had at 300 baud.

As described in part 2 of the SID Symphony story, Bryan and I attended the World of Commodore show in Philadelphia, on September 15 & 16, 1990. Gary Farmaner, the author of Dialogue 128, came down to the show from Toronto and hung out with us. Here’s a picture of the three of us—the only known picture of Dr. Evil Labs personnel “on the job”:

Kent Sullivan, Gary Farmaner, and Bryan Minugh

Gary Farmaner and Nick Rossi and are the only people from our third-party developer program that I recall meeting in person.

Conclusion

I hope you have enjoyed reading this history of the SwiftLink-232 Serial Cartridge! Bryan, Noel, and I had a great time designing, building, and producing it. It’s hard to believe that the entire project lasted less than 18 months, from the time I met Bryan and Noel until we handed over production to CMD.

In September, 2013, I uncovered some royalty statements that CMD sent to us, and they indicate that they sold at least 741 SwiftLink-232 cartridges, not counting the ones we sold them outright. You can read more about this in the “All Good Things” post.

Please leave comments, especially with questions and suggestions for other topics to cover. Also, every SwiftLink-232 that Dr. Evil Labs produced has a serial number, printed on a label inside the cartridge shell. If you own one, please post the number, just for fun…

Postscript

After I got back into the CBM 8-bit world in 2012, I learned about the existence of CMD’s Turbo232 High Speed Modem Interface. I found one on eBay in 2013 and have included some pictures of it below. I know little about its design or operation beyond what the instructions say. The device supports newer 57.6k baud modems, which is an important enhancement.

Exterior, showing product label

It’s interesting that the copyright date is 1997—far later than I realized CMD was doing new product development. Thanks to commodoreserver.com user Moloch, shortly after publishing this post, I found more info on the Turbo232 in CMD’s own magazine, Commodore World:

• October, 1996 issue: Last issue SwiftLink-232 was advertised
• December, 1996 issue: Turbo232 announced, with nice full-color ad, and SwiftLink-232 production officially discontinued
• March, 1999 issue: Last known Turbo232 advertisement (final issue of Commodore World)

Interior, showing top side of circuit board

The Turbo232 has jumpers for $DExx / $DFxx, NMI / IRQ, and the DSR trace, which are all nice improvements.

Interior, showing bottom side of circuit board

If anyone knows more about this product, feel free to post comments. I wonder what U2 and U3 are? CMD put adhesive paper labels on these chips. Mysterious…

Thanks to Rik Magers and Ryan Sherwood for pointing me to a few other, even more recent, CBM 8-bit designs using the 6551:

• PitchLink (Andreas Andersson)
• Link232 (Jim Brain)
• GLink232 (Gabriele Gorla)

If anyone has experience with any of these, feel free to post comments.