Report on vintage "Programmer Electronnic Control" alias "RAF Tornado Computer"

Roger Holmes roger.holmes at microspot.co.uk
Mon Mar 12 15:03:20 CDT 2007


>
>>> not know how long development of such an aircraft takes but
>>> the first take-off was in 1974 I think, so this would match
>>> the design of this box wuite well - what do you think?
>> Aircraft development takes a long long time. To make it worthwhile
>> the aircraft has a long service life. Whilst the computers are bullet
>> proof in an office/home, the  temperature extremes, vibration, high G
>> forces etc in service means that many failures occur and PCBs could
>> be replaced many times over the years, so do not pay too much notice
>> of the dates on components of the boards currently installed.
> OK, I understand this. I do not know much about these
> issues, but on the internet often the COTS strategy
> is mentioned and in using standard components, I think
> moderen aircraft swap technology more often than was done
> in the 60s and 70s, right?

I am no longer in the Avionics field so I don't know anything about  
modern practice.

>
>> There were at least four 12 bit versions, and one 13 bit apparently.
>> Then 12 bit models were the 902, 102C, ARCH 105 and Minim or 12/12.
> Thank you - I will try to find information on the
> web in the next days. Compared to the Elliott machines
> the DECs are very common stuff   ;-)

I doubt you will find much apart from the names in timelines.  
Specialised machine will always be rarer than general purpose ones.  
The design considerations for a harsh environment plus the need to  
save weight means much more expense, so they are not affordable for  
normal use. Every extra Kg in the Avionics adds a lot to the overall  
takeoff weight. For a helicopter, I think the ratio was somewhere  
around six. Then there's the power, every extra watt needs bigger  
alternators/generators and a bigger engine to drive them, and more  
fuel to carry, which means more engine power and so on.


>
>>> Yes, that matches - the core memory module already has the
>>> label GEC. So this is (as I suspected) older than the CPU and
>>> taken maybe from a different design?!
>> You have it the wrong way around. The GEC name replaced the Marconi
>> name, which had earlier replaced Elliott. Core memory was very
> Thank you for this hint. I checked wikipedia and obviously
> GEC got involved very early and the name was changed to GEC
> later (1984). Sorry for my misunderstanding, now I got it.
>
>> convenient for military applications and was in use long after it was
>> replaced in commercial applications. Think of a missile or torpedo
>> held in stock for many years, stick a power plug into it and program
>> the target, pull out the plug and then launch it. Only then does the
>> internal power supply come up, the processor boots up and does its
>> thing.
> The internet claimes sometimes, that core memory is less sensitive
> to radiation, too. This might have been an advantage in certain
> military applications (really bad applications, honestly speaking).

DEAD right!

> Data retenttion of the core memory should be quite good,
> but since reading is always destructive, there is the
> rist, that bad data gets written back. In the case of
> Programmer Electronic Control, they did quite a lot
> to adjust the core memory's dirver current automatically
> according to a temerature measurement of the core. As
> my experiments show, you have to reduce the current if
> temperatuere goes up. This physically understandable
> (1/T).

My old mainframes also have a temperature sensor in the core store,  
and they are only allowed to be used in a narrow temperature band,  
about 10 to 30 degrees C.

>
>>>> bit 920s before moving on to the Zilog Z8001.
>>> Hey, than you are a valuable expert on these - do you have
>>> got any source of intormation about the 920s?
>> Not directly but I may be able to help.
> Hey, that is even better. I highly appreciate, that
> you spend time in sharing your information! Thanks
> a lot in advance!
>
>>>
>>>> 9    Jump if negative
>>>   RIGHT  - all three jumps are relative ones
>> On the 18 bit machines these were relative to the start of the 8k
>> memory module the instruction was in. An interesting modification.
> In my case they are relative and you can jump
> +/-127 words (crossing any border). Here again, the
> box uses 1complement and thus jump 0x00 is the same
> as jump 0x80: An infinite loop!

If 0x00 is the same as 0x80, then it is not one's complement. Sounds  
like sign/absolute. In ones complement, the two representations of  
zero are all zeroes and all ones. On the 920, a jump to itself was  
referred to as a 'Dynamic Stop', and was the standard was to stop the  
computer as there is no stop instruction. I try to avoid doing it on  
my mainframes as continually accessing the same word in core might  
make it overheat.

>
>>>> 11   Store program counter (for function return)
>>>   SIMILAR - This stores PC and then does a
>>>             table jump
>> On the 18 bit machines, it actually stored the program counter + 1
>> and the following instruction was either an 8 or a "/8", i.e. 24.
> Hmm, I do not understand fully what you mean by "the following
> instruction was either an 8 or a "/8", i.e. 24".

In 920 assembler, instructions did not have mnemonics, you used their  
decimal operation code values. To indicate 'B Line modification' in  
the assembler you wrote a / before the operation code. The assembler  
simply added 16 to the opcode, so /8 = 24, but you don't have the B-Line
bit on your machine - its always on.


>
> The Programmer Electronic Control (Let's call it PEC in the future)
> stores PC+1 (as your 18bit) to the specified location into
> core. The new address is taken from the position in memory
> where the index register points to. So in my case this is
> a perfect table jump.

Ah, so you do this ?
	0	word with address of routine
	11	link word
>
>>>> 12   Multiply
>>>   RIGHT, unsigned multiplication
>> This should multiply the signed accumulator and the signed memory
>> operand giving a double length result in the A and Q registers.
> Results are as you mention, but if either operand is
> negative, the result contains wrong values. But maybe
> I check whether this depends on the content of the
> index register prior to the operation...
>
>>>> 13   Divide
>>>   HMMM, the command takes very long but the results are
>>>         very strange. I thought it might be some type of
>>>         random number generation by an irreducible polynomal,
>>>         but it is definitively not Divide. Maybe here is something
>>>         different or wrong with the microcode.
>> This divides a signed DOUBLE LENGTH number in the A and Q registers
>> by a signed memory operand. IIRC the A register gets the result and
>> the Q register the remainder.
> OK, I will verify this in the coming days. Now I
> know what to look form but according to my records
> the results of this command always have been junk.
>
>>>> 14   Shift
>>>   In PART: Here exist many subgroups of commands including
>>>   shift left/right. Also the Q as you call it can be transferred
>>>   to Accu and vice versa. There als is a MTA (MoveToAccu as I  
>>> call it)
>>>   which is a two-word instruction (most others are one-word) and
>>>   transfers the word following this command into Accu. About
>>>   16 bit patterns have (at least to me now) the same meaning in
>>>   this segment.
>> Shifting by the entire word length does transfer Q to A or A to Q
> Right. But here again, the bit 11 is the sign bit and
> thus the shift does not affect the bit 11 of the
> destination. I.e. bit 0 of A is moved to bit 10 of Q
> in shifting right for example.

I see. The Q register was always a bit weird.

>
>> (but the data disappears from the source). A load immediate
>> instruction would have been very handy.
> Yes, the load immediate is really nice. A block
> move does not exist on PEC. Essentially the immediate
> "MTA - Move To Accu" is one of two "two-read-cycles"
> instructions. Up to now I did not fugire out, what
> the other instruction does with the data read. Do
> you remember any "two-read" instructions in the Elliotts?

Only the instruction I invented. The first word had the address of a  
link word (in page 0) and the whole second word was the address of  
where to jump to. So this was convenient for the compile to generate  
a call without lots of special literals. We reused /3 I think, anyway  
the original instruction was corrupt the Q Register with B-Line  
indexing, but B-Line indexing corrupted the Q register at the start  
of the instruction, so a totally useless opcode.

>
>> orders were encoded in the 14 order on the 12 bit machines with only
>> 256 numbers available compared with 8k on the 18 bitters.
> Yes, this seems to be absolutely correct!
>
>>>> 15   Input/Output and special (like interrupt return)
>>>> 16 to 31, as above but indexed by B register.
>>>
>>>   NOPE - The box is 12-bit and does not have got this block.
>>>   EVERYTHING is done via the index register I as I called it.
>>
>> Do you mean you cannot turn the B-register modification off?
> Correct: Everything is modified by the index register.
> Exceptions are the jumps, MTA for example.

>
>> Does it get cleared automatically somehow?
> You are clever - that is exactly what appens:
> Every instruction which is affected by this
> register (ADD, SUB, LDA, STA, ...) clear
> the register. So you have to load it right before
> each instruction. A severe constraint in my
> opinion is, that the index register can only
> be loaded from words 0-127 in the lower 4k. So
> this might be a bottleneck in memory since the
> table jump (I called it IDXCALL since it used
> the index register to get ne new address from)
> requires memory for each routine called, too.
>
>>> perhaps studying the Elliot would help to solve the remaining
>>> problems??!?!?!!
>> I am willing to try.
> Great!  T H A N K S  a  L O T!
>
>> By the way, there are two 't's in Elliott.
> Thanks - is stored into my brain now  ;-)
>
>
>>>> bootstrap, in later versions, this was just copied into core  
>>>> when the
>>>> machine was initialised.
>>> Interesting. The Programmer Electronic Control starts execution
>>> at 0x0a0 after reset.
>> Could it be that there is a value of 0x0A0 at location 0?
> No, if the machine is held in reset state,
> the PC is forced to 0x0a0 since the reset line
> is connected to the Set/Clear pins of the flip-flops
> making the program counter. Immediately after reset
> is set high, the first word is read and executed
> from this address.
>
>>> But of course the application was different
>>> and the operation software was completely loaded via the big plug
>>> boefore operation.
>> I suspect the big plug is for the OMP (Operator's Monitor Panel), and
> Some kind of blinking-light console? Something like
> this exists for the Rolm 1666b, too. This would be
> cool to have!  ;-)

Yes, but these were of course much rarer than the computers themselves.

>
>> yes the program would be loaded via this once, probably in the
>> factory or at a maintenance depot, and the machine would probably be
>> rebooted many times afterwards.
> If data gets corrupted, than the complete aircraft has
> to return to a maintenance depot for reprogramming
> the machine? So if there are 10 or 20 of these boxes in
> one aircraft, they need service quite often I think.
> Roger, how was your experience - was this reliable with
> the Elliotts or did you have to reporgram the pater tape
> loader quite often?
>
> In my case, the transputer setup generates some spikes
> doring it bootup. If PEC is already turned on, this
> corrupts the data in core memory. So I always do a
> memory-test on PEC after turn on (to adjust the core
> driver current) and than freshly program my test
> routines.
>
>> The 920 was unusual in that it booted into the highest level
>> interrupt, level 1, so no interrupts will be serviced until you go
>> down an interrupt level or two or three.
> So 15 7168 increases the interrupt level and
> after executing this once, the interrupt 1 can be
> serviced, right?

Thats it.

>
> What happens in the Elliott, if an interrupt occurs?
> Is there a jump to a certain address in core or is the
> new program counter itself read from core?

For a level 1 interrupt when the processor is on level 2, it stores  
the SCR in location 2, and the B in location 3. Then it loads the SCR  
from location zero and the B from location 1.
>
> I have to think how to figure this out for PEC.... Of
> course I have to apply signals to all possible interrupt
> sources, load a program trying the yet unknown instructions
> and watch wheter any irregularities or jumps occur. I will
> have to trap PEC if the idle-loop is left. This is a bigger
> project and I will need some weeks to check this.
>
>> The 15 order is coded thus:
>>
>> 15      0 to 2047 Input
>> 15      2048 Shift A register left 7 places and OR in a character  
>> from the
>> paper tape reader (via OMP)
>> 15      2052 (IIRC) Wait until character pressed on teletype and  
>> read into
>> A register (via OMP)
>> 15      4096 to 6143 Output
>> 15      6144 Output character to paper tape punch (via OMP)
>> 15      6148 Output character to teletype (via OMP) if I remember
>> correctly
>> 15      7168 Terminate current program level i.e. return from  
>> interrupt
>> 15      7169 Test if standardised IIRC, skip the next instruction  
>> if the
>> accumulator is zero or top two bits are different
>> 15      7170 Increment B and skip the next instruction if bottom  
>> 13 bits
>> are zero
>> 15      7171 Read the value of the control keys on the OMP
>> 15      7172 Move l.s. 17 bits of A to the m.s. 17 bits of Q.  
>> Bottom bit
>> of Q is zeroed
>> 15      7173 Move m.s. 17 bits of Q to l.s. 17 bits of A. Top bit  
>> of A is
>> zeroed
>> 15      7174 Move A to B
>> 15      7175 Move B to A
>> 15      7176 Set relative addressing mode
>> 15      7177 Set absolute addressing mode
>
> Thank you very much for this list. This gives me
> valuable hints and ideas what to try out next.
>
> BTW: Have there been timers on the Elliotts you
> know about?

Yes bit not within the CPU box.

>
> Since you are such an expert I am sure you
> have a nice collection of vintage hardware,
> right? Perhaps you even have got an Elliott
> up and running?

No, when I started working for Elliotts, all computers were out of my  
reach, but then I was offered an old mainframe (which originally cost  
247,000 pounds, for scrap value, 150 pounds). It was built in 1962. I  
now have two of them in a barn at home. LOTS of lights and switches,  
each has a card reader, card punch, line printer and one has a paper  
tape reader and punch. Oh they both have drum stores and ten track  
magnetic tape.

Roger Holmes.




More information about the cctech mailing list