RAM / ROM Test

[Chris Savage]

With regards to this thread...particularly toward the end...

One of the things I found within the code (subroutines) not used in this application was my ROM Checksum Code. I remember that I had some issue figuring out how to implement it, because when the object code is loaded into the buffer of the device programmer, there is a checksum calculated. When you enter the checksum values into the reserved area of your ROM to compare against, you change the checksum.

So, at the time I didn't know how the device programmer was calculating the checksum within their software, and in fact I didn't know until several years ago that this is a standardized calculation. At the time I thought it was proprietary. Once I understood how it worked, it was easy enough to add / update the checksum every time I updated the object code. It's actually much easier than you might think, and if y'all are interested, I can do a tutorial on how to implement a ROM Checksum into your CPU programs to test the integrity of code stored on older EPROM / EEPROMs.

I was also planning on sharing my RAM Test routine, which actually tests RAM using four bit patterns (00000000, 10101010, 01010101, 11111111) and is non-destructive. That is, the original contents of the RAM location are restored during the test, which is useful if you're using NVRAM, as I often did.

[Chris Savage]

Once I post these routines, I would be interested in getting some feedback from MicroNut, as a fellow Z80 enthusiast.

[Chris Savage]

One final thing with regards to this thread...I know that many are really more into microcontrollers than CPUs, however, I am curious if anyone would like to see a tutorial posted on Savage///Circuits discussing RAM / ROM testing? I would use my own RAM / ROM test code for the Z80 to describe how I go about conducting these tests, however, it would be very similar to how a PC does the same thing.

[granz]

I remember, back in school (USAF Tech School, Keesler Air Force Base) we would write simple routines to test/exercise the memory on our mainframe (Burroughs D-825 Multi Processor system, Air Force BUIC - Back Up Interceptor Controller, for live air defense.) We would write it out on paper, then key it in (48-bits per memory location, 32K words. ) You could not use just all ones, then all zeros, because that would not check neighboring bits stuck (magnetic core memory.)

It was much faster and easier to write tests for the Z-80.  How do you test the ROM? Do you just add up the bytes and then create a check sum?

[Chris Savage]

How do you test the ROM? Do you just add up the bytes and then create a check sum?

Yes. When you get a checksum from a device programmer, it is literally a sum of all the bytes of the buffer / device. I reserve 4 bytes at the end of ROM for the checksum. These bytes are cleared ($00). Once the checksum is generated, these bytes are populated (little endian) with the checksum and the ROM Test counts all the bytes except the last four. The last four bytes are compared to the calculated checksum. If they match, ROM is good. If not, ROM is bad.

[granz]

How do you test the ROM? Do you just add up the bytes and then create a check sum?

Yes. When you get a checksum from a device programmer, it is literally a sum of all the bytes of the buffer / device. I reserve 4 bytes at the end of ROM for the checksum. These bytes are cleared ($00). Once the checksum is generated, these bytes are populated (little endian) with the checksum and the ROM Test counts all the bytes except the last four. The last four bytes are compared to the calculated checksum. If they match, ROM is good. If not, ROM is bad.

Yep, that should work.

Interestingly, yesterday, while reading over some of my old magazines, I came across a RAM test written in BASIC - I believe that it was for when you took the original 4K chips out of the TRS-80 Model I to upgrade to 16K, and then built a board to hold those 4K chips to have 20K. The BASIC test program would test the 4K extension. The trouble with that is that you cannot relocate the test program to test the lower RAM. That relocating is something that we had to do with machine language so that it could test the entire RAM.

[Chris Savage]

Interestingly, yesterday, while reading over some of my old magazines, I came across a RAM test written in BASIC - I believe that it was for when you took the original 4K chips out of the TRS-80 Model I to upgrade to 16K, and then built a board to hold those 4K chips to have 20K. The BASIC test program would test the 4K extension. The trouble with that is that you cannot relocate the test program to test the lower RAM. That relocating is something that we had to do with machine language so that it could test the entire RAM.

Did the program use PEEK / POKE to facilitate the testing? I remember the Model 1. It was like $600 at the time. I used to get the Radio Shack catalogs and I remember drooling over that computer. While I never did own one, I did eventually own the TRS-80 Color Computer and subsequently the Coco 2 and Coco 3.

[granz]

Did the program use PEEK / POKE to facilitate the testing?

Yes, I believe that it did.

I remember the Model 1. It was like $600 at the time. I used to get the Radio Shack catalogs and I remember drooling over that computer. While I never did own one, I did eventually own the TRS-80 Color Computer and subsequently the Coco 2 and Coco 3.

I also remember it fondly - I actually got one while stationed at Mountain Home Air Force Base, Idaho (1985-'86.) I remember trading a handheld ham radio (no idea where I got that) for a pair of 2/3-height disk drives. Then after getting stationed at Bergstom AFB, TX, I obtained a Radio Shack Line Printer IV. That LP IV ended up being my printer when I was forced to purchase my first PC - just needed a custom cable.