Hi Roger,
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.
Sniff...
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,
Erik.