Memory tests. - Does anyone bother?

[BigDumbDinosaur]

PaulF wrote:

The only real way to tell the end of memory from a memory fault is to check the address the test fails at. If it fails at an expected location (e.g. $2000 for an 8k RAM, $8000 for a 32k RAM) then this is likely to be the end of memory. If it fails at some random address, this is probably a fault. Of course, once you have a failure, you know how much memory is available to use - just don't use the address the test fails at or anything above it!

However, if the machine can accept varying amounts of RAM (e.g., using plug-in DIMMs like Garth's), how would you define "the expected location?" Assuming that all RAM is good, you expect that a full test (checkerboard, at least) will eventually "run off the road," causing a benign fault. However, the "end of the road" can't be written into the test procedure, since it's unknown. I think this is where a single bit address bus test would clearly differentiate between an "end of the road" fault and an actual defect.

This is something that I am mulling as I close in on bringing POC V2 to fruition. It will have 512KB in a single SRAM, so some means of verifying that all 512KB are there will be required. Yet I don't want to hard-code that specific size into the BIOS, since something may prompt me to add more RAM. Also to be considered, the glue logic will (eventually) allow writes to ROM to bleed through to RAM, as well as allow I/O hardware to be mapped out and replaced with RAM (for what reason I don't know, but I will try it). How would a checkerboard test be done on those RAM ranges?

[BigEd]

Checkerboard is good to find bad memory implementations - bad bits, or bits which influence nearby bits. It works best if you know the internal layout of the memory. For example $AA might be $F0 internally.

I would guess that much more likely failures are stuck-at or short or open faults on address lines, chip selects, or data lines. Missing chips and broken decode logic are also possible. So it would be nice to be confident in finding - and perhaps distinguishing - those kinds of things, especially if it can be done quickly.

Examples of things to look out for:
- mirrored memory, so $1000 and $3000 are actually the same locations
- addressing or chip select trouble, so $2000 and $3000 both write to $3000

I think it's probably necessary to write sentinel values in other locations, then the test value, and then check both the sentinel values for not being changed and the test value for being correctly written. Also necessary to pre-write and pre-read something different from the test value beforehand. It might be enough to have just one sentinel location for each test location, carefully chosen, but I'm not sure of that. (It would surely be overkill - and very slow indeed - to have every other location as a sentinel location!) Perhaps enough to flip one of the address bits:
- test location $0001, sentinel location $0002
- test location $0002, sentinel location $0004
- test location $0004, sentinel location $0008
- test location $0008, sentinel location $0010
- test location $0010, sentinel location $0020
and so on. But, if two non-adjacent address bits are shorted, will that be found? If we have a memory size which is not a power of two, such as 24k, will it be tested correctly? I suspect not.

Cheers
Ed

[BigDumbDinosaur]

BigEd wrote:

Checkerboard is good to find bad memory implementations - bad bits, or bits which influence nearby bits. It works best if you know the internal layout of the memory. For example $AA might be $F0 internally.

I would guess that much more likely failures are stuck-at or short or open faults on address lines, chip selects, or data lines. Missing chips and broken decode logic are also possible. So it would be nice to be confident in finding - and perhaps distinguishing - those kinds of things, especially if it can be done quickly.

Examples of things to look out for:
- mirrored memory, so $1000 and $3000 are actually the same locations
- addressing or chip select trouble, so $2000 and $3000 both write to $3000

I think it's probably necessary to write sentinel values in other locations, then the test value, and then check both the sentinel values for not being changed and the test value for being correctly written. Also necessary to pre-write and pre-read something different from the test value beforehand. It might be enough to have just one sentinel location for each test location, carefully chosen, but I'm not sure of that. (It would surely be overkill - and very slow indeed - to have every other location as a sentinel location!) Perhaps enough to flip one of the address bits:
- test location $0001, sentinel location $0002
- test location $0002, sentinel location $0004
- test location $0004, sentinel location $0008
- test location $0008, sentinel location $0010
- test location $0010, sentinel location $0020
and so on. But, if two non-adjacent address bits are shorted, will that be found? If we have a memory size which is not a power of two, such as 24k, will it be tested correctly? I suspect not.

Cheers
Ed

Another approach is to write the page number into all locations of a page and then read them back. If you write into page $14 (with the value $14) but get back $04, then you know that A12 is acting up.

The most extensive test I ever saw did a page write as I described above, followed by a "quadruple" checkboard ($AA, $55, $A5, $5A), followed by a bit rotation on each cell. Slow but thorough.

[teamtempest]

Quote:

Also to be considered, the glue logic will (eventually) allow writes to ROM to bleed through to RAM, as well as allow I/O hardware to be mapped out and replaced with RAM (for what reason I don't know, but I will try it).

I don't know if the specifics of your machine would make it useful, but on the good 'ol C64 the character ROM and the I/O block both "overlaid" the same RAM addresses. In the default memory map the 6510 "saw" the I/O block but the VIC-II "saw" the character ROM.

If so inclined, it was possible to manipulate the memory map so the 6510 "saw" the character ROM instead of the I/O block. Then you could copy the character ROM to the RAM "underneath" it, relying on the write-through-ROM-to-RAM behavior. Once there you could make the 6510 "see" the RAM, which would let you alter some of the character patterns (if you were going to alter them all, there'd be no point in copying the default character set). Set the VIC-II to "see" that RAM as well, and you have a custom character set without giving up any normally available RAM space. You'd have to be careful with interrupts while the I/O block was unavailable, but it was still pretty straightforward.

Used that in a couple of games.

[BigDumbDinosaur]

teamtempest wrote:

Quote:

Also to be considered, the glue logic will (eventually) allow writes to ROM to bleed through to RAM, as well as allow I/O hardware to be mapped out and replaced with RAM (for what reason I don't know, but I will try it).

I don't know if the specifics of your machine would make it useful, but on the good 'ol C64 the character ROM and the I/O block both "overlaid" the same RAM addresses. In the default memory map the 6510 "saw" the I/O block but the VIC-II "saw" the character ROM.

If so inclined, it was possible to manipulate the memory map so the 6510 "saw" the character ROM instead of the I/O block. Then you could copy the character ROM to the RAM "underneath" it, relying on the write-through-ROM-to-RAM behavior. Once there you could make the 6510 "see" the RAM, which would let you alter some of the character patterns (if you were going to alter them all, there'd be no point in copying the default character set). Set the VIC-II to "see" that RAM as well, and you have a custom character set without giving up any normally available RAM space. You'd have to be careful with interrupts while the I/O block was unavailable, but it was still pretty straightforward.

Used that in a couple of games.

The RAM bleed feature of the C-64 was not fully appreciated when the machine first came out. However, it wasn't long before people were taking advantage of it. Back when I had a C-64 attached to a Lt. Kernal hard drive, I used the 8KB of RAM under the BASIC interpreter ROM as a set of disk block buffers. Reads from disk required no special action, due to the bleed-through feature. A write to disk required that the BASIC ROM be mapped out to expose the block buffers.

POC V2's I/O will be the only thing in the I/O block, other than the RAM underneath.

[Rob Finch]

I've used checkboard testing in the past. I don't usually do a memory test unless I suspect bad memory already.
I find the memory test actually tests my patience so I usually skip it.

I do a doubled up checkerboard test, writing $AAAA5555 to all memory locations first, then reading it back later to ensure that bus capacitance isn't holding the memory value. Then I switch the pattern around to $5555AAAA and repeat the test.

I usually do a checksum on ROMS. I spit out the checksum value in a running system and compare it to what my tools generated to make sure they're the same.

To determine the amount of memory, write a magic number to the last suspected word of memory in each in block. For example if going in 64k increments write to $FFFC-$FFFF. Then readback the number and see if it's valid. Increment by a whole block size to test the next block.