What could a program called MemTest do? Hm, would it be possible that it do something strange like testing memory? Maybe. Let's test the following: memtest 0 100000 The screen turns to grey or does something other unforeseeable things. After a delay it appears as it disappears before. But was happen? The processor has changed the memory completely in order to catch the lazy bits that never want to represent what they shall do, but that do what they want. After outputting the results you are able to take a program like BlockMem to prevent these bits from further usage. The reason for writing this program is simple: When I wrote in a text editor it happens sometimes that the characters changed without my help. I detected this, because the written text was assembly language and the changed letters doesn't have any sense in Assembler. First I thought it would be a bug of the text editor, but other editors shows the same behaviour. Remember this bug happens seldom and was difficult to reproduce. So I'm not sure how long this defect lives in my Amiga. It could have been a virus, but I found nothing. At last I assumed the unbelievable and tried to find data changes with a monitor. I filled big blocks with $FF and searched with cursor scrolling if somewhere flashes a character. And it does in SlowMem of my internal A500 memory card. It was a bit turning to 0 after you typed 1. Now the idea of a program for automatically testing memory was born. I wanted to know a_l_l defects of my memory. But I couldn't make a copy of the whole memory to harddisk, filling the memory with $FF, looking for changes and take back the memory from harddisk, because I had to switch off the multitasking, and then disk accesses wouldn't be possible. Besides it would not be possible to turn back in the state before storing the memory on harddisk. But I found another way: If the memory was unused for a sufficient time all faulty bits should be in their favourite state. When I take a check-XOR the check-XOR of the completely inverted memory should also be inverted. If it does not a faulty bit is in the tested memory block. In this way you can nest in the block and find the address of the faulty bit and at the end you can easily restore the memory. The only you risk is that two bits on the same position inside a longword but in different longwords cannot be detected. First the program didn't find any errors. And I wonder if the program was wrong or if I have forgotten something. After I have seen my program has no obvious bug, I guessed that the bits do not refuge the data, but storing it and forget it after a delay. So I put a delay in my program, too. And now I found not only the already known bit, but another that flips from 0 to 1 and needs a longer time. This things you should pay attention to: 1. Make sure that the MemTest program is not loaded in the memory area you want to test. If you want to test ChipMem you should have enough FastMem for these 14K ;-) MemTest is then automatically loaded there. Otherwise you are requested to call NoFastMem to force MemTest to be loaded in ChipMem. 2. Before using MemTest you should use a tool like the AmigaRealTimeMonitor to get addresses and sizes of the memory installed in your Amiga. 3. Keep in mind that the bits could take some time to flip. (My 0->1 bit takes up to a second for this work!) The third parameter is for adjusting this and defaults to 1000000 (one million). Hope your CPU is not too fast in counting the complete range of longwords (4Giga). Henning Thielemann Veilchenweg 34 06118 Halle Germany E-Mail: henning.thielemann@student.uni-halle.de URL: http://www.informatik.uni-halle.de/~erz/ht/Index.html PS: I can't test the program any longer. Since I changed my old FatAgnus against a BigAgnus in order to get 1 MB ChipMem (Yes I did it not until December 1996!!!) the bits work correctly again.
Alek_NGI