My (computer) beginnings

c 1969 - 1978

Time sharing

While working in a product development lab at RF Communications (soon to become a division of Harris Corp) I heard wide-eyed fables of the new Hewlett-Packard minicomputer that another development lab within the company had just received. This was probably about 1969 or '70. Supposedly it could even plot filter curves for the Butterworth and Chebychev filters with which we worked. I never saw it, though.

In 1972, while working in a development lab at Sunair Electronics, I saw my first handheld scientific calculators. The heavy-hitter was the HP-35. A few colleagues bought the HP-35 and the later HP-45 and learned their RPN (reverse Polish notation); they were too expensive for me.

I did, though, have access to a time shared computer terminal: a Teletype Model 33 that sat in a corner of the lab. It talked via a modem and phone line to a commercial time-shared minicomputer. Among other jobs it ran a BASIC interpreter. With it, I could create and run simple programs, most of which analyzed circuit behavior and organized bills of material. Our department stored our few modest programs on punched paper tape. Watching the noisy Teletype machine print out the results of its calculations was intoxicating. I was hooked.


Late in 1976 I bought my first gadget that could be called a computer: a MOS Technologies KIM-1 (Keyboard Input Monitor). It was a single printed circuit board with an LED display (in hexadecimal), a numeric keypad, an 8-bit 6502 microprocessor (which was internally almost identical to Motorola's much more expensive 6800 CPU), and a few kilobytes of memory.

It had a tape interface. I think that it was designed as a development tool and demonstration of what the 6502 could do. I was forced to learn the rudiments of how an 8-bit CPU (central processing unit) works, as well as hexadecimal arithmetic. For such a small thing, it presented me with a steep learning curve.

Funny: To this day, the precise meaning of RS-232 lines is still ambiguous!

The Horizon came with NorthStar's operating system and its relatively crude BASIC. I wasn't impressed with either. Instead, I bought Digital Research's CP/M version 1.4, Compiler Systems' CBASIC, and Structured Systems Group's NAD name and address program with their QSort -- all on 5.25 inch NorthStar diskettes.

Commodore PET 2001

My next computer, which really could be called a computer, was one of the first Commodore PETs. It contained a 6502 CPU, 8 K of RAM, a small video monitor, a tiny keyboard, a cassette tape drive, a couple interfaces, a BASIC interpreter in ROM, and a metal case(!). I jumped at it when I first heard about it. I bought mine directly from Commodore in late 1977 or early 1978. (I guess that they hadn't yet set up distribution channels.) When I first switched it on, it booted almost instantly and greeted me with a friendly "READY ?" prompt. It (like the Teletype time sharing terminal) was intoxicating. I felt instantly at home, even though I didn't know what I was doing.

The feature that appealed to me the most was that the PET was self-contained in one attractive all-metal case. My KIM-1 had been a mess . . . the PET was tidy . .. you could say that it was house-trained.

I could run BASIC programs and store them on the PET's cassette tape drive. The tape drive was very slow: I could start the tape drive, get a cup of coffee, and when I returned it would still be loading a program.

Since my small business needed an inventory system, I wrote a simple one in BASIC for the PET. It seems laughable now, but part of the sorting process involved hand swapping data cassettes in and out of the drive as needed by the program. It worked, but it was a frustrating mess to use. The fact that the tape reads would frequently fail didn't help.

I tried to turbocharge the PET by adding external memory (in an Integrand S-100 box that was almost the size of the PET itself). I used an S-100 interface card that was made by a tiny company that called itself HUH? Electronics. I bought three 8-Kilobyte static RAM S-100 cards from Bill Godbout. His were the cheapest that I could find -- a mere $150 or so apiece. (Dynamic RAM boards were cheaper, but I wasn't sure that I trusted them to be refreshed.) So for 24 Kilobytes of RAM, I paid $450, plus case, etc. (Compare that to today's memory prices.) They ran fine, but ran hot!

Teletype 43

Next, I added a Teletype Model 43 terminal, which I used as a printer.

It had a serial (RS-232) interface; I hung that off the PET's IEEE-488 port via an IEEE-488 to RS-232 converter box that was made by another small company called NETworks (I think). I added a pair of tractor drives to my Model 43 so that it could pull tractor drive perforated paper through it.

My first hardware upgrade was to double-density diskettes: a whopping 180K per diskette. This required a new disk controller card (still with many TTL chips), which cost at least several hundred dollars. It apparently used programmed I/O through the CPU, as it still couldn't tolerate turning off interrupts while it was reading or writing.


I developed a love/hate (mostly hate) relationship with the RS-232 interface: I guess that it worked fine for its intended purpose, but when used otherwise by manufacturers who modified the RS-232 spec, it could be surprisingly tough to troubleshoot. The exact meaning of RS-232 lines would change, and their 0 and 1 voltage levels would change. It was only a prelude to decades of RS-232 entertainment.

With the PET and all its ancillary boxes, I had created a kludge . . . and it still lacked reliable data storage and a comfortable keyboard -- which would add two more boxes.
Reluctantly, I concluded that I'd bet on the wrong horse . . . er, computer. It's ironic that though the PET was self-contained, to make it work for me, I needed to add external boxes . . . and I had bought it because it was self-contained!

I still think that the PET would have made a fine controller for intrumentation, in a manufacturing or product test setting. It was a natural, since it contained an IEEE-488 interface (also called HPIB: Hewlett Packard Interface Bus and GPIB: General Purpose Interface Bus).

So far, I’d not met anyone who shared my interest in microcomputers. Soon, computer stores were springing up, so I ventured into one of the first stores in this area.

I venture into CP/M and its inner workings.

c 1979 - 1983

NorthStar Horizon

In 1980, I bought a NorthStar Horizon from a local shop (Computer Age?) in Pompano Beach. It had a 4 MHz 8-bit Zilog Z-80 CPU, 16 Kilobytes of RAM, and two 5.25" Shugart SA400 floppy drives.

Each hard-sectored floppy disk held 90 Kilobytes. I attached a new Hazeltine 1500 video terminal via an RS-232 cable, and I was in business. The Hazeltine 1500 had a pleasant green on black display. It was originally set up for 9600 Baud, but I found that by enabling the RS-232 DTR (Data Terminal Ready) or CTS (Clear To Send) line to provide flow control, I could make it work at 19.2 kilobaud and eventually 38.4 kilobaud.

What’s CP/M?

CP/M is (or. was) an operating system that preceded MS-DOS. MS-DOS's system calls are a superset of CP/M's. It was created by Gary Kildall, who founded DIgital Research.

"If you feel like finding out how exactly computers work, from the ground up, studying CP/M is the best way to do it." - Oscar Vermeulen

The Horizon was delivered with a complete set of schematic diagrams. Imagine that today!

With the Horizon, I purchased a program called NAD (Name and Address), which was written in CBASIC by Structured Sytems Group. I'm pretty sure that it included its source code. I also purchased its companion utility, Qsort, which allowed the NAD data file to be sorted by any field or combination of fields. I don't think that source code was included with Qsort. I used NAD for years to track prospects and customers. Before each business trip, I'd sort the file by date of last contact and print only the zipcode range of my destination. It worked great.

I had a simple inventory program written for me in CBASIC by an IBM programmer who moonlighted the job. It worked, but was crude: it contained no error checking anywhere. After being nickeled and dimed on simple changes, I bit the bullet and began modifying the inventory program myself.


CBASIC was a great language, for BASIC. The programmer could add comments galore to the source code without imposing a runtime penalty because the source code would be submitted to CBASIC's compiler, which created the runtime file. Gordon Eubanks (the creator of CBASIC) called this file "Intermediate code". At runtime, an interpreter (called CRUN) would execute this code. CBASIC was a giant step away from the easy interactive nature of classic Dartmouth BASIC or Microsoft BASIC, but it was perfect for business applications.

Among CBASIC's many nice features was its freedom from line numbers. Instead, subroutines could be given alphabetic names. You could define your own functions. It had structured programming features, but didn't enforce them. It included both integer math and floating point math with precision that exceeded any other BASIC's. It was wonderful for writing business applications.

CBASIC’s origin

CBASIC was created by Gordon Eubanks, a friend and student of Gary Kildall, who created the CP/M operating system (from which Microsoft's PC-DOS and MS-DOS 1.0 was derived). Years later, Gordon went on to become CEO of Symantec, having been attracted by their interactive database system named "Q&A". CP/M was beaten to the IBM-PC starting gate by Microsoft's PC-DOS, and slid into a steady decline, as the 8-bit 8080 and Z-80 CPUs were superseded by the 16-bit 8086 and 8088 CPUs. It's a pity that Symantec's current products lack the elegant power of CBASIC.

What happened to CBASIC?

John Dvorak's well-done story about CBASIC, Osborne Accounting, and most of the other players c 1979 - 1982.


Soon afterward I bought a word processor for the Horizon: Autoscribe, as well as an NEC Spinwriter 5520 thimble printer (What an awesome printer!), also with an RS-232 interface. The Horizon, Autoscribe, Hazeltine 1500 video terminal, and the Spinwriter printer made an impressive word processor system. I punched out thousands of business letters (most were filled with boilerplate) with that system. Its only shortcoming was that it was its own world. I think that it used NorthStar's primitive operating system, but I didn't know how to determine that.


After happily using the Autoscribe word processor for over a year, I bought an early release of WordStar. I liked it because it allowed me to suck in reports from my inventory program. I used its mailmerge to read in NAD records to send targeted announcements. This was c 1982. WordStar was an awesome wordprocessor.

Osborne Accounting

I bought a copy of Adam Osborne's Accounts Payable and Accounts Receivable in BASIC for a Wang computer. It was close to CBASIC, though written for a tiny screen (20 rows of 16 column charcters), so I began hand keying it with my modifications unto a floppy diskette, using CP/M's ED line editor. It took me many weeks to key it in. I was intrigued with the way that the program kept its data files sorted and then performed binary searches. There were no indexes, that I can recall. It was a batch-oriented system: you'd enter a transaction into a transaction file; at day's end or week's end, you'd print and review the transaction file, then post it. The posting operation would merge the transactions with the existing file. Once I'd debugged it, it worked very well. The binary searches, even with many thousands of records, were almost instantaneous.

Getting this to run properly took many months and taught me a great deal about business programming.

Then Adam Osborne released A/R, A/P, and G/L in real CBASIC, and I punched in all of that. What a time consumer that was! There were bugs, but fixing them taught me a lot about business programming and accounting. I used this system for several years, happily churning out invoices and checks, and keeping my business' books balanced.

Upgrading keyboard input

The Horizon was very reliable, but its BIOS had the annoying habit of turning off interrupts. The effect was that your keystrokes would occasionally disappear. I saw that fixing this would mean modifying NorthStar's BIOS for CP/M . . . and that meant teaching myself how to use CP/M's daunting DDT (Dynamic Debugging Tool) and ASM (assembler). Eventually I was able to patch the BIOS and through trial and error I quickly learned that the diskette drive electronics needed to turn off interrupts while it was reading or writing. I saw hope, though, for the video terminal (the Hazeltine 1500, which talked via an RS-232 port that CP/M called CON:). The NorthStar had simply used polling to grab characters from the serial port's USART.

One nice hardware feature of the NorthStar was that most of its i/o ports ran through a DIP (dual in-line package) header where the lines could be swapped in the connector's pins. It also accomodated rewiring the traces that ran to the programmable interrupt controller.

I'd begun subscribing to LIFELINES, which was published by Lifeboat Associates. It was filled with wonderfully technical articles, including an Assembler tutorial by Ward Christensen that taught me 8080 assembler. It also had articles with real working 8080 assembler source code. I borrowed a circular buffer interrupt service routine from a Lifelines article, and patched it so that it would relocate to the peripherals jump table in the Horizon's CP/M BIOS. Then I cut a trace or two on the Horizon motherboard and wired its serial port in question so that when a character appeared in its USART's buffer it would pull down a pin on the interrupt controller. Somehow, though I was stumbling in the dark, I got this to work. It was like magic. Now I could type madly away and not lose characters (until the diskette drive needed to work).

I uploaded this patch with instructions to a few BBSs, but never heard from anyone who'd tried it.

Assembler tricks

Then, drunk with the new-found power that assembler gave me, I started working on other aspects of the Horizon / CP/M system. I found unused acres (well, hundreds of bytes) of precious RAM and placed various routines, such as a software real-time clock, in it. The Horizon's disk i/o routine's insistence on turning off interrupts messed that up, so I replaced my software clock with a simple memory test routine that tested most of the machine's memory while it was idle.

Dialing for data

I bought a Hayes 300 baud modem that plugged into an S-100 connector in the Horizon. I bought a couple CP/M User group diskettes from Lifeboat Assocates, where I found Ward Christensen's Modem7 assembler source. I edited it and assembled it so that it worked on my NorthStar. I also had to add modem I/O routines to the NorthStar's BIOS. Next, I hunted down BBS's (bulletin board systems). My phone bill shot through the roof, as I'd call around the country with my modem and sometimes download huge files -- even 40 or 50 Kilobytes!

It seems laughable today, doesn't it?

Most of the early BBS's were RCPM (Remote CP/M) systems: you'd log on and seem to be running the other guy's computer from the command prompt. In fact, you were.

File libraries

Before there were ZIP files, before there were ARC files, there were LBR (Library) files. A file with an .LBR filename extension contained a set of files and were used by early BBS'ers. The first utility that I used to handle LBR files was LU.COM, and later, NULU.COM.

From 300 bps to 1200 bps!

I replaced the 300 baud Hayes S-100 modem with an external 1200 baud Prometheus modem, which seemed lightning fast.

CP/M 1.4 to CP/M 2.2 upgrade

Next, I upgraded from CP/M 1.4 to CP/M 2.2, and from the original CBASIC to CBASIC-2, which allowed chaining of programs. This was the magic ingredient that allowed me to call various accounting programs from one central accounting menu. CP/M 2.2 added USER areas and allowed larger disk partitions. (I think that CP/M 1.4 had a maximum partition size of 8 Megabytes!)

My first hard drive

Next up was a reposessed NorthStar HD-18 hard disk. It consisted of a metal housing that was about the same size and weight as the Horizon, attached to it via a pair of parallel data cables (one in; one out), and retailed for $4999(!). Its starting current was 12 Amps at 120 VAC, and its running current was 3 Amps: That's over 1400 Watts (about the same as a toaster) to start and yes, the lights would momentarily dim. It was closer to a washing machine than today's disk drives.

It contained a power supply, a 14 inch diameter Century Data Marksman Winchester disk drive which looked stout as can be, and a not so robust looking NorthStar interface card. All the DIP chips were (I think) TTL (transistor-transistor logic). It worked fine, when it worked, but would usually crash a few times each day. Sometimes the crashes were caused by drive speed problems, so I'd remove the drive belt, clean it, and replace it.

I got out my trusty disassemblers (Ward Christensen's RESOURCE and DazzleStar, a remarkable disassembler with a WordStar-like interface). Then I poked through the object files that ran the hard drive until I'd locate error routines and one by one I'd try NOP'ing them out or JMP'ing around them until I managed to resurrect the hard drive. That's not an approved procedure! I had none of NorthStar's HD-18 software source code, but judging by what I found in its object code, it was bizzare.

When the drive worked, it was heavenly. But it rarely worked.

Buffering print jobs

Next, I added a buffered parallel port card. (I don't recall the manufacturer; it was another tiny company.) It was a full size S-100 card with a Z-80 processor on board and a ton of memory. It was supplied with a listing of its source code in 8080 assembler. To make the card work, I needed to modify the NorthStar BIOS' "PRN:" out routine, and load its 1 kilobyte or so of object code somewhere in memory. Once working, I could send huge print jobs to the printer without tying up the computer. I was in heaven. By this time, writing assembler and using DDT to debug programs was becoming increasingly comfortable.

By the time that I reached this stage, IBM had been selling their new PC like hotcakes. The microcomputer times, they were a-changin’.

Business Applications for CP/M get real.

c 1980 -1983

Word Processors and Spreadsheets

Between about 1980 and '83, good business applications appeared for use on the CP/M operating system. Wordstar was the first that I used. Then I tried this new thing called a spreadsheet. My first exposure was Multiplan. (Yes, it was originally available for CP/M.) I used it to store all sorts of information. Multiplan was a wonderful spreadsheet program that, at least as far as I was concerned, predated Lotus 1-2-3.

These early spreadsheets quickly killed off a class of business programs that analyzed financial questions such as lease or buy decisions. With Multiplan, any bookkeeper could plug his lease or buy formulas into his own custom-tailored spreadsheet.

The number of records (or rows, in spreadsheet language) was limited to something like 64,000, and you couldn't index any fields (or columns). I don't think that you could link records in one spreadsheet with those in another, either. I was ready for a database program.

dBase II

Next, I learned dBase II, published by Ashton-Tate. (There never was a dBase 1. The "II" was a marketing ploy to make consumers think that the product was mature.) Initially, I used it interactively and it was very impressive. Then, I started writing programs using its proprietary language, which were stored as .PRG files. The same program could be used both interactively and as a runtime interpreter. I'd never seen anything like it. I wrote a simple sales lead prospecting program that used dBase II.

dBase II program files were properly called command files.

I liked dBase II and respected its power. With just a few commands, you could have it index a data file, and then find a record by searching any indexed field. It was great! To do this in CBASIC would have required pages of code. Even better, you could save those few commands as a .PRG file, call it a program, and execute them later. dBase II, as a language, lacked one thing: structure. To write long programs, the programmer had to impose his own discipline. My dBase programs tended to fall apart as they grew. It also had a low limit on the number of data files that you could keep open simultaneously: was it two? I forget.

Turbo Pascal

Then Turbo Pascal entered my life. Wow! That was an amazing product: within a 27 KB TURBO.COM it generated fast, small object code yet was a high level language with, of all things, a built-in editor, which used Wordstar commands. So, you could write a little code, compile it in an instant, and run it -- all without leaving the editor! (CP/M's executable files had .COM filename extensions.) This came to be called an Integrated Development Environment (IDE).

Read more about Turbo Pascal:

One of the wonderful things about Turbo Pascal was that it wouldn't compile a program that didn't conform to Pascal's strict rules. I found that if a Turbo Pascal program would compile, it would probably run, and if I was lucky it would work as intended. The discipline of Pascal was just what I needed, and the fact that Pascal code tends to be self-documenting was a plus.

I had read about other Pascals. One of the most interesting was UCSD Pascal, which apparently ran on what was called "the p-system" or "p-machine". The p-machine was a virtual machine in software only that in turn could be customized to run on a variety of hardware. I guess that the p-machine was equivalent to CP/M's BDOS (Basic Disk Operating System). I wanted to play with this, but couldn't afford the entry cost (at least $400), so I was thrilled that the first Turbo Pascal cost a mere $49.00. It was an amazing bargain.


Then I was exposed to BDS C. It was an inexpensive C compiler about which I knew almost nothing, and couldn't find much support. I played with it and wrote a few small programs, but I was always drawn back to Turbo Pascal, because it was so easy to create working programs, and I liked the structure that Pascal imposed and its self-documenting nature.

CP/M datcom upgrade

I downloaded, customized, compiled, and began using MEX, which was a slick terminal program that was written in assembler -- or at least its interface was. It was delivered as an object file with an interface block that allowed the user/integrator to customize it by hooking into defined offsets with predefined values in the CPU registers. I liked its user interface. I stopped using the simpler, but less capable, Modem7. With MEX, I could use the zmodem file transfer protocol, which resulted in faster file transfer speeds than xmodem (128 byte blocks) and ymodem (1024 byte blocks). My phone bills, though, remained high, as the modem's CD (carrier detect) light remained lit for hours at a time.


One of my last CP/M adventures involved replacing CP/M's CCP (console command processor) with ZCPR1 and then ZCPR2. ZCPR (Z80 command processor replacement) was a terrific idea: it kept CP/M's BDOS and BIOS in place, but put a new face on it: the ZCPR command processor used Z80 instructions, so it was fast, and added more transient commands and a command history buffer. It also introduced the idea of command aliases to CP/M: you could, if you wanted, make ZCPR respond to the UNIX "l"ist command with the output of CP/M's "DIR" command.

CP/M just fades away

But, for the market, and for me, ZCPR was too late. The IBM-PC and its follow-up, the PC-XT, had been out for a couple of years. All commercial attention was focused on them and the MS-DOS (and PC-DOS) operating system. CP/M, the S-100 bus, and Z80 based computers were dying or had already died from lack of interest.

In retrospect, it's amazing how quickly CP/M fell from grace. I remember reading an article when the IBM PC first appeared, that said in so many words, "The IBM PC with MS-DOS will have a tough time competing with the huge base of installed S-100 bus CP/M computers. There are at least 100,000 in place already!". Those words sound almost comical today. I'll bet that 100,000 PCs are cranked out every day.