30 Oct
2018
30 Oct
'18
10:14 a.m.
My Nicolet did the same thing it would load 0 into the intended start location ( on my
machine it was a jump to 0 ).
The front panel worked fine otherwise. It turned out to be some missing clocks because of
a bad 7474. Strange that a common problem on different machine created by completely
different issue but all writing 0 back to core.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Paul Koning via cctalk
<cctalk at classiccmp.org>
Sent: Tuesday, October 30, 2018 10:01:29 AM
To: Klemens Krause; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: behaviour of classic PDP-8 frontpanel
On Oct 30, 2018, at 11:07 AM, Klemens Krause via
cctalk <cctalk at classiccmp.org> wrote:
Is there anybody out with a working classic PDP-8?
For a long time we had the problem, that starting a program on our 8 by pressing
<LA> <START> keys, this program crashed. Examining the memory contents showed,
that typically one or two words short behind the starting adress after such a crash had
inadvertently content 0000.
For a long time I suspected a subtle memory problem. But now after carfully having
revised the memory timing I hopefully found the real reason for this nasty misbehaviour:
if the machine is running and I press the <START> key, it stops and
there is also the chance, that one word in memory is nullified.
A look in the maintenance manual shows, that pressing <START> clears the memory
data register and others asynchronously. Naturally if this occours in the moment, when a
memory read is in progress, data from core has been transfered to memory data register,
which clears the word just have been red, and before the memory timing chain was able to
write this word back to memory, then this word is cleared out.
Interesting. I know another machine that has a similar behavior, which was actually
considered a feature. That is the CDC 6000 series. Its peripheral processors do the
read-restore cycle of memory as part of the operation of the execution pipeline, rather
than with a dedicated data path. PPUs always run (there is no "halt"
operation). When you press the boot ("deadstart") button, that forces a
specific address into the program counter register. That happens at a pipeline state
between the instruction fetch and the memory restore cycle, so while the restore write is
done, it goes to the fixed address rather than to the address that was just read. The
result is that a PPU memory dump tells you where the PC pointed, if you are lucky enough
to find a zero in the code section of memory that doesn't belong there. Since PP
dumps only give you memory (no registers) this actually matters for debugging.
This feature was known as system programmer lore but not documented. Analyzing the block
diagrams carefully would show it, though, and a VHDL model makes it crystal clear.
paul