From: Dan Olson <dano@agora.rdrop.com>
To: linux-8086@vger.kernel.org
Subject: Re: 768k XT?
Date: Sat, 14 Jun 2003 13:26:48 -0700 (PDT) [thread overview]
Message-ID: <20030614131522.Q95623@agora.rdrop.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0306140118540.4877-100000@olympus.btstream.com>
> Alan Cox (and maybe others) actually answered your question about running
> ELKS on this machine last November when you were trying to run it on a
> 512K machine: ELKS is compiled to use exactly 640K; you *might* be able to
> use more if you re-compile it. I can assure that ELKS runs properly in a
> machine with more than 640K, it just isn't aware of the additional memory.
I understand that ELKS is compiled for 640k memory, my real question is
exactly what you mentioned, has anyone tried to recompile with more than
640k? I get the impression that there is little chance of a) this working
and b) this being useful, though.
> It does appear that you have 768K. There are several possible explanations
> for this, among which are:
> 1. It actually is an AT-class board. If it's a desktop motherboard, check
> the expansion slots for two, rather than one connector per card slot.
It has 8 bit slots.
> 2. It's an XT-286. I don't know just what they are, but I've seen
> references to them.
I'm 99% sure I saw an 8088 in there. I believe the XT-286 looks like an
XT to the outside world, using an XT keyboard and lacking space for a full
AT size expansion board. Basicly IBM squeezed a 286 board in an XT case
:)
> 3. A decade or so ago there was a shortage of 64K memory chips. I heard
> that some manufacturers changed their boards to accept the more-expensive
> 256K chips, which were more readily available. I don't know any details.
This could very well be, and also, this board lacks room for two banks of
64k chips and instead has one bank of 256k chips. It's very possible they
only intended to use 128k of that memory.
> Some suggestions:
> 1. The next time you do a cold boot, look carefully at the memory size
> message(s). If you see something about extended or expanded memory size,
> in additional to the 640K "conventional" memory, then your computer is
> almost certainly capable of using the additional memory (with the right
> driver).
Nope, it just lists the 640k.
> 2. If you have the originals for your computer, check CONFIG.SYS and
> AUTOEXEC.BAT for references to something line "himem", "emm", "qemm", or
> "loadhigh". Any such lines would probably indicate that your computer can
> use memory above the "conventional" 640K, and would indicate their proper
> use.
I picked this computer up second hand with no software.
> 3. ELKS seems to be quite good at identifying the processor. I haven't
> tried it on an XT, but I've seen it correctly identify 286, 486, and
> Pentium class processors. Check the first few lines printed on the screen
> when ELKS boots to see if you actually have a 286. I don't remember if an
> XT had an MMU chip, but if so it could probably map additional memory into
> an unused area where an expansion-card ROM would otherwise be found (with
> the right driver, of course). This area starts at segment C000 and ends
> below segment E000 (or is it F000?). If you have a 286 or higher, an MMU,
> and the right driver, you could probably map the additional memory above
> the 8086's 1-Meg address limit.
I *suspect* it's just a cheap 8088 with the minimal hardware, I would have
noted seeing a 286 while the cover was off.
> 4. Someone suggested that you use DEBUG to test memory in the Axxx and
> Bxxx segments. That probably won't tell you anything usefull. That area is
> reserved for memory on the video card, not on the motherboard. The DEBUG
> commands stated were correct, however. Since XT harddrive controllers are
> usually jumpered to start at segment C800, the data displayed by the
> DEBUG command:
> d c800:0000
> will probably include some plain text indicating the hard drive controller
> manufacturer, because almost all expansion card ROM's have some sort of
> plain-text signature. Likewise, the "e" command allows you to not only
> examine, but try to change memory. Note that, due to the way the circuitry
> is usually designed, addresses with no corresponding RAM are likely to
> display as "FF"; that is to say:
> Displays as: Changable? Is probably:
> FF No ROM or unused
> other than FF No ROM
> (anything) Yes RAM
> This might help you identify areas where the right driver could map (or
> already has mapped) additional memory.
This is my next step. There is no hard drive controller, just a VGA board
and it's RAM/BIOS, and the system BIOS. I'll report back with what I
find.
Dan
next prev parent reply other threads:[~2003-06-14 20:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-07 19:36 ELKS on Laptops Juanjo Marín
2003-06-10 20:43 ` 768k XT? Dan Olson
2003-06-10 21:57 ` Chad Page
2003-06-11 1:46 ` Dan Olson
2003-06-10 23:14 ` Riley Williams
2003-06-11 1:54 ` Dan Olson
2003-06-14 9:57 ` jb1
2003-06-14 20:26 ` Dan Olson [this message]
2003-06-15 9:23 ` jb1
2003-06-15 18:24 ` Dan Olson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030614131522.Q95623@agora.rdrop.com \
--to=dano@agora.rdrop.com \
--cc=linux-8086@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox