Ben,
Check bitsavers for the hardware manuals for the PDP-8
and the PDP-5
lots of detail in what happens.
Thanks. No docs needed: Bitsavers is well known and
I have most of the original docs.
The problem as I see it is that you are
thinking
the PDP-8 can have any memory thrown at and it works for realistic state
emulation.
Nearly realistic. Not 100% realistic. But it's quite sufficient the
way I implemented it.
All the computers of that era is based on the memory
cycle of *CORE*
memory.
Yes, and my design is based on the memory cycle of block rams :-)
My design makes one memory access on EVERY clock cycle. It is a bit pipelined as
all operations (execute phase) is layered with next fetch etc.
Only IOT operations need two cycles and waste one memory access time. That has been done
because I wanted to give a bit relief to the decode state logic.
<setup
address><read><pause><write back> Untill you design your memory
around that you will have problems.
Why should I? My (first) design has passed the
MAINDEC acceptance tests and runs original software.
The improved design is still being debugged and enhanced.
The PDP 8/e's clock was I think 20MHZ
to generate the proper timing for 1.2us memory cycle, I think you could
just get by
with 5 or 6 clocks per memory cycle.
I do one clock per memory cycle. But an ISZ
instruction takes at least three cycles.
That's the only instruction where my design is really slower than the original.
ISZ I plus auto-increment is currently the longest instruction.
The tricky part is that Memory
buffer register
is latched with the core data, and then incrimented on the *same* clock.
I know.
It's done nearly that way.
A 100 MHZ FPGA could endup at 20 MHZ but that really
depends on the
speed of the
block ram.
No. Currently I run 100Mhz CYCLE frequency. The block RAM can virtually
has no speed limit on
FPGAs.
To be clear:
My PDP-8 currently does 50000000 additions/second. Or 100000000 operate or jump
instructions/second.
Best wishes,
Philipp
--
http://www.hachti.de