The Gig of Ham

One geek's contributions to the series of tubes

Nov 1, 2018 - 8 minute read - amiga retrocomputing sysadmin howto

Connecting to an Amiga over a serial port using NComm

I’ve been spending a fair amount of time with the local Commodore nerds restoring my A1200, A2000, and A4000 systems. We’ve also been developing a piece of hardware to connect classic machines via their Serial interface to modern systems called the GuruModem - but I’ll have a lot more about that in some other posts. In the mean time, I wanted to share how to move larger files without the use of physical or virtual floppies: the magic of NComm.

Back in the 90s, I loved using a piece of software on PCs called Lap Link. It allowed you to connect two machines together using a serial or parallel cable and transfer files between them. Before the widespread availability of things we take for granted now, like USB drives and ubiquitious networking, or the luxuries of back then (a ZIP drive), Lap Link worked on pretty much every machine and even had a bootstrap process to install on another machine without using a floppy. It was a great way to move large files, or lots of files, without using slow floppy drives. “But serial links are slow” I hear you say, yes - but they are faster than floppies on systems that can do 19200bps or higher.

So after getting my first Amiga, and discovering the worlds of software available through aminet I knew I needed a way to get stuff from the Internet to my Amiga. Especially since the Floppy drive I had in my first Amiga was broken, I was kind of stuck. With some clever mashing of WinUAE, a CF card, and some luck I was able to get my A1200 an OS and first thing I dropped on was a serial terminal emulator with ZModem support to move files back and forth. It wasn’t going to be Lap Link, but it was going to be the next best thing.

Zmodem?

For those who didn’t grow up in the 80s and 90s and cut their teeth on the BBS scene, a little explaination is required. Connection to a BBS via an analog modem connected to a phone line was slow and unreliable - on a good day. I wish I could express the pain and frustration of getting most of the way through downloading the Wolf3d demo (which would take over an hour) only to have it interrupted most of the way through. In order to transfer files between machines, protocols were developed to help. The most common was XModem. It’s a great first start, but it was not easy to use. You had to select a file from the host, start sending it, and open the XModem download on your machine within a few seconds to start the transfer. It did not include such nice things as telling you the name of the file you were trying to download (you had to enter it yourself), and it was slow. Oh man was it slow, and very unforgiving. XModem got extensions to help with some of these problems, but that caused compatibility issues. So many of those improvements were wrapped up in a new protocol called YModem - but there were so many patches to XModem that there wound up being several variants of YModem as well (most of which were also incompatible with eachother). This was not ideal. In another world, a different complete system was being developed called Kermit. It preserved file names, and had an autostart feature. All very cool stuff! But Kermit was a bit of a walled garden, it wasn’t until very late in the game that implementations existed that would work with exisitng comm software - you would need to switch to using a Kermit client. Which wasn’t ideal for a lot of reasons. But the ease of use was nice, so the best parts of Kermit and the lessons learned from YModem were merged into…ZModem. It was architecture independent (like Kermit), and more platform independant than Kermit. It allowed for machines with different capabilties to communicate with eachother (7 bit, 8 bit, EBDIC, all sorts of things). It supported auto start of downloads, preserved file names, would continue interrupted downloads, and it was fast. All of this sounds like table stakes now, but in the 1990s it was game changing.

But ZModem was a very late entry - it was coming around at about the same time as Internet access was becoming widespread. This had an advatage howver, in order for ZModem auto-download to work the comm software needed to be updated to support that. If it had that feature, it meant it was popular and still in active development in the late 90s and it had a really good chance of being really full featured. So my barometer of finding a good comm program is to find one which supports ZModem with autodownload.

Installing NComm

NComm fit all the points I wanted, but installing it is somewhat non-tivial. The application was larger than a single floppy, and came in three parts. NComm 3, the 3.06 patch, and the Public Key (the software used to be commercial but the authors made it free by releasing a full feature key into the wild). In order to help ease that mess, I created a ADF disk image which has everything you need. It can be written to a physical floppy, or use in a floppy emulator.

Once you have the disk inserted into your Amiga, it would appear like this: NComm Install Screenshot

You’re not going to see much on the disk in Workbench, so let’s open up an AmigaShell to get started: NComm Install Screenshot

If you do not have LhA installed on your system, let’s do that. If you do have LhA installed, skip the next couple of steps. First, let’s run the lha.run self extracting tool and have it extract to your RAM disk: NComm Install Screenshot

Next you can copy the generic LhA binary into your system’s C: directory. If you know your machine has a 68020 or better, you can use the lha_68020 binary instead. If you are lucky enough to have a 68040 better processor you can use the lha_68040 binary instead. If you are unsure, just follow the screenshot and use the lha_68k generic binary: NComm Install Screenshot

Now that you have LhA installed, we can extract the archive I’ve included on the floppy image. This has NComm patched to version 3.06, with the “enhanced” theme setup, and the registration key ready for use. It’s contained in a folder with a fancy icon, so you can just extract to whever suits you. In the screenshot, I’m just placing it in the top level of the first hard drive, DH0: but you can adjust this to suit your needs. If you are not sure, just use SYS: in place of DH0: and you’ll be good to go: NComm Install Screenshot

If all goes well, LhA will tell you everything worked: NComm Install Screenshot

Now you will have an NComm drawer in your primary drive. Since I took this screenshot I cleaned up the icon so it should look better. I also did this on a freah install of OS 3.1, it will look better on 3.1.4, 3.5, or 3.9 by default. Either way, you should find that NComm drawer: NComm Install Screenshot

Once the folder is open, there is an Install script that needs to be run. If you are using Workbech 1.3, run the Install13 script. If you are using Workbench 2.0 or later run the Install20 script. It’s very quick and just installs a few fonts: NComm Install Screenshot

And that’s it. You can now launch NComm and be greeted to a screen like this: NComm Install Screenshot

The status line on the bottom tells you the current terminal emulation settings, currently this is using 19200bps baud, 8 data bits, No parity bits, 1 stop bit, and 7bit US ASCII character encoding. It’s also got a clock. How handy. Right clicking will grant you access to the menu and allow you to change these parameters and other.

NComm supports ZModem automatic downloads, so be sure to set a default transfer folder in the menu. It also supports several other protocols if ZModem is not available on your connected device.

Connecting to another machine

I use NComm to connect to my Linux system with a USB Serial adapter and a “NULL Modem” cable between the two. Then I use the picocom program (along with lrzsz) to connect to the Amiga and transfer files. On Windows, I tend to stick to HyperTerminal (which also supports ZModem), or TeraTerm. If you have a Mac, I prefer ZTerm. I’ve found on the older OCS/ECS based Amiga systems (the A1000, A500, A600, A2000, and CDTV) that you can’t reliably use speeds over 19200bps. On A3000 and AGA based systems (A4000, CD32), speeds up to 115200bps work reliably. If your storage is slow, ZModem accounts for that so no worries there. If your system is connected correctly you should be able to type on one machine and see it on the other. At a minimum the baud rate must match between the systems. Ideally the baud, data, parity, and stop bits should match. You won’t get what is called “local echo” by default, so you will not see what you type locally. All the software listed above supports ZModem auto download, so starting an upload on either machine will automatically start the download on the other.

Hopefully that will help you, in some future posts I’ll get into what the GuruModem can do to expand your retrocomputing systems like the Amiga even more.