LISTING OF THE DIAGNOSTIC GIVES ME LOCATIONS OF THE START OF EACH SECTION
I can replace the first instruction word with a special halt - using the unassigned operation code b11111 to form words of the form F80n where n is the number of each stop. I have a spreadsheet with the original value of those words, so that once it stops at a point, I can restore the proper instruction and let it continue.
At each point, I will know that all the tests up to that point were completed successfully. Once it begins looping I know the issue arises from the last wait point forward and can more granularly sprinkle F80n waits to zoom in on the misbehaving instruction.
RESULTS OF RUNNING THE MODIFIED CPU TEST DIAGNOSTIC
I discovered one corrupted word in memory that caused the looping and repaired it. I then ran through sections, with the waits I had inserted. I got through almost every section without issues. There were two anomalies.
First, the diagnostic gave an error stop while testing the Store Index (STX) instruction. When I single step through that part of the test it works perfectly and doesn't get the error, but when I run at normal speed, it fails. I must have a timing issue here that needs to be checked.
Second, the section where it attempts to test multiple and divide cases had a parity stop in fetching the second word of a long instruction, again with bit 0 flipped on to cause the parity error. I repaired the location, started the section where it looped for a bit and then stopped with the same bit flip parity error.
I guess the good news is that I have some code that will repeatedly cause the bit flip, thus I can begin instrumenting the machine to catch it in the act. I am not certain how to catch whatever problem is happening with the STX test section. That too failed the same way several times, but it doesn't trigger a parity error, which is a definitive trigger for logic analyzers and oscilloscopes, instead just executing improperly in an unknown way.
I've always found CPU diagnostics to be really tricky to use. Because they run on the CPU being diagnosed they have to depend on at least some instructions working properly. When one or more of that subset of instructions misbehaves I've gotten some really misleading results at times. They are a really nice check when all instructions work correctly though. Good luck!!!
ReplyDeleteAs far as I could tell, all were working properly. Agreed that a bad instruction can send the code off and produce very misleading answers from the diagnostic
Delete