Report on vintage "Programmer Electronnic Control" alias "RAF Tornado Computer"
erik at baigar.de
Tue Mar 13 13:32:55 CDT 2007
thank you very much for all the valuable information.
I have lot of stuff to do now and I will keep the
group and you up to date on my results. I apologize,
that I have to do this in small pieces since I can
not spend too much time on this project, so I can not
comment all of your points now. But anyway I say many
thanks for the hints!
> > +/-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.
Of course you are right - it is sign+value which is used
in PEC for the jumps.
> 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.
I read about this before, but I think in my case it is no
problem since my setup automatically loads the program,
starts the logic analyzer, starts the unit for a
certain time (for current tests 1ms), stops the unit,
reads the core and the logic analyzer and returns
to the shell. So currently I do not fear overheating,
but thank you for this hint and I am aware of this...
> >>>> 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.
Did the experiment on the real unit:
Memory operand had always value 0x003, executed
several of the (with index register zero at
the start) broken-divide:
Akku before: 001 005 010 020 050 100 120 150 200 500 fff
Q before: fff 500 200 150 120 100 050 020 010 005 002
Akku after: 2ab d55 ff5 fe5 fb5 f05 ee5 eb5 e05 b05 d57
Q after: 000 000 001 001 002 002 003 003 004 004 005
So honestly speaking I cannot see the system behind
these numbers ;-) In repeating the experiment I get
the same numbers. Changing the memory operand to
0x234 I get the following:
Akku after: 003 013 03b 075 123 3a1 415 4c5 743 f2f ffd
Q after: 000 000 001 001 002 002 003 003 004 004 005
So... ...big questionmark ...
> > "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
Hey, you where active in the design of these beasts!
Really great! So I am proud, that you join this
discussion so actively!
> 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.
Interesting story! In my opinion and in modern
times using VHDL to implement everything into hardware
very easy, the true heroes are the people like you
who implemented microcode with the solder iron or
the hand wired type of core-ROM! Really great!
> >> 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.
> 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.
That is a clever concept and should be easy to detect.
So I will have to do some hardware work in supplying the
signals to the appropriate lines and than I will be
able to test this hypothesis.
> > BTW: Have there been timers on the Elliotts you
> > know about?
> Yes bit not within the CPU box.
Ah OK, so there is some kind of external data bus on the
Elliotts. In the case of PEC it consists of a multiplexed
open collector bus with a strobe line: address is
applied, than the strobe line is set low by the CPU.
Shortly afterwards address is removed by the CPU again
and the memory unit applies the data to the bus if
read is compite and signalizes this to the CPU. This
bus runs quite stable even with the 75cm of ribbon
cable of my setup attached to it. The shortest instructions
which read only onw word are executed within 1.2us
independent of the value of the index register.
> 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.
Wow - that is a really great setup!!!! Do you
have got any photos???? How much space offered
the drum memory?? Recently I saw a card reader
in action at the cray-cyber.org and I know that
this is really great stuff!!
Happy computing and thanks again,
More information about the cctech