home *** CD-ROM | disk | FTP | other *** search
/ Amiga Format 96 / af096sub.adf / memflip.LZX / MemFlipTest / MemTest.doc < prev    next >
Text File  |  1981-01-02  |  4KB  |  74 lines
  1.  
  2. What could a program called MemTest do?
  3. Hm, would it be possible that it do something strange like testing memory?
  4. Maybe.
  5. Let's test the following:
  6. memtest 0 100000
  7.  The screen turns to grey or does something other unforeseeable things.
  8. After a delay it appears as it disappears before. But was happen?
  9.  The processor has changed the memory completely in order to catch the lazy
  10. bits that never want to represent what they shall do, but that do what they
  11. want.  After outputting the results you are able to take a program like
  12. BlockMem to prevent these bits from further usage.
  13.  
  14.  The reason for writing this program is simple:  When I wrote in a text
  15. editor it happens sometimes that the characters changed without my help.  I
  16. detected this, because the written text was assembly language and the
  17. changed letters doesn't have any sense in Assembler.  First I thought it
  18. would be a bug of the text editor, but other editors shows the same
  19. behaviour.  Remember this bug happens seldom and was difficult to
  20. reproduce.  So I'm not sure how long this defect lives in my Amiga.  It
  21. could have been a virus, but I found nothing.  At last I assumed the
  22. unbelievable and tried to find data changes with a monitor.  I filled big
  23. blocks with $FF and searched with cursor scrolling if somewhere flashes a
  24. character.  And it does in SlowMem of my internal A500 memory card.  It was
  25. a bit turning to 0 after you typed 1.
  26.  Now the idea of a program for automatically testing memory was born. I
  27. wanted to know a_l_l defects of my memory. But I couldn't make a copy of
  28. the whole memory to harddisk, filling the memory with $FF, looking for
  29. changes and take back the memory from harddisk, because I had to switch off
  30. the multitasking, and then disk accesses wouldn't be possible. Besides it
  31. would not be possible to turn back in the state before storing the memory
  32. on harddisk.
  33.  But I found another way:  If the memory was unused for a sufficient time
  34. all faulty bits should be in their favourite state.  When I take a
  35. check-XOR the check-XOR of the completely inverted memory should also be
  36. inverted.  If it does not a faulty bit is in the tested memory block.  In
  37. this way you can nest in the block and find the address of the faulty bit
  38. and at the end you can easily restore the memory. The only you risk is that
  39. two bits on the same position inside a longword but in different longwords
  40. cannot be detected.
  41.  First the program didn't find any errors. And I wonder if the program was
  42. wrong or if I have forgotten something. After I have seen my program has no
  43. obvious bug, I guessed that the bits do not refuge the data, but storing it
  44. and forget it after a delay. So I put a delay in my program, too. And now I
  45. found not only the already known bit, but another that flips from 0 to 1
  46. and needs a longer time.
  47.  
  48. This things you should pay attention to:
  49. 1.  Make sure that the MemTest program is not loaded in the memory area you
  50. want to test.  If you want to test ChipMem you should have enough FastMem
  51. for these 14K ;-) MemTest is then automatically loaded there.  Otherwise
  52. you are requested to call NoFastMem to force MemTest to be loaded in
  53. ChipMem.
  54. 2.  Before using MemTest you should use a tool like the
  55. AmigaRealTimeMonitor to get addresses and sizes of the memory installed in
  56. your Amiga.
  57. 3.  Keep in mind that the bits could take some time to flip.  (My 0->1 bit
  58. takes up to a second for this work!) The third parameter is for adjusting
  59. this and defaults to 1000000 (one million).  Hope your CPU is not too fast
  60. in counting the complete range of longwords (4Giga).
  61.  
  62. Henning Thielemann
  63. Veilchenweg 34
  64. 06118 Halle
  65. Germany
  66.  
  67. E-Mail: henning.thielemann@student.uni-halle.de
  68. URL: http://www.informatik.uni-halle.de/~erz/ht/Index.html
  69.  
  70. PS:  I can't test the program any longer.  Since I changed my old FatAgnus
  71. against a BigAgnus in order to get 1 MB ChipMem (Yes I did it not until
  72. December 1996!!!) the bits work correctly again.
  73.  
  74.