Keyboard controller reports A20 *always* enabled.
Rod Pemberton
I decided to update an A20 util of mine to report by which method A20 was
enabled: keyboard controller or PS/2 fast port. I got some really odd
results for my newer computer.
The A20 ON/OFF indicator is from an A20 enabled test using Int 0h. The KBD
ON/OFF is a read of the keyboard controller's A20 bit from it's output port
via D0h command. The PS2 ON/OFF/none is the A20 bit from the fast PS/2
port (or unused bit 2 set for "none").
First, let's look at two older computers:
233Mhz machine
initial: A20 OFF KBD OFF PS2 none
kbd on : A20 ON KBD ON PS2 none
This is normal. A20 turns on/off via keyboard controller only.
450Mhz machine
initial: A20 OFF KBD OFF PS2 OFF
kbd on : A20 ON KBD ON PS2 OFF
ps2 on : A20 ON KBD OFF PS2 ON
both on: A20 ON KBD ON PS2 ON
This is normal. A20 turns on/off via either keyboard or fast PS/2 port. On
the 450Mhz and 2.8Ghz machine (below), if both methods are active, both
require turning off, as expected.
Those two machines are normal, AFAICT. The util works correctly on the
older two machines, so I'm taking that as a proxy I coded it correctly...
Now for the wierdness of the day:
2.8Ghz machine
initial: A20 OFF KBD ON PS2 OFF
kbd on : A20 ON KBD ON PS2 ON
ps2 on : A20 ON KBD ON PS2 ON
both on: A20 ON KBD ON PS2 ON
This is not normal.
Notice that the 2.8Ghz machine reports the KBD A20 bit as on *initially* and
*always*. It cannot be turned off by either method, either initially or
after other methods being enabled. I also tried to get it to disable with a
AT keyboard using PS/2 adapter instead of a USB keyboard, and by turning of
legacy USB in BIOS. Nothing worked. If I turn on A20 via keyboard
controller, the PS2 bit reports on. It also reports PS2 bit turning on for
the PS2 enable of A20. It accurately keeps track of both being on, and both
needing to be turned off. I.e., it's functionally correct, but the read of
the ports are wrong.
Rod Pemberton
James Harris
wrote:
...
> 2.8Ghz machine
>
> initial: A20 OFF KBD ON PS2 OFF
> kbd on : A20 ON KBD ON PS2 ON
> ps2 on : A20 ON KBD ON PS2 ON
> both on: A20 ON KBD ON PS2 ON
>
> This is not normal.
>
> Notice that the 2.8Ghz machine reports the KBD A20 bit as on *initially* and
> *always*. It cannot be turned off by either method, either initially or
> after other methods being enabled.
Sorry for not replying sooner. Like you I'm puzzled about what's
happening. Is it possible that your machine doesn't have a keyboard
controller and is emulating essential parts of it in firmware (SMM)?
If so the issue may lie in what the firmware thinks it should report.
How about the other bits in the byte.
http://aodfaq.wikispaces.com/mkbc-output-port
What does your machine report for those bits and do they make sense?
> I also tried to get it to disable with a
> AT keyboard using PS/2 adapter instead of a USB keyboard, and by turning of
> legacy USB in BIOS. Nothing worked.
The keyboard shouldn't matter. When you turn off legacy USB in the
BIOS does that prevent you using the USB keyboard?
> If I turn on A20 via keyboard
> controller, the PS2 bit reports on. It also reports PS2 bit turning on for
> the PS2 enable of A20. It accurately keeps track of both being on, and both
> needing to be turned off. I.e., it's functionally correct, but the read of
> the ports are wrong.
So if you enable A20 via KBC the PS/2 bit reports it enabled. If you
then disable A20 via the KBC does the PS/2 port report it disabled,
and does it test as disabled?
Ditto with the PS/2 port (0x92). Can it both enable and disable A20?
Or is it that once enabled it's impossible to turn A20 off?
James
Rod Pemberton
news:f31b32c3-89c6-4c0d...@u26g2000yqu.googlegroups.com...
> On 1 July, 22:54, "Rod Pemberton" <do_not_h...@notreplytome.cmm>
> wrote:
> > Notice that the 2.8Ghz machine reports the KBD A20 bit as on *initially*
and
> > *always*. It cannot be turned off by either method, either initially or
> > after other methods being enabled.
>
> Sorry for not replying sooner. Like you I'm puzzled about what's
> happening. Is it possible that your machine doesn't have a keyboard
> controller and is emulating essential parts of it in firmware (SMM)?
My suspicion is SMM too, esp. since PS/2 toggles ON/OFF for both... But,
you know on what side of correct they (my suspicions) have been lately...
:-)
> If so the issue may lie in what the firmware thinks it should report.
> How about the other bits in the byte.
>
> http://aodfaq.wikispaces.com/mkbc-output-port
>
> What does your machine report for those bits and do they make sense?
>
Unfortunately, I don't know that. The routine just has a simple bit check
and branch. I thought about adding hex routine, but I didn't. I might. I
should. AFAIK, the port could be 0xFF-ing, or returning an ACK (0xFA), or
etc. (0xFn) controller error code ...
> When you turn off legacy USB in the
> BIOS does that prevent you using the USB keyboard?
When legacy USB is disabled:
For an OS, if it doesn't have USB keyboard support, then no keyboard...
I.e., no keyboard for DOS, but Windows will find and use a USB keyboard (if
you don't boot into DOS first - Win98SE). My OS has no USB stuff. So, yes,
it prevents me from using the keyboard with DOS (development environment)
and my OS, but not for Windows. I haven't tried Linux. (Uh... Linux
conversation continued at the bottom.)
For the BIOS, I can use a USB keyboard from power-on until the BIOS attempts
to load an OS. E.g., you can still get into the BIOS or select a boot
device via BBS. The BIOS also displays a warning that legacy USB is
disabled, even if a PS/2 keyboard is available... At that point, a USB
keyboard will stop working for OSes that don't support USB keyboards. I had
some issues with this a while ago, I couldn't get into my BIOS with a USB
keyboard, but I think that may have been because I was attempting to do a
bit too late.
> > If I turn on A20 via keyboard
> > controller, the PS2 bit reports on. It also reports PS2 bit turning on
for
> > the PS2 enable of A20. It accurately keeps track of both being on, and
both
> > needing to be turned off. I.e., it's functionally correct, but the read
of
> > the ports are wrong.
>
> So if you enable A20 via KBC the PS/2 bit reports it enabled. If you
> then disable A20 via the KBC does the PS/2 port report it disabled,
> and does it test as disabled?
Yes and yes.
> Ditto with the PS/2 port (0x92). Can it both enable and disable A20?
Yes.
> Or is it that once enabled it's impossible to turn A20 off?
No. A20 enable/disable by both methods separately and together works
correctly. Each is independent of the other. It functions just like the
450Mhz machine. It's just that what I'm getting reported is A20 always on
for the bit read from the KBD port, and PS/2 bit on for either one on. If
both are on, both must be off before PS/2 bit goes off, by any order. It
could be SMM emulating A20 via a PS/2 method, or motherboard chipset, or
maybe some issue with my program (missing wait?, didn't read an ACK? etc.)
that I'm unaware of at this point. It just seemed really odd to me that it
worked correctly for the other two machines.
RP Linux conversation:
I haven't tried Linux [with a USB keyboard and BIOS disabled legacy USB
support]. I've got a 64-bit version that I'm not using much. I really need
to downgrade it to 32-bit version so I can work on some code and use some
utils available on Linux. I'd like to keep the 64-bit version for when I
get around to 64-bit stuff. But, the drive is way too large to defrag so I
can repartition it safely, so I'm going to have to reformat, setup multiple
partitions, and reinstall. Unfortunately, you always get locked in to
whatever partition sizes you choose, when you've got multiple OS' installed.
I'd like to have a DOS partition first for recovery and/or backups of other
DOS partitions when needed, Linux always wants a swap partition, I'd like a
32-bit and 64-bit Linux. At the moment the DOS and Linux swap can be the
same, but if I ever need both Linux and DOS at the same time, which I've
come across before, I've got a problem without a Linux swap. So, I've been
procrastinating...
Rod Pemberton
James Harris
wrote:
...
> No. A20 enable/disable by both methods separately and together works
> correctly. Each is independent of the other. It functions just like the
> 450Mhz machine. It's just that what I'm getting reported is A20 always on
> for the bit read from the KBD port, and PS/2 bit on for either one on. If
> both are on, both must be off before PS/2 bit goes off, by any order. It
> could be SMM emulating A20 via a PS/2 method, or motherboard chipset, or
> maybe some issue with my program (missing wait?, didn't read an ACK? etc.)
> that I'm unaware of at this point. It just seemed really odd to me that it
> worked correctly for the other two machines.
Thanks for sharing the info.
>
> RP Linux conversation:
>
> I haven't tried Linux [with a USB keyboard and BIOS disabled legacy USB
> support]. I've got a 64-bit version that I'm not using much. I really need
> to downgrade it to 32-bit version so I can work on some code and use some
> utils available on Linux. I'd like to keep the 64-bit version for when I
> get around to 64-bit stuff. But, the drive is way too large to defrag so I
> can repartition it safely, so I'm going to have to reformat, setup multiple
> partitions, and reinstall. Unfortunately, you always get locked in to
> whatever partition sizes you choose, when you've got multiple OS' installed.
> I'd like to have a DOS partition first for recovery and/or backups of other
> DOS partitions when needed, Linux always wants a swap partition, I'd like a
> 32-bit and 64-bit Linux. At the moment the DOS and Linux swap can be the
> same, but if I ever need both Linux and DOS at the same time, which I've
> come across before, I've got a problem without a Linux swap. So, I've been
> procrastinating...
Partitioning can be a pain. You could consider something like one or
two of these
and keep your operating systems on separate disks, or keep your
Windows separate from Linux etc. Being trayless these ones allow you
to change a SATA drive (which can be the boot drive) without attaching
runners to the drive. Just pop the bare drive in or out as needed. And
using these doesn't preclude having other disks built-in.
If the URL isn't clickable google for trayless sata or similar.
James
Rod Pemberton
news:i0tetc$3ue$1...@speranza.aioe.org...
> "James Harris" <james.h...@googlemail.com> wrote in message
> news:f31b32c3-89c6-4c0d...@u26g2000yqu.googlegroups.com...
> > On 1 July, 22:54, "Rod Pemberton" <do_not_h...@notreplytome.cmm>
> > wrote:
> > > Notice that the 2.8Ghz machine reports the KBD A20 bit as on
*initially*
> > > and *always*. It cannot be turned off by either method, either
initially
> > > or after other methods being enabled.
> >
> > If so the issue may lie in what the firmware thinks it should report.
> > How about the other bits in the byte.
> >
> > http://aodfaq.wikispaces.com/mkbc-output-port
> >
> > What does your machine report for those bits and do they make sense?
> >
>
> Unfortunately, I don't know that. The routine just has a simple bit check
> and branch. I thought about adding hex routine, but I didn't. I might.
I
> should. AFAIK, the port could be 0xFF-ing, or returning an ACK (0xFA), or
> etc. (0xFn) controller error code ...
>
Ok, I inserted a hex routine. The 233Mhz and 450Mhz report 0x49 initially.
If A20 is enabled via keyboard controller on either, they report 0x4B.
(PS/2 fastport only on 450Mhz is 0x49, both methods 0x4B.) The 2.8Ghz
reports 0x4B always.
Rod Pemberton
James Harris
wrote:
...
> > > > Notice that the 2.8Ghz machine reports the KBD A20 bit as on
> *initially*
> > > > and *always*. It cannot be turned off by either method, either
> initially
> > > > or after other methods being enabled.
>
> > > > [...]
> > > If so the issue may lie in what the firmware thinks it should report.
> > > How about the other bits in the byte.
>
> > > http://aodfaq.wikispaces.com/mkbc-output-port
>
> > > What does your machine report for those bits and do they make sense?
>
> > Unfortunately, I don't know that. The routine just has a simple bit check
> > and branch. I thought about adding hex routine, but I didn't. I might.
> I
> > should. AFAIK, the port could be 0xFF-ing, or returning an ACK (0xFA), or
> > etc. (0xFn) controller error code ...
>
> Ok, I inserted a hex routine. The 233Mhz and 450Mhz report 0x49 initially.
> If A20 is enabled via keyboard controller on either, they report 0x4B.
> (PS/2 fastport only on 450Mhz is 0x49, both methods 0x4B.) The 2.8Ghz
> reports 0x4B always.
It seems some of my machines have similar issues.... I'll check
further once I can clear some current related problems. I wonder why
machines which presumably emulate parts of the original keyboard
controller produce such values. 0x4B is 0100_1011 which apparently
reports as set KB and mouse clock lines, the A20 gate and the system /
reset line. Perhaps the clock lines have been redesignated on newer
machines and now signify something. It still doesn't explain why the
A20 gate line should be reported as a 1 when A20 is not enabled.
James
Mike Gonta
> Ok, I inserted a hex routine. The 233Mhz and 450Mhz report 0x49 initially.
> If A20 is enabled via keyboard controller on either, they report 0x4B.
> (PS/2 fastport only on 450Mhz is 0x49, both methods 0x4B.) The 2.8Ghz
> reports 0x4B always.
I'd check that hex routine!
Writing a "one" to bit zero of either port 60h or port 92h will cause
a CPU reset.
You will not be able to read a "one", it has to be "zero", which means
even
numbers only.
Interestingly, the super i/o chip on a modern PC that provides the KBC
and
port 92h functions (among others) OR's the port 60h and port 92h bit
1's
together to provide the gateA20 output. This would explain why when
enabled by one method it can not be disabled by the other.
( 1 OR 0 => 1)
Mike Gonta
look and see - many look but few see
Rod Pemberton
news:4680e27f-80f6-4f5f...@k39g2000yqd.googlegroups.com...
> On Jul 9, 2:09 am, "Rod Pemberton" wrote:
>
> > Ok, I inserted a hex routine. The 233Mhz and 450Mhz report 0x49
initially.
> > If A20 is enabled via keyboard controller on either, they report 0x4B.
> > (PS/2 fastport only on 450Mhz is 0x49, both methods 0x4B.) The 2.8Ghz
> > reports 0x4B always.
>
> I'd check that hex routine!
> Writing a "one" to bit zero of either port 60h or port 92h will cause
> a CPU reset.
Writing a "one" to bit zero of port 92h _should_ reset AIUI when the port is
there... I've not tried this.
But, don't you have port 60h backwards? AIUI 60h bit 0 is inverted, i.e.,
normally high and active low. You write 0xFE (bit 0 = 0) for a reset, yes?
> You will not be able to read a "one", it has to be "zero", which means
> even numbers only.
>
What I'm seeing (0x49/0x4B), matches the info from the section 11.5 of
"Keyboard scancodes" by Andries Brouwer:
"11.5 The output port P2"
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-11.html#ss11.5
0x49 = 0100 1001
keyboard clock (bit 6 = 1)
mouse clock (bit 3 = 1)
normal (bit 0 = 1)
RBIL in PORTS.A, Table P0405 "Bitfields for keyboard controller output
port", says:
"bit 0 (system reset) should always be set when writing the output port, as
the system may hang constantly; use pulse output port (command FEh)
instead."
Rod Pemberton
Mike Gonta
wrote:
> "Mike Gonta" <mikego...@gmail.com> wrote in message
>
> news:4680e27f-80f6-4f5f...@k39g2000yqd.googlegroups.com...
>
> > On Jul 9, 2:09 am, "Rod Pemberton" wrote:
>
> > > Ok, I inserted a hex routine. The 233Mhz and 450Mhz report 0x49
> initially.
> > > If A20 is enabled via keyboard controller on either, they report 0x4B.
> > > (PS/2 fastport only on 450Mhz is 0x49, both methods 0x4B.) The 2.8Ghz
> > > reports 0x4B always.
>
> > I'd check that hex routine!
> > Writing a "one" to bit zero of either port 60h or port 92h will cause
> > a CPU reset.
>
> Writing a "one" to bit zero of port 92h _should_ reset AIUI when the port is
> there... I've not tried this.
>
> But, don't you have port 60h backwards? AIUI 60h bit 0 is inverted, i.e.,
> normally high and active low. You write 0xFE (bit 0 = 0) for a reset, yes?
Correct, my mistake, and I thought you were also referring to a
port 92h read.
The super i/o chip requires port 92h functionality to be initialized
by the BIOS. An uninitialized port 92h write is ignored and a read
is undefined (unlike a non existent i/o port which reads as 0FFh.
James Harris
wrote:
...
> Ok, I inserted a hex routine. The 233Mhz and 450Mhz report 0x49 initially.
> If A20 is enabled via keyboard controller on either, they report 0x4B.
> (PS/2 fastport only on 450Mhz is 0x49, both methods 0x4B.) The 2.8Ghz
> reports 0x4B always.
I've now run similar tests and there is a mixed bag of results. They
are online at
http://aodfaq.wikispaces.com/machine+characteristics#A20%20Controls
Like your machines some of mine showed the effect in the KBC output
port bit (as C8-CA or 49-4B) whereas others did not (49 stayed as 49
on one machine, CF stayed as CF on another). One of mine was like
yours in reflecting the KBC change in the PS/2 fastport.
In developing the code to try different options I've had good results
in that I can reliably switch A20 on and off as needed on the test
machines. Either method works. The BIOS is too hit-and-miss both in
what it does and what it reports. I don't think it's a dependable
option.
Since I never need to turn off A20 (and nor would any sane person!)
I'm thinking to enable it via the KBC and subsequently also enable it
via System Control Port A.
Anyone see a problem with enabling A20 via BOTH mechanisms?
James
Rod Pemberton
> On Jul 10, 1:17 am, "Rod Pemberton" <do_not_h...@notreplytome.cmm>
> wrote:
> > "Mike Gonta" <mikego...@gmail.com> wrote in message
> >
news:4680e27f-80f6-4f5f...@k39g2000yqd.googlegroups.com...
>
> > > On Jul 9, 2:09 am, "Rod Pemberton" wrote:
>
> > > > Ok, I inserted a hex routine. The 233Mhz and 450Mhz report 0x49
> > initially.
> > > > If A20 is enabled via keyboard controller on either, they report
0x4B.
> > > > (PS/2 fastport only on 450Mhz is 0x49, both methods 0x4B.) The
2.8Ghz
> > > > reports 0x4B always.
> >
> > > I'd check that hex routine!
> > > Writing a "one" to bit zero of either port 60h or port 92h will cause
> > > a CPU reset.
> >
> > Writing a "one" to bit zero of port 92h _should_ reset AIUI when the
port is
> > there... I've not tried this.
>
> > But, don't you have port 60h backwards? AIUI 60h bit 0 is inverted,
i.e.,
> > normally high and active low. You write 0xFE (bit 0 = 0) for a reset,
yes?
>
>
> Correct, my mistake, and I thought you were also referring to a
> port 92h read.
Sorry, no, I didn't output the PS/2 port values... Those are just KBD port.
It seems James has both on his webpage. So, I might do so to compare.
Rod Pemberton
Rod Pemberton
> On 9 July, 07:09, "Rod Pemberton" <do_not_h...@notreplytome.cmm>
> wrote:
>
> ...
>
> > Ok, I inserted a hex routine. The 233Mhz and 450Mhz report 0x49
> > initially.
> > If A20 is enabled via keyboard controller on either, they report 0x4B.
> > (PS/2 fastport only on 450Mhz is 0x49, both methods 0x4B.) The 2.8Ghz
> > reports 0x4B always.
>
> I've now run similar tests and there is a mixed bag of results. They
> are online at
>
> http://aodfaq.wikispaces.com/machine+characteristics#A20%20Controls
>
There's no change in the AOpen or EEE KBC bit, but A20 enables? Nice...
Well, it looks like we can check if A20 is enabled by 92h PS/2 fast method
(SCPA), it seems consistent on your and my machines (when present) changing
from 00 to 02. But, checking for A20 enabled via the keyboard controller
output port (KBC), is definately unreliable...
> Like your machines some of mine showed the effect in the KBC output
> port bit (as C8-CA or 49-4B) whereas others did not (49 stayed as 49
> on one machine, CF stayed as CF on another). One of mine was like
> yours in reflecting the KBC change in the PS/2 fastport.
>
Ok, I've listed the machines I've tested in James' format so they can be
compared. (I don't have the BIOS control.) I've added two additional
combinations, and listed Windows console or "dosbox" for kicks:
Machine KBC SCPA
233Mhz Works 49-4B FF-FF Fails 49-49 FF-FF (No PS/2 92h port.)
450Mhz Works 49-4B 00-00 Works 49-49 00-02
MSI Neo-F Works 4B-4B 00-02 Works 4B-4B 00-02
Machine KBC and SCPA
450Mhz Works 49-4B 00-02
MSI Neo-F Works 4B-4B 00-02
FYI, the 2.8Ghz machine (chart above) is MSI Neo-F (here). First, notice FF
for no PS/2 port. I check one of the reserved bits for 0... I.e., if
you're not, it may return false result. As stated originally, the Neo-F KBC
A20 bit is always on. It does not turn off. It's PS/2 bit indicates either
A20 method active. It stays on until both are off.
For Windows "console", my A20 test reports A20 is OFF, but the KBC and SPCA
values are 4B and 02 always, i.e., both ON...
"dosbox" 4B-4B 02-02 (unchangeable)
Rod Pemberton
James Harris
wrote:
> "James Harris" <james.harri...@googlemail.com> wrote in message
...
> > http://aodfaq.wikispaces.com/machine+characteristics#A20%20Controls
>
> There's no change in the AOpen or EEE KBC bit, but A20 enables? Nice...
That's right. There's no change visible in either the KBC or the SCPA
bit. What fun! That's a good point and I've updated the notes to make
it clear.
...
> Ok, I've listed the machines I've tested in James' format so they can be
> compared. (I don't have the BIOS control.) I've added two additional
> combinations, and listed Windows console or "dosbox" for kicks:
>
> Machine KBC SCPA
> 233Mhz Works 49-4B FF-FF Fails 49-49 FF-FF (No PS/2 92h port.)
> 450Mhz Works 49-4B 00-00 Works 49-49 00-02
> MSI Neo-F Works 4B-4B 00-02 Works 4B-4B 00-02
I'd like to add at least the 233MHz machine to the table. If it's
alright with you could you tell me some more info about it? I've
included in the table
* Make of machine or motherboard
* CPU model
* BIOS maker and, if available, BIOS version.
BTW, I noticed that all those I'd added had Intel CPUs. With some
surprise it turns out that I only have one AMD-based machine. It is
the one I use from day-to-day and is not in the test set but I've
added its data to the table for comparison.
I've also added notes on system reset since I noticed that the read
KBC output port bit 0 value is not consistent. (OK only the oldest
machine returns the bit clear but one is enough.)
James
Rod Pemberton
> On 11 July, 01:11, "Rod Pemberton" <do_not_h...@notreplytome.cmm>
> wrote:
> > Ok, I've listed the machines I've tested in James' format so they can be
> > compared. (I don't have the BIOS control.) I've added two additional
> > combinations, and listed Windows console or "dosbox" for kicks:
> >
> > Machine KBC SCPA
> > 233Mhz Works 49-4B FF-FF Fails 49-49 FF-FF (No PS/2 92h port.)
> > 450Mhz Works 49-4B 00-00 Works 49-49 00-02
> > MSI Neo-F Works 4B-4B 00-02 Works 4B-4B 00-02
>
> I'd like to add at least the 233MHz machine to the table. If it's
> alright with you could you tell me some more info about it? I've
> included in the table
>
> * Make of machine or motherboard
Motherboard is an ABIT AB-SM5-A The PC was assembled from components.
> * CPU model
BIOS reports Pentium-MMX at 233Mhz. I'm pretty sure it's an Intel and
233Mhz. I'm hoping to not need to pop the cpu-cooler to confirm... I've
got no idea where my heatsink grease is.
> * BIOS maker and, if available, BIOS version.
Award Modular v4.51PG
> BTW, I noticed that all those I'd added had Intel CPUs. With some
> surprise it turns out that I only have one AMD-based machine.
>
That's the only Intel I've got... Got it used from a friend. Years ago, I
never could justify the premium of Intel over AMD. It was frequently
substantial. I was buying from the "just about obsolete 'bin'". Later on,
the AMD cpu's became highly recommended for gaming. Intel's still cost much
more at my local store. And, while they carry mostly Intel's and a wide
selection, I can't get the specific performance cpu versions for Intels.
E.g., if I lookup online which AMD and Intel cpu is very fast for game XYZ,
I can usually get a specific AMD model (and even stepping), but not for the
Intels. Go figure. So, between cost, performance, and/or availability, I
end up with AMDs...
Rod Pemberton
James Harris
> > alright with you could you tell me some more info about it? I've
> > included in the table
>
> > * Make of machine or motherboard
>
> Motherboard is an ABIT AB-SM5-A The PC was assembled from components.
>
> > * CPU model
>
> BIOS reports Pentium-MMX at 233Mhz. I'm pretty sure it's an Intel and
> 233Mhz. I'm hoping to not need to pop the cpu-cooler to confirm... I've
> got no idea where my heatsink grease is.
You've given me all the details I wanted for the table but if you want
more for yourself you may be able to use software. There's the cpuid
instruction if you can wade through the nonsense that is the processor
signature, be prepared to disambiguate it and even then to accept that
it may still leave you not knowing which CPU you have! (Ambiguity can
remain at least for Intel. AMD may be better organised. It's a while
since I've looked.)
Some free (as in beer) software that I've found helpful in identifying
machine components is Belarc Advisor. There is another one I haven't
used for ages ... in fact I've just found it: cpu-z from cpuid.com.
Both programs are very good.
>
> > * BIOS maker and, if available, BIOS version.
>
> Award Modular v4.51PG
Thanks. With its absence of SCP A it makes a great addition to the
online document.
> > BTW, I noticed that all those I'd added had Intel CPUs. With some
> > surprise it turns out that I only have one AMD-based machine.
>
> That's the only Intel I've got... Got it used from a friend. Years ago, I
> never could justify the premium of Intel over AMD. It was frequently
> substantial. I was buying from the "just about obsolete 'bin'". Later on,
> the AMD cpu's became highly recommended for gaming. Intel's still cost much
> more at my local store. And, while they carry mostly Intel's and a wide
> selection, I can't get the specific performance cpu versions for Intels.
> E.g., if I lookup online which AMD and Intel cpu is very fast for game XYZ,
> I can usually get a specific AMD model (and even stepping), but not for the
> Intels. Go figure. So, between cost, performance, and/or availability, I
> end up with AMDs...
I thought I'd generally favoured AMD in machines I'd built - but then
over the years there's been that Pentium M I'd wanted for a fanless
media PC project, the motherboard I'd found with the many SATA
connectors I'd needed for another project and which happened to
require an Intel CPU, the Atom CPU I'd needed for the small barebones
machine etc. So I've ended up with more Intel than I realised!
James