PDP 8/e, RK8E Weirdness - Scope Traces - Update

Hello, all, This morning I did some looking at my RK8E boards, and it appears that it has been ECO'd to make a change to the clock generation logic for the Current Address Counter. This ECO supposedly helped with the issue, but apparently it isn't good enough for this RK8E to work properly in my 8/e. I tacked in an extra probe wire to the least significant bit of the Current Address Counter on the RK8E. I put things back together, and toggled in my little test program that loads the Current Address Counter with 0, then loops on itself to generate scope traces. When I ran the program, it was instantly obvious that the counter is indeed incrementing due to the transient in the clock signal. The LSB of the counter goes to logic 0 for a short time (as a result of the load operation), then pops up to logic 1 due to the transient causing a count cycle on the 74161 counter. You can view the traces here: http://pail.bensene.com/RK8ECounter.jpg The top trace is the LOAD signal into the counter, the middle trace is the CLK signal into the counter, and the bottom trace is the LSB of the counter. It's clear that when the CLK signal goes high (the clock triggers on the positive edge) after the transient, the counter counts up one, causing the LSB to go to 1. As David Humphries mentioned, it appears to be a design flaw in this clock generation circuitry that, depending on small timing variances in different machines, causes this transient to be generated, messing up the operation of the RK8E. A couple of different signals from the master timing of the PDP 8/e are used to generate this clock signal, and it could be that one of these signals on my machine is slightly off due to variances in propagation times in gates and flip flop timing chains that manifests this weakness in the RK8E Current Address Counter clock circuitry. The machine where the RK8E was tested as good may have had slightly different timing that either rendered the transient too short to trigger a count, or eliminated it completely. The next step is to try to figure out what I need to modify to make this transient either go away or such that it is no longer effective in triggering the Current Address Counter to count up before DMA operations begin. Suggestions as to how to clear this up are warmly welcomed. Thanks to all, Rick Bensene