I'm sure some one will read this post and comment, well that's not innovative, using an Apple II as a 'dumb' terminal to a Mac. My answer is that this solution is not meant to be original or even 'modern'. The steps outline here is about practicality - with perhaps a sense of style, long standing appreciation for Apple hardware and fun at discovering or rediscovering some useful computing setups. There are of course plenty of wild and crazy projects people have undertaken with 'out-dated' hardware, but in the end are those projects 'useful'? Setting up an Apple II as a terminal might not be useful to everyone, but what I've outlined below is an evolution of a project I've been thinking about from sometime, and the obvious usefulness in a working environment just finally caught up with me.
One other note, I've had succeeded in setting up an un-enhanced Apple IIe and an Apple IIc in the manner described below. In theory any Apple II should work, but I make no promises that the process is the same, or is even possible on all compatible Apple IIs.
It's a well-regarded 'fact' that electronic devices are outdated even before the packaging has been completely removed. This fact might explain why the Apple II computing platform's 30th birthday this month has come with little fanfare (or perhaps everyone is just overly stimulated waiting for the iPhone?) Yet, the Apple II family of computers can be just as useful today even if they are no longer considered 'state-of-the-art'.
The first Apple II computer, the successor to Apple's first computer, was introduced to the world in April of 1977, yet it didn't go on sale until June, hence its June 5th birthday. The platform's openness and ubiquity help carry it even in today's world of 'modern' computing platforms. For example, take a look at my current office setup, one Mac mini, one Apple IIc. If you look closely enough, you'll see that IIc is more than decoration, it is running and is in fact used everyday.
A nice, functional workspace
For those new to this blog, I work as a web developer for zoomshare. In this capacity I can have any number of different applications running at the same time. Usual suspects include Text Wrangler, Safari, Internet Explorer (versions 6 and 7 via Parallels), Firefox, Terminal, iTunes and Mail. With those applications and more, depending on what I'm working on, my screen can get pretty cluttered, pretty fast. Over the years there have been many 'solutions' to this issue, bigger screen, multi-screen or virtual screen (a.k.a. virtual desktops) setups.
Bigger screens and multi-screen setups are fancy (and in vogue these days), but on the Mac side of things you have to plunk down serious money, not something many budget conscious businesses will spend out of hand. Worst yet these options don't really solve the problem but lessen it but trying to add more 'real estate' to the computing desktop. Virtual desktops are a better solution since they skip the hardware display's limit all together. With virtual desktops any number of desktop workspaces can be created. But until Spaces in OS X 10.5 is released, its not supported by default on the Mac platform and third party apps can get a bit messy, with dialog boxes and toolbars getting 'lost' from their application's main window.
So virtual desktops is workable, but not perfect. What I need is the ability to off-load some of windows, ones that need to be visible even for a quick glance, as needed, an IRC conversation or the output of a running web process, for example. Taking a looking at the applications I depend on I see the beginnings of an idea. Terminal is an interesting application, a piece of software that's mimicking what use to be a hardware function. Why can't it be a hardware function again or at least why can't it be running on a dedicated piece of cheap, reliable hardware? Enter the Apple II platform and the nice, compact IIc.
While the IIc is a 'closed' system, unlike other Apple IIs it does include two built in serial ports, one for a printer and one for a modem. A compatible Super Serial Card drives both of these serial ports. The Super Serial Card, introduced in 1981, became the main stay of serial cards from Apple since it replaced the need for two individual cards for a printer and modem. Another eccentricity of the IIc is the fact that instead of a standard RS-232 port the two serial ports are 5-pin DIN connectors, which will thus require an adaptor cable from the DIN connector to the more standard, 9 pin, RS-232 connector.
5 pin DIN to RS-232
RS-232 Null Modem
Keyspan USB to RS-232
On the Mac side of things, the mini includes a collection of Firewire and USB ports. Since USB is just a glorified serial port a USB to RS-232 adaptor does the trick for the task at hand. All that remains is to connect everything, plugging in the DIN cable into the IIc's modem port the USB into a free USB port on the mini and the two RS-232 adaptor ends via a null modem, which is simply a RS-232 cable wherein the transmit and receive lines are crossed.
First step is to install the drivers on the mini for the USB-Serial adaptor. At the time I started this project, I had to go fishing on Keyspan's website for Intel compiled drivers, so if at first you don't succeed try, try again. Once the driver is installed I opened up Terminal a did the following:
$ cd /dev
$ ls tty.*
tty.USA19H5d1P1.1 shows I've successfully completed the first step.
If you happen to have an old copy of a telecommunication software for the Apple II that supports vt100 terminal emulation then your all set software-wise. If not, the next step is to download a copy of Virtual II for the mini, which is what I had to do.
Virtual II, by Gerard Putter, emulates an Apple ][, ][+ or //e on the Mac OS X platform. Better yet the download also includes A2V2 (a Mac program) and ADT (Apple II program) that allows for the transferring of disk images of Apple II software to and from via the newly created serial connection. Moreover, the documentation for setting up a serial connection and transferring disk images that's supplied with A2V2 is fantastic, I relied on it quite heavily while first researching and attempting this little project.
After downloading A2V2 I first needed to follow the documentation to transfer a copy of ADT, Apple Disk Transfer, software to the Apple II. It also makes a nice first test to verify the serial connection. With ADT up the next item on the agenda is to download and transfer a communication program to the IIc. I tried a number of different software titles, even purchased PROTerm 3 off of eBay, but after a bit of fits and starts with different titles, I've finally settled on Modem.MGR.
Modem.MGR is solid communications program that will run on the II+, IIe, IIc and IIgs and, obviously, supports a wide-range of hardware configurations. It supports a number of different functions, including vt100 (actually vt220) emulation and is available for DOS 3.3 and ProDOS. Best of all Modem.MGR is Freeware, so I don't have to worry about infringing on any old (but still enforceable) copyrights. All that flexibility comes at a cost given the limitations of the Apple II platform in terms of memory, which means a bit of upfront work to configure Modem.MGR for the Apple II in question.
With the disk transfer completed I had three floppies hanging around for Modem.MGR a Installation, Utilities and Work disk. The first step towards getting Modem.MGR up and running is to insert and boot up the Installation disk. When ready Modem.MGR will ask for the Work disk, what will be the main application disk, to be installed and read from. Once back to the Installation disk its time to configure the app. For the IIc this means selecting the
Apple // 80 column (menu option 2) video driver and selecting the
Non-smart modem (menu option 10) option for the modem. One can review the selections if needed, but really the next step is to save the configuration back onto the Work disk.
When Modem.MGR is booted and loaded from the Work disk it displays a listing of commands that can be accessed by first pressing the 'ESC' key and then pressing the letter (on the left-hand side of the colon) that corresponds to the command one wishes to enter. At any time, if I'm not sure which letter/command combo I wish to use I can simply press the 'ESC' key and Shift-? to redisplay the complete list.
The first two steps in Modem.MGR is to set the modem baud rate, i.e. the connection speed and the parity for the data connection, when to stop and verify bits sent across the connection. The connection speed, ESC-M, can be set to one's liking, up to 19200 baud. I've settled at 1200 baud, because I like the retro feel of working at that speed and, to be perfectly honest, I don't think the IIc's display can keep up with the higher speed. The parity, ESC-J, is 8+1+None.
Next stop in Modem.MGR is to startup the vt220 terminal emulation. The key combination for this is ESC-: (that's a colon if your not sure) and then 'V' for loading the vt220 terminal emulation module.
Within everything ready on the IIc side of things, its time to take a look at the mini; in theory all that needs to be done to enable the mini is to get ttys to run getty, i.e. initialize the relevant serial port and invoke the login ability at the command-line. To enable getty requires the following line in the ttys configuration file at
tty.KeySerial1 "/usr/libexec/getty std.1200" vt100 on local secure
The first line item is the USB adaptor; the second line item is the getty app location along with the terminal type and baud rate. The last set of items include additional information about the terminal, what type of emulation, if it's a local connection and if its secured such as to allow root logins from. With a reboot to reload ttys all will be golden, a login prompt will appear on the IIc and one is off to the races, happy and carefree.
Yet something seems off. I've tried this numerous times, but I always end up with the same result, nothing, nada, zilch. As far as I can tell there seems to be a low-level conflict that hangs up the connection. I assume its either getty or USB driver(s). If I try to access the connection, say using A2V2 I get a device busy error. The USB adaptor from Keyspan has a green led that flashes when data is being transmitted. When getty is running via ttys it shows a solid green light, like its thinking, but it knows not what. Worst yet if I try shutting down or restarting the mini the machine will hang, obviously waiting for the USB port to finish up so it can get on with shutting down. The only way around all of this this is a hard rest, removal or commenting out the relevant line from
/etc/ttys and another hard reset.
So close and yet so far....
I kept fooling around with options for ttys, wondering that was the cause, but to no luck. Being able to transfer disk images shows that the serial connection worked, so that isn't the issue. After some more futzing, I realized that if I couldn't get the setup exactly right, the next best thing would be to approximate it. That, I could do with GNU screen. screen is quite a handy swiss army knife type computer tool. At its simplest level it's a virtual desktop for the 'old-style' command line. screen however has all kind of features, including the ability to execute commands within a screen session, detach from a session leaving the executing command running and the ability to connect to a specified ttys device. Best of all everything screen does is in the standard vt100 terminal emulation mode by default.
To get everything going I startup Terminal on the mini and make sure the terminal windows is 80x24 (the screen resolution of the IIc). screen will adapt itself to this setting when launched. At the command line prompt the next set is to run screen on the serial connection:
$ screen /dev/tty.KeySerial1 1200
Then within screen its time to execute getty. The key combo in screen is Control-A and then Shift-: (colon again) and then to type is at the colon:
exec ::: /usr/libexec/getty std.1200
The three colons tell screen how to handle standard in, out and error, to connect the I/O of the serial device to the process, making screen a bridge between the running process, getty and Modem.MGR on the IIc. One can then login via the IIc and detach and close Terminal on the mini.
Success, less windows on the mini, less clutter on the desktop and yet a handy terminal (and a retro stylish one at that) is up and running.
Now, I have to admit, running a virtual terminal program on the mini to get another terminal manager program to commutate to a third piece of terminal emulation software, just so the IIc can act as a 'dumb' terminal is a bit awkward. But hacking together a solution around a restrictive bug can lead one down a long and winding path. However, there is an advantage to this solution that I hadn't anticipated at the time, if I need to cut and paste something from the terminal to lookup, a URL posted on IRC or an error message from a process log, I can reattach to the screen process on the mini, cut and paste the info I need into Safari, and detach to keep the desktop a little less funky. Not to shabby, if you ask me.
In some areas, such as setting up a serial connection between a Mac or even a PC, and a Apple II, there is a lot of information and programs floating around on the 'net (I've adding links as needed within this post obviously). On the other hand, setting up a dumb terminal to a Mac, or dealing with conflicting ttys connections, there seems very little. Hopefully the information posted here will be a helpful in between for anyone else looking to attempt the same. And who knows, maybe someone out there has the information I'm missing to setup a cleaner, simpler connection. Or better yet I might end up at Apple, fixing the bug myself ;-)
Update: Well I knew a few people would be interested in this little project, but it seems I've started a little mini-fad. As a couple of comments below point out. Here are just a few of the more interesting followup posts:
Apple II Forever!