Carrying one CAD program from a 613 kHz HP-85 to a Mac M4 that drafts from speech taught me about accuracy, speed, and writing code the next reader can pick up cold.
This article was written and contributed to Engineering.com by John M. Christy, founder of Tetra720 and the author of CADD/85, CADD 200/300 and C3. All opinions are his own.
My journey as a CAD developer began 45 years ago, and it started with a circle.
In the 1970s I had a small company called JMC Engineering. I designed audio products for musicians, instrument preamps, a phase-locked-loop frequency counter that stayed accurate at low frequencies, and whatever else came along. I did circuit board artwork on a light table, on film, in ink, with drafting tape of various widths, drawn at four-to-one and photographically reduced, which shrank the errors along with it. I still have the light table.
And then, at the Design Engineering Show at McCormick Place in Chicago, I saw a computer system that could actually draw. The only problem was that it ran on what was then called a minicomputer and was priced at roughly $500,000. I could barely afford $500, let alone $500,000. I wanted a computer that could draw a circle, and there was none I could afford. So I decided to teach myself programming and make my own.
I’m still making it 45 years later. Software development has changed dramatically; these days I do most of my programming with AI. Changes are coming for CAD as well, but my decades of CAD development have taught me what shouldn’t change—and why less is often more.
Creating CADD/85
My first computer was an HP-85. It had a five-inch screen, a thermal printer and a tape cartridge in one box, HP BASIC in ROM with engineering graphics in the language, and an easy path to an HP plotter. Its clock ran at 613 kilohertz when other machines ran at 4 megahertz. HP had chosen complex and slow over simple and fast, doing its arithmetic in binary-coded decimal to fifteen significant digits. The answers were right, but the machine was not fast. A variable name was either one letter or one letter plus one digit, so you had 286 simple variables and that was it.
I wrote a CAD program inside that box. It drew circles, lines and boxes, it grew a library of schematic symbols, and because the HP-85 sat on engineers’ desks all over the world as an instrument controller, CADD/85 sold quite well. Hewlett-Packard listed me in its software catalogue as a supplier. I soon released CADD/86-87 for the HP-86 and HP-87.
Then HP brought out the 9816, and the only way to get real performance out of it was HP Pascal, so I spent a year getting good at it and started over. The result was CADD 200, later CADD 200/300, published by Tensegrity, Inc. in Chicago. (The name came from Buckminster Fuller, who personally gave me permission to use it for my company as long as I told people, in his words, that “the word tensegrity is an invention of R. Buckminster Fuller.” I printed that on my business cards. I attended his lectures in the 1970s, and we met and talked several times.)
Two decisions from that rewrite have outlived every machine it ran on. The first was in the database. I gave every item an extent, so a redraw only touched what passed through the screen and ignored everything that did not. Most CAD programs of the day redrew the whole file every time. That alone made CADD/200 many times faster than the products it competed with.
The second decision was in the source. No longer limited to one-letter variables, I named everything for what it was and what it did, and I commented heavily. Four decades later I can open any procedure in that Pascal source and see what it does at once.
The users taught me the rest. John Hardy of The John Hardy Company in Evanston, Illinois, who designs precision audio equipment, started on CADD in 1983 and never stopped. He used it on a succession of HP machines for sheet metal, injection-molded plastic, machined parts, schematics and circuit boards. I gave him the source, and he added what he needed, including wide lines in the 1980s and a Gerber output in 2012. A customer extending a program thirty years after it was written is the best test of readable code I know of.
In the 1990s I went into a different business and put CADD to the side. But last year, in a very different environment than the one in which I had started, I decided to revitalize it.
The 2025 rewrite
The first question was which platform to use. I looked hard at the PC first, but found no combination of language, graphics library and tools that made sense as a whole. The Apple ecosystem did, because it was the HP workstation world again: hardware, operating system, language and tools as one coherent thing. For that reason I started my rewrite for the Mac.
The rewrite began around October 2025. I had my Pascal printed out and a 1980s HP 340 running beside my MacBook, feeding drawing files across a serial link. Early on I began handing pieces of the Pascal to Claude to analyze and comment on, and that is how the Apple code began.
The more we worked, the more it became an actual team. My job changed. I stopped being the programmer who writes the code and became the producer and director who decides what gets built, and the quality-control tester who decides whether it ships. The program, now called C3 (an abbreviation of CADD300_Modern), was feature-complete by February 2026.
I’m currently working on a Windows version of C3, mostly written by Claude under my direction.
Features on request
In the HP days, when a user asked for a feature I could usually build it, but it took a lot of coding, a lot of testing, and a lot of time. I always invited my users, mostly very good engineers and scientists, to ask for whatever they needed.
With Claude as my programming partner, an idea, its implementation, and its testing sometimes take minutes instead of months. Before any new code is committed, nearly two thousand tests run to ensure that what we are adding does not break what we already have. The whole suite finishes in under half a minute.
For example, not long ago I was drawing in C3 and was not sure how to use a function I needed, so I went to the manual and searched around, which is slow. I said, “Claude, we need context-sensitive help.” The user guide, which runs over two hundred pages, was restructured, and now, whenever you press the help key, the program opens the manual to the exact spot for whatever you were doing. Another time I wanted photographs and spreadsheets in a drawing, and the program could not do either yet. Within minutes it could, and the spreadsheet lives inside the drawing itself, with formulas for bills of materials and hole schedules saved in the same file.
The C3 assistant came in three steps, and the first two had nothing to do with artificial intelligence. In January I asked for voice guidance that tells you what to click next. For a line that is trivial; for an angular dimension you click the start and end of one line, the start and end of the other, and then the place you want the arc. A new user has no way of knowing that (I forget the sequence half the time myself, and I wrote the program). So in May I asked whether we could just talk to it: “lines menu,” “circles menu,” etc.; it now understands more than two hundred spoken commands. In September I asked whether it could draw something from a request in plain words. That became the assistant: a language model driving the program through its own command catalogue, one undo step per request, and driven by dictation.
What did not change
What changed in 45 years is everything you can see: the machines, the languages, the screens, the fact that I now describe a part out loud and watch it appear. What did not change is what I would tell an engineer or a manager to hold onto.
Accuracy before speed. HP built a 613 kilohertz machine that got the arithmetic right while the competition ran six times faster and rounded. The program today solves every construction, tangent circles, arc fits, intersections, and offsets in closed form, never by a grid search or an approximation, because an error nobody can see on the screen shows up at a hundred-times zoom and in the shop.
Draw only what the screen can see. The item extents from the first Pascal version are still there, as a spatial index with bounding-box culling.
Write it so the next reader can start cold. The comments and descriptive names I adopted after living with one-letter variables are the reason I could read my own 1985 Pascal in 2025, and the reason a language model could read it too and help carry the design forward. The new code and its plan documents are written the same way, for whoever reads them next, person or model.
R. Buckminster Fuller had a word for the phrase in my title. He called doing more with less ephemeralization, and he meant it as the way a growing population could be supported without anyone having less: each generation of tools gets more result out of less material, less time, and less energy. One person carrying one program across 45 years, and building in minutes what once took months, is a small instance of exactly that.
I wanted a computer that could draw a circle. It took a while.
About the author
John M. Christy is the founder of Tetra720 LLC in Chicago and the author of CADD/85, CADD 200/300 and C3, a 2D CAD program for Mac and Windows with a built-in assistant that drafts from plain-language requests. Because C3’s code base was structured so that a language model can read and change it safely, he builds the functions his users ask for in days rather than months, which he does not know another CAD program to offer. Earlier he designed audio equipment under the JMC Engineering name and wrote the roaming settlement systems used by most of the Baby Bells. He attended Buckminster Fuller’s lectures in the 1970s and has used the Tensegrity name with Fuller’s personal permission since the 1980s. To learn more, visit tetra720.com.
