Please help with dead system

On 18 Nov 2006 21:19:53 GMT, Arno Wagner <me.TakeThisOut@privacy.net> put finger
to keyboard and composed:

>In comp.sys.ibm.pc.hardware.misc Franc Zabkar <fzabkar.TakeThisOut@iinternode.on.net> wrote:
>> On 18 Nov 2006 02:38:27 GMT, Arno Wagner <me.TakeThisOut@privacy.net> put finger
>> to keyboard and composed:
>
>>>In comp.sys.ibm.pc.hardware.misc Franc Zabkar <fzabkar.TakeThisOut@iinternode.on.net> wrote:
>>>> On 17 Nov 2006 23:54:02 GMT, Arno Wagner <me.TakeThisOut@privacy.net> put finger
>>>> to keyboard and composed:
>>>
>>>>>In comp.sys.ibm.pc.hardware.misc Trent <none.TakeThisOut@dev.nul.pissoff> wrote:
>>>>>> On 16 Nov 2006 15:02:04 GMT Arno Wagner <me.TakeThisOut@privacy.net> wrote in Message
>>>>>> id: <4s3crcFthuckU1.TakeThisOut@mid.individual.net>:
>>>>>
>>>>>>>That is wrong. 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.
>>>>>
>>>>>> Proof please. The beep codes are generated from the 8254 timer chip, which
>>>>>> must be programmed by the processor. If the processor is missing or cannot
>>>>>> do code/data fetches from the BIOS ROM, there are *no* post codes. Period.
>>>>>
>>>>>Since your information is wrong, I don't feel I have to proof
>>>>>anything.
>>>
>>>> Yes, you do.
>>>
>>>>>But please remain unenlightened, if you want.
>>>>>
>>>>>Otherwise have a look at the schematics again. Should be at least PC-AT,
>>>>>since I think the original PC and XT actually could not do this AFAIK.
>>>>>
>>>>>Arno
>>>
>>>> I have the original IBM PC/AT Technical Reference Manual.
>>>
>>>> Here are scans of the relevant circuits:
>>>> http://www.users.on.net/~fzabkar/PC-AT/
>>>
>>>> Note that the speaker is driven by an 8254 timer gated with speaker
>>>> data from "Port B", ie I/O port 61h.
>>>
>>>> There is no connection between the 8042 keyboard controller and the
>>>> speaker.
>>>
>>>Ok, so you did actually look. In my PC-AT schematics, I/O D1 from
>>>the 8042 (U126) is connected to the Speaker via U127 (ALS175,
>>>a quad D-Flip flop) and mixed together with the output of the 8254
>>>(U103) in U92. Yes, ordinarily the AND-gate acts as a gate. But it
>>>can be used as mixer as well, if the signal from the 8254 is "1".
>>>
>>>Arno
>
>> Look again. I/O D1 from the 8042 is connected to a shared data bus.
>> This data bus is controlled by the host CPU, not the 8042.
>
>No. This is a Tri-State bus and (given the right arbitration)
>every device can write to it.

Every device *may* be able to write to the bus and in so doing
exchange data with the host CPU, but not every device can write to
every *other* device.

>> In any case
>> the clock for U127 is "-PortB WR" which is also generated by the host
>> CPU via an Out instruction to port 61h. The 8042 has *no way* of
>> clocking data through U127.
>
>You have no way of knowing this. The 8042 may be able to write to 61h.

The 8042 *does not* control the data bus. In fact there are 14 pages
which describe in detail what the keyboard controller actually does.
These pages also contain an additional simplified functional diagram.

>Don't forget that this is the I/O bus, not the normal CPU memory
>bus.

The I/O bus is derived from the host CPU's data bus. The "-PortB WR"
clock signal is derived from the CPU's M/IO* pin. See pages 1,2,15,
and 18 of your own copy of the schematics.

>However, given that some data is missing, e.g. the PROM data,
>I don't know.
>
>> Page 1-30 of the manual states:
>
>> =====================================================================
>> The system unit has a 2-1/4 inch permanent-magnet speaker which can be
>> drive from:
>
>> . The I/O-port output bit
>> . The timer/counter's clock out
>> . Both
>> =====================================================================
>
>> Page 1-10 has a simplified circuit diagram which may be easier for you
>> to understand:
>> http://www.users.on.net/~fzabkar/PC-AT/TimerCounter.jpg
>
>Sorry, don't need that and please can your arrogance.

Pot kettle black.

"Since your information is wrong, I don't feel I have to proof
anything. But please remain unenlightened, if you want."

>Arno

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.
 >> Stay informed about: Please help with dead system 

In comp.sys.ibm.pc.hardware.misc Franc Zabkar <fzabkar.TakeThisOut@iinternode.on.net> wrote:
> On 18 Nov 2006 21:19:53 GMT, Arno Wagner <me.TakeThisOut@privacy.net> put finger
> to keyboard and composed:

>>In comp.sys.ibm.pc.hardware.misc Franc Zabkar <fzabkar.TakeThisOut@iinternode.on.net> wrote:
>>> On 18 Nov 2006 02:38:27 GMT, Arno Wagner <me.TakeThisOut@privacy.net> put finger
>>> to keyboard and composed:
>>
>>>>In comp.sys.ibm.pc.hardware.misc Franc Zabkar <fzabkar.TakeThisOut@iinternode.on.net> wrote:
>>>>> On 17 Nov 2006 23:54:02 GMT, Arno Wagner <me.TakeThisOut@privacy.net> put finger
>>>>> to keyboard and composed:
>>>>
>>>>>>In comp.sys.ibm.pc.hardware.misc Trent <none.TakeThisOut@dev.nul.pissoff> wrote:
>>>>>>> On 16 Nov 2006 15:02:04 GMT Arno Wagner <me.TakeThisOut@privacy.net> wrote in Message
>>>>>>> id: <4s3crcFthuckU1.TakeThisOut@mid.individual.net>:
>>>>>>
>>>>>>>>That is wrong. 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.
>>>>>>
>>>>>>> Proof please. The beep codes are generated from the 8254 timer chip, which
>>>>>>> must be programmed by the processor. If the processor is missing or cannot
>>>>>>> do code/data fetches from the BIOS ROM, there are *no* post codes. Period.
>>>>>>
>>>>>>Since your information is wrong, I don't feel I have to proof
>>>>>>anything.
>>>>
>>>>> Yes, you do.
>>>>
>>>>>>But please remain unenlightened, if you want.
>>>>>>
>>>>>>Otherwise have a look at the schematics again. Should be at least PC-AT,
>>>>>>since I think the original PC and XT actually could not do this AFAIK.
>>>>>>
>>>>>>Arno
>>>>
>>>>> I have the original IBM PC/AT Technical Reference Manual.
>>>>
>>>>> Here are scans of the relevant circuits:
>>>>> http://www.users.on.net/~fzabkar/PC-AT/
>>>>
>>>>> Note that the speaker is driven by an 8254 timer gated with speaker
>>>>> data from "Port B", ie I/O port 61h.
>>>>
>>>>> There is no connection between the 8042 keyboard controller and the
>>>>> speaker.
>>>>
>>>>Ok, so you did actually look. In my PC-AT schematics, I/O D1 from
>>>>the 8042 (U126) is connected to the Speaker via U127 (ALS175,
>>>>a quad D-Flip flop) and mixed together with the output of the 8254
>>>>(U103) in U92. Yes, ordinarily the AND-gate acts as a gate. But it
>>>>can be used as mixer as well, if the signal from the 8254 is "1".
>>>>
>>>>Arno
>>
>>> Look again. I/O D1 from the 8042 is connected to a shared data bus.
>>> This data bus is controlled by the host CPU, not the 8042.
>>
>>No. This is a Tri-State bus and (given the right arbitration)
>>every device can write to it.

> Every device *may* be able to write to the bus and in so doing
> exchange data with the host CPU, but not every device can write to
> every *other* device.

Yes, and actually most cannot, since the address lines and
handshaking lines are pure inputs. For the 8042 this is not true.
It has general purpose I/O and just pretends to be a
memory-mapped I/O device.

>>> In any case
>>> the clock for U127 is "-PortB WR" which is also generated by the host
>>> CPU via an Out instruction to port 61h. The 8042 has *no way* of
>>> clocking data through U127.
>>
>>You have no way of knowing this. The 8042 may be able to write to 61h.

> The 8042 *does not* control the data bus. In fact there are 14 pages
> which describe in detail what the keyboard controller actually does.
> These pages also contain an additional simplified functional diagram.

The 8042 can do a lot of things not in the normal operation description.
For example, it can control any signal deliverd to it.

>>Don't forget that this is the I/O bus, not the normal CPU memory
>>bus.

> The I/O bus is derived from the host CPU's data bus. The "-PortB WR"
> clock signal is derived from the CPU's M/IO* pin. See pages 1,2,15,
> and 18 of your own copy of the schematics.

Well. I think this discussion has reached the end of its usefulness.
See my other posting.

>>However, given that some data is missing, e.g. the PROM data,
>>I don't know.
>>
>>> Page 1-30 of the manual states:
>>
>>> =====================================================================
>>> The system unit has a 2-1/4 inch permanent-magnet speaker which can be
>>> drive from:
>>
>>> . The I/O-port output bit
>>> . The timer/counter's clock out
>>> . Both
>>> =====================================================================
>>
>>> Page 1-10 has a simplified circuit diagram which may be easier for you
>>> to understand:
>>> http://www.users.on.net/~fzabkar/PC-AT/TimerCounter.jpg
>>
>>Sorry, don't need that and please can your arrogance.

> Pot kettle black.

> "Since your information is wrong, I don't feel I have to proof
> anything. But please remain unenlightened, if you want."

Look one posting further up....

Arno
 >> Stay informed about: Please help with dead system 

On 17 Nov 2006 23:54:02 GMT Arno Wagner <me.TakeThisOut@privacy.net> wrote in Message
id: <4s70cqFubcoeU1.TakeThisOut@mid.individual.net>:

>In comp.sys.ibm.pc.hardware.misc Trent <none.TakeThisOut@dev.nul.pissoff> wrote:
>> On 16 Nov 2006 15:02:04 GMT Arno Wagner <me.TakeThisOut@privacy.net> wrote in Message
>> id: <4s3crcFthuckU1.TakeThisOut@mid.individual.net>:
>
>>>That is wrong. 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.
>
>> Proof please. The beep codes are generated from the 8254 timer chip, which
>> must be programmed by the processor. If the processor is missing or cannot
>> do code/data fetches from the BIOS ROM, there are *no* post codes. Period.
>
>Since your information is wrong, I don't feel I have to proof
>anything. But please remain unenlightened, if you want.

Suuuure...
*giggle*

>Otherwise have a look at the schematics again. Should be at least PC-AT,

Yep. I still have my IBM PC AT technical reference manual. Pg. 16 of 22 of
the schematics. Looks like that pesky old 8254 needs programming to me.
All those beep codes referenced by different BIOS manufacturers require a
processor that can run well enough to do code and data fetches from ROM.

>since I think the original PC and XT actually could not do this AFAIK.

I've been debugging to the component level on processor, memory, and I/O
boards since the 8080 days on Intel Multibus based systems, and you were
most likely still suckling at your dad's teat, you confused pinhead. Why
don't you quit while you're behind?
 >> Stay informed about: Please help with dead system 

On 18 Nov 2006 22:35:31 GMT Arno Wagner <me.TakeThisOut@privacy.net> wrote in Message
id: <4s9g5jFus4g6U1.TakeThisOut@mid.individual.net>:

>Ok, whether or not the original IBM AT could beek a "CPU missing" is
>really besides the point. More important is what amodern PC mainboard
>would do. In order to find out, I just hookes an EPOX EP8-KRA2+
>up to a PSU and speaker. This board also has a POST display,
>which hung at "FF" as expected. In addition there were no beeps,
>so I retract my earlier statement: A modern mainboard does
>not necessarily beep when the CPU is missing.

I expect an apology is forthcoming?
 >> Stay informed about: Please help with dead system 

On Sat, 18 Nov 2006 19:00:43 -0500 Tony Hill <hilla_nospam_20.TakeThisOut@yahoo.com>
wrote in Message id: <0b5vl2ddh90fa7ba8gtd6kcp280e7gsksh.TakeThisOut@4ax.com>:

>On Fri, 17 Nov 2006 05:20:07 -0500, Trent <none.TakeThisOut@dev.nul.pissoff>
>wrote:
>
>>On 16 Nov 2006 15:02:04 GMT Arno Wagner <me.TakeThisOut@privacy.net> wrote in Message
>>id: <4s3crcFthuckU1.TakeThisOut@mid.individual.net>:
>>
>>>That is wrong. 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.
>>
>>Proof please. The beep codes are generated from the 8254 timer chip, which
>>must be programmed by the processor. If the processor is missing or cannot
>>do code/data fetches from the BIOS ROM, there are *no* post codes. Period.
>
>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/TechSupport/CoreRedirect.jsp?redirectReason=DocIndexPDF&prodSeriesId=472276&targetPage=http%3A%2F%2Fh20000.www2.hp.com%2Fbc%2Fdocs%2Fsupport%2FSupportManual%2Fc00368814%2Fc00368814.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.
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.

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

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

>This is also where the "Keyboard MCU" resides and it's also where the
>POST beeps (or blinking lights, or voice warnings on some new systems)
>come from.

I've yet to see a design where the keyboard controller can write data to
the speaker.

>This is not some XT or AT system we're talking about here, things have
>changed quite a bit in the past 25 years.

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.

From the 82801DB technical reference .pdf dated May 2003:

"The ICH4 contains three counters which have fixed uses. All registers and
functions associated with the 8254 timers are in the core well. The 8254
unit is clocked by a 14.31818 MHz clock."


>----------------------------
>Tony Hill
>hilla <underscore> 20 <at> yahoo <dot> ca

You sig delimiter is improperly constructed.
 >> Stay informed about: Please help with dead system 

On Sat, 18 Nov 2006 19:00:43 -0500, Tony Hill
<hilla_nospam_20.DeleteThis@yahoo.com> put finger to keyboard and composed:

>On Fri, 17 Nov 2006 05:20:07 -0500, Trent <none.DeleteThis@dev.nul.pissoff>
>wrote:
>
>>On 16 Nov 2006 15:02:04 GMT Arno Wagner <me.DeleteThis@privacy.net> wrote in Message
>>id: <4s3crcFthuckU1.DeleteThis@mid.individual.net>:
>>
>>>That is wrong. 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.
>>
>>Proof please. The beep codes are generated from the 8254 timer chip, which
>>must be programmed by the processor. If the processor is missing or cannot
>>do code/data fetches from the BIOS ROM, there are *no* post codes. Period.
>
>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/TechSupport/CoreRedirect.jsp?redirectReason=DocIndexPDF&prodSeriesId=472276&targetPage=http%3A%2F%2Fh20000.www2.hp.com%2Fbc%2Fdocs%2Fsupport%2FSupportManual%2Fc00368814%2Fc00368814.pdf

Hmmm, "Processor not installed" seems unambiguous to me. However,
AFAICS, the higher level diagnostic tests definitely require a
functioning x86 CPU and BIOS code.

>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

That could still require a partially functioning CPU. Obviously all
the other tests require a functioning x86 CPU and BIOS code.

In fact test #1 in the BIOS POST routines of the original IBM AT was a
rudimentary CPU test. The program listing (yes, the Tech Ref Manual
lists the complete BIOS assembly code) states that test #1 writes 01
to the diagnostic port at 80h, and then tests the CPU's flags and
registers. If an error is detected, the test jumps to an error
handling routine consisting of a single instruction, HLT. There are no
beeps, no blinking lights. I suspect that the LEDs in your Dell
example are connected to port 80h, rather than to some special
hardware, in which case you could drive them using the Debug example
in my other post.

>Note that these codes are NOT generated by any "8254 timer chip" as
>such chips haven't existed on motherboards for 10+ years now.

That's irrelevant. In fact chipsets that incorporated the
functionality of the 8254 timer were introduced in early 286
motherboards (eg VLSI Tech, Chips & Tech) way back in the early 90s.
But that doesn't change the fact that the speaker is driven from a
piece of silicon that emulates the functionality of the original
discrete 8254 chips. And that's what matters. If you are a Windows
user, any version of Windows, check you Device Manager I/O resource
list. You will find a speaker port at 61h and a system timer port at
40-43h, exactly where they have always been.

>The
>functionality of the 8254 timer chip has been incorporated into the
>motherboard chipset, typically in the I/O controller or southbridge.
>This is also where the "Keyboard MCU" resides and it's also where the
>POST beeps (or blinking lights, or voice warnings on some new systems)
>come from.

Agreed, but that does not prove that the keyboard MCU is doing the
talking. On the contrary it is obvious that certain POST routines
*must* be executed by the host CPU from BIOS code. For example, a ROM
checksum test, or a memory test, or a test for the presence of a
graphics adapter all require x86 intelligence.

>This is not some XT or AT system we're talking about here, things have
>changed quite a bit in the past 25 years.

Yes they have, but not the way you think. The fundamentals are still
there.

>----------------------------
>Tony Hill
>hilla <underscore> 20 <at> yahoo <dot> ca

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.
 >> Stay informed about: Please help with dead system 

On 19 Nov 2006 01:47:52 GMT, Arno Wagner <me.RemoveThis@privacy.net> put finger
to keyboard and composed:

>In comp.sys.ibm.pc.hardware.misc Franc Zabkar <fzabkar.RemoveThis@iinternode.on.net> wrote:
>> On 18 Nov 2006 21:19:53 GMT, Arno Wagner <me.RemoveThis@privacy.net> put finger
>> to keyboard and composed:

>>>>>> I have the original IBM PC/AT Technical Reference Manual.
>>>>>
>>>>>> Here are scans of the relevant circuits:
>>>>>> http://www.users.on.net/~fzabkar/PC-AT/
>>>>>
>>>>>> Note that the speaker is driven by an 8254 timer gated with speaker
>>>>>> data from "Port B", ie I/O port 61h.
>>>>>
>>>>>> There is no connection between the 8042 keyboard controller and the
>>>>>> speaker.
>>>>>
>>>>>Ok, so you did actually look. In my PC-AT schematics, I/O D1 from
>>>>>the 8042 (U126) is connected to the Speaker via U127 (ALS175,
>>>>>a quad D-Flip flop) and mixed together with the output of the 8254
>>>>>(U103) in U92. Yes, ordinarily the AND-gate acts as a gate. But it
>>>>>can be used as mixer as well, if the signal from the 8254 is "1".
>>>>>
>>>>>Arno
>>>
>>>> Look again. I/O D1 from the 8042 is connected to a shared data bus.
>>>> This data bus is controlled by the host CPU, not the 8042.
>>>
>>>No. This is a Tri-State bus and (given the right arbitration)
>>>every device can write to it.
>
>> Every device *may* be able to write to the bus and in so doing
>> exchange data with the host CPU, but not every device can write to
>> every *other* device.
>
>Yes, and actually most cannot, since the address lines and
>handshaking lines are pure inputs. For the 8042 this is not true.
>It has general purpose I/O and just pretends to be a
>memory-mapped I/O device.

Technobabble. The 8042 does not control the data bus. Period.

>>>> In any case
>>>> the clock for U127 is "-PortB WR" which is also generated by the host
>>>> CPU via an Out instruction to port 61h. The 8042 has *no way* of
>>>> clocking data through U127.
>>>
>>>You have no way of knowing this. The 8042 may be able to write to 61h.
>
>> The 8042 *does not* control the data bus. In fact there are 14 pages
>> which describe in detail what the keyboard controller actually does.
>> These pages also contain an additional simplified functional diagram.
>
>The 8042 can do a lot of things not in the normal operation description.
>For example, it can control any signal deliverd to it.

More technobabble. What an 8042 MCU can do in another application is
completely irrelevant. In a PC/AT the 8042 is just another I/O device.
It doesn't do DMA or bus mastering or anything exotic. It just does
what the host CPU tells it to do (via ports 60 and 64).

>>>Don't forget that this is the I/O bus, not the normal CPU memory
>>>bus.
>
>> The I/O bus is derived from the host CPU's data bus. The "-PortB WR"
>> clock signal is derived from the CPU's M/IO* pin. See pages 1,2,15,
>> and 18 of your own copy of the schematics.
>
>Well. I think this discussion has reached the end of its usefulness.
>See my other posting.

There is nothing in that post which is relevant to the present
discussion. Instead I suggest you examine pages 1,2,15, and 18 of your
own copy of the schematics and follow the signal path from the host
CPU, to the I/O decoder, to the timer, and then on to the speaker. We
don't need to speculate, the proof is in the schematics. If you have
difficulty understanding them, I'll be happy to explain, unless of
course you think I'm being arrogant.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.
 >> Stay informed about: Please help with dead system 

In comp.sys.ibm.pc.hardware.misc Trent <none RemoveThis @dev.nul.pissoff> wrote:
> On 18 Nov 2006 22:35:31 GMT Arno Wagner <me RemoveThis @privacy.net> wrote in Message
> id: <4s9g5jFus4g6U1 RemoveThis @mid.individual.net>:

>>Ok, whether or not the original IBM AT could beek a "CPU missing" is
>>really besides the point. More important is what amodern PC mainboard
>>would do. In order to find out, I just hookes an EPOX EP8-KRA2+
>>up to a PSU and speaker. This board also has a POST display,
>>which hung at "FF" as expected. In addition there were no beeps,
>>so I retract my earlier statement: A modern mainboard does
>>not necessarily beep when the CPU is missing.

> I expect an apology is forthcoming?

And why would you do that?
 >> Stay informed about: Please help with dead system 

On Mon, 20 Nov 2006 19:00:57 -0500, Tony Hill
<hilla_nospam_20 RemoveThis @yahoo.com> 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

--
A Lost Angel, fallen from heaven
Lost in dreams, Lost in aspirations,
Lost to the world, Lost to myself
 >> Stay informed about: Please help with dead system 

On 20 Nov 2006 15:11:05 GMT Arno Wagner <me.DeleteThis@privacy.net> wrote in Message
id: <4sdus9Fv3tahU1.DeleteThis@mid.individual.net>:

>In comp.sys.ibm.pc.hardware.misc Trent <none.DeleteThis@dev.nul.pissoff> wrote:
>> On 18 Nov 2006 22:35:31 GMT Arno Wagner <me.DeleteThis@privacy.net> wrote in Message
>> id: <4s9g5jFus4g6U1.DeleteThis@mid.individual.net>:
>
>>>Ok, whether or not the original IBM AT could beek a "CPU missing" is
>>>really besides the point. More important is what amodern PC mainboard
>>>would do. In order to find out, I just hookes an EPOX EP8-KRA2+
>>>up to a PSU and speaker. This board also has a POST display,
>>>which hung at "FF" as expected. In addition there were no beeps,
>>>so I retract my earlier statement: A modern mainboard does
>>>not necessarily beep when the CPU is missing.
>
>> I expect an apology is forthcoming?
>
>And why would you do that?

You're right. Save your apology for the bitch that whelped you.
 >> Stay informed about: Please help with dead system 

On Sat, 18 Nov 2006 19:00:43 -0500, Tony Hill
<hilla_nospam_20.TakeThisOut@yahoo.com> put finger to keyboard and composed:

>On Fri, 17 Nov 2006 05:20:07 -0500, Trent <none.TakeThisOut@dev.nul.pissoff>
>wrote:
>
>>On 16 Nov 2006 15:02:04 GMT Arno Wagner <me.TakeThisOut@privacy.net> wrote in Message
>>id: <4s3crcFthuckU1.TakeThisOut@mid.individual.net>:
>>
>>>That is wrong. 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.
>>
>>Proof please. The beep codes are generated from the 8254 timer chip, which
>>must be programmed by the processor. If the processor is missing or cannot
>>do code/data fetches from the BIOS ROM, there are *no* post codes. Period.
>
>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/TechSupport/CoreRedirect.jsp?redirectReason=DocIndexPDF&prodSeriesId=472276&targetPage=http%3A%2F%2Fh20000.www2.hp.com%2Fbc%2Fdocs%2Fsupport%2FSupportManual%2Fc00368814%2Fc00368814.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
--
Please remove one 'i' from my address when replying by email.
 >> Stay informed about: Please help with dead system 

In comp.sys.ibm.pc.hardware.misc Trent <none.RemoveThis@dev.nul.pissoff> wrote:
> On 20 Nov 2006 15:11:05 GMT Arno Wagner <me.RemoveThis@privacy.net> wrote in Message
> id: <4sdus9Fv3tahU1.RemoveThis@mid.individual.net>:

>>In comp.sys.ibm.pc.hardware.misc Trent <none.RemoveThis@dev.nul.pissoff> wrote:
>>> On 18 Nov 2006 22:35:31 GMT Arno Wagner <me.RemoveThis@privacy.net> wrote in Message
>>> id: <4s9g5jFus4g6U1.RemoveThis@mid.individual.net>:
>>
>>>>Ok, whether or not the original IBM AT could beek a "CPU missing" is
>>>>really besides the point. More important is what amodern PC mainboard
>>>>would do. In order to find out, I just hookes an EPOX EP8-KRA2+
>>>>up to a PSU and speaker. This board also has a POST display,
>>>>which hung at "FF" as expected. In addition there were no beeps,
>>>>so I retract my earlier statement: A modern mainboard does
>>>>not necessarily beep when the CPU is missing.
>>
>>> I expect an apology is forthcoming?
>>
>>And why would you do that?

> 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
 >> Stay informed about: Please help with dead system 

In comp.sys.ibm.pc.hardware.misc Trent <none.DeleteThis@dev.nul.pissoff> wrote:
> On Mon, 20 Nov 2006 19:00:57 -0500 Tony Hill <hilla_nospam_20.DeleteThis@yahoo.com>
> wrote in Message id: <bbc4m2pbkopd02l318ptcpqd7f1b5qnt1i.DeleteThis@4ax.com>:

>>On Mon, 20 Nov 2006 07:06:54 -0500, Trent <none.DeleteThis@dev.nul.pissoff>
>>wrote:
>>>On Sat, 18 Nov 2006 19:00:43 -0500 Tony Hill <hilla_nospam_20.DeleteThis@yahoo.com>
>>>wrote in Message id: <0b5vl2ddh90fa7ba8gtd6kcp280e7gsksh.DeleteThis@4ax.com>:
>>>>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/TechSupport/CoreRedirect.jsp?redirectReason=DocIndexPDF&prodSeriesId=472276&targetPage=http%3A%2F%2Fh20000.www2.hp.com%2Fbc%2Fdocs%2Fsupport%2FSupportManual%2Fc00368814%2Fc00368814.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
 >> Stay informed about: Please help with dead system