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, as well, was able to implement remedies for several 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 the quirkiness there was no question that such a machine was effective, and a customer of mine ran a collection of 1240M's very successfully. The firm produced cheques and bound them into chequebooks which, through banks, were sold to the consumer market.

Wescode 1240M's were typesetters which printed the individual bank account numbers and account-holders' names onto heavy paper sheets. The sheets were used as plates, aka: "masters." They could be mounted on a printing press, allowing you to then mass-produce cheques using plain paper.

The information to be printed arrived on floppy disk from another system. The 1240M would read the disk then print the masters using impact printers: specifically, Xerox "Diablo" 1345WP's. (I describe these remarkable devices here. They clearly are a topic in themselves.)

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 located 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 when the printers were running flat out. It was quite a sight 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 board handled I/O for the terminal and floppy disk, and boards two and three drove the MICR and Text printers. But the components were ancient! The CPU's were 8080's, and the shared-memory array was 16K (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 back to the computer. When I was done, there was only one path for ESD current, and that was straight 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 on the used equipment market, 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, because naturally I had access to higher-integration 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 net capacity 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.

For program interaction the operator relied on 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 could have prevented 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.

• 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. (An MCS-48 assembly-language routine served as the UART, since none is featured on this microcontroller.) 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."

NAVIGATE
Home
Commercial & Manufacturing
Stage & Studio
Laboratory & OEM