VCF: 3D Printing In The 80s

The Vintage Computer Festival East is going down right now, and I’m surrounded by the height of technology from the 1970s and 80s. Oddly enough, Hackaday frequently covers another technology from the 80s, although you wouldn’t think of it as such. 3D printing was invented in the late 1980s, and since patents are only around for 20 years, this means 3D printing first became popular back in the 2000’s.

In the 1970s, the first personal computers came out of garages. In the early 2000s, the first 3D printers came out of workshops and hackerspaces. These parallels pose an interesting question – is it possible to build a 1980s-era 3D printer controlled by a contemporary computer? That was the focus of a talk from [Ethan Dicks] of the Columbus Idea Foundry this weekend at the Vintage Computer Festival.

The serial number

Revar’s LCD mod

Ethan’s test bench of electronics

First, the hardware. [Ethan]’s test bench consists of a Commodore PET Model 8032, running a 1MHz 6502, sporting 32k of RAM, and connects to the outside world through the ‘user port’ that has a grand total eight digital outputs.

The exemplar printer for this talk was a MakerBot Cupcake. No, the Cupcake was not in operating condition. A working MakerBot Cupcake is a newsworthy event, after all. However, this is actually a pretty good choice for a simple 3D printer. There are only three stepper motors on this printer, with each driver only requiring a step and direction signal. Endstops really aren’t required on the Cupcake, the extruder is just a DC motor, and a heated bed is a luxury. In total, you’ll need about eight control signals to run the motors in this printer, one or two more to turn the heaters on and off, and an analog input. Add in Revars LCD mod (expunged from MakerBot, but the Wayback machine caught it), and you can easily control a printer with a PET.

While it is possible to control the motors in a printer with a 6502, it’s not exactly easy. The electronics board developed for the Cupcake – the Sanguinololu – uses an ATMega644 running at 16MHz. The 6502 in the PET runs at 1MHz, but it gets worse: a lot of the instructions on the ATMega only require one clock, whereas the 6502 takes several clocks per instruction. The 6502 simply doesn’t have the ability to step through the code as fast as a three-dollar microcontroller.

There is also the problem of how to store a 3D printable file on a vintage computer. Today, it’s not uncommon for simple STL files to weigh in at Megabytes. A complicated model couldn’t have been stored on a vintage hard drive.

[Ethan] has a few solutions to these problems. He can’t really get around the processing speed of the PET, but he does have a solution to the size of an STL cube. During slicing, a 3D printable file of a cube is split up into layers. The bottom layers are simply solid, the middle layers have a perimeter and an infill pattern, and the top layers are just solid again. Instead of processing a file that weighs in at a few Megabytes, [Ethan] is simply taking a few bottom layers, a middle layer, and the top layers and running them through a for loop.

Was [Ethan] able to grind some MakerBot motors with a PET? Unfortunately not. The theory is there, even if slicing a model is far, far beyond the scope of this hack. Still, it is at least possible to build a 3D printer around a computer from the 80s. You only need to look at the original patents for evidence of that.

This is just Brian’s cognitive bias and the typical “Open Source” ignorance regarding the IP world.

Patent’s didn’t prevent anyone from working on 3D printers in the 20th century. Definitely not the ‘ground-braking” work of shitty FDM printers.

People like myself were building “Santa Claus” machines in the early 90s using salvaged pen plotters and shoving any material we could think of into a hacked hotmelt glue gun. The biggest problem was access to CAD computer programs and having a PC with enough computational power to run them.

Several of us built businesses out of this weekend work. Scott Crump was part of the small scattered community trying to develop a reliable material. For those not familiar, he’s the founder of Stratasys. The joke who started the Rep-Crap took nearly all of the community’s work for his mindless project, now he’s considered some ‘father of 3D printing’.

Literally zero innovations have been made in this FDM field in the last twenty years. Most of the new awesome seen in HaD is just stuff that you’ll find in a ten year old commercial $10k printer. This is why most big players got into catalyst resins, laser sintering, etc decades back.

The first rule of HaD:
If it’s not on a blog with pictures and original content for Supply Frame to exploit, the documentation never existed.

Unlike the “Open Source Hardware” community, we didn’t demand recognition or use stupid ‘licenses’, just put it in the public domain. … which in the 80s and 90s was mostly hobby magazines, amateur radio conversations spawned from HAM meetups, trade magazines, bulletin boards, computer clubs, etc.

Guess I could donate a few weeks of my time rounding up all this non-existent documentation so HaD can pay the bills with another poorly written article pointing to my blog…

The speed of the computer is not an issue at all. The only problem with a slow speed is that it will take a print longer to finish. A 1MHz processor isn’t a slow as you might think. But it helps to think more outside of the box. Where a modern computer could generate the stepperpulses realtime at crazy speeds (output through lpt, like with Mach3, my own selfmade 3d printer uses that software, works like a charm), the CBM could not… but think out of the box. If you use a 555 (yeah!!!) in combination with some counting logic and latches, you could let the CBM load the latch, let the external logic do the counting (stepper pulsing) until the desired value has been reached. Then give the CBM a signal and load the new value. So instead of shifting out 256 clock pulses you only send out an 8-bit digital value, which could be done MANY times per second. But again, I doubt if it is really needed. So anyway, slow is true but is doesn’t have to be the problem that stops the project.

As mentioned in the article, storing the file that needs to be printed is the real problem. But a pet can be connected to a diskdrive. If it was a 8250 which can hold 500Kbytes per side, it has 2 double sided drives, so you could store 2MByte without swapping disks (so you could leave the printer printing unattended). A 2MB file gives you enough storage room to print small but practical projects. Using an SD-card is therefore much more convenient. Because a CBM with a harddisk of that same period, only gave you less then 7.5 MBytes. If the file was spread over multiple disk, use as many as you’d like, the the sky is the limit… and be honest… who leaves his printer unattended for long periods of times. I’m always near the machine, listening for it’s noise, waiting for it’s input, ready to wipe the printer dripping “nose”.
Anyway, I like the method of this project, to copy the simple layers in order to reduce the filesize. A crude but effective workaround.

Are ther emore photos available of the setup / the machine?

PS: I have many types of Commodore computers and like to develop hardware and programs for it. It is a very fun challenge to make these machines do the unexpected. Build devices with modern components and do things that were unimaginable or way too expensive in the time these machines ruled the world. So I really dig these kind of projects, thanks for posting.

which isn’t impossible, but I think that you get the point. A 555 may not be the best choice for a clock source, but a much faster clock divided by presetable counter can do the job. Certainly, not as easy as generating the pulses directly from the computer, but no rocket science either. Depending on the acceptable error this could be it. There are more then one solution to this problem.

The system would essentially consist of two registers for the number of steps in X and Y directions, and two registers to set their stepping rates individually, and then double that for a command buffer so you don’t glitch or have to stop when issuing a new command.

And it still wouldn’t do curves without issuing a new command every other cycle at worst. It’d be easier, less complex and cheaper, to just add another 6502 to handle the stepping.

HA! Yep, It was totally Don Lancaster, and I subsequently found the article in this treasure trove of his ‘Hardware Hacker’ series.http://www.tinaja.com/glib/hackar1.pdf
there’s plenty of Postscript proselytizing in there too ;)

I guess what really took long is not the 3D printer itself. The most difficult at the time was probably the CAD for 3D modelling. Remember how the European symbols for logical gates became rectangular at the time early CAD for graphical schematic showed up…

If I were trying to do 3d printing on an 8 bit system, I don’t think I would try to store a traditional 3d model. Rather, I’d try to have a mathematical formula that generated each layer on the fly as a set of differential movements of the printhead. Some objects would be easier to make than others, so builds would probably be split into multiple parts that could be rendered easily. Essentially, each part would be a single extrude, loft, or revolve operation. I think this could be done in real time, but if not, it could be calculated like a raster on a scanline-by-scanline basis.

The first time I saw a 3D printer was on an old rerun of Arthur C. Clark’s “Mysterious World” back in the early ’90s, and it was actually a stereolithography machine. I’m sure they used something like a PDP-11, as opposed to a PET though.