I’m Old, Part XV: PostScript Printer Development

TurboButton_5e82e769-9cf9-4f8e-b56d-8b07cdf126d2

When I worked at Adobe on PostScript printers, there were four choices for development, and one of them was a non-choice. The best was if you had a system where the print controller was a device running a real operating system. This would mean that you could use actual development tools, like a debugger, on the system when it was live. Few of the printers had this. Next best was have an I.C.E. (In-Circuit Emulator), which could let you do all kinds of nifty things like halt the processor when a particular value was written or read from a memory location or range. This was fantastic for tracking down heap smashers and is still better than the state of the art for desktop development, IMHO.

Next, and most common, was a system where the controller was rigged to have extra RAM and there was a simple monitor that could download code into RAM for execution. If you were lucky, the monitor had some break point facilities, but they were usually very primitive in that you had to pull up the symbol table on the host, search for the function you wanted to break on, then you could type that address into the monitor to set a break point (or as a stepping off point to disassemble the code and find the actual address. The monitor would typically replace the instruction at the address you specified with an instruction that would generate an interrupt so that the monitor could take over.

The worst way to develop was to compile, burn ROMs, plug in the the ROMs and test the code. Totally sucked, and I was glad I had to do it only rarely.

During all of this, there was a system that was built by Treve Bonser called a Soft Printer, which did its best to simulate a typical printer controller, but ran entirely on the host. This allowed you to take advantage of host debugging tools that didn’t totally stink, but to be honest, in the 1990’s, debuggers on the hosts weren’t very good.

Most of my work was done in the RAM based version.

This was OK, but it wasn’t great. When I compiled a new version of the code, I would look forward to having to download it over a serial connection to the printer. Several of megabytes at 19200 baud, was still significant. Ed McCreight, an ex-Xerox engineer who invented the B-Tree, had made a nifty device that hooked into the SCSI port of the host and a ROM socket on the printer. This done, the monitor could then pull in code via SCSI which ran at around 10-20 megabytes/sec – way better than serial.

With some help, I made a specialized socket for the 68K processor on one system with a push button that connected the non-maskable interrupt pin of the CPU to ground. This let me break into the monitor by pushing a button.

Still, the system was hardly ideal. RAM and ROM are fundamentally different and there are bugs that show when you run in RAM that don’t show in ROM and vice versa. Irritating. In addition, when you’re debugging, you typically end up commandeering one of the serial ports of the printer for communications to the monitor, which is a hassle when you have a bug reported that “sometimes you get a blank page when the printer is reading from both serial ports at the same time.”

In addition, there is an unfortunately too common problem where the CPU jumps to address 0, which is typically the result of calling a NULL function pointer. Should happen, but it does because programmers are lazy or sloppy or both.

With the 68K, low memory is dedicated to interrupt vectors. The problem with this is that the typical interrupt vectors look like valid code to the CPU, so when you jump to 0, it executes the interrupt vectors and often jumps into space, after having destroyed the contents of the CPU registers, making it hard to figure out (1) where you came from and (2) what the CPU state was when it happened.

There was an early interrupt vector that was guaranteed not to be used on our hardware, so I made a change to the master source code that would ensure that that vector was set to a value that would break into the monitor. Ta da.

One of my favorite hardware mods was done to a controller used by Ross Thompson. If I recall correctly, the controller was mounted in an old PC case because it was there and the power supply was adequate. Ross insisted that the hardware engineer wired up the “Turbo” button so that the indicator lit up. It didn’t do anything else, but Ross was happier to have a turbo button.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.