Quote:
Originally Posted by SiriusHardware
Even with that mild bug your test firmware was instrumental in getting the machine this far and I'm grateful that you sidelined whatever you meant to be doing the other evening to knock that tweaked version up for us instead.
Although Daver2's test firmware is obviously quite advanced in terms of what it does, the way it stalled on the screen test might have had us a a little bit perplexed if we had not had your alternative which was able to go past that point.
I would imagine it is very hard to write a comprehensive test suite in 2K when you have the crippling limitation of not being able to use either RAM or subroutines, at least initially.
|
Testing of test software can be a bit difficult - as you need to induce deliberate hardware faults or have an emulator test harness that can simulate this.
Yes, the Daver2 one was currently designed to just loop back to writing the whole of the screen-RAM, as soon as it detected a read-back error.
And would have been nice if it had a timeout / skip on any keypress (providing keyboard does work on at least one key) to an attempt to write something (maybe multiple places) to the screen etc. regarding the error that was found - as it does with Main RAM test.
Although this still wouldn't be able to find whether it was RAM IC's or the buffers at fault, so still need to do some tracing of known signals through the circuitry. And having the ability to be able to produce a customised test-routine that can be dropped in quickly to do this is rather useful.
In retrospect, I think the read fault on the main uP-side buffer could have still been detected using the Daver2 code, being as the main buffer was always active wither reading or writing (so did in fact replicate the databus either side) - But would have been more difficult if it was an actual RAM IC fault.
And still not clear how good the built-in diagnostics are, that may require a lot more working even though they do display RAM data errors.