Generic Digital Instrument

The prototype imagined something like a software defined radio but with acquisition, memory and display modules aimed at test instrumentation.

The physical design was TM500 sided modules with a 20 MHz ECL bus connecting adjacent plugins which would then have to be plugged in together. A debug extender card was not an option.

Computing was provided by an adjacent rack with a then new Multibus backplane. Various processor, memory and io cards shared the bus asynchronously. We found the commercially available cards lacking in an environment without reliable setup and hold. Instructions failed to properly set state. Memories dropped refresh cycles and eventually forgot.

I was responsible for modular software that would communicate with queued data packets in a scheme generally referred to as "mailboxes". I wrote a round-robin scheduler for tasks resident on each individual cpu board. A generic digital module then would consists of its tasks and would communicate with other addressable tasks disregarding their origins.

I chose a fixed packet size of 80 bytes plus headers. This matched the terminals we used which were 80 characters wide. In retrospect I should have chosen 128 bytes which would have seemed more modern at the dawn of the microcontroller era.

A request was composed as a sequence of numbers interspersed among control bytes drawn from the printable ascii alphabet. They were created and sent with string interpolation inspired by unix printf. They were parsed upon receipt with a switch statement where clauses for each control code would read numbers where expected. I converted binary data to decimal thereby avoiding any concern for word-endian differences between cpu cards.

I learned the trick of assembling numbers in the slightly larger space of negative two's-complement numbers then negating the result.

while (nextchar isDigit) assembly = assembly * 10 - digitValue

Tasks could be bundled and burned into EPROM with headers that would cause them to be launched at boot. Parts would be labeled with a bundle name and start address, C000, D000 or E000, depending on which socket they would be placed.

Collaborating tasks guided data through the modular hardware whatever its current configuration. A frequent destination was the custom waveform display which mixed video with 24x80 color characters.

A window task managed overlapping rectangular character regions on behalf of other tasks. A color manager allocated scarce pallet slots on behalf of tasks that wanted color. A touch task recognized taps, drags and two-finger stretches and dispatched corresponding messages to tasks that registered them.

Aside from the rigor of developing in a demanding environment, the multi-bus machinery turned out to be little more than an exotic memory bank switcher commonly used in simpler designs to extend the then prevalent 16-bit processor address space.