Pay attention part 2.
There are 12 discrete items that sit on the main data bus which are now, in theory, properly hooked up to the propeller chip. The theory is clearly standing on shaky legs for, as we have discussed, there is just too much noise on the D0-D7 data lines which cannot be explained away if everything is actually properly hooked up.
Here then, we go on a walking tour of the data bus and discover that we really weren't paying attention.
The problem: when the entire data bus is set to be disabled from the controller chip, I am reading wildly random voltages on the D0-D7 data lines.
Conjecture: Something is either not actually getting disabled or I'm missing a component completely.
This should be pretty simple to test out. I set the machine controller code to put all of the bus components to a disabled state, set all of the data lines to output, pulled them to low output, then entered a loop. At this point I measured the voltage on each of the data lines, first at the propeller chip just before hitting the inline serial register voltage divider, then at the main CPU chip socket on the CPU board.
Everything measured zero at the propeller chip, and all of the control lines measured at 3.3V (high output) which is correct as coded. This should cause all of the enable pins of along the data bus to be set as disabled.
Measuring the data lines at the CPU socket, I read a variety of values from .4V up to 4.84V.
Next I made a handy list of everything on the data bus, what kind of chip it is, which pin on the chip is the chip enable and which control line should be hooked up to the enable pin.
I was going to include the chart here, but it appears to be in my other suit. I'll try to update this later with the details.
This helped a lot. Immediately a few things jumped out at me. First off, the RAM and ROM chips have been pulled from the CPU board. This leaves the D0-D7 lines at those chips floating. Floating inputs are bad. Second, a few of the data bus components have control signals that are not hooked up. This means we have no way to tell what the chip is doing. See, paying attention helps.
For the ROM and RAM chips, I decided to just re-socket the chips and hook their enable lines to +5 volts to permanently set them to disabled. A similar hook up was made to temporarily set the I/O driver board bus transceiver to be disabled.
At this point, I carefully went to each chip enable pin and verified that everything on the bus was finally actually disabled.
A re-measuring of the data lines shows that we now have a steady ~ +.4V at each data line when measured at the CPU socket.
On one hand, steady is good. On the other hand, why +.4V? This value is well within the valid range of logic low for everything on the bus, but I don't know why there would be any + Voltage at all. When presented with something that we don't understand there are a lot of ways to react. I ran quickly through frustrated, then passed by a lament that I didn't pay more attention in high school physics, and finally landed at the inevitable realization that I need to study more.
Fine I'll study more, but why not put the main program back in and see what happens? The results are rewarding, but not successful. There is now zero flicker on the data line. The dedicated switches get a solid signal when enabled and can clearly be processed more than fast enough. The switch matrix carries the exact same problem that it did before. Once a column is latched, it stays latched.
One thing is abundantly clear here. I'm using the wrong tool for the job. There is no way I'm going to be able to determine what is happening with a chip that is enable for just a few dozen nano seconds, 100's of times a second, using just a multi meter.
Thus did I put an order in for a simple inexpensive USB oscilloscope. And thus did I hit the books again while keeping a wistful eye on the mailbox.