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 >  
I venture into CP/M and its inner workings.
 
 
 
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"


Click for interior view

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.
 
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.
 What's CP/M?
 
It's an operating system that preceeded MS-DOS. MS-DOS's system calls are a superset of CP/M's. 
 
"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.
 

What happened to CBASIC?

John Dvorak's well-done story about CBASIC, Osborne Accounting, and most of the other players c 1979 - 1982:
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.
 
Footnote: 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.
 
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.
 
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.
 
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. 
 
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, 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.
 
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.
 
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.
 
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.
 
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.
 
I replaced the 300 baud modem with an external 1200 baud Prometheus modem, which seemed lightning fast.
 
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!)
 
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.
 
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'. 
 
Next page . . .