I worked at CPT from 1980 to 1986 - the first year as a writer and editor and the following five
years in software development. For my first year as a technical writer, I worked with Gail
Ostrow’s group with the task of developing a set of manuals for the newly released CPT 8000
word processor. the CPT was a dealer driven sales network and Customer Support
Representatives had handled customer training - but until we started, there was no user official
manual for the system.

The writing department was brand new although the company was several years old. The
legendary story was that every year CPT showcased their system at the Hanover Fair in
Germany and the past year they were showcasing a 20MB add-on external disk. The press
release that went out to clients and the technical press apparently said “CPT Corporation
Announces 20 Megabyte Hard Dick”. Dean Scheff was so incensed at the error that he ordered
the start of a writing department of professional editors who would oversee all publications and
releases. I believe that Clarence Lehman brought on Gail Ostrow to oversee and build the
department. I heard this story from both Gail and Henry Neils so there was probably some
truth to it.

I edited, along with several others, the first user manual for the CPT 8000. Whenever I had a
question about how some feature or function worked, I went either to one of the Customer
Support Representatives or more frequently to Henry Neils who I believe, after Clarence, was
the principal programmer of the CPT system.

Clarence had written and designed the OS along with most of the low level screen drivers, print
drivers disc drivers and hardware interface (bus/io etc). I believe Henry did much of the higher
level features programming. There is a story about Henry . . . He apparently started working at
CPT as a night janitor cleaning floors, emptying wastebaskets, wiping desks etc. In his down
time, he began going through the printouts of the macro assembly language that Clarence was
working on and eventually figured out the how the whole operating system worked. He also
took broken chassis, memory cards and CPU cards and figured out how to fix them well
enough so that he had a working prototype in one of the janitor closets. One day he ran into
Clarence and told him he wanted to show him something, took Clarence to the closet, fired up
the cobbled together prototype, plugged in a boot disk and had the system play a section of
Bach’s Brandenburg Concerto’s over the tinny system speaker. The story goes that Clarence
hired him to do software on the spot. Henry later gave me a copy of the boot disk so I know
that part is true.

The system key feature was that the screen looked and functioned like a typewriter. It had a
high scan black and white screen of remarkable clarity. This sounds quaint today but
remember that you were dealing with a workforce that grew up using typewriters. As the
system looked and worked (digitally) like a typewriter, operating it seemed instantly familiar.
Text was typed on a single line and the ‘paper’ moved up when you hit the return key. Text
was typed along a typing line and for all the world it very much resembled an IBM Selectric.
This was a huge sales point at the time.

The CPT systems were based primarily on 8080 Intel processors. (And as an aside, the CPT
headquarters was located at 8080 Mitchell Drive.) Programming was done in a ‘macro-
assembly’ language which I believe was devised by Clarence Lehman whom I also believe
wrote the compiler. I’ve attached a copy of the instruction set which I can’t believe I still have.
My understanding was that Clarence’s OS was more or less multitasking. There were some
subtle differences but for intents and purposes it looked like it was a true multitasking system
which was unique at the time on an 8080 processor. In practical (and sales) terms that meant
users could print and still do word processing at the same time.
Clarence’s macro assembly language had the advantage of being extremely efficient in terms
of program space and execution - all of which was critical when you were trying to squeeze
functionality into 64K of memory and run efficiently on an 8080 8 bit processor.
The CPT 8000 had 64K of memory split into two 32K banks. I think the CPT 6000 had 48K of
memory. When we started out, the system had 2 8” floppy disks, later changed to 5” floppy
disks and then 3” semi-rigid disks. I don’t recall the disk capacities.

Henry Neils was a singular force within the corporation. Literally everyone - dealers, marketing
support representatives, sales people - knew him and if you needed to talk to anyone, all you
needed to say was ‘Henry asked me to talk with you’ and you’d have their attention. Needless
to say, there were lots of ‘Henry’ stories. He told me that one time they were committed to
show an external hard disk storage system (I believe it was the 20 megabyte hard dick above)
at the Hanover equipment fair but the hardware simply didn’t get done in time. Henry told me
he spent a long weekend putting a standard floppy disk inside a large enclosure then adding a
fan with bad bearings so it was loud, then he hooked up a bunch of lights on the outside so it
looked like it was ‘accessing’ something. Since the floppy disks had a limited directory, he
rewrote part of the disk access code to look like there were thousands of files on the disk. It
worked convincingly enough to start bringing in orders.

CPT was also, I believe, one of the first systems to offer an Arabic language word processor.
Henry designed all the hardware and wrote all the software to make it work on the system. He
told me that he worked out the hardware and software design while on a long drive out west.
He drove and talked and Sandy (his wife who also worked at CPT) wrote down detailed notes.
It took him about six months to pull the hardware and software together. This became a huge
source of income for the company. - and it was literally all Henry.

Another story was that the dealers and marketing kept hassling Henry to allow more features to
run contemporaneously on the system. It was problematic because we were bound to the 64K
of the system memory. The story goes that Henry kept trying to explain to them that
programming took up memory - and the more advanced the feature, the more memory it took
up. But the requests kept coming and the story is that Henry walked into a dealer/marketing
meeting with a 64 ounce pitcher and smaller pitchers with the memory requirements of the
requested features. He poured in the operating system, then the print system, then the basic
features. Then he started adding in the features that they requested - MathPak, WordPak,
Scientific Symbols etc. and the pitcher overflowed across the conference table and said ‘Now
do you understand?’

Henry had written a program called MathPak which allowed users to perform mathematical
operations within the text of a page. This meant that the system could do very basic
spreadsheet-type work. A bill could be typed out and then automatically added up; taxes and
shipping charges could be calculated; billable hours could be summed and calculated. I was
assigned to write the manual and apparently I asked Henry so many questions that suggested I
just look at the underlying code to see if I could figure it out for myself. As I began to learn the
code I started bringing changes and improvements to him. He finally suggested I just join
software development rather than stay in writing. The pay was a lot better and the work was
more interesting so that’s how I got started. I’d taken both fortran and an intro to micro-
computers in college so it wasn’t that much of a stretch.

Off and on we’d talk about features we thought might add value to the system and one of the
most requested was a spelling checker. We looked at it a number of ways but it always boiled
down to not having enough memory to implement a workable system. They even once sent
me out to talk to a VP at either Merriam Webster or Random House to talk it over. We all knew
the technology simply wasn’t there and we spent a pleasant hour in New York talking about
Shakespeare and computer based text analysis. One Monday Henry came in and showed me
a program he’d worked on over the weekend. It was a set of subroutines that let you hash
code a number of text strings and another routine that checked the hash table to determine if a
string had been encoded. The unique thing about it was that it was very space efficient, code
efficient and very fast. It sometimes gave false positives, but never gave false negatives. We
still didn’t have enough memory to make any kind of reasonable spell checker, but the program
was cool.

I did some thinking about it and decided that if you couldn’t do a comprehensive spell checker,
there might be some use for a partial one. So I spent a couple days writing a program that
looked at each word as you typed it, checked a hash coded table to see if it had been
encoded. The encoded word was then looked up in a table and the typed text would be
replaced with with text from a stored table. It was an interactive search and replace. I’d
apparently just invented a very rudimentary auto correction. I pulled Henry over and showed
him what I’d implemented using his hash coding routine. I had him type hn and it was instantly
replaced with Henry Neils; sn became Sandra Neils; ds became Dean Scheff. Henry didn’t say
anything for a minute, then asked me if I’d shown it to anyone or talked to anyone about it. I
hadn’t. He said don’t talk to anyone, finish it up (it still had a few bugs and hooks that needed
to be added in the system) and let him know when it was submitted to the library and tested in
the system. It took me several more days to make sure it was stable in the system and didn’t
screw anything else up.

Henry, meanwhile went to work on marketing and legal. He argued with legal that this feature
was a profoundly different and unique idea that no one else was doing. You weren’t simply
telling the computer what to do, but the computer was actually monitoring your input and
interacting with you in real time, No one had ever seen that before- at least not in a word
processor Though truth be told we had auto hyphenation which was pretty close in concept.
Henry argued for a broad based patent which he knew would be extremely valuable to the
company. In the end the lawyers applied for and received a specific patent on the
methodology:
https://patents.google.com/patent/US4650349

It really was a curious place to work. Much of upper management was a revolving door. They
may have been competent managers in their fields but this was the early days of high tech and
many of them simply seemed to be overwhelmed by the pace of changes or clueless about the
role of software. In the one demonstration I saw him, Dean Scheff seemed distinctly ill-at-ease
with operating the system. Many managers wrote out letters/memos by hand, or dictated
them, and had the secretarial staff do the typing. We always found it odd how incurious they
were about exactly what they were engineering. This was in stark contrast to the regional
dealers.

Henry had developed this software feature that allowed users to type scientific symbols - a
feature aimed at the academic market. Gail Ostrow was in the meetings to name it (and I wrote
the user manual for it). The story she told me was that in the initial meeting they had presented
her with the advertising campaign that said ‘CPT Present SS - Scientific Symbols - the final
solution in technical typing.’ She said she looked at it in disbelief and asked if it was a joke.
They told her no it was a word play. She said they can’t do it and told me that they were
completely clueless on why it was unacceptable. It was a huge argument and I know that Gail
spent a lot of time talking to Dean Scheff and Clarence. In publications we kept trying to call it
‘Technical Typing’ or ‘Scientific Typing’ to no avail. We finally got them to just call it Scientific
Symbols - no SS abbreviation and no reference to a ‘final solution.’ They were interesting
times.

By 1985, the IBM PC was starting to steamroll the market. Despite its better screen and
efficient OS, The PC was a quarter to a third of the price with far more memory and an open
architecture. A couple of us in our off time programmed up a word processing program for the
PC that had a very similar user interface - it was basically a core CPT system written in the C
programming language that ran pretty efficiently on an 8088 processor. Because it was written
in a higher level language, it could be recompiled for whatever hardware was developed. It
was a demonstration project that showed we could port the CPT system over to the PC and
we estimated that with a small team we could get a more or less CPT 8000 equivalent up and
running in 6 months. We showed it to Henry who took it to management. The response was
that management felt we were a hardware company and that the PC could never compete with
us.

The CPT Phoenix was another story. Clarence Lehman and a small hardware group took about
a year to develop a successor to the CPT 8100. It was supposed to be a graphic based
system. My understanding is that Clarence built the whole thing out of PALs on a monstrously
complex display board that accomplished a number of affine transformation. The prototypes
that I worked on generated so much heat that the PALs would pop our of their holders and
you’d have to periodically remove the board and press all the PALs back into place. I also
heard that it was expensive to manufacture mostly because of the parts count.
One story I heard (whether true or not) is that toward the end of the Phoenix development, an
NEC (or it might have been Toshiba) salesperson demonstrated to Clarence a single chip set
graphic processor that did 95% of what Clarence’s board did at what was probably 1/10 the
cost. The story goes that Clarence ordered him out of the building. I’ve no idea whether it was
true but graphic processing chipsets were starting to show up.

The Phoenix used the basic CPT 8100 programming and the same macro assembly language.
One thing I developed for it was ‘soft’ keys - or a series of screen based ‘keys’ that
corresponded to hardware keys above the regular keyboard. But ‘soft’ keys could dynamically
change function or even be programmed with user functions.

There are lots of other CPT stories. Whether anyone is really interested is another matter . . .