Background
At this point in history (roughly 1980), the newspaper industry was trying to move to full-page electronic pre-press and away from manual layout with scraps of paper, scissors and glue, along with at least three different technologies for type, graphics, and halftone photographs. They were held back by two barriers: no workstations capable of interactively working with all those elements, and no typesetter capable of outputting them all together. Camex set out to solve both problems.
I was most heavily involved in the typesetter program. We called it an imagesetter since it wasn’t limited to just type. There were two pieces: the electronics, called a raster image processor, marketed as the BitCaster, and the actual output device or BitSetter, the combination called the SuperSetter. The goal was simply stated, but very ambitious at the time: produce full broadsheet newspaper pages at 1000-dpi resolution in under a minute per page, including type, type at an angle, rules (horizontal and vertical lines like the ones that separate newspaper columns), black-and-white graphics and halftone photographs. This required much invention and innovation along with good engineering and some savvy business deals.
A small portion of a demo ad showing the sorts of page elements that could be supported: halftones, line graphics, type at arbitrary sizes and angles, drop shadows, halftone greyscale fill of objects, etc. This is a 1000dpi original scanned at 300dpi (the best my scanner can do) so the halftone quality is not adequately represented.
Learning about fonts
Most of us had worked with fonts a little or a lot, in order to correctly drive phototypesetters like the APS-4, APS-5 and Linotron 505 used by many of our 135 and 1350-series customers. Tom Hagan felt that a thorough presentation was in order, so he invited Chuck Bigelow to come give us a tutorial over lunch. Poor Chuck! He was knowledgeable, personable and patient as lunch stretched into dinner, then dessert. I think we’d have kept him all night if the restaurant hadn’t closed.
Buying fonts: BitStream
If we were to have a typesetter/imagesetter, we needed fonts. So we approached our contacts at Compugraphic, Autologic, Mergenthaler, etc. The conversation invariably went like this:
Camex: We’d like to license your font library.
Manufacturer: So you can compete with our product line?!
Camex: Well, yes.
Manufacturer: Don’t let the door hit you in the ass on the way out.
The executives at Mergenthaler were no exception, but the type design department was intrigued. “You mean fonts are software, not tied to hardware? We can get behind that!” So we crafted an agreement: the designers left Mergenthaler and formed a new company, BitStream. Camex (mostly Jim Flowers) built a font-design system called the Letter Input Processor based on the 1351 platform. We gave BitStream a few machines in exchange for rights to the first 50 fonts they produced. Those fonts were the original Camex type library. Samples of each font were printed on cards about 8"x8", and stored in a nice box.
My copy is a bit yellowed after 45 years on the shelf.
BitCaster architecture
We did the math: 17 inches times 22 inches is 374 square inches, each of which had 1000x1000 1-bit pixels (we called them bitsels, a term which did not receive wide acceptance). 374,000,000 dots in one minute means 6.23 million dots per second, or roughly 6 MHz, 780 Kbytes/second. This was not gonna happen with just a PDP-11; we were going to have to build a micromachine to do the fast parts.
The other problem is that the naive approach of just having a bitmap of the entire page was not going to fly. 47 Mbytes of memory at 1980 prices would price us out of the market. So we had to find a way to generate the bits on the fly without using too much memory. Mike Speciner’s experience with generating line art scan line by scan line was instructive: trying to interpret a complex page model where every scan line might intersect hundreds of characters and graphic elements would be grossly inefficient. Tom Hagan had the brilliant insight: let’s process “patches” of the page, say 512 bits on a side, then assemble the patches into a “swath” that could be output scan line by scan line at speed. I realized that patches 1024 bits wide by 256 deep would be about as efficient, and halve some of the memory requirement.
So the output side of the hardware had two swath buffers: 16384 bits wide by 256 bits high, arranged as a double buffer so the micromachine would fill one swath while the other swath was being clocked out to the output device. The micromachine in turn had a double buffer of very fast memory for two patches 1024x256 bits each, one of which would be copied to the swath buffer while the other was being filled.
The actual rendering of the page happened in three stages. A front end MC68000 machine running Xenix ran two processes, written in C. A parser read our high-level page description language and created an intermediate description listing all the font characters and graphic elements required, and a process called “INTER” read that description, created raster versions of the font characters (i.e. choosing intercepts, hence the name), and stored that description of the page in memory, where the micromachine could then process and output it.
We developed a clever representation for characters and simple shapes like rectangles at any angle. The basic idea was to represent the first scan line with a full 16-bit beginning and end, then represent subsequent scan lines with a variant of Huffman encoding which used very few bits if the next scan line was the same or only slightly different, and more bits if there was a large change or discontinuity.
For line graphics, we adopted the Group 3 encoding used by fax machines.
For halftones, we did convolution on the fly. One input was the usual array of 8-bit pixels representing the image, together with scaling information (the image might be 1000x1000, but could be scaled up or down to fit into any bit dimensions). The halftone dot was itself represented as an array of 8-bit values, one per output bit, so an 8x8 array at 1000 dots per inch would correspond to a 125-line halftone screen.
One customer had the unusual business of printing blueprints for major projects. An apartment building or factory might have hundreds of blueprint pages, typically output on an HP pen plotter. I wrote microcode that understood HP-GL, the language of those plotters. For very complex pages, rendering time was reduced from hours to one minute!
Typical HPGL output. Again, 1000dpi original scanned at 300dpi, so artifacts are not in the original.
The micromachine
The architecture of the micromachine was hammered out between Andy VanAbs and myself. Andy had decades of EE experience, and I was the designated microprogrammer who would have to make it play. We designed a micromachine with 16-bit data paths, 4K of 96-bit instruction memory, and a fixed 100ns cycle time, using four AMD 2903 bit-slice ALUs, a 16x16 multiplier chip, 4K of scratchpad memory, and four 74181 ALUs between the 2903s and the two 32K “patch” memories. The latter (copied from the Knight TV architecture) allowed the micromachine to use hardware bit-set, bit-clear or xor operations while outputting data, rather than having to read the patch memory and operate on it within the 2903.
There was an interesting feature we built into the micromachine to support rapid output of halftones, which were the most CPU-intensive elements. The basic operation for producing a halftone bit was to compare two 8-bit values, and the carry bit was the output bit. So there was a bit in the microinstruction word that divided the ALU into two 8-bit halves, and a shift register that would accumulate two carry bits (one from the low 8 bits, one from the high 8 bits) per compare. I then could program a loop comparing 8 pairs of 8-bit pixel values, accumulating a 16-bit result that could be copied from the shift register, through the 74181 ALU to the patch memory.
Output devices
Proof copies could be sent to a Canon LBP-10 240dpi laser printer, called the BitPrinter. The 1000dpi output device was a Monotype Lasercomp, (see page 12 of https://apmub.wordpress.com/wp-content/uploads/2014/01/monotype-and-phototypesetting-andrew-boag.pdf) which used a laser beam to expose silver-based phototypesetter paper. Camex sold these under the name BitSetter; BitCaster+BitSetter=SuperSetter. Another device whose name and manufacturer I no longer remember used a much more powerful laser to directly expose printing plates.
A SuperSetter being set up for a tradeshow. The ADM3 terminal was used for programming and debugging, but was not part of the product. The touchscreen display (then a novelty) atop the BitCaster was used to start, stop and replay jobs. The open cabinet reveals the VMEbus card cage containing the OEM MC68000 processor board, memory cards, and the micromachine card. Below that is the hard disk drive and the power supply. The cabinet on the right is the BitSetter (Monotype Lasercomp).
The Breeze workstation
In parallel with the SuperSetter imagesetter, another team developed a new workstation for composing ads and pages. It used the BitCaster micromachine to drive a framebuffer and high-res raster display, while retaining the tablet for sketching and command input from the 135 and 1351 machines. This was called the Breeze.
Breeze being demonstrated at a tradeshow
Similarly, here’s a Breeze with its guts hanging out, prior to being demonstrated at a tradeshow.
Epilogue
We started to bat around a design for a 32-bit micromachine to power the next generation of Camex products, based on the then-new Am29000 chip. But I left in September 1987 to join Symbolics.