aab@sfsup.UUCP (A.Bellotti) (01/13/89)
I have a 6386WGS computer with 1Mbyte of Ram Running DOS 3.3. Is there any way to use the memory between the 640K and 1M limit as a Ram Drive. I tried using the /E option for vdisk, but it seems to work for memory above the 1M limit only. Any help will be appreciated. Alberto Bellotti ihnp4!attunix!aab
leonard@bucket.UUCP (Leonard Erickson) (01/14/89)
In article <4616@sfsup.UUCP> aab@sfsup.UUCP (A.Bellotti) writes:
<
<I have a 6386WGS computer with 1Mbyte of Ram Running DOS
<3.3. Is there any way to use the memory between the 640K
<and 1M limit as a Ram Drive.
<
<I tried using the /E option for vdisk, but it seems to
<work for memory above the 1M limit only.
The reason you can't do it is because there *isn't* any system RAM
between 640k and 1 meg! System RAM is between 0 and 640K after that
the address space is reserved for display adapters and various ROMs
If your AT has 1 meg of memory, the most common motherboard setup allows
two setups. 512k of normal RAM and 512k of extended RAM (RAM addressed
above 1 meg), or 640K of normal RAM and the remaining 384k is ignored.
Some motherboards allow mapping as 640k normal and 384k extended, but
if you add more memory you have to go back to the 512/512 setup or have
a "hole" in your extended RAM.
A few motherboards (Compaq, for one) have some extra chips to fill the
512k to 640k gap, otherwise you are stuck with buying a board that will
let you "backfill" this space...
--
Leonard Erickson ...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I used to be a hacker. Now I'm a 'microcomputer specialist'.
You know... I'd rather be a hacker."wales@valeria.cs.ucla.edu (Rich Wales) (01/17/89)
My system (a Wugo PC-II-AD, a Taiwanese turbo XT clone) has 1 meg on the motherboard, and the top 384K *is* accessible as a RAM disk. What Wugo did was implement a band-switching hack in their hardware, in which the extra RAM (640K-1Meg) can share the same address space with 128K-512K. This is under control of I/O port 0E0H (which is unused and reserved in the "true blue" IBM PC). If the value 0FFH is output to port 0E0H, the alternate RAM is accessed; regular memory mapping is restored by outputting a zero to port 0E0H. My system came with a special RAM disk device driver that knows about this odd hardware. As it turned out, the RAM disk driver had a serious bug in it -- there were some "windows" during which the extra memory was "mapped in" while hardware interrupts were enabled. If any hardware interrupt handler resided even partially between 128K and 512K, needless to say, this was a sure recipe for utter chaos and disaster. I eventu- ally found the bug (by disassembling the driver) and managed to fix it with DEBUG; the RAM disk works just fine now. I sent a letter to Wugo's US office describing the bug and the fix; hopefully they'll do something about it in their later releases. Presumably, one could write a TSR that would use this extra memory as a disk cache. Maybe I will one of these days, if I get really ambitious. -- Rich Wales // UCLA Computer Science Department // +1 (213) 825-5683 3531 Boelter Hall // Los Angeles, California 90024-1596 // USA wales@CS.UCLA.EDU ...!(uunet,ucbvax,rutgers)!cs.ucla.edu!wales "Now, if you do see me again today, I want you to report it to me immediately."