Fast Banked RAM Tester

[JimmyDansbo]

Test banked RAM on the Commander X16 for errors.

All available banks, except 0, are tested. If an error is found, the address is reported and the test stops.

ramtest.png (29.02 KiB) Viewed 5995 times

Download here:

RAMTEST.PRG

(580 Bytes) Downloaded 460 times

For more information on how the software works, visit https://github.com/jimmydansbo/ramtest/
#R45

[kelli217]

Ah, something for the Digital Basement videos of the future.

Also, is there a typo in your URL or is that actually a CGI gateway?

[JimmyDansbo]

No, it is not a typo and no it is not cgi.
It is actually index.php that has a list of $_GET variables that redirects to other sites.

[m00dawg]

EDIT: Realized I didn't start by saying thank you for the tool So thank you!

On the note of Adrian and his digital basement, he did have a video talking about rollover and phantom banking or something like that with suggestions on how to modify a RAM tester to catch those?

I found the RAM tester on the SD card did _not_ catch memory errors I was having with the higher banks. I think it might be due to writing FF rather than going through patterns of 0's and 1's. Only certain bank addresses would cause an error, which I can reproduce in my own applications. Oddly when using a 65816 I don't have any problems with memory. Only when I plonk in my 65C02 are there issues. I need to test with another 65C02 to see if it's the CPU or maybe some bus timing thing, I'm not sure.

At any rate, thoughts on adding a bit march and/or considering some of Adrian's suggestions for memory testers? EDIT: Also perhaps a loop mode? Since I don't fully trust the RAM I'm using yet, being able to do a sort of burn-in test and have it loop indefinitely and output errors when it sees them (but otherwise continue) would be really nice.

[JimmyDansbo]

Would you happen to remember which of Adrian's videos you are thinking about?
I have no particular knowledge about testing memory, but if I can gather some information on the topic, I would be glad to give it a go.

I actually think that we should have the RAM tester build into the ROM if there is room. That way it would be possible to test more, if not all, of the memory.

[m00dawg]

Not sure which vid it was precisely but it was the one where he fixes his trash Amiga. May have been on his 2nd channel.

One thing I was thinking about was FF as well as 00 and various bit patterns (10101010, 01010101, 10011001, etc.). The bad RAM I have only was bad at certain addresses and seemingly certain values which is why the writing 1's likely didn't catch it in the test.

This works except when wrapping memory or something. In Adrian's case, writes were getting written on one area of the memory that were also appearing in another area, or something like that. To avoid that, going through tests where the banks don't all contain the same data would catch that. He explains it better than I can though.

Adding it to ROM would be fantastic, agreed.

[DragWx]

I've looked around because I'm curious about how RAM tests work too, and found four fairly simple tests that can be done to detect bus issues:

Walking 1 on data: pick one memory address, then write %00000001 and read it back to verify. Then write %00000010 (to same address) and verify, and so on until all 8 bits are tested. (EDIT: I originally thought this would have bus capacitance issues, but forgot that the last value on the bus would've been the last byte of the current opcode, so no need to multi-write and multi-read for this test.)

Walking 0 on data: Exact same as walking 1, but the bits are inverted, e.g., %11111110, then %11111101, etc.

Walking 1 on address: Choose all memory addresses where the address only has one bit set (e.g., $0001, $0002, $0004, $0008, $0010, etc) and clear them. Then, pick one constant value (like $AA or $55). Write this constant to one address, then verify the other addresses are still cleared, then verify the written address still contains the constant. Clear, then repeat the test with another address from our list until all such addresses have been tested.

Walking 0 on address: Exact same as walking 1, but the address bits are inverted, e.g., $FFFE, $FFFD, $FFFB, $FFF7, etc. This wouldn't help much on the X16, so maybe modify this so A15 is always 0, so $7FFE, $7FFD, $7FFB, etc.


Next, after these pass, there's another test called the "self address" test, where you write the memory address itself to each memory address. There wasn't an explanation for how exactly this "should" work, but I can imagine just simply adding the LSB and MSB together might be fine. Otherwise, a pass of writing the LSB, then a pass of writing the MSB.

For the X16's banked ram, you'd want to either include a pass where you write the current bank number to each byte of each bank, or if adding MSB+LSB, adding the bank number to that could work. Keeping in mind that the number of available banks is variable, that is.


I know there's better and more exhaustive tests than this though, and I'm not sure how well this would do in detecting chip faults, like stuck bits or paging errors. This is just what I've been able to find so far.

[JimmyDansbo]

... I know there's better and more exhaustive tests ...

Thanks for your help. I think I have found a fairly simple, but still effective algorithm.
See RAM diagnostic ROM for more information.