III offers 3 options of intensity levels - 8, 64 and 256 respectively. Software systems (such as Driver or III Displayers) written for one option can be transferred to machines with other options with minimal effects on the pictures they produce. This paper describes how this can be achieved.
The relationship among the three options is best represented by a 3-level tree. It can be seen that each intensity level is refined further as one travels down the tree.
Each terminal node C(t) of the tree above can be represented by an ordered triple (i,j,k) such that,
i: relative position of the node in the sub-tree at level-3
j: relative position of the node in the sub-tree at level-2
k: relative position of the node in the sub-tree at level-1
The ranges of j and k are from 0 to 7 and that for i is from O to 3 as can be expected.
C(248) = (0,6,7) C(224) = (0,0,7)
To represent an ordered triple in FR80, 8 bits are required such that
BITS [15:17] = k (which means k is stored in bits 15-17) BITS [12:14] = j BITS [10:11] = i
(see section 6 for the actual implementation)
For machines which support 8 levels, the hardware selects only the lower 3 bits from the AC and ignore the higher bits , Similarly, it selects the lower 6-bits for the 64-option and 8 bits for the 256-option.
Suppose Driver was designed for a 256-option machine and is now in fact running on a 8-option machine. Let us assume the intensity level required is 248. The actual intensity chosen is calculated as follows:
C(248) = (0,6,7)
so the result is 7 because the hardware selects the lower 3 bits only and in this case it is the highest intensity that the machine allows.
The arguments can be the other way round. Say, Driver was designed for a 8-option machine and is now running on a 256-option one. If the chosen level is 7, the actual one selected will be C(224). In this case it is probably slightly weaker than expected.
Currently, our machine supports 256 intensity levels and Driver is designed with this in mind. As can be seen, the hardware picks up what is in the AC blindly and it is up to the software to ensure that the correct information are loaded. In other words, using the example above, Driver has to load 67 (octal) into the accumulator before calling the hardware (using IOT LBRT instruction). The mechanism used for the conversion will be discussed in the next section.
The best way to describe how Driver handles this problem is by listing the codes here. Diagrams 1 and 2 shows what is in the accumulator before and after the conversion (the user value is assumed to be 248 decimal which is 370 octal).
LAC uservalue / see diagram-1 now CLQ / clear MQ and link LRSS 8 / right shift 8 bits into MQ CLL / clear link LLS 1003 / clear AC / then left shift 3 bits from MQ into AC DAC temp / store in temporary storage LLS 1003 / do it again for the next 3 bits in MQ ALS 3 / shift ACs left 3 bit ADD temp / DAC temp / store it back LLS 1010 / clear AC / the remaining two bits in MQ is now shifted / 8 bits into AC ADD temp / now see what is in diagram-2 LBRT / call hardware to load value / into brightness register
Moving from higher to lower options there may be a slight gain in intensity. On the other hand, moving from lower to higher options, there may be a slight loss. The loss/gain is minimal and this is achieved by the combined efforts of the software and hardware.