behaviour of classic PDP-8 frontpanel

[dwight]

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