2 Jul
2012
2 Jul
'12
5:11 p.m.
The RICM is still wrestling with the core in the PDP-8.
After replacing some diodes on the core stack we have all addresses working.
We observed an interesting core memory behavior during our debugging
last Saturday.
We started the memory alignment procedure by looking at the
STROBE FIELD 0 signal and the amplifier output on pin E1 of the sense
amplifier. The STROBE signal was very late compared to Figure 5-6 in
the 8/L Maintenance Manual. We ran a short JMP loop and adjusted the
relationship with the trimpot on the M360 delay module. When we halted the
processor and tried a examine core we only got just zeros.
We adjusted the M360 delay back where it was and single step worked
again. We found that the strobe-to-one-bit relationship was almost
100ns earlier when in single-step than it was with the processor
running. We checked the whole timing path from MEM START at pin N2 of
the M113 in slot C03, through all of the gates, delays, and
flip-flops, and found no timing difference between single-step and
running. Right now it looks like there is a 100ns delay difference
between the READ(1) signal that turns on the current in the core and
the bit signal showing up on the E1 pin of the sense amplifier when in
the single-step and running.
Is this normal behavior?
--
Michael Thompson
4 Jul
4 Jul
7:46 a.m.
Regardless of normality, I guess if it were me I'd be thinking about
what could cause that. Looking at my drawings, it looks like there are
some things might affect the timing of a memory readout with respect to
READ(1), and since some of them are derived from manual vs. run timing,
this may not be a big surprise. The things I spotted from the
schamatics were:
1) The address lines being asserted. [Now, one would HOPE that those
were locked in before strobing the memory, but maybe that is the
problem, and that does look like the most likely culprit.]
2) The timing of the strobe pulse [Which *should* be fixed from the
delay line.]
3) B MEM ENABLE (which also affects the current drivers) [But this
signal *should* be static being drived from not power clear]
4) NEG CLAMP [This should also be static]
I didn't see anything else, so you should probably look at the timing on
the MA Load and MA lines vs. READ(1). Or, as another has suggested, a
power supply / decoupling issue of some crazy sort.
If the address lines are the issue, is it one or are they all
(consistently) different in comparison to READ(1) in manual vs. RUN?
If they are all (consistently) different with respect to READ(1) in
manual vs. RUN, then I'd check MA LOAD and its relationship to READ(1).
I noted that one line that controls MA LOAD is Not KEY CONT. The
others are TP4 and MFTP1. MFTP1 also has a relationship to manual
operation, of course.
On 7/2/2012 7:11 PM, Michael Thompson wrote:
The RICM is still wrestling with the core in the
PDP-8.
After replacing some diodes on the core stack we have all addresses working.
We observed an interesting core memory behavior during our debugging
last Saturday.
We started the memory alignment procedure by looking at the
STROBE FIELD 0 signal and the amplifier output on pin E1 of the sense
amplifier. The STROBE signal was very late compared to Figure 5-6 in
the 8/L Maintenance Manual. We ran a short JMP loop and adjusted the
relationship with the trimpot on the M360 delay module. When we halted the
processor and tried a examine core we only got just zeros.
We adjusted the M360 delay back where it was and single step worked
again. We found that the strobe-to-one-bit relationship was almost
100ns earlier when in single-step than it was with the processor
running. We checked the whole timing path from MEM START at pin N2 of
the M113 in slot C03, through all of the gates, delays, and
flip-flops, and found no timing difference between single-step and
running. Right now it looks like there is a 100ns delay difference
between the READ(1) signal that turns on the current in the core and
the bit signal showing up on the E1 pin of the sense amplifier when in
the single-step and running.
Is this normal behavior?
15 Jul
15 Jul
5:32 a.m.
After we received a number of great debugging suggestions we decided
to replace the FDH-333 diodes that we used to repair the core stack
with 1N4149 diodes. Other PDP-8 owners have used 1N4149 diodes
successfully in core repair. We ran the Memory Address Test and the
Memory Checkerboard for quite a while with no errors. So, that issue
is fixed and now we can work on the spurious interrupt issue.
Thanks for the help.
--
Michael Thompson
4542
days inactive
4554
days old
2 comments
2 participants
participants (2)
-
cube1＠charter.net -
michael.99.thompson＠gmail.com