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-boun...@classiccmp.org> on behalf of Paul Koning via
cctalk <cctalk@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@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
