From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Olson Subject: Re: 768k XT? Date: Sat, 14 Jun 2003 13:26:48 -0700 (PDT) Sender: linux-8086-owner@vger.kernel.org Message-ID: <20030614131522.Q95623@agora.rdrop.com> References: Mime-Version: 1.0 Return-path: In-Reply-To: List-Id: Content-Type: TEXT/PLAIN; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-8086@vger.kernel.org > 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