Pressing the testbutton on the MPU board also often causes a stack overflow which will crash the software. The processor will write its statusregister and return address to the stack every clock cycle as long as the button is pressed. And the stack isn't that deep in these early boards.... I encountered this problem also when coding testsoftware for these boards. Williams avoided this problem at its early system3-7 boards implementing a nice "glitch generator" with the 2 NAND gates. Try to press the test button as short as possible sometimes helps. I avoided "multiple execution" of the NMI routine in my testsoftware by just resetting the stackpointer and IRQ flag and jumping to a known memory location in stead of the usual RTI instruction. It looks a bit dirty in the code but it has a reason. What Quench is writing about a jump to a not present memory location might also be the case if the software doesn't poll for the presence of an AID card. By the way: big respect for what mr. slochar is doing here; nice to see someone coding in good old 8 bit Motorola assembly