Skip to main content

Computer Technical Support

by Russ Bellew · phone 954 873-4695

Home  Services  About Me  Tips  Truth  FAQ  Viruses  Jargon  My blog  Talk  Contact Me  Search   
My PC History 1 > My PC History 2 > Zilog Z80 > My PC History 3 > My PC History 4 > My PC History 5 > My Faves >  
Business Applications for CP/M get real.
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.
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.
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, it was too late. The IBM-PC and its follow-up, the PC-XT, had been out for a couple 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.