I think the really interesting part about all of this is that it is possible. You can hook up an oscilloscope and a logic analyzer and really figure out what's going on all the way down to reading the microcode and decoding the signals. You won't be doing that on a modern system.
I love the part on modern systems where you put the Agilent or Tektronix logic analyzer on the frontside bus of your Pentium system and just after it triggers on your test condition it pops up the screen "Please enter your Intel NDA license in order to display signals" Seriously, a piece of test equipment that won't display signals for the device under test.
So yes, 30 years from now, I doubt you'll be able to look at anything useful on a modern system.
Intel licensed the protocol specs to Tek and Agilent so they could implement it in their logic analyzer, but mandated that it be behind an NDA-wall so people couldn't use an analyzer to easily reverse their bus protocols. The NDA nonsense started in the P-II days, during a time when both AMD and Cyrix were making drop-in chips for Socket-7, and Intel wanted to lock them out.
I don't see why it should not be doing that on a modern system. It will just be a lot harder to do (less access, wider busses, much higher frequencies), but possible non the less
Ok, practical. An oscilloscope that can probe a high speed bus like PCIe is priced in the same range as a house. Not to mention motherboards are 8-10 layer PCBs, which makes it pretty tough. The high level of integration is also going to make it rather difficult to get inside a lot of the parts and listen in, much less the sheer amount of stuff one person would have to know to understand what is going on from the bottom up is a lot more unreasonable than it is on a relatively primitive machine (architecture wise) like the Alto.
I'm pretty sure you couldn't get down to the microcode level without special debugging facilities (an in-circuit-debugger rig of some sort) or an emulator. Modern CPUs are so integrated that even a de-capped chip would be effectively impossible to probe in this manner.
Looking through the schematic of the disk controller, it wouldn't surprise me if the bad inverter also ended up causing the parity errors. That one pin ends up affecting error detection, clocking, and addressing of the disk controller, which could very well end up manifesting as the parity errors you're seeing, especially given that your entries suggest that the errors went away once you dead bugged the inverter. Regardless, this is definitely an interesting series and I wish you lots of luck in getting things running.
