Vector Lookup Tables

I helped electrical engineer Jeff Bradford complete a vector generator for the Projection Kanji Keyboard. Jeff simplified the ECL design by moving considerable logic into static ram lookup tables. I used APL's array manipulation to formulate and check the bit patterns that would fill these tables.

Hardware

The display driver could draw vectors fast enough to paint flicker free characters from vector strokes. It was realized as a single board using the power-hungry but very fast bi-polar transistor emitter-coupled logic (ECL). Static rams were available that were correspondingly fast. The board consisted of rams, registers and the DACs that would drive the display.

Jeff used table lookup in several locations. Sometimes this involved splitting tables between rams as the desired size parts were not available.

The rams would be loaded at power-up from much slower ultra-violet erasable electrically programmable roms routinely used in the then emerging micro-controller field.

Representation

I created two-dimensional arrays of bits using APL functions which were all stored in an APL workspace between sessions.

I wrote a format converter that would translate a properly dimensioned array into the text format required by the commercial rom programmer in use in our lab.

Although this process was repeatable, we had little desire to debug mistakes we might make in constructing tables on the high-speed hardware in which they would eventually run.

Methodology

We developed tables for each section of Jeff's design one by one. I worked with Jeff at the terminal writing formulas that would generate bits.

We wrote first using arrays of integers to understand the lookups as they would occur at the register level.

We transformed these into bits and then split those bits into the shapes of the ram parts in the design.

We then transformed ram bits into the bits as they would appear in the roms, reversing the transformation that would happen on power-up.

At each step we would first create an array and then ask ourselves how we might know that it is the correct array. We would create row or column sums and then look at the distribution of these. Did they make sense knowing what the vector generator would be doing?

If sums alone weren't convincing we would write some part of the hardware in APL and then run it in all possible cases rendering some part of the result as graphics on the high-resolution 4014 display.

This process worked. Over several days we built the necessary software tools, developed and checked the bits, and then programmed the hardware that worked first time. No after the fact debugging required.