Hi folks,

I have just taken my 65c02 project off the top shelf again and I'd like to hear peoples opinion of testing onboard memory.

I've just tried a routine that tests zero page using the 55 & AA bit patterns and I put that as the first step of my board initialisation. Straight away I come across a couple of issues.

1. Nothing has been initialised yet, so how do you report the result of the test.

2. If I leave it later then by that time I'm using zero page & the stack. It probably isn't a good idea to stamp all over the stack with a memory test after initialisation.

I have free space in the memory map. I always know there should be 32K, but I could add another 16K if I needed, so I can see a use for the memory test to identify the top of memory as well - assuming contigious RAM.

Any thoughts?

My 6809 board tests it's memory immediately at reset. No stack is used. Error reporting is via an onboard sounder which requires a single byte on a port to generate a tone of given frequency. I think this works quite well on my fafairly simple SBC.

In terms of signalling error you could signal the other way, on success, of course.

I believe memory tests are very useful...

_________________
8 bit fun and games: https://www.aslak.net/

A non-destructive test will save the value in each byte before writing and testing the two patterns - should be feasible, using X or Y to keep the value.

(Edit: but http://www.ganssle.com/testingram.htm doesn't think much of that idea. Worth a read. See also http://stackoverflow.com/a/20679170)

Outputting the result for a failure is more of a challenge, without making some minimal assumption, but going into a tight loop with no exit is one possibility. Better a machine which doesn't boot, than one which is unreliable.

Cheers
Ed

I don't usually bother. The only time I had a problem with RAM it was due to someone putting a chip in the wrong way round.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

POC's firmware does several memory tests. The first test destructively checks direct page, page 1 (hardware vectors and SCSI work area),the MPU stack $00CD00-$00CDFF), and the TIA-232 buffers ($00CE00-$00CFFF). Following those tests, I/O is initialized, a POST screen is displayed and then all RAM from $000200-$00CCFF is non-destructively tested. During this second test, a count is displayed as testing progresses. In the event of an error, the system is halted and the last address that was tested is displayed. If the first stage test fails, there is no notification, as no hardware would be available to alert the user.

Incidentally, I use the alternating bit patterns %01011010 and %10100101 for checkerboard testing. A really detailed test would also do a single bit "walking" check on each location as well, but one might not have the patience to wait for such a test to complete.

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

His comments seem more applicable to DRAM than the SRAM most of us use. At least with SRAM we don't have to worry about background radiation randomly flipping bits.

The traditional test using $55 and $AA seems to have been around since the dawn of the microprocessor and use of TTL memory. I use $5A and $A5 just to be perverse. One system I worked on years ago also used the single-bit "walking" test, which basically amounts writing $00 to the location being tested, setting carry and then rotating the test location nine times. If carry was set after the ninth rotation, then it was implied that all bits at the test location were good. It's a slow, but pretty thorough test. I don't know that I'd want to sit there and wait for a 65C816 to cycle bits through 16MB of RAM.

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

It seems worthwhile to me to have a test which would detect addressing problems, though.
Cheers
Ed

My bench computer includes a memory test - it runs after the LCD has been initialised so it can display the address of a memory failure. The LCD can be initalised without needing to use RAM at all.

The memory test itself generates a random sequence of bytes using a LFSR generator to fill the memory. It then resets the LFSR seed and confirms the values in memory match those generated by a re-run of the random sequence. Thiis will fail if the address lines are shorted or open and so tests more than just the RAM device itself. Indead, given the reliability of RAM chips, it was my wiring I was more interested in testing!

The test uses the first 4 bytes of zero page as temporary storage. Of course, this means these bytes can't be tested but if these are faulty, the test will fail at byte 0004 or 0005, indicating a problem with the RAM device.

So far, the only time the test has failed was when I replaced the 32K RAM with an 8K device as a test of the RAM test!

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

Interesting replies, thanks.



So. I guess I am being a bit paranoid. I could initialise the VIA port and then I have four LEDs and the LCD avaliable.



Then what would the best means of differentating between a memory error and the end of memory, it seems either condition would throw an error. Is it just a matter of testing against expected bounds?

In my first big project (1987 or so), I had it test every RAM location and also get a checksum on the ROM. The test was never failed. I can see testing for RAM quantity, but ICs have to be put in by hand, so jumpers could be too; and the wrong type of IC, or one put in backwards, will make things fail immediately, so you'll definitely catch it. I have never, ever, seen RAM fail once in service, so I don't test anymore.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I agree to an extent. However, a memory bus fault would not be detected, since the MPU wouldn't actually know what the RAM hardware is seeing on its address inputs. You'd have to devise a test that checks all addresses, and then rechecks for single bit address bus failures. In practice, once a design is working and as Garth noted, faults rarely occur.

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

The idea in the stackoverflow answer I linked was pretty direct and efficient, and apparently helped with a production problem. So it needn't been terribly expensive.

I would think a hobby machine might well fail a test after a long time idle, depending on construction, treatment and environment.

Cheers
Ed

Just came across yet another thread on Stardot forums about memory trouble - clearly it does happen, so here's a pointer to some code from Mike Willegal:
http://www.willegal.net/appleii/6502mem.htm

Cheers
Ed

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!

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

Here's a thing, from well before my time:

From http://ed-thelen.org/comp-hist/lgp-30.html
and see also my post over at http://anycpu.org/forum/viewtopic.php?f=22&t=136
(Bear in mind that the drum was the RAM of this machine, and also stored the register data.)