On 6/25/10, dwight elvey <dkelvey at hotmail.com> wrote: There was a common debug tool back in the PET era - a 6502 CPU with the data bus pins bent backwards and wired up such that no matter what might have been fetched from ROM or RAM (or I/O locations), the CPU gated in $EA, the NOP instruction. The effect would be to have the CPU see $EAEA as the ROM start vector, and any NMI interrupts that might be invoked would also send the processor to $EAEA. After that, the address bus just increments at the machine's clock speed, so it's easy to scan for stuck address bits and memory bank selects (since most of the machines of that era had a 74154 or 74138s or similar parts to generate select signals for RAM and ROM and I/O chips). At least for the case of the 6502, it's pretty cheap to sacrifice one CPU to be able to test a variety of machines. Less common chips might warrant a board and dip switches, as you suggest. Given how 8-bit machines function, "random" forced data bus values might have to be limited to single-byte instructions, or at least a _very_ limited range of two byte instructions (for the 6502, $A9 being one, because two of them in a row is LDA #$A9, but there are a few others that would probably be safe). Nothing comes to mind that's "better" than NOP, though. In part, what you are describing reminds me of Nicholas Welte's ROM/RAM board, but with the ability to force a known byte onto the data bus. His board contains an arbitrary amount of ROM and up to 32K of RAM and an address/personality GAL controlled by a bank of DIP switches that allows you to a) customize the appearance of ROM and RAM for different system memory maps (PETs vs disk drives etc) and b) customize the quantity or content of ROM and/or RAM for a specific machine (disk with or without JiffyDOS or a PET with selectable ROM Kernel versions, etc). Made slightly more generic, buffering and isolating the CPU from the target socket would only add a handful of chips (74LS125s or something like them) - you could also then rig the address map to favor RAM on the test board vs the target board or ROM or whatever, to isolate subsections that might be causing problems. In principle, this sounds interesting, but in practice, I think it'd be much like designing one Z-80 SBC then one 8080 SBC then one 6502 SBC, etc, since there is so much variance between the different 8-bit hardware architectures. Which one you would start with would probably be a function of what chips you know best or what you have the tallest pile of on the workbench. -ethan