1983: Growing up Apple

I don't remember ever not having the Apple IIe that I grew up with; it must've been delivered about the same time I was.

My family upgraded to an Apple IIgs in 1988. We still have that machine, as well as another IIgs that ran a dial-up BBS for four years.

Over the years, we tricked it out with the usual upgrades: SCSI card, sound card, handheld scanner, modem, joystick, 4MB of RAM. An accelerator boosted the CPU to 10 MHz, which may not sound like much, but it was quadruple the stock speed -- making Lode Runner quite a challenge to play. (The enemies moved four times faster; my brain and reactions didn't.)

The original IIgs machine is still at my father's house, where he occasionally depends on it for the family business accounting. Though my current computer is a MacBook Pro, it has all the Apple II programs and files I accumulated over the years. I access them with the Sweet16 emulator, which turns my Macintosh into an Apple II laptop.

Emulating has allowed me to have used the same word-processing software, AppleWorks Classic, for the past 20 years, for everything from a 4th grade science paper on the whooping crane to my 100-page college thesis to all my Computerworld articles. All this history fills up only 3MB of my hard drive. Most recently, I created a quick-and-dirty Apple II program to convert 700 blog posts for importing into WordPress -- a huge timesaver over doing it manually.

I just wrote a story about Dan Budiac, a guy who paid US$2,600 on eBay to get back an old Apple IIc. Why not do what I did and just never stop using it in the first place?

-- Ken Gagne

1984: Bubble magic

The first computer I ever used was a luggable word-processing machine, called a PortaBubble because it used magnetic bubble memory. When I started my new job at Computerworld's Washington bureau in June 1984, this was the company's standard equipment for the bureaus and traveling reporters.

I say luggable because it was quite heavy, the size of a microwave oven and took up about half of an airline's overhead bin. Dragging it through the airport would definitely make one arm longer than the other.

The PortaBubble, made by Teleram Communications, had a hard, gray plastic case and opened up to reveal a small monochrome screen and a chunky keyboard (just right for producing carpal tunnel syndrome). On the top was an acoustic coupler that allowed you to put a phone handset into the rubber cups and send stories to headquarters over the telephone. The machine did word processing, nothing else, and frequently "ate" reporters' stories.

Bubble memory didn't catch on, because semiconductor memory got bigger, better and cheaper. Teleram went bankrupt in 1985 as journalists switched in droves to RadioShack's much lighter TRS-80 portable.

-- Mitch Betts

1970: Personal computing with a mainframe?

My first "personal" computer was an IBM 1401. Wait, I'm serious!

In 1970, I used a 1401 Data Processing System at a US Navy supply depot in Vietnam during the war. The 1401 and its associated card reader, card punch, chain printer and tape drives filled a small room.

Although the system was obviously not intended to be used by just one person, we in effect treated it that way much of the time. It was like a time-share condo -- you had it for maybe just 30 minutes, but when you had it, it was yours.

Here's how it worked: The computer had just 12,000 characters (bytes) of magnetic core memory. Instructions and data were stored in memory in variable-length words separated by special characters called wordmarks and, unless you changed your program, each word went into the same, known memory location every time the program ran.

When your program was running, nothing else was running, not even an operating system, because there was none.

These characteristics, plus some handy-dandy user-controllable hardware features, provided the ultimate in debugging capability. You could stand at the console and, by manipulating a series of toggle "sense switches," step through your program a few instructions at a time.

At each key point as you stepped through your code, you could check the contents of registers via little lights to see if something got clobbered, and you could check the address of the next instruction to make sure that an unanticipated branch had not occurred. If you saw that a certain instruction wasn't working the way you wanted, you could just override it by inserting a "no-op" (a placeholder instruction that does nothing) and keep on running.

This could be a slow and tedious process, to be sure, but the cool thing was that you had complete knowledge and control over the execution of your program. Try that the next time you get a blue screen of death.

-- Gary Anthes