Hi..
I'm currently writing a RAM tester in FlatRealMode. I have my code working 
well, based on FRM entry code found in the Assembly Snippets archive,
and an alogarythm found in "Memtest-86" (Linux program) which works as 
follows:
  Turn off cache, turn on writethru, then WBINVD.
  repeat the following 5 times, for each dword to be tested:
{
  Set all bits in dword to be tested to 0, excpt the bit under test. Set the
  bit to be tested to '1'.
  Read-memory & verify it read OK.
  Perform logical NOT on the memory dword. Ie all 1's become 0, all 0's
  become 1.
  Read-memory & verify all bits changed state properly.
}
In practice I use XCHG eax,fs:[memlocn] to do both the NOT and the memory 
read in one operation. This makes the code faster, which is apparently very 
important... if one delays reading the memory, after having set it, a bit too 
long the bad bit is never seen.
This works rather well, detecting a bad memory bit in a known bad SIMM module 
I have (for this very purpose), which HIMEM.SYS also objects to, however this
alogarythm is only one of many ways to write a RAM tester.
I'm looking for other alogarythm's to try. Can anyone describe or refer me to 
any other RAM tester source code/alogarythm descriptions? I can take internet 
URL's if you have them... Information on this topic isn't easily gleaned, and 
so far a good read of what few memory manufacturer's data sheets I have has 
found very little.
I am especially keen to try and devise a test that can detect the sitation 
where the user fits two different SIMM modules to a single bank - on their 
own each SIMM works OK, but as a pair in the same bank, they fail. (for 
example, one 80ns & one 60ns SIMM, or one EDO + one NonParity SIMM). This is 
a common enough mistake and will cause major instability problems for 
linux/win95/NT users.
At the moment the source code is a hybrid of TASM (for getting FlatRealMode 
setup), Turbo Pascal (mundane screen drawing tasks, etc) and BASM (TP's 
built-in Assembler) for the actual 32-bit testing. I'm sure a full 32-bit 
protected mode version could be produced with some work -- I just hate 
writing boring things like screen drawing code in assembler, espescially 
since this program is very much in the 'lets try this idea' stage, rather 
then the 'we know what we're doing, so lets make the final program' stage.
I would very much like to hear from anybody with any thoughts on this 
bject!
    Regards, Craig
--- FMail/386 1.20+
---------------