RAM Mapping Script

[Ben Scott]

On Sun, Mar 2, 2008 at 3:39 PM, Jim Kuzdrall <gnhlug at intrel.com> wrote:
> Your suggestion even comes before I forgot where all the screws I took out
>  came from.

  One thing I've seen a field service tech do is carry a stack of
plastic "Dixie" cups (2 oz size).  Each set of screws went into a cup,
and the next one stacked inside that one.  As long as one reassembles
components in the same order one took them apart, this works nicely as
a guide.  And one can put an empty cup in the top of the stack and
wrap the stack in tape to keep them from spilling.

>  Actually, remapping the add-on RAM to the low address makes a lot of
>  sense from the hardware design aspect.

  Ahh, interesting.  Nice to know there's a good reason behind it.  :-)

> It irks me to toss a beautiful piece of engineering ...

  Yah, I'm the same way.  I've got a large collection of junk I'm
convinced can be restored to fully-operational glory if I can just
find the time to fix just one small problem.  :-)

>  INT 19h stores the code when the numeric keypad is used with the alt
>  key.

  Are you sure?

  According to Ralf Brown's Interrupt List (*the* guide, which I still
recall from my MS-DOS days), software interrupt 0x19 is "BOOTSTRAP
LOADER", which "reboots the system without clearing memory or
restoring interrupt vectors".

http://www.cs.cmu.edu/~ralf/files.html

http://www.delorie.com/djgpp/doc/rbinter/id/79/22.html

  Google results seem to corroborate this:

http://www.google.com/search?q=%22int+19h%22

> Real or unreal mode, the location of the interrupt jump table is
> built into the processor, as has been pointed out.

  Once the system switches into protected mode, I'm given to
understand that things don't work that way anymore.  I'm guessing that
if one is in protected mode, using the new way, it may be possible to
discard the real-mode table located at address 0 and reclaim that
memory for other purposes.  (Whether such an action is a good idea, or
the kernel actually does so, I have no idea.)

  Google finds more info, if you're so inclined:

http://www.google.com/search?q=protected+mode+software+interrupt+table

>  I only intended to show that the program did not report a memory
>  error at $64 every so often no matter what it was testing.

  Right, and a good sanity-test.  I was only remarking that I've seen
MemTest86 report false positives on some hardware.

> To see if your RAM removal suggestion works, I should probably use
>  the same program that reported the error the first time.

  Absolutely.  But running additional tests may prove to be useful,
should removing the memory module not solve all your problems.  :-)

-- Ben