Please help with dead system

In comp.sys.ibm.pc.hardware.misc Trent <.****off> wrote:
> On Mon, 20 Nov 2006 19:00:57 -0500 Tony Hill <>
> wrote in Message id: <>:

>>On Mon, 20 Nov 2006 07:06:54 -0500, Trent <.****off>
>>wrote:
>>>On Sat, 18 Nov 2006 19:00:43 -0500 Tony Hill <>
>>>wrote in Message id: <>:
>>>>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/bizsupport...Fc00368814.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.

> 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."

>>>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.

> 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

On Tue, 21 Nov 2006 03:18:38 GMT,
a?n?g?e? (The little lost angel) wrote:

>On Mon, 20 Nov 2006 19:00:57 -0500, Tony Hill
><> wrote:
>>??? Uhh, care to point to some "specification" for sig delimiting?!
>>----------------------------
>>Tony Hill
>>hilla <underscore> 20 <at> yahoo <dot> ca
>
>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.
--
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

On Tue, 21 Nov 2006 07:20:47 -0500, Trent <.****off>
wrote:
>On Mon, 20 Nov 2006 19:00:57 -0500 Tony Hill <>
>wrote in Message id: <>:
>>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?

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.

>>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?

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.

>>>>Dell has a similar code for their new Dimensions, where only light 3
>>>>of their diagnostics lights is on:
>>>>
>>>>http://support.dell.com/support/edoc....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.
>
>Gee... I thought we were talking about beep codes.
>
>Oh ohh... some text has mysteriously gone missing here. Allow me to fix
>that:
>
>>>Additionally, that LED code is probably generated by default at
>>>power up. You could pry the chipset off the board with a big old
>>>screwdriver, AND have a fully functioning CPU and get the same result.
>
>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).

>>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.

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...hts/290744.htm
>
>Anyway, I'll just paste the relevant text below, and expound on it a bit.
>I'm helpful like that:
>
>>>"Speaker: The SPKR signal is the output of counter 2 and is internally
>>>“ANDed” with Port 61h bit 1 to provide Speaker Data Enable. This signal
>>>drives an external speaker driver device, which in turn drives the system
>>>speaker. Upon PCIRST#, its output state is 0. NOTE: SPKR is sampled at the
>>>rising edge of PWROK as a functional strap. See Section 2.20.1 for more
>>>details."
>>>
>>>"The counter/timers are programmed in the following fashion:
>>>1. Write a control word to select a counter.
>>>2. Write an initial count for that counter.
>>>3. Load the least and/or most significant bytes (as required by Control Word bits 5, 4) of the
>>>16-bit counter.
>>>4. Repeat with other counters."
>>>
>>>Table 5-13. Counter Operating Modes
>>>Mode Function Description
>>>0 Out signal on end of count (=0) Output is 0. When count goes to 0, output goes to 1 and
>>>stays at 1 until counter is reprogrammed.
>>>1 Hardware retriggerable one-shot Output is 0. When count goes to 0, output goes to 1 for
>>>one clock time.
>>>2 Rate generator (divide by n counter) Output is 1. Output goes to 0 for one clock time, then
>>>back to 1 and counter is reloaded.
>>>3 Square wave output
>>>Output is 1. Output goes to 0 when counter rolls over, and
>>>counter is reloaded. Output goes to 1 when counter rolls
>>>over, and counter is reloaded, etc.
>>>4 Software triggered strobe Output is 1. Output goes to 0 when count expires for one
>>>clock time.
>>>5 Hardware triggered strobe Output is 1. Output goes to 0
>
>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...ex/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.

>>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.

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....1d990701839d94

<quote>
>>>One thing you may try is removing the CPU and see whether you
>>>get beep codes. If you do not, then the mainboard is likely
>>>broken.
>>
>>If the CPU is not present or is not working, then you will not get any
>>beep codes.
>
>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.
<end quote>


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.
--
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

On Wed, 22 Nov 2006 20:57:22 -0500, Tony Hill
<> put finger to keyboard and composed:

>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.

<snip>

>Just in case you forgot what this discussion was all about, here is
>exaclty how it started:
>
>
>http://groups.google.com/group/comp....1d990701839d94
>
><quote>
>>>>One thing you may try is removing the CPU and see whether you
>>>>get beep codes. If you do not, then the mainboard is likely
>>>>broken.
>>>
>>>If the CPU is not present or is not working, then you will not get any
>>>beep codes.
>>
>>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.
><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
--
Please remove one 'i' from my address when replying by email.

On 21 Nov 2006 00:22:55 GMT, Arno Wagner <> put finger
to keyboard and composed:

>In comp.sys.ibm.pc.hardware.misc Tony Hill <> wrote:

>> On Mon, 20 Nov 2006 07:06:54 -0500, Trent <.****off>
>> wrote:

>>>On Sat, 18 Nov 2006 19:00:43 -0500 Tony Hill <>
>>>wrote in Message id: <>:

>> 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).

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
--
Please remove one 'i' from my address when replying by email.

On 21 Nov 2006 13:25:08 GMT Arno Wagner <> wrote in Message
id: <>:

>In comp.sys.ibm.pc.hardware.misc Trent <.****off> wrote:
>> On Mon, 20 Nov 2006 19:00:57 -0500 Tony Hill <>
>> wrote in Message id: <>:
>
>>>On Mon, 20 Nov 2006 07:06:54 -0500, Trent <.****off>
>>>wrote:
>>>>On Sat, 18 Nov 2006 19:00:43 -0500 Tony Hill <>
>>>>wrote in Message id: <>:
>>>>>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/bizsupport...Fc00368814.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.
>
>> 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."
>
>>>>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.
>
>> 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?

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 ****, ****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.

On Fri, 24 Nov 2006 15:32:40 +1100 Franc Zabkar
<> wrote in Message id:
<>:

>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.

On Wed, 22 Nov 2006 20:57:22 -0500 Tony Hill <>
wrote in Message id: <>:

>On Tue, 21 Nov 2006 07:20:47 -0500, Trent <.****off>
>wrote:
>>On Mon, 20 Nov 2006 19:00:57 -0500 Tony Hill <>
>>wrote in Message id: <>:
>>>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?
>
>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.

>>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.

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?

>>>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?
>
>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 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.

Suuuure they do...

>>>>>Dell has a similar code for their new Dimensions, where only light 3
>>>>>of their diagnostics lights is on:
>>>>>
>>>>>http://support.dell.com/support/edoc....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.
>>
>>Gee... I thought we were talking about beep codes.
>>
>>Oh ohh... some text has mysteriously gone missing here. Allow me to fix
>>that:
>>
>>>>Additionally, that LED code is probably generated by default at
>>>>power up. You could pry the chipset off the board with a big old
>>>>screwdriver, AND have a fully functioning CPU and get the same result.
>>
>>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.

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?

>>>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.
>
>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?

>> 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...hts/290744.htm
>>
>>Anyway, I'll just paste the relevant text below, and expound on it a bit.
>>I'm helpful like that:
>>
>>>>"Speaker: The SPKR signal is the output of counter 2 and is internally
>>>>“ANDed” with Port 61h bit 1 to provide Speaker Data Enable. This signal
>>>>drives an external speaker driver device, which in turn drives the system
>>>>speaker. Upon PCIRST#, its output state is 0. NOTE: SPKR is sampled at the
>>>>rising edge of PWROK as a functional strap. See Section 2.20.1 for more
>>>>details."
>>>>
>>>>"The counter/timers are programmed in the following fashion:
>>>>1. Write a control word to select a counter.
>>>>2. Write an initial count for that counter.
>>>>3. Load the least and/or most significant bytes (as required by Control Word bits 5, 4) of the
>>>>16-bit counter.
>>>>4. Repeat with other counters."
>>>>
>>>>Table 5-13. Counter Operating Modes
>>>>Mode Function Description
>>>>0 Out signal on end of count (=0) Output is 0. When count goes to 0, output goes to 1 and
>>>>stays at 1 until counter is reprogrammed.
>>>>1 Hardware retriggerable one-shot Output is 0. When count goes to 0, output goes to 1 for
>>>>one clock time.
>>>>2 Rate generator (divide by n counter) Output is 1. Output goes to 0 for one clock time, then
>>>>back to 1 and counter is reloaded.
>>>>3 Square wave output
>>>>Output is 1. Output goes to 0 when counter rolls over, and
>>>>counter is reloaded. Output goes to 1 when counter rolls
>>>>over, and counter is reloaded, etc.
>>>>4 Software triggered strobe Output is 1. Output goes to 0 when count expires for one
>>>>clock time.
>>>>5 Hardware triggered strobe Output is 1. Output goes to 0
>>
>>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!

Show me a reference design that does this.

>>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...ex/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.

i848:
http://www.intel.com/design/chipsets...s/25366102.pdf

It's the latest one publicly available that I could find. Same ****ing
deal.

>>>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.
>
>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....1d990701839d94

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.

In article <>,
<""> wrote:

> Smell the power supply. If it smells like something is burned,
> probably it is.

That figures <g>