19 Dec
2001
19 Dec
'01
9:13 a.m.
From: Ben Franchuk <bfranchuk(a)jetnet.ab.ca>
All of the above, though I believe the predominence of ASCII for IO
had a big impact and even IBM coding {EBDIC???} wanted around
8 bits.
Bent in that you might want a load to always be some opcode and
a logic change down stream makes it something different do to gating.
A PLA or Prom to translate opcodes from a irregular pattern
of hardware convenience to something regular is handy.
Besides with 48 bits of ucode the address of the next instruction is
in the ucode and the logic is a really wide prom with a really wide
latch and a really simple next address select logic (some LS257s).
No counters or incrementors, The translated opcode from the prom
was the source of the high order ucode address after a "next
instuction fetch". Made the ucode very simple though not very
efficient in terms of bits. Eproms though slow made it cheap with
bipolar proms as follow up for speed.
Allison
Right on very
few if any! Most went to byte wide or multiples of byte
wide... give a guess why?
4 bit TTL? IBM-360's? ASCII ? If you don't keep ISZ and I/O instructions the same
speed that
seems quite possible. The PDP-X runs at 8 MHZ and executes 1 memory
cycle every 500 ns. http://surfin.spies.com/~dgc/pdp8x/ That is 3x
faster than a PDP-8/I with PDP timing.
ISZ was expendable though very useful. The PDP-8 style of IO however
was where a lot of the power in that machine was hidden. You could
seriously extend the machine there.
is simpler in
some respects but far less flexible when it comes to
fixing a bent opcode.
Bent opcode ... that is where you use the BIG HAMMER!
In the design I was prototyping I had a lot of short instructions thus
a 512x32? rom was more than ample.