Suudy wrote:
BigEd wrote:
I would guess that the ascending pattern and the incrementing is intended to check that all 256 bytes of zero page are present and distinct and writeable. An addressing fault which causes, for example, only 128 bytes to be mirrored twice could be difficult to debug without a specific check.
Interesting. Mirroring is not a failure mode I would have expected. But perhaps detects a common board failure they saw before. Thanks for the suggestion.
My first gig as an intern was at a fabless ASIC company and I wrote some components for built-in self tests for RAMs and CAMs. We never did an ascending type pattern. We did marching 1's, 0xaa/0x55, and read, invert, writeback, readback. And we did check for some cross-coupled faults by writing every other address w/ 0xff/0x00. But the incrementing and ascending we never did.
I was involved in test/diagnostics for computer boards in the late 80s/early 90s and it's amazing the tests the engineers wanted - also weird to find boards that would run the tests for days in the burn-in chambers and fail 30 seconds into a customer program run... I'd often go and check the PCB layouts and try to work out stuff like cross talk, etc. I did enjoy that work for a while.
As for writing address into memory location - it's a valid test for shorted address lines - maybe even shorted data lines if there are separate address and data line buffers between board peripherals - if no buffers then any address line or data line short is really going to stop system starting in the first place... And while I've not seen the code, it's a quick and easy test to do without requiring RAM:
Code:
ldx #0
: txa
sta 0,x
cmp 0,x
bne failed
inx
bne :-
It may also be used to leave RAM in a known state, so debugging can see which locations may have been written.
But sometimes it might just feel like a good thing to do when it's not that effective. I've heard of worse. I think I'd probably follow that with some back to back read/modify/write tests - inc/dec instructions or shifts if I wanted to be fully confident ZP was fine before using it - if I felt the need to power on test at all...
A strategy that I adopted early on in this department was to do a basic functional "quick & dirty" test at the start, then move onto the more complex tests like alternating words, marching ants and so on. It was relatively rare for boards to fail the hard-core tests after they passed the quick and dirty ones and sometimes these were boards with vast quantities of RAM compared to the relative speed of the CPU - for the time, anyway.
A favourite test of mine was writing inverse addresses - but this was on 32-bit systems with a multiplexed address + data bus. That would sometimes throw some weird errors. No use on a 6502, but may have value on '816 systems with many MB of RAM...
CPUs with a block-move instructions were good to test too - especially on larger memory sizes - write a known pattern in the first (say) 1KB, then move that all up memory in 1K increments and test the last K. Lots of nice tricks like that but often very board specific. (We had many different CPU boards and configurations for the system as a whole)
I did start to write some test & diagnostics for the 6502 but never got round to really making it usable. Too many different systems to even think about.
-Gordon
_________________
--
Gordon Henderson.
See my
Ruby 6502 and 65816 SBC projects here:
https://projects.drogon.net/ruby/