In the 1980's I had a client that manufactured cheques, and the typesetting was done by four or five "Wescode 1420M" systems. These technological marvels used an 8" floppy drive to input order data -- the customer name, account number and so on. The output was rendered onto a single web of fan-fold material which successively threaded its way through two Diablo daisy-wheel printers. The key point is it was a pipeline, with multiple orders in flight simultaneously.
Floppy swapping was a normal part of the work flow, and there was an obscure vulnerability in this regard. In some circumstances if the disk was changed at an incorrect time it was possible for data to leak between orders. (For example, Ted's cheques might bear Alice's account number! To call this intolerable is putting it mildly.) Disk-swap prompts were displayed on a terminal for the operator's benefit, but the environment was hectic and humans are fallible.
Did I alter the software so it'd preview the data and verify that every disk change occured as prompted? No. The 1420M computer featured three 8080 microprocessors mucking around in shared memory, and the code was a spaghetti monolith written in assembly language. I've reverse-engineered lots of stuff before -- there are a coupla stories here [1][2] -- but some challenges you need to walk away from. The time frame would've been open-ended, and that wasn't acceptable.
What I did was supply the client with a gory hack. No apologies -- it was the best way to serve their needs! On each 1240M I installed an 8741 microcontroller that monitored program status by eavesdropping on the RS232 line that carried text strings to the terminal. If those messages failed to agree with observed disk-change activity (relayed by the Door_Open signal on the floppy drive) the microcontroller would yank the 1240M Reset line low. This would crash the pipeline and force the operator to reboot -- a considerable nuisance... and yet, enormously preferable to allowing the error to go undetected!
Floppy swapping was a normal part of the work flow, and there was an obscure vulnerability in this regard. In some circumstances if the disk was changed at an incorrect time it was possible for data to leak between orders. (For example, Ted's cheques might bear Alice's account number! To call this intolerable is putting it mildly.) Disk-swap prompts were displayed on a terminal for the operator's benefit, but the environment was hectic and humans are fallible.
Did I alter the software so it'd preview the data and verify that every disk change occured as prompted? No. The 1420M computer featured three 8080 microprocessors mucking around in shared memory, and the code was a spaghetti monolith written in assembly language. I've reverse-engineered lots of stuff before -- there are a coupla stories here [1][2] -- but some challenges you need to walk away from. The time frame would've been open-ended, and that wasn't acceptable.
What I did was supply the client with a gory hack. No apologies -- it was the best way to serve their needs! On each 1240M I installed an 8741 microcontroller that monitored program status by eavesdropping on the RS232 line that carried text strings to the terminal. If those messages failed to agree with observed disk-change activity (relayed by the Door_Open signal on the floppy drive) the microcontroller would yank the 1240M Reset line low. This would crash the pipeline and force the operator to reboot -- a considerable nuisance... and yet, enormously preferable to allowing the error to go undetected!
[1] http://laughtonelectronics.com/Service/Embedded%20Computer/e... [2] http://laughtonelectronics.com/Projects/uCtlr%20Interfacing/...