Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!uakari.primate.wisc.edu!xanth!mcnc!ncsuvx!shumv1!unkydave
From: unkydave@shumv1.uucp (David Bank)
Newsgroups: comp.sys.ibm.pc
Subject: Re: ALR 386/220
Keywords: raam ramblings
Message-ID: <4664@ncsuvx.ncsu.edu>
Date: 27 Nov 89 17:03:18 GMT
References: <[256fa9cc:24]comp.sys.ibm.pc@tronsbox.UUCP>
Sender: news@ncsuvx.ncsu.edu
Reply-To: unkydave@shumv1.ncsu.edu (David Bank)
Organization: NCSU Computing Center
Lines: 31


    The only thing I can thing of, offhand, is that your machine is
reserving the 128 KB of RAM regardless of the setting of the
ROM-to-RAM DIP switch.

    The main reason such a ROM-to-RAM copy is done is because
DRAM is so much faster than ROM chips -- nature of the semiconductors
used. However, I should think that in such a scheme (and I could be
wrong, but the idea seems sensible to me) that such memory would
be, at least nominally, protected from writing once the transfer
is completed.

    If this inhibition exists and is hardware based, then that might
explain why you can't use the 128 KB....the machine is "wired" such that
the memory is off-limits to "normal" usage at all time, regardless of
the ON/OFF state of the ROM-to-RAM copy.

    Anyway, this is a lot of guesswork, I admit. I worked on an
NCR '386 clone that had this "problem". It seems to me that
"1 MB RAM" should mean 1 meg of USER memory, that the user can
access freely...rather than 128 KB being hogged by the system and
the user being locked out. That, to me, is not 1 MB RAM.

    Hope I've given you some ideas.

Unky Dave
unkydave@shumv1.ncsu.edu

DISCLAIMER: The above message constitutes is honest effort by the author
            to impart information he knows or reasonably knows to be
            true. All other interpretations are erroneous.