The Wescode Typesetter: a mixed-tech monstrosity

Laughton Electronics

This article describes some unique typesetting equipment which I serviced during the 5 years or so that it was part of my client's operation. I took care of routine breakdowns, and also implemented remedies for a few systemic problems. The most serious of these posed an acute quality control issue.

Physical layout of components

Logical interconnections

Wescode Description and Function

The Wescode 1240M was a bizarre and seemingly backward collection of gear, but despite its quirkiness it was effective, and a customer of mine ran a collection of 1240M's very successfully. The firm printed and bound cheques which, through banks, were sold to the consumer market.

Wescode 1240M's were typesetters which printed the account numbers and account-holders' names onto sheets of heavy paper. The sheets were then used as plates, aka: "masters." Mounted on a printing press, they were a cost-effective means of mass-producing the final product — the cheques — using plain paper.

The information to be printed arrived on floppy disks produced by another system. The 1240M would read the disk then print the masters using impact printers: specifically, Xerox "Diablo" 1345WP daisy-wheel printers. (I describe these remarkable devices here.)

Each 1240M (diagram, left) used two printers: one that printed the customer's name and address, and one that was specially equipped to print the account number — a field requiring machine-readable MICR typeface.

The paper master material was fed in a continuous web through the system. Starting from a fanfold supply underneath, the web traveled up to the plain-text printer first, and then up again to the MICR printer above. Due to the delay between printers, at any given time the system would be producing two jobs at once. The entire apparatus was contained in a bulky, oddly shaped fiberglass cabinet that tended to jiggle and shake from the strenuous carriage excursions of the printers. That, plus the machine-gun racket from the printwheel hammers, made a room full of Wescodes truly memorable to behold.

The electronics were peculiar as well. The designers had seen fit to deploy a sophisticated, triple-microprocessor system with a shared-memory architecture. The main memory array connected to three individual processor boards, each with a CPU, dedicated I/O and some private ram and EPROM. One CPU handled I/O for the terminal and floppy disk, and the others were for the MICR and Text printers. But the components were ancient! The CPU's were 8080's, and the shared-memory array was 16KBytes (standard).

Wescode Service: routine and not-so-routine

Routine service on these systems involved a lot of problems with the floppy drive, and at first we were also plagued by a shoddy wiring harness that (sometimes) supplied DC power to the boards. We had a lot fewer system crashes after I reworked the power distribution.

The other main cause of system crashes was electrostatic discharge (ESD). It used to be a serious nuisance, because the operator needs to tweak the setup occasionally, and of course that involves touching the printers. But merely touching a printer could produce an ESD sufficient to crash the software, forcing a reboot — and, worse yet, emptying the pipeline and wasting 4 or 5 half-completed masters.

The "fix" was to redirect the chassis ground on the printers so that ESD current didn't have any parallel path through the signal-ground wiring leading back to the computer. When I was done, there was only one path for ESD current, and that was via a dedicated conductor running straight from the printer chassis to the ground on the AC mains cord that powered the entire system.

A Memory Upgrade

When my client acquired some additional 1240M's, we discovered that the machines, purchased used, had only a single 16K memory board each, whereas we were using 32K (two boards) per machine. This turned out to be kind of a fun problem to solve, as I had access to RAM chips whose capacity dwarfed that of those in the original design.

For each machine, instead of adding chips or adding a second board, I removed all thirty-two of the original chips. Then I altered the board wiring to accept a single 32K-by-8 CMOS static ram. Despite using 1/32 as many chips, the capacity of the board was doubled!

the kludge that no-one questioned

The Wescode Disk Watchdog

The strangest and by far the most serious malfunction the 1240M's ever presented was one I couldn't effectively resolve except by getting well "outside the box." The problem had to do with the interaction between the human operator and the machine's software.

The program and the operator communicated via the 1240M's terminal, which featured a keyboard and a two-line ASCII display. Repeatedly throughout the day, the operator would insert a new floppy disk containing cheque data and then use the terminal to control the printing. But in certain circumstances it was necessary to be quite careful in regard to when you inserted the next disk. Otherwise, it was possible for data from two different disks to get intermingled and printed on the same master. Specifically, it was possible to produce an order of cheques that showed one person's name and address, but the account number would be for someone else's account! It was an absolute nightmare waiting to happen.

100% vigilance by the operators would avoid the problem, but management understandably wanted a more robust defense against disaster. Besides vigilance, another solution would've been to revise the 1240M software. But to do so would've taken an enormous commitment. It was a multiprocessor system, remember, and the program was a spaghetti monolith written in 8080 assembly language.

Luckily I was able to offer my client a third option, which I explained carefully and they accepted. It was doable, and it answered their need for something bulletproof. But it was hardly elegant, as you will see.

I added a fourth processor to each system — not an 8080, and not connected to the shared memory array. It was a single-chip microcontroller from the Intel MCS-48 family, and it tapped into only three signals on the 1240M:
  • One signal was the RS232 serial data line going to the operator's terminal
  • another was the Drive_Door_Open line (part of the floppy drive interface)
  • the third was an output driving the System Reset line. (You see where this is going?)

The new chip monitored 1240M program status by eavesdropping on the text strings sent to the terminal. (Although the microcontroller lacks a UART, an assembly-language routine served that function.) The Drive_Door_Open signal indicated when the floppy-drive door had been opened. If the operator opened the door to insert a new disk at a time when the program wasn't in an appropriate state, the chip would react (somewhat drastically) by yanking the 1240M Reset line low, thus bringing the entire system crashing to a halt and forcing the operator to reboot!

I make no apology for having sold such a kludge to my customer. It was the quickest solution that could be put in place, and with a potential crisis on their hands, their priorities weren't on any niceties of engineering aesthetics. "Not everything worth doing is worth doing right."

Commercial & Manufacturing
Stage & Studio
Laboratory & OEM
copyright notice (Jeff Laughton)