25 Jun
2010
25 Jun
'10
8:35 a.m.
On 6/25/10, dwight elvey <dkelvey at hotmail.com> wrote:
What I've been thinking of is a simpler idea...
a simple socket header to go between the processor and
the rest of the machine... On reads,
it would intecept the data and replace it with an instructiion
provided by some dip switches.
It would not effect addresses, just let the processor free run.
...I'm not sure which single instruction would be best but
for a 8080, a push or pop are quite useful.
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