Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!acorn!moncam!emmo
From: emmo@moncam.co.uk (Dave Emmerson)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Need Help with ROM/empty address distinction
Message-ID: <366@marvin.moncam.co.uk>
Date: 16 Jan 90 15:43:00 GMT
References: <1990Jan15.162053.14109@ee.rochester.edu>
Organization: Monotype ADG, Cambridge, UK
Lines: 34

In article <1990Jan15.162053.14109@ee.rochester.edu>, jal@ee.rochester.edu (John Lefor) writes:
> [deleted] but how do I distinguish between
> ROM and nothing.  In my experiments nothing sometimes is read as the
> same hex data and other times the data changes between reads.

The problem is that empty memory is just that, you could literally read
*any* valid bit pattern from *any* empty adrress *any* number of times
on many systems.
What you need is a method to force empty locations to a known state. The
simplest, cheapest and safest method (which *should* be standard practice
on any well-designed system) is to put a 10K ohm pull-up resistor on each
data bus line. If your motherboard has an empty ROM socket (2 if it's an AT)
it's an ideal place to fit them. All unused locations then show up as hex
'FF'.
I won't go into detail, I suspect you want your software to work on any
machine without modification. To do that, write known pseudo-random data
to a small-ish area (16-256 bytes), read back and compare the results,
and *store them too*. If it doesn't match, either it's not RAM, or something
is overwriting it (an interrupt routine etc..), or it's empty. Now read it
back again (a few times if necessary), this time comparing with the first
readback. If it fails to re-match it's most likely empty, otherwise, unless
it's all HEX FF's it's almost certainly ROM (probably, but not necessarily,
a valid BIOS ROM).
On other machines, I have found it worthwhile using different opcodes
for the second and third passes, it seems like the data bus had enough
capacitance to retain the last valid data for several uSec, so it
always seemed to read the exact same data ( the last byte/word of the
read instruction ). If you're using a high level language, this might
be difficult. I haven't gotten my hands that dirty with a PC yet, so
I can't offer any further suggestions.

Hope that helps,

Dave E.