[comp.windows.ms] Windows Crash with expanded memory addition

schwartz@dinl.uucp (Michael Schwartz) (06/03/89)

Thanks to all those who responded with help on the problem of expanded
memory with Windows/286.  A number of the responses were not applicable
to my system, but may interest others.

With some pointers from those of you who helped, I'm now up and running.
The only question remaining is "what is the difference between an
AboveBoard 286 and an AboveBoard Plus", the latter being all that is
marketed by Intel today.

From: waltw@pogo.wv.tek.com (Walt Wilson)
Try looking for memory conflicts, especially if you are using a Paradise VGA.

Walt informs me that CONFIG.SYS can be changed to take care of this.

From: ames!auvax.AthabascaU.CA!kevinc
  If you don't have emm set up exactly to how much mem you have then
  the whole damn system barfs.

Kevin's statement is a critical area if the board is being used for
extended memory.  For expanded memory, EMM.SYS can be told to CHECK to
see if one has EXACTLY the amount of expanded memory expected.


From: Scott Thurlow <gatech!cs.utexas.edu!uunet.UU.NET!rlgvax!scott>

  I had a similar problem with my AST Premium 286.  I solved it by using the 
  expanded memory driver that came with Windows rather than the expanded memory
  driver that came with the hardware.

Scott's statement is also critical if you have one of the older EMM
drivers.  Curiously, the AboveBoard came with a driver dated 6 months
earlier than the Windows driver, though they could be byte-compared with
no differences!

One of the MicroSoft engineers (Ralph Lipe) posted a news article
(5798@microsoft.UUCP) providing technical detail on the meaning of an
Internal Stack overflow, and a mechanism for controlling it in the
CONFIG.SYS file.  This was disclaimed as a personal opinion.

I may never really understand what caused the problem, though the most
substantial change I made was replacing the HIMEM.SYS that came with
windows/286 with the HIMEM.SYS from my SDK.  I believe the problem was
caused by conflicts over a software interrupt; SOMETHING caused the IRQ3
handler to go off in the weeds.  Additionally, I installed all the
windows drivers AFTER the shell command in my CONFIG.SYS (I'm too
stubborn to patch COMMAND.COM to give me a reasonably sized
environment), though I have not (and probably will not) test to see if
this is a problem.  For debugging purposes, I tested this with the slow
boot" windows installation.  I decided I like it this way, so "slow
boot" will stay, also.  There is the slightest possibility that the
problem was tied to the contents of a strange root directory entry that I
wiped out in tracking through one of my drivers.  If it recurs, I will
post.

An interesting side effect is that Windows grabs about 128K of the
expanded memory at start-up, but gives half of it back at the first
opportunity to move segments.

I STRONGLY suggest that anyone with a similar problem write a small
program to dump interrupt vectors and trace what's going on in the more
suspicious ones.  Of course, prepare a fresh boot diskette to help
control this, and add drivers one at a time, saving the results for 
comparison.

Also, as a side issue, a logitech mouse must be powered down if anything
wrote to its serial port before trying to use it again.

BTW, I believe the newer HIMEM.SYS is the one available on SIMTEL20
(pardon me, WSMR-SIMETEL20) as PD1:<MSDOS.SYSUTL>HIMEM.ARC, but am not
positive (Thanks Ralf Brown and Keith Petersen!).

Sorry for the length, but I hope this helps others.
-- 
Michael Schwartz
ncar!dinl!schwartz
MSchwartz@Dockmaster.ARPA

patrickd@chinet.chi.il.us (Patrick Deupree) (06/05/89)

In article <1036@dinl.mmc.UUCP> schwartz@dinl.uucp (Michael Schwartz) writes:
>
>The only question remaining is "what is the difference between an
>AboveBoard 286 and an AboveBoard Plus", the latter being all that is
>marketed by Intel today.
>
There's a difference that is really kind of small, but actually very big.

In the world of EMS there are large frame and small frame EMS.  Large frame
EMS is usually called 4.0 and the standard was set by Intel.  Unfortunatly they
made a little boo boo and, even though the AboveBoard 286 uses LIM4.0, it
doesn't support large frame EMS.  So, they fixed this little error with the
AboveBoard Plus (luckily all it involved was replacing one chip, so they were
able to use all the old AboveBoard 286's).  Since there is no reason to get
a small frame board if a large frame one is available, the 286 board was
phased out.

We're getting one of the Plus's in here soon to give it a shot with our 
product.  Should be interesting.

-- 
"I place my faith in fools.  Self confidence, my friends call it."
					-Edgar Allen Poe

Patrick Deupree -> patrickd@chinet.chi.il.us