The Preface
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.
The Necessity
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.
The Hardware
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.
The Software
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.Bluetooth-PDA-Sync
tty.KeySerial1
tty.USA19H5d1P1.1
The
tty.KeySerial1 and/or
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
/etc/ttys:
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.
The Conclusion
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.
Two Loves
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!