Nor would I. However, it would be useful to be able to determine how much RAM a system has, which means testing the full extent of address space in some fashion. The C-64 did this (the kernel RAMTAS subroutine), although with usually predictable results. In the case of a 65C816 system, a test to determine how much extended RAM is available would be necessary. Otherwise, the operating system wouldn't know how much space it would have to assign to tasks.


Discrete logic seldom fails once past infant mortality. If it does the system is likely going to crash immediately or very soon after power-on.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I agree that a comprehensive RAM test is useful for diagnostic purposes. This should look for four classes of problem:

1: Single bits stuck on or off. This test should also be able to detect completely missing RAM.

2: Addressing uniqueness. This can be done by writing low-order bytes of addresses to all locations, then verifying them; then repeat for high-order bytes, and on a 24-bit address (or other paging) system, repeat also for bank address. This should be enough to catch errors both internal to a RAM chip, and in external decode logic.

3: Writes to one address "leaking" to other addresses. Testing for this is more complex than the above, and errors of this type are probably rarer.

4: Refresh adequacy - only relevant for DRAMs, not SRAMs. This requires writing some data to the addresses of interest, then purposefully avoiding access to those addresses (or related ones which might provoke a refresh of them) for a while - also known as a "bit fade" test. This covers potential shortcomings in the refresh-generating logic of the support hardware (eg. the BBC Micro had special measures to ensure adequate refresh when in MODE 7, since as that display mode covered only 1KB RAM, fewer addresses were inherently generated by the 6845). It also covers a potential ageing fault of DRAMs.

A much simpler test can be used to determine RAM quantity, given some very minor assumptions such as the minimum size of a RAM device. You really only need to write two values (and verify them) at *one* address to verify that there is RAM at that address, and infer that there is also RAM at addresses related to it (eg. in the same 4KB page, if your RAMs are all 32Kbit or larger). This should be a very fast operation, even if you have potentially several megabytes to check for - and it can be done non-destructively.

Yup. The curve for the failure rate slopes downward after the "infant" phase; then the rate levels off. Just a reminder: much later the failure rate starts slowly going back up again, resulting in what's known as the bathtub curve, shown below in blue. (The Wikipedia graph doesn't specifically pertain to IC failure rates. But I recall seeing a graph which did, and the plot had a much wider, flatter bottom and a gentler upward curve on the right.)
https://en.wikipedia.org/wiki/Bathtub_curve

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html