Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!crdgw1!rpi!quimby
From: quimby@madoka.its.rpi.edu (Tom Stewart)
Newsgroups: comp.windows.ms
Subject: Re: Can Windows damage hardware (RAM)?
Message-ID: <_B-&3$&@rpi.edu>
Date: 16 Feb 91 18:50:42 GMT
References: <1991Feb12.220834.1991@syssoft.com> <13920@as0c.sei.cmu.edu> <1991Feb15.195757.6133@maverick.ksu.ksu.edu>
Lines: 25
Nntp-Posting-Host: madoka.its.rpi.edu

rogerhef@matt.ksu.ksu.edu (Roger Heflin) writes:

>The memory that you are getting the parity error on is probably above
>the 1M mark.  If you where not using extended and/or expanded memory for
>anything the memory was unused, and since nothing used it there was no   
>reason to get a parity error.  Putting the machine down to 8Mhz is very
>similar to adding a wait state to the ram, it the fact that it slows down
>the ram access.  The boot-up test passes because on most machines I have
>seen the boot-up test starts without reading the CMOS setup on the machine,
>and so the ramtest test with a certain maximum number of wait states, it 
>does not see it the wait states are set properly for the memory, it just 
>checks to see it the memory works at the slowest speed allowed by your    
>computer.  

Another reason is that the boot check doesn't execute above 1M -- it only
does read/write.  The timing for an opcode fetch is much tighter than
for read/write.  DOS, even with EMS, never executes about 1M, so the 
potential problem doesn't appear until you try to run Windows, or UNIX.
(Sometimes it doesn't appear until you install UNIX, ship the machine to
a customer, and let him try to run 2 users on the machine at once. :) )
  
Quimby
  
(mailer disfunctional, replies to: quimby@mts.rpi.edu, quimby@rpitsmts.bitnet)