A
Arno Wagner
In comp.sys.ibm.pc.hardware.misc Trent said:
And why would you do that?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
And why would you do that?
F
Franc Zabkar
That is definitely false. I have pretty extensive experience on HP's
Business Desktop line, and every one of them will give you a beep code
(3 beeps) if there is no processor installed in the system. See page
A-13 from the following document:
http://h20000.www2.hp.com/bizsuppor...support/SupportManual/c00368814/c00368814.pdf
I've been looking at some hardware monitoring chips (eg Winbond's
W83697HF). Its datasheet states that it provides an "Automatic Power
On voltage detection Beep". It does this via a dedicated BEEP pin, not
via the system timer. I presume that this BEEP signal would be ORed
(or XORed) with the timer output from the chipset.
The W83697HF also has several watchdog timers which can trigger the
beeper when temperatures, fan speeds, and voltages fall outside their
allowable ranges, but these all require programming.
As was initially suggested, I concede that the keyboard MCU *could*
operate as a watch dog timer and beep the speaker. All you would need
would be an additional gate, and one of the MCU's many spare I/O pins
on ports 1 and 2. Whether any motherboard design does this remains to
be shown.
- Franc Zabkar
T
Tony Hill
I'd be curious to see a schematic of this motherboard, most likely it's a
simple watch dog timer which is triggered after a certain period of bus
inactivity. These are not the beep codes as referenced by the BIOS
manufacturers.
Uhh.. if they aren't "beep codes" than what the heck do you call it
when the system gives a beep in a specific sequence? I don't have the
wiring diagram for how it works, but for all practical purposes it IS
a POST beep code.
In any case, the OP in this thread's system is not an HP desktop it is a
homebuilt, and will not output POST beep codes if no CPU is present.
And why not?! There's nothing magical about HP's systems. Ok, the
link listed above uses the custom HP BIOS, but other HP systems using
Award BIOSes also give the same beep codes. I know some current Asus
boards can also detect that a CPU is not detected and play a voice
message saying as much.
Irrelevant to the discussion, as there are no "beep codes" for a missing
CPU chip.
If you can wire up LEDs than you can wire up a speaker.
Note that these codes are NOT generated by any "8254 timer chip" as
such chips haven't existed on motherboards for 10+ years now. The
functionality of the 8254 timer chip has been incorporated into the
motherboard chipset, typically in the I/O controller or southbridge.
[rolls eyes]
In other words, it is generated from an 8254.
No, it's generated from a chipset that probably COMPLETELY ignores
this part of the 8254 spec from the old AT and implements something
totally unrelated.
Whether or not it's buried
deep within the chipset matters not. There is still a device which behaves
and acts exactly like an 8254 - three programmable timers with numerous
modes of operation, and each MUST be programmed by the CPU before it will
do anything at all.
Holy crap this is a modern chipset! You don't need to do everything
*EXACTLY* the same way that it was done in the original XT or AT! As
long as what you do is COMPATIBLE with the original and doesn't break
software, it'll work.
Just because the latest Intel Core 2 Duo chips support the same
instruction set as the 8086, that doesn't mean that they haven't
expanded on that with addition features. Same goes with the
functionality in modern chipsets.
I've yet to see a design where the keyboard controller can write data to
the speaker.
I'm not aware of any either, the keyboard controller seemed like a bit
of an odd comment from another poster. The only connection I'm aware
of between the POST error beeps and the keyboard controller is that
some BIOSes will blink the LEDs on a keyboard to signify certain error
codes.
Yet still there is a 100% software compatible 8254 device deep within. I
never stated there was a discrete 24 pin DIP device for the function.
100% software compatible does *NOT* mean that it must ONLY be used in
100% the same way.
You sig delimiter is improperly constructed.
??? Uhh, care to point to some "specification" for sig delimiting?!
A
Arno Wagner
Uhh.. if they aren't "beep codes" than what the heck do you call it
when the system gives a beep in a specific sequence? I don't have the
wiring diagram for how it works, but for all practical purposes it IS
a POST beep code.
And why not?! There's nothing magical about HP's systems. Ok, the
link listed above uses the custom HP BIOS, but other HP systems using
Award BIOSes also give the same beep codes. I know some current Asus
boards can also detect that a CPU is not detected and play a voice
message saying as much.
If you can wire up LEDs than you can wire up a speaker.Note that these codes are NOT generated by any "8254 timer chip" as
such chips haven't existed on motherboards for 10+ years now. The
functionality of the 8254 timer chip has been incorporated into the
motherboard chipset, typically in the I/O controller or southbridge.
[rolls eyes]
In other words, it is generated from an 8254.
No, it's generated from a chipset that probably COMPLETELY ignores
this part of the 8254 spec from the old AT and implements something
totally unrelated.
Holy crap this is a modern chipset! You don't need to do everything
*EXACTLY* the same way that it was done in the original XT or AT! As
long as what you do is COMPATIBLE with the original and doesn't break
software, it'll work.
And since this part is done before the BIOS code executes, you
can do anything you like and still be compatible!
Just because the latest Intel Core 2 Duo chips support the same
instruction set as the 8086, that doesn't mean that they haven't
expanded on that with addition features. Same goes with the
functionality in modern chipsets.
I'm not aware of any either, the keyboard controller seemed like a bit
of an odd comment from another poster. The only connection I'm aware
of between the POST error beeps and the keyboard controller is that
some BIOSes will blink the LEDs on a keyboard to signify certain error
codes.
Ah, no. The keyboard controller is the prime suspect, because it is
a small computer of its own on the mainboard. The only ''intelligence''
besides the main CPU, so it would be easy to have the "CPU missing"
detection in its software (which is in a ROM contained within the chip
or in the ASIC today).
The MCU inside the keyboard is actually still another controller.
The keyboard controller sits on the mainboard.
100% software compatible does *NOT* mean that it must ONLY be used in
100% the same way.
All too true...
Arno
T
The little lost angel
??? Uhh, care to point to some "specification" for sig delimiting?!
RFC 2646 (on format=flowed etc) includes:
4.3. Usenet Signature Convention
There is a convention in Usenet news of using "-- " as the
separator
line between the body and the signature of a message. When
generating a Format=Flowed message containing a Usenet-style
separator before the signature, the separator line is sent as-is.
This is a special case; an (optionally quoted) line consisting of
DASH DASH SP is not considered flowed.
Sorry! =X
T
Trent
Uhh.. if they aren't "beep codes" than what the heck do you call it
when the system gives a beep in a specific sequence? I don't have the
wiring diagram for how it works, but for all practical purposes it IS
a POST beep code.
What part of "These are not the beep codes as referenced by the BIOS
manufacturers." flew over your head at mach 1?
In addition, it is not a true POST code. You DO know what a POST code is,
don't you? Concentrate on the "ST" part of "POST."
And why not?! There's nothing magical about HP's systems. Ok, the
link listed above uses the custom HP BIOS, but other HP systems using
Award BIOSes also give the same beep codes. I know some current Asus
boards can also detect that a CPU is not detected and play a voice
message saying as much.
Why don't you point out on any BIOS manufacturers support web page where
there is a beep code for a missing CPU?
Do you honestly think that a traditional POST beep code can be generated
when no CPU is present and no code can be executed?
If you can wire up LEDs than you can wire up a speaker.
Gee... I thought we were talking about beep codes.
Oh ohh... some text has mysteriously gone missing here. Allow me to fix
that:
No comment here? ****, I could perform the same feat of *MAGIC!* with a 4
bit latch and a few resistors. I'll guarantee that this is merely a 4 bit
WO register that comes up after a power on in a known state - bit 0,1, and
3 off, bit 2 on. You could remove everything on the motherboard except
whatever device has this register and the LEDs, and you'd get the same
result. About as useful as a "check engine" light in a car for figuring
out what the fault is.
Note that these codes are NOT generated by any "8254 timer chip" as
such chips haven't existed on motherboards for 10+ years now. The
functionality of the 8254 timer chip has been incorporated into the
motherboard chipset, typically in the I/O controller or southbridge.
[rolls eyes]
In other words, it is generated from an 8254.
No, it's generated from a chipset that probably COMPLETELY ignores
this part of the 8254 spec from the old AT and implements something
totally unrelated.
Utter horseshit. It is a fully programmable 8254. I noticed you didn't
bother to refute my other reply to you with regards to the 82801DB ICH4.
I urge you to download a datasheet, and edumacate yourself:
http://www.intel.com/design/chipsets/datashts/290744.htm
Anyway, I'll just paste the relevant text below, and expound on it a bit.
I'm helpful like that:
Whoah! That looks identical to the 8254 referenced in my 1989 Intel
Microprocessor and Peripheral Handbook vol. II beginning on pg. 6-25!
Jeez... right down to all the same modes of operation. But I guess it's
really NOT an 8254, eh?
BTW, did you know that the 8259 and 8237 devices are still alive and well
too?
*wink*
Further, Looking an old dual Pentium 2 reference design schematic from
Intel http://www.intel.com/design/chipsets/designex/gxdgsch.pdf
I see the 82371EB device that drives the speaker through a 2N3904
transistor. If you like, drag up the .pdf for the chipset and see for
yourself on pages 18 and 32.
Holy crap this is a modern chipset! You don't need to do everything
*EXACTLY* the same way that it was done in the original XT or AT! As
long as what you do is COMPATIBLE with the original and doesn't break
software, it'll work.
What's your point? It's a fully programmable 8254 With NO ADDITIONAL
FEATURES.
Just because the latest Intel Core 2 Duo chips support the same
instruction set as the 8086, that doesn't mean that they haven't
expanded on that with addition features. Same goes with the
functionality in modern chipsets.
8254 8254 8254... There are NO additional features with regards to the
small bit of silicon buried in the chipset that houses the 8254.
I'm not aware of any either, the keyboard controller seemed like a bit
of an odd comment from another poster. The only connection I'm aware
of between the POST error beeps and the keyboard controller is that
some BIOSes will blink the LEDs on a keyboard to signify certain error
codes.
100% software compatible does *NOT* mean that it must ONLY be used in
100% the same way.
It is a 100% compatible 8254 with NO additional function whatsoever. Look
at the datasheet above and get back to me.
??? Uhh, care to point to some "specification" for sig delimiting?!
I see that someone posted the relevant information. The reason this is
done is that when someone replies to you, a proper newsreader will
automatically snip out the .sig.
T
Trent
And why would you do that?
You're right. Save your apology for the bitch that whelped you.
T
Trent
Uhh.. if they aren't "beep codes" than what the heck do you call it
when the system gives a beep in a specific sequence? I don't have the
wiring diagram for how it works, but for all practical purposes it IS
a POST beep code.And why not?! There's nothing magical about HP's systems. Ok, the
link listed above uses the custom HP BIOS, but other HP systems using
Award BIOSes also give the same beep codes. I know some current Asus
boards can also detect that a CPU is not detected and play a voice
message saying as much.If you can wire up LEDs than you can wire up a speaker.Note that these codes are NOT generated by any "8254 timer chip" as
such chips haven't existed on motherboards for 10+ years now. The
functionality of the 8254 timer chip has been incorporated into the
motherboard chipset, typically in the I/O controller or southbridge.
[rolls eyes]
In other words, it is generated from an 8254.No, it's generated from a chipset that probably COMPLETELY ignores
this part of the 8254 spec from the old AT and implements something
totally unrelated.Holy crap this is a modern chipset! You don't need to do everything
*EXACTLY* the same way that it was done in the original XT or AT! As
long as what you do is COMPATIBLE with the original and doesn't break
software, it'll work.
And since this part is done before the BIOS code executes, you
can do anything you like and still be compatible!
If your brains were dynamite you wouldn't have enough to blow your toupee
off.
Ah, no. The keyboard controller is the prime suspect, because it is
a small computer of its own on the mainboard. The only ''intelligence''
besides the main CPU, so it would be easy to have the "CPU missing"
detection in its software (which is in a ROM contained within the chip
or in the ASIC today).
The MCU inside the keyboard is actually still another controller.
The keyboard controller sits on the mainboard.
All too true...
Arno
You know so little, why do you work so hard to prove it?
A
Arno Wagner
In comp.sys.ibm.pc.hardware.misc Trent said:
You're right. Save your apology for the bitch that whelped you.
Well, is seems your manners are nonexistent to begin with.
So no need to apologize in any case.
Arno
A
Arno Wagner
In comp.sys.ibm.pc.hardware.misc Trent said:id: <[email protected]>:In comp.sys.ibm.pc.hardware.misc Tony Hill said:<[email protected]>:
That is definitely false. I have pretty extensive experience on HP's
Business Desktop line, and every one of them will give you a beep code
(3 beeps) if there is no processor installed in the system. See page
A-13 from the following document:
http://h20000.www2.hp.com/bizsuppor...support/SupportManual/c00368814/c00368814.pdf
I'd be curious to see a schematic of this motherboard, most likely it's a
simple watch dog timer which is triggered after a certain period of bus
inactivity. These are not the beep codes as referenced by the BIOS
manufacturers.Uhh.. if they aren't "beep codes" than what the heck do you call it
when the system gives a beep in a specific sequence? I don't have the
wiring diagram for how it works, but for all practical purposes it IS
a POST beep code.In any case, the OP in this thread's system is not an HP desktop it is a
homebuilt, and will not output POST beep codes if no CPU is present.And why not?! There's nothing magical about HP's systems. Ok, the
link listed above uses the custom HP BIOS, but other HP systems using
Award BIOSes also give the same beep codes. I know some current Asus
boards can also detect that a CPU is not detected and play a voice
message saying as much.Dell has a similar code for their new Dimensions, where only light 3
of their diagnostics lights is on:
http://support.dell.com/support/edocs/systems/dimC521/en/SM_EN/tshoot.htm#wp1064555
Irrelevant to the discussion, as there are no "beep codes" for a missing
CPU chip.If you can wire up LEDs than you can wire up a speaker.Note that these codes are NOT generated by any "8254 timer chip" as
such chips haven't existed on motherboards for 10+ years now. The
functionality of the 8254 timer chip has been incorporated into the
motherboard chipset, typically in the I/O controller or southbridge.
[rolls eyes]
In other words, it is generated from an 8254.No, it's generated from a chipset that probably COMPLETELY ignores
this part of the 8254 spec from the old AT and implements something
totally unrelated.Whether or not it's buried
deep within the chipset matters not. There is still a device which behaves
and acts exactly like an 8254 - three programmable timers with numerous
modes of operation, and each MUST be programmed by the CPU before it will
do anything at all.Holy crap this is a modern chipset! You don't need to do everything
*EXACTLY* the same way that it was done in the original XT or AT! As
long as what you do is COMPATIBLE with the original and doesn't break
software, it'll work.
And since this part is done before the BIOS code executes, you
can do anything you like and still be compatible!
If your brains were dynamite you wouldn't have enough to blow your toupee
off.
Having emotional problems?
Arno
A
Arno Wagner
In comp.sys.ibm.pc.hardware.misc Trent said:
What part of "These are not the beep codes as referenced by the BIOS
manufacturers." flew over your head at mach 1?
In addition, it is not a true POST code. You DO know what a POST code is,
don't you? Concentrate on the "ST" part of "POST."
Why don't you point out on any BIOS manufacturers support web page where
there is a beep code for a missing CPU?
Do you honestly think that a traditional POST beep code can be generated
when no CPU is present and no code can be executed?
You don't get it, do you? The 8042 has its own firmware and it is
not part of the system BIOS....
Arno
T
Tony Hill
RFC 2646 (on format=flowed etc) includes:
4.3. Usenet Signature Convention
There is a convention in Usenet news of using "-- " as the
separator
line between the body and the signature of a message. When
generating a Format=Flowed message containing a Usenet-style
separator before the signature, the separator line is sent as-is.
This is a special case; an (optionally quoted) line consisting of
DASH DASH SP is not considered flowed.
Sorry! =X
Hehe, no problem L'Angle. I stand corrected, this does indeed seem to
standard covering sig delimiting, I stand corrected.
Should be fixed now.
T
Tony Hill
What part of "These are not the beep codes as referenced by the BIOS
manufacturers." flew over your head at mach 1?
Right, and you've got the latest specification that BIOS manufacturers
provide to all of their OEMs?
In addition, it is not a true POST code. You DO know what a POST code is,
don't you? Concentrate on the "ST" part of "POST."
This is a test that the computer runs on itself on power up. I fail
to see how this is not a Power On Self Test.
Why don't you point out on any BIOS manufacturers support web page where
there is a beep code for a missing CPU?
Here are a list of beep codes from a variety of BIOS manufacturers.
http://www.pcsympathy.com/bios_beep_codes.html
Note that they will ALL beep on some form of CPU failure. HOW they do
this is purely academic.
Do you honestly think that a traditional POST beep code can be generated
when no CPU is present and no code can be executed?
Do I honestly care about a "traditional POST" beep code? I'm talking
about the REAL WORLD of today! I don't care what the IBM XT or AT
did, because they haven't existed for ages!
The fact of the matter is that MANY systems will give some form of
beep, LEDs or voice command if a CPU is missing during their power up
self-test.
Gee... I thought we were talking about beep codes.
Oh ohh... some text has mysteriously gone missing here. Allow me to fix
that:
No comment here? ****, I could perform the same feat of *MAGIC!* with a 4
bit latch and a few resistors. I'll guarantee that this is merely a 4 bit
WO register that comes up after a power on in a known state - bit 0,1, and
3 off, bit 2 on. You could remove everything on the motherboard except
whatever device has this register and the LEDs, and you'd get the same
result. About as useful as a "check engine" light in a car for figuring
out what the fault is.
I haven't used Dell systems as much, so I can't comment on them.
However your comments are definitely not accurate for HP systems,
which WILL beep if the CPU is missing but will almost never give the
same beep code for anything else. Even if your motherboard is
completely shot you won't get the "no CPU" beep code. The only time
I've ever encountered it is if the CPU was damaged (beeps maybe 25-50%
of the time) or if the CPU really isn't there (beeps pretty much ALL
the time unless there are other major problems with the system, like a
dead power supply).
Utter horseshit. It is a fully programmable 8254.
So? My AthlonXP contains a fully programmable 8086 chip, that doens't
mean that I can't use 32-bit software, SSE, MMX, etc. etc.
Just because the 8254 functionality exists, that doesn't mean it's the
ONLY functionality in the system!
I noticed you didn't
bother to refute my other reply to you with regards to the 82801DB ICH4.
I urge you to download a datasheet, and edumacate yourself:
http://www.intel.com/design/chipsets/datashts/290744.htm
Anyway, I'll just paste the relevant text below, and expound on it a bit.
I'm helpful like that:
Whoah! That looks identical to the 8254 referenced in my 1989 Intel
Microprocessor and Peripheral Handbook vol. II beginning on pg. 6-25!
Jeez... right down to all the same modes of operation. But I guess it's
really NOT an 8254, eh?
<sigh> You really aren't using any imagination here. So my speaker
can be handled the same way as it was 25 years ago, who cares! That
doesn't mean I can't do MORE than what is specified! If no one
bothered to go above and beyond the basics than computers wouldn't
have advanced one bit.
Here's a hint: that output line doesn't need to go DIRECTLY to the
speaker all on it's own, you can wire MORE stuff in there!
BTW, did you know that the 8259 and 8237 devices are still alive and well
too?
Again, buried in a chipset and no requirement that the chipset ONLY
does the original functions of those devices. So long as it's still
compatible, adding on is a good thing!
Further, Looking an old dual Pentium 2 reference design schematic from
Intel http://www.intel.com/design/chipsets/designex/gxdgsch.pdf
I see the 82371EB device that drives the speaker through a 2N3904
transistor. If you like, drag up the .pdf for the chipset and see for
yourself on pages 18 and 32.
No I don't much care to view another 10 year old reference design.
What's your point? It's a fully programmable 8254 With NO ADDITIONAL
FEATURES.
8254 8254 8254... There are NO additional features with regards to the
small bit of silicon buried in the chipset that houses the 8254.
Wow. I'm glad we aren't depending on you to design computer systems,
otherwise we wouldn't have moved beyond the AT.
It's a simple fact that computers DO detect if a CPU is present or
not. High-end servers and workstations computers do very advanced
diagostics on the CPU, going WAY beyond the capabilities of the
original IBM AT POST test. Desktops tend to stick to a fairly simple
"is there a CPU there?" test and give some sort of failure code if
not.
How the various systems accomplish this is of little importance. The
fact is that they ARE doing this.
Just in case you forgot what this discussion was all about, here is
exaclty how it started:
http://groups.google.com/group/comp...thor:tony+author:hill&rnum=1#e31d990701839d94
<end quote>That depends entirely on the system and how the CPU failed. Some
systems will beep if they do not detect a CPU, others will not. Of
those that will beep if a CPU is not detected, they *might* beep if
the CPU has failed or they might not. Beep codes are (usually)
handled entirely by the motherboard with no CPU intervention.
Now, I've already provided you with MANY examples of systems that WILL
produce beeps, LEDs or even a voice response if the CPU is not being
detected, so really the proof is in the pudding.
F
Franc Zabkar
Do I honestly care about a "traditional POST" beep code? I'm talking
about the REAL WORLD of today! I don't care what the IBM XT or AT
did, because they haven't existed for ages!
The fact of the matter is that MANY systems will give some form of
beep, LEDs or voice command if a CPU is missing during their power up
self-test.
Just in case you forgot what this discussion was all about, here is
exaclty how it started:
http://groups.google.com/group/comp...thor:tony+author:hill&rnum=1#e31d990701839d94
<end quote>
And there's the problem. If you had intended to mean that BIOS beep
codes do not require a CPU, then that is clearly absurd. If OTOH you
had intended to mean that certain low-level "pre-POST" checks could
produce a beep in the absence of a CPU, then this is clearly an
exception to the norm. Words such as "many" and "usual" are
inappropriate, to say the least. Instead the OP should proceed on the
more reasonable assumption that the motherboard will be inactive
without a CPU. I'd hate to think that he could end up tossing a board
simply because it was one of those 99.9% that needed a brain in order
to beep, blink, or talk.
Now, I've already provided you with MANY examples of systems that WILL
produce beeps, LEDs or even a voice response if the CPU is not being
detected, so really the proof is in the pudding.
You've provided *one* example ... maybe.
As for those motherboards that can talk, I confess I have no
experience with these. However, I found the manual for an Albatron Via
motherboard which has a Voice Genie chip. I notice that the voice chip
can be enabled or disabled via the BIOS setup. This suggests to me
that the status of the chip would need to be fetched from CMOS RAM (or
perhaps the flash BIOS) at power-on. Only a working CPU (and BIOS
code) could do this. The only other [unlikely] alternative would be a
user configurable area within the voice chip itself.
As for the blinking LEDs, I've suggested on two occasions that they
could be attached to a standard diagnostic port at 80h (such as is
used by POST cards). I've even provided a simple DOS method to confirm
or disprove this.
- Franc Zabkar
F
Franc Zabkar
Ah, no. The keyboard controller is the prime suspect, because it is
a small computer of its own on the mainboard. The only ''intelligence''
besides the main CPU, so it would be easy to have the "CPU missing"
detection in its software (which is in a ROM contained within the chip
or in the ASIC today).
Yes, it would be easy, but you haven't produced a single example of
where this is actually done. And that's what counts. Until you can
produce one real world example, your idea remains just an idea.
The MCU inside the keyboard is actually still another controller.
The keyboard controller sits on the mainboard.
In your original post you stated that "the beep codes are produced by
the keyboard MCU and that will beep a 'CPU not present' if it is not
contacted by the CPU after a certain time".
After pondering this statement, it occurs to me that it cannot
possibly be correct. If the keyboard MCU "is not contacted by the CPU
after a certain time", then it has no way of distinguishing between
any of several possible causes including "CPU not present", "CPU
dead", "BIOS chip missing/corrupt", or "bad flash".
- Franc Zabkar
T
Trent
You don't get it, do you?
You really are a complete ****ing imbecile, aren't you?
The 8042 has its own firmware and it is
not part of the system BIOS....
No shit, ****o, I never said it was to begin with. Christ, you're a thick
one.
Your original statement: "The beep codes are produced by the keyboard
MCU and that will beep a "CPU not present" if it is not contacted by the
CPU after a certain time." is false.
The beep codes are NOT produced by the keyboard in ANY design I've ever
seen. And I've seen a lot of them, and debugged them to the component
level on our own designs. Unless you can show me a reference design
schematic where the keyboard controller has this function, or a BIOS
manufacturer's web site that shows a beep code for a missing CPU, go back
to flapping your recessed jaw in that thread about capacitors - a subject
where your knowledge is only somewhat below par.
T
Trent
In your original post you stated that "the beep codes are produced by
the keyboard MCU and that will beep a 'CPU not present' if it is not=20
contacted by the CPU after a certain time".
After pondering this statement, it occurs to me that it cannot
possibly be correct. If the keyboard MCU "is not contacted by the CPU
after a certain time", then it has no way of distinguishing between
any of several possible causes including "CPU not present", "CPU
dead", "BIOS chip missing/corrupt", or "bad flash".
Or, as I said to Tony, you could pry every other chip off the motherboard
and get the same result. IOW, completely meaningless.
T
Trent
Right, and you've got the latest specification that BIOS manufacturers
provide to all of their OEMs?
We ARE an OEM. We manufacture and integrate embedded x86 boards. We also
integrate numerous off the shelf PICMG, ATX, 5", 3.5" designs as well.
None will beep when the CPU is missing.
This is a test that the computer runs on itself on power up. I fail
to see how this is not a Power On Self Test.
This is not a test of anything! It's an idiot light. That beeping you
reference could be the result of ANY of the follow conditions:
1. Someone pried the MCH off the motherboard with a large screwdriver.
(Probably Arno Wagner, in a botched repair attempt to replace a
capacitor.)
2. All the FETs in the Core regulator have blown gates.
3. Inexplicably, every passive component is missing from the board.
4. Someone passed the entire motherboard through a band saw in a fit of
rage, removing a third of the board. (After botched repair attempt. See
item 1)
Do you get the picture, or should I break out the crayons and make some
pretty diagrams instead?
Here are a list of beep codes from a variety of BIOS manufacturers.
http://www.pcsympathy.com/bios_beep_codes.html
Note that they will ALL beep on some form of CPU failure. HOW they do
this is purely academic.
Not that I am admitting that the above site has correct information, but I
don't see one for a missing CPU.
Do I honestly care about a "traditional POST" beep code? I'm talking
about the REAL WORLD of today! I don't care what the IBM XT or AT
did, because they haven't existed for ages!
The fact of the matter is that MANY systems will give some form of
beep, LEDs or voice command if a CPU is missing during their power up
self-test.
Suuuure they do...
I haven't used Dell systems as much, so I can't comment on them.
However your comments are definitely not accurate for HP systems,
which WILL beep if the CPU is missing but will almost never give the
same beep code for anything else.
Go ahead - pry off the MCH.
Even if your motherboard is
completely shot you won't get the "no CPU" beep code.
De-solder and lift the pins of all the gates on the FETs driving the core.
The only time
I've ever encountered it is if the CPU was damaged (beeps maybe 25-50%
of the time) or if the CPU really isn't there (beeps pretty much ALL
the time unless there are other major problems with the system, like a
dead power supply).
Got a band saw?
So? My AthlonXP contains a fully programmable 8086 chip, that doens't
mean that I can't use 32-bit software, SSE, MMX, etc. etc.
What's your point?
Just because the 8254 functionality exists, that doesn't mean it's the
ONLY functionality in the system!
I never said it was. Is English your third language?
<sigh> You really aren't using any imagination here. So my speaker
can be handled the same way as it was 25 years ago, who cares! That
doesn't mean I can't do MORE than what is specified! If no one
bothered to go above and beyond the basics than computers wouldn't
have advanced one bit.
Here's a hint: that output line doesn't need to go DIRECTLY to the
speaker all on it's own, you can wire MORE stuff in there!
Show me a reference design that does this.
Again, buried in a chipset and no requirement that the chipset ONLY
does the original functions of those devices. So long as it's still
compatible, adding on is a good thing!
No I don't much care to view another 10 year old reference design.
i848:
http://www.intel.com/design/chipsets/schematics/25366102.pdf
It's the latest one publicly available that I could find. Same ****ing
deal.
Wow. I'm glad we aren't depending on you to design computer systems,
otherwise we wouldn't have moved beyond the AT.
Show me the additional features supported by the small bit of silicon
buried in the chipset that functions as the 8254. There are none.
It's a simple fact that computers DO detect if a CPU is present or
not.
Idiot light. Could be anything.
High-end servers and workstations computers do very advanced
diagostics on the CPU, going WAY beyond the capabilities of the
original IBM AT POST test.
How the **** are you going to do diagnostics on a CPU that does not exist?
Keep in mind we're talking about off the shelf boards here.
Desktops tend to stick to a fairly simple
"is there a CPU there?" test and give some sort of failure code if
not.
Could mean anything. IOW, entirely meaningless.
How the various systems accomplish this is of little importance. The
fact is that they ARE doing this.
You've shown exactly one (an HP freak of nature) that allegedly does this.
The original poster stated his was home built.
None of the CPU boards we have in house can do this (more than 50
DIFFERENT types, some old some new), nor can any of the embedded designs
we've made.
Just in case you forgot what this discussion was all about, here is
exaclty how it started:
http://groups.google.com/group/comp...thor:tony+author:hill&rnum=1#e31d990701839d94
Yep. You stated "Beep codes are (usually) handled entirely by the
motherboard with no CPU intervention. "
^^^^^^^^^^^^^^^^^^^
Which is complete bullshit. The only one eating it up is that
mouth-breathing moron Arno.
M
Mark Conrad
Smell the power supply. If it smells like something is burned,
probably it is.
That figures <g>