From: Ben Franchuk <bfranchuk_at_jetnet.ab.ca>
>> 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 ?
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.
>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.
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
Received on Wed Dec 19 2001 - 09:13:44 GMT