As I investigated why one of my 16K memory boards works and the others sometimes
 fail, I came to the conclusion that poor grounding [of the memory boards 
through the expansion backplane] allowed [a timing] glitch to invade the clock
 signal.

I have been chasing that Altair 680b memory bug that my memory test so nicely
 exposes. The root cause is a design flaw that gates a glitch created by the
 4200 RAM chips onto the data bus. I can think of all kinds of re-designs of
 the Altair board that would fix this, but none is simple and clean. The
 ultimate problem is that the Altair 680 requires the memory board to drive
 the data bus through both phases of the MC6800 2-phase clock, whereas 
Motorola intended peripherals to drive the bus only during phase 2.

During a memory-read cycle, the Altair 680 requires data to be driven onto the
 bus through both phases  to make the front panel LEDs work - they are driven
 directly by the (unlatched) bus data signals. If the memory board didn't
 drive the bus during phase-1, the LEDs would not turn all the way off for
 data bits that are zero.

To make matters worse, the 4200 RAM chips' data-out signals are latched with
 transparent latches, which just pass data through when open. But the 4200
 produces an ugly glitch on its outputs at the beginning of its chip-select
 pulse. This glitch drives right through the transparent latches, and gets
 nicely amplified onto the bus by the 74367 drivers. This, in turn, honks 
on the ground lines, and you can see the glitch on everything, especially the clock.

Well well.... Yesterday I got my replica 680 Expansion Boards [which I designed],
 from the PCB fabricator. With my Expander board (with fresh, new 100-pin
 connectors and fresh, new gold on its edge connector), all of my memory 
boards work perfectly. You can still see the glitch still on the clock
 signal, but at less than half the magnitude - low enough that it does
 not upset any other circuits. I believe that this argues for poor 
grounding with the original expander board.

Attached is the source code, listing,  and S-Record executable for my memory
 test program. It's a pretty good memory test program, fitting in less than
 700 bytes. Post if you like :-)

MTEST instructions:

Load the file MTEST4.obj into an Altair 680b using the PROM Monitor's 'L' command.
 Then jump to it at 0100 by typing 'J 0100'. Follow the directions - MTEST will
 first ask you where to put the code - pick an address outside where you want
 to test, and MTEST will relocate itself there, assuming there is actually
 memory at the address you specified. (If not, MTEST will abort to the PROM
 Monitor.)

Next, tell MTEST the address range of the memory to test. MTEST will run
 through 30 passes over the range. Each pass takes about 10 seconds for
 each 16Kbytes of tested memory. MTEST will print the pass number at the
 end of each pass. (Note that pass 0 only fills memory - no testing occurs.)
 Every time MTEST finds an error, it will report the address, what it wrote,
 and what it read.

Cheers,
Martin Eberhard
Nov 14 2011