I want to really thank everyone for the help and beginner's advice, I really appreciate it. I consider myself an expert x86 software guy -- hardware is a completely new domain for me and I'm having to do tons of reading and video-watching every time I come up across something I don't understand
Thanks to the information 1ST1 found, I missed something in my BIOS analysis: If it fails within the POST section (in my case, checkpoint 43h) but is not hung, it XOR's the previously-sent result and sends that back out. I confirmed that behavior by looking at the codes sent out on my working 6300, and sure enough I see the complement of the last checkpoint code sent out after a successful POST. Based on that information, I've deduced roughly where the failure is occurring: After the DMA controller test has started, and before the 64K RAM test (both of these are part of Checkpoint 43h). My reasoning: If the POST gets to the part where the 64K RAM test fails, it does the XOR of the code, outputs it, then halts. Because I'm not seeing that, I believe the 8237 DMA controller itself is faulty (or, a borked trace on the motherboard exhibiting as such) because the code is not getting to the RAM test which would not hang.
While I do not (yet?) have the skill and patience to trace motherboard traces, I think I can give replacing the 8237 a shot. I've ordered two 8237A-4's and a few 40-pin DIP sockets, and will practice my soldering/desoldering on smaller projects before attempting it on this board.
If it helps with this project, in the stuff I recently picked up is a 6300 Hardware Reference with schematics.
Thanks, but I've got scanned copies of that already.
Also, my 6300 has an AM9517A DMA controller, not the Intel described in the documentation.
That appears to be an AMD compatible part. In the 6300 I'm trying to repair, I have a Fujitsu 8086 that I've never seen before (has
a neat groove as part of its styling).
If the BIOS POST halts (executes an F4h HLT instruction) when it detects an error the first thing you would probably want to know is what code was it executing immediately prior to the HLT. The most simple setup would be to connect the logic analyzer to the EPROM address and data lines and uses the output enable as the state clock. Then it should record the address and data for every BIOS code fetch. (You wouldn't really need to record the data as that would already be known for every address). When the system halts you could scroll back through the state history to see the code fetch addresses prior to when it halted.
I appreciate the offer; maybe if I visit Seattle I'll take you up on it
This would probably be one of the lesser painful ways to trace it, but thankfully I am 95% certain I know exactly where the code is failing (see above).