LAUGHTON
ELECTRONICS

The Wescode Typesetter: a
mixed-tech monstrosity

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 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."