Please help with dead system
Chris
on but no post, no beep codes just cpu fan, power supply fan and hard
disk comes on. I believe it;s the CPU because when the problem
happeed there was alot of dust across the top of the heat-sink
completely covering the top restricting flow of air to the heat-sink.
Since there are no beeps, no post, no video and the dirty heat sink,
I'm guessing the cpu. Can anyone offer any advice? I don't want to
waste money replacing the cpu and I have no known good cpu's or
motherboards for this cpu.
Chris
If life seems jolly rotten
There's spmething you've forgotten
and thats to laugh and smile and dance and sing!
KC Computers
> on but no post, no beep codes just cpu fan, power supply fan and hard
> disk comes on. I believe it;s the CPU because when the problem
> happeed there was alot of dust across the top of the heat-sink
> completely covering the top restricting flow of air to the heat-sink.
> Since there are no beeps, no post, no video and the dirty heat sink,
> I'm guessing the cpu. Can anyone offer any advice? I don't want to
> waste money replacing the cpu and I have no known good cpu's or
> motherboards for this cpu.
It's pretty rare for a CPU to fail like that. It's more likely a
motherboard
or power supply issue. Can you borrow a power supply to try?
---
KC COMPUTERS www.kc-computers.com
Internet computer dealer since 1991!!! See customer ratings at:
http://www.resellerratings.com/topstores.pl
Tony Hill
<chri...@notalotofunwanted.aol.com> wrote:
>I have a pc AMD 2000+ (home built) that will not power on. It powers
>on but no post, no beep codes just cpu fan, power supply fan and hard
>disk comes on. I believe it;s the CPU because when the problem
>happeed there was alot of dust across the top of the heat-sink
>completely covering the top restricting flow of air to the heat-sink.
>Since there are no beeps, no post, no video and the dirty heat sink,
>I'm guessing the cpu. Can anyone offer any advice? I don't want to
>waste money replacing the cpu and I have no known good cpu's or
>motherboards for this cpu.
Standard process here is to try to isolate the issue. The problem
sounds like you have an electrical short somewhere in your system,
which means it could be ANY component.
First, pull out ALL unnecessary components, ie any PCI cards, anything
connected to USB, keyboard, mouse, external speakers, hard drives,
floppy, etc. etc. Basically you want to be left with nothing other
than your motherboard, CPU and power supply. At the very least this
should give you some beep complaining about the lack of memory.
If you get nothing at that point, then at least you've narrowed it
down to three parts, CPU, power supply and motherboard. Now, at this
point there are only two options. First is to physically inspect the
parts to see if there is an obvious proble. Most important here is to
check the capacitors on the motherboard to see if they are bulging,
leaking or just otherwise looking ugly. Given the approximate age of
your system, I would give it about a 75% or higher probability that
this is where you problem is.
Now, if a visual inspection doesn't bring up anything obvious, the
second option is to swap parts. Of course, this requires compatible
replacement parts in order to test things, so hopefully you've got a
similar spare PC lying about and/or have a friend that does. Swap
parts out one at a time to try to isolate the issue, then replace the
defective part.
----------------------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Arno Wagner
> I have a pc AMD 2000+ (home built) that will not power on. It powers
> on but no post, no beep codes just cpu fan, power supply fan and hard
> disk comes on. I believe it;s the CPU because when the problem
> happeed there was alot of dust across the top of the heat-sink
> completely covering the top restricting flow of air to the heat-sink.
> Since there are no beeps, no post, no video and the dirty heat sink,
> I'm guessing the cpu. Can anyone offer any advice? I don't want to
> waste money replacing the cpu and I have no known good cpu's or
> motherboards for this cpu.
If the HDD starts, then both +5V and +12V from the PSU is
reasonably good. HDDs have bad power detectors so they can
decide when to spin-up and spin-down.
One way you could get your symptoms is if the reset line
(called power-good) from the PSU is failing. HDDs atsrt on
their own. The way to test for this is with a different
PSU.
If the CPU is broken, you should get the according
beep code (or POST code, if your mainboard has a POST display).
However if it is partially broken, that may not work....
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. This does not matter a lot, since you cannot get
CPUs or mainboards from that generation anymore anyways.
But first, remove everything, except CPU, RAM and video card.
See wheter it still does not start. Then test with a different
PSU. Then you can try the CPU removal experiment.
Arno
George Macdonald
<chri...@notalotofunwanted.aol.com> wrote:
>I have a pc AMD 2000+ (home built) that will not power on. It powers
>on but no post, no beep codes just cpu fan, power supply fan and hard
>disk comes on. I believe it;s the CPU because when the problem
>happeed there was alot of dust across the top of the heat-sink
>completely covering the top restricting flow of air to the heat-sink.
>Since there are no beeps, no post, no video and the dirty heat sink,
>I'm guessing the cpu. Can anyone offer any advice? I don't want to
>waste money replacing the cpu and I have no known good cpu's or
>motherboards for this cpu.
Sounds about the right time frame for the capacitor problem - check the
capacitors, especially the cluster near the CPU, for doming of the top and
leakage around the base. See www.badcaps.com for examples.
--
Rgds, George Macdonald
mygarb...@hotmail.com
Smell the power supply. If it smells like something is burned,
probably it is.
NNN
Franc Zabkar
to keyboard and composed:
>In comp.sys.ibm.pc.hardware.misc Chris <chri...@notalotofunwanted.aol.com> wrote:
>> I have a pc AMD 2000+ (home built) that will not power on. It powers
>> on but no post, no beep codes just cpu fan, power supply fan and hard
>> disk comes on. I believe it;s the CPU because when the problem
>> happeed there was alot of dust across the top of the heat-sink
>> completely covering the top restricting flow of air to the heat-sink.
>> Since there are no beeps, no post, no video and the dirty heat sink,
>> I'm guessing the cpu. Can anyone offer any advice? I don't want to
>> waste money replacing the cpu and I have no known good cpu's or
>> motherboards for this cpu.
>
>If the HDD starts, then both +5V and +12V from the PSU is
>reasonably good. HDDs have bad power detectors so they can
>decide when to spin-up and spin-down.
>
>One way you could get your symptoms is if the reset line
>(called power-good) from the PSU is failing. HDDs atsrt on
>their own. The way to test for this is with a different
>PSU.
>
>If the CPU is broken, you should get the according
>beep code (or POST code, if your mainboard has a POST display).
>However if it is partially broken, that may not work....
>
>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.
- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.
Franc Zabkar
>On Wed, 15 Nov 2006 20:48:53 GMT, Chris
><chri...@notalotofunwanted.aol.com> wrote:
>
>>I have a pc AMD 2000+ (home built) that will not power on. It powers
>>on but no post, no beep codes just cpu fan, power supply fan and hard
>>disk comes on. I believe it;s the CPU because when the problem
>>happeed there was alot of dust across the top of the heat-sink
>>completely covering the top restricting flow of air to the heat-sink.
>>Since there are no beeps, no post, no video and the dirty heat sink,
>>I'm guessing the cpu. Can anyone offer any advice? I don't want to
>>waste money replacing the cpu and I have no known good cpu's or
>>motherboards for this cpu.
>
>Standard process here is to try to isolate the issue. The problem
>sounds like you have an electrical short somewhere in your system,
A short would shut down the PSU. Clearly this is not happening in the
OP's case.
Arno Wagner
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.
Arno
Chris
Thanks for the replies so far... I have swapped the power supply for a
known good supply, removed all cards, usb cables ram etc... Still no
change. No beep codes and the CPU (heat sink) does not get warm at
all. I gave it a good visual inspection under a magnifying glass (I
am a pc technician) and there does not appear to be any problem with
the motherboard. CPU's are still available for this system, but I'm
not sure about MB's except maybe used... I have a post card but it's
ISA and the MB doesn't have any ISA slots. I can try to boot the
system with no cpu and see what happens. It's been very rare in my
experience for a cpu to go bad, in over 10 years I've only seen one
and it was a bad cache on a g3 chip, but at work I've always had known
good equipment and with this I don't and I am not working at the
moment. Any other ideas?
Tony Hill
<fza...@iinternode.on.net> wrote:
>On 16 Nov 2006 00:36:03 GMT, Arno Wagner <m...@privacy.net> put finger
>to keyboard and composed:
>>reasonably good. HDDs have bad power detectors so they can
>>decide when to spin-up and spin-down.
>>
>>One way you could get your symptoms is if the reset line
>>(called power-good) from the PSU is failing. HDDs atsrt on
>>their own. The way to test for this is with a different
>>PSU.
>>
>>If the CPU is broken, you should get the according
>>beep code (or POST code, if your mainboard has a POST display).
>>However if it is partially broken, that may not work....
>>
>>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.
Tony Hill
<fza...@iinternode.on.net> wrote:
In my experience a short will shut down the PSU only about 50% of the
time at most. Other times it just hangs in a state exactly like the
original poster described, no POST, no video, no beeps, but everything
seems to be getting power fine.
A short will only shut down the PSU if the voltage can be directly
pulled from that power supply. If the short is on the far side of a
voltage regulator which has a maximum current that it will supply,
then your PSU never sees the short circuit and just happily goes about
it's business. Another possibility is that the short circuit only
lasted about a milisecond until it burned out some other chip and
caused an open circuit. Same basic symptoms and same fix either way.
Arno Wagner
I agree to that. Basically only the very visible "chip is burnt"
type, when the heatsink falls off an older CPU.
> in over 10 years I've only seen one
> and it was a bad cache on a g3 chip, but at work I've always had known
> good equipment and with this I don't and I am not working at the
> moment. Any other ideas?
Well, the total no-reaction would lead me to believe that the
chipset is shot. With no CPU you should get a beep-code.
If not, the board is broken.
Arno
Franc Zabkar
<hilla_n...@yahoo.com> put finger to keyboard and composed:
Just to be clear, you don't mean *all* the POST beep codes, do you?
Franc Zabkar
<hilla_n...@yahoo.com> put finger to keyboard and composed:
>On Thu, 16 Nov 2006 16:12:43 +1100, Franc Zabkar
><fza...@iinternode.on.net> wrote:
>
>>On Wed, 15 Nov 2006 18:45:56 -0500, Tony Hill
>><hilla_n...@yahoo.com> put finger to keyboard and composed:
>>
>>>On Wed, 15 Nov 2006 20:48:53 GMT, Chris
>>><chri...@notalotofunwanted.aol.com> wrote:
>>>
>>>>I have a pc AMD 2000+ (home built) that will not power on. It powers
>>>>on but no post, no beep codes just cpu fan, power supply fan and hard
>>>>disk comes on. I believe it;s the CPU because when the problem
>>>>happeed there was alot of dust across the top of the heat-sink
>>>>completely covering the top restricting flow of air to the heat-sink.
>>>>Since there are no beeps, no post, no video and the dirty heat sink,
>>>>I'm guessing the cpu. Can anyone offer any advice? I don't want to
>>>>waste money replacing the cpu and I have no known good cpu's or
>>>>motherboards for this cpu.
>>>
>>>Standard process here is to try to isolate the issue. The problem
>>>sounds like you have an electrical short somewhere in your system,
>>
>>A short would shut down the PSU. Clearly this is not happening in the
>>OP's case.
>
>In my experience a short will shut down the PSU only about 50% of the
>time at most. Other times it just hangs in a state exactly like the
>original poster described, no POST, no video, no beeps, but everything
>seems to be getting power fine.
I've repaired thousands of power supplies in all manner of equipment.
I don't recall any case where a short on one of the rails of a PC SMPS
did not shut down the supply. In fact short circuit current protection
is a design requirement. However, I *have* seen plenty of cases in
other equipment where a particular rail has fused in response to a
short, or where the load has been switched off by a protection
circuit.
>A short will only shut down the PSU if the voltage can be directly
>pulled from that power supply. If the short is on the far side of a
>voltage regulator which has a maximum current that it will supply,
>then your PSU never sees the short circuit and just happily goes about
>it's business.
Yes, that's possible, although I think such regulators are designed to
shut down, assuming they have not failed.
>Another possibility is that the short circuit only
>lasted about a milisecond until it burned out some other chip and
>caused an open circuit. Same basic symptoms and same fix either way.
>----------------------------
>Tony Hill
>hilla <underscore> 20 <at> yahoo <dot> ca
There is nothing in the OP's post that would have me automatically
suspecting a short.
Franc Zabkar
to keyboard and composed:
I was thinking of BIOS/POST beep codes. These require a working CPU. I
was not aware that the keyboard MCU in a modern PC chipset could
actually control the speaker (it is normally accessed via I/O port
61h). In any case, a "POST display" requires that error code data be
sent to I/O port 80h. I can't see how the keyboard MCU could do this.
Trent
id: <4s3crcF...@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.
The little lost angel
wrote:
I had seen modern motherboards which are able to tell if the CPU is
not working. Specifically on an older AOpen K7 board, I had the
occasion where the board was able to tell me "Your CPU may have a
problem" using the beeper as a voice speaker.
My older MSI Socket A board also had a diagnostic LED that had codes
for a improperly installed or non-functional CPU, basically equates to
a dead CPU.
My current one probably has beep codes for that as well but I'm too
lazy to dig up the manual :ppPp
--
A Lost Angel, fallen from heaven
Lost in dreams, Lost in aspirations,
Lost to the world, Lost to myself
Arno Wagner
Since your information is wrong, I don't feel I have to proof
anything. 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
Franc Zabkar
a?n?g?e?l...@lovergirl.lrigrevol.moc.com (The little lost angel) put
finger to keyboard and composed:
>On Fri, 17 Nov 2006 05:20:07 -0500, Trent <no...@dev.nul.pissoff>
>wrote:
>
>>On 16 Nov 2006 15:02:04 GMT Arno Wagner <m...@privacy.net> wrote in Message
>>id: <4s3crcF...@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.
>
>I had seen modern motherboards which are able to tell if the CPU is
>not working. Specifically on an older AOpen K7 board, I had the
>occasion where the board was able to tell me "Your CPU may have a
>problem" using the beeper as a voice speaker.
If the speaker was talking to you, then clearly the code that does
this is being executed by some kind of CPU. I'd be very surprised if
such intelligence was incorporated into the chipset. Perhaps your CPU
was only partially bad.
>My older MSI Socket A board also had a diagnostic LED that had codes
>for a improperly installed or non-functional CPU, basically equates to
>a dead CPU.
If it's just a single LED, then that's a lot easier than generating a
beep code.
>My current one probably has beep codes for that as well but I'm too
>lazy to dig up the manual :ppPp
All BIOSes appear to have beep codes for malfunctioning CPUs. However,
AFAICS, these require that the CPU has enough functionality to execute
BIOS code. A totally dead CPU cannot execute anything.
Having said the above, I *could* envisage a scenario where a spare pin
on the keyboard MCU could be used to drive the speaker by ORing it
with the normal data path. Such a design *could* detect an empty CPU
socket, but none of your anecdotes confirm that this is what was
happening in your case.
Franc Zabkar
to keyboard and composed:
>In comp.sys.ibm.pc.hardware.misc Trent <no...@dev.nul.pissoff> wrote:
>> On 16 Nov 2006 15:02:04 GMT Arno Wagner <m...@privacy.net> wrote in Message
>> id: <4s3crcF...@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.
Arno Wagner
> Yes, you do.
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
Franc Zabkar
to keyboard and composed:
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. 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.
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
The little lost angel
<fza...@iinternode.on.net> wrote:
>>My older MSI Socket A board also had a diagnostic LED that had codes
>>for a improperly installed or non-functional CPU, basically equates to
>>a dead CPU.
>
>If it's just a single LED, then that's a lot easier than generating a
>beep code.
It's a set of 4 dual colour (red/green) LED so it's a bit more
complicated than just lighting up one LED if the board doesn't see a
CPU?
Wouldn't it be possible that the chipset has included "intelligence"
to be used for controlling the speaker or such a diagnostic function?
I'll try to see if anybody I know has a spare system and willing to
try a little test by pulling out the CPU totally. :p
Franc Zabkar
a?n?g?e?l...@lovergirl.lrigrevol.moc.com (The little lost angel) put
finger to keyboard and composed:
>On Sat, 18 Nov 2006 11:09:32 +1100, Franc Zabkar
><fza...@iinternode.on.net> wrote:
>
>>>My older MSI Socket A board also had a diagnostic LED that had codes
>>>for a improperly installed or non-functional CPU, basically equates to
>>>a dead CPU.
>>
>>If it's just a single LED, then that's a lot easier than generating a
>>beep code.
>
>It's a set of 4 dual colour (red/green) LED so it's a bit more
>complicated than just lighting up one LED if the board doesn't see a
>CPU?
I suspect that these 4 dual-colour LEDs code for 8 data bits at
diagnostic port 80h, in which case they would be controlled by the
host CPU.
I'm not sure if the following will work, but I'd try accessing your
LEDs using DOS Debug.
For example, to turn all LEDs on, off, alternating on/off, type ...
debug
-O 80 FF (O = oh, not zero)
-O 80 0
-O 80 55
-O 80 AA
-Q
>Wouldn't it be possible that the chipset has included "intelligence"
>to be used for controlling the speaker or such a diagnostic function?
I guess some *rudimentary* diagnostic might make sense, but POST
functions require an X86 CPU and BIOS code.
>I'll try to see if anybody I know has a spare system and willing to
>try a little test by pulling out the CPU totally. :p
If you can't find anybody, I'll post a follow-up to
alt.comp.hardware.homebuilt. Those people seem to have more practical
experience.
mygarb...@hotmail.com
a?n?g?e?l...@lovergirl.lrigrevol.moc.com (The little lost angel) wrote:
>On Sat, 18 Nov 2006 11:09:32 +1100, Franc Zabkar
><fza...@iinternode.on.net> wrote:
>
>>>My older MSI Socket A board also had a diagnostic LED that had codes
>>>for a improperly installed or non-functional CPU, basically equates to
>>>a dead CPU.
>>
>>If it's just a single LED, then that's a lot easier than generating a
>>beep code.
>
>It's a set of 4 dual colour (red/green) LED so it's a bit more
>complicated than just lighting up one LED if the board doesn't see a
>CPU?
>
>Wouldn't it be possible that the chipset has included "intelligence"
>to be used for controlling the speaker or such a diagnostic function?
>
>I'll try to see if anybody I know has a spare system and willing to
>try a little test by pulling out the CPU totally. :p
You don't even have to pull the cpu to make the whole thing
unresponsive. A few weeks ago I grabbed an IBM T40 off a junk pile at
work - cracked LCD, because of that it was stripped of RAM and
discarded. It was totally unresponsive (no beeps, nothing at all)
until I put in a SODIMM. Then it worked well with external monitor,
and last week I replaced LCD. However the fact is that if you pull
just the memory, it's braindead, despite the fact that it has 1MB
cache on the CPU, and DOS needed what? "640k enough for anyone" - Bill
Gates ;)))))))))))))
NNN
Arno Wagner
No. This is a Tri-State bus and (given the right arbitration)
every device can write to it.
> 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.
Don't forget that this is the I/O bus, not the normal CPU memory
bus.
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.
Arno
Arno Wagner
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.
Arno
Franc Zabkar
to keyboard and composed:
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
Tony Hill
<fza...@iinternode.on.net> wrote:
>On Thu, 16 Nov 2006 20:30:54 -0500, Tony Hill
><hilla_n...@yahoo.com> put finger to keyboard and composed:
>>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.
>
To tell you the truth, I'm not sure, since systems pretty much only
give ONE error code even if more than one error occurs. If the CPU is
not detected, it gives ONLY the "CPU not found" error, even if there
are other problems (eg. memory not detected). Different errors occur
at different stages and it also varies from one board to the next. I'm
sure that SOME errors require CPU intervention. Just as an example,
on an Athlon64/Opteron system it almost certainly won't be possible to
detect if the memory exists or not if the CPU is not present given
that the memory controller is on the CPU.
Still I would say that many beep codes are handled totally
independently of the processor. Certainly the "CPU Not detected" is,
and same for "power supply overloaded". Others like "CPU fan not
detected" are also probably independent of the processor. Obviously
all of this is highly dependent on the individual BIOS and chipset of
the system board.
Tony Hill
wrote:
>On 16 Nov 2006 15:02:04 GMT Arno Wagner <m...@privacy.net> wrote in Message
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:
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
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.
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.
This is not some XT or AT system we're talking about here, things have
changed quite a bit in the past 25 years.
Arno Wagner
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
Arno Wagner
> On 18 Nov 2006 21:19:53 GMT, Arno Wagner <m...@privacy.net> put finger
> to keyboard and composed:
>>In comp.sys.ibm.pc.hardware.misc Franc Zabkar <fza...@iinternode.on.net> wrote:
>>> On 18 Nov 2006 02:38:27 GMT, Arno Wagner <m...@privacy.net> put finger
>>> to keyboard and composed:
>>
>>>>In comp.sys.ibm.pc.hardware.misc Franc Zabkar <fza...@iinternode.on.net> wrote:
>>>>> On 17 Nov 2006 23:54:02 GMT, Arno Wagner <m...@privacy.net> put finger
>>>>> to keyboard and composed:
>>>>
>>>>>>In comp.sys.ibm.pc.hardware.misc Trent <no...@dev.nul.pissoff> wrote:
>>>>>>> On 16 Nov 2006 15:02:04 GMT Arno Wagner <m...@privacy.net> wrote in Message
>>>>>>> id: <4s3crcF...@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.
>>>>>>
P.S.: See the posting from Tony Hill for an example of a system that
does beep "no CPU". Also I agree with him, that the state of the art is
more important than the historic discussion.
Arno
Arno Wagner
> http://support.dell.com/support/edocs/systems/dimC521/en/SM_EN/tshoot.htm#wp1064555
I agree to that. See my other posting were I describe that a
board with VIA chip from Epox does not sugnal anything if
the CPU is missing.
I guess today it just depends on the individual board. Also
anything done before the BIOS starts executing (which requires
the CPU to be present and working), is up to the board
manufacturer anyways.
Arno
Franc Zabkar
<hilla_n...@yahoo.com> put finger to keyboard and composed:
>On Fri, 17 Nov 2006 05:20:07 -0500, Trent <no...@dev.nul.pissoff>
>wrote:
>
>>On 16 Nov 2006 15:02:04 GMT Arno Wagner <m...@privacy.net> wrote in Message
>>id: <4s3crcF...@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
Franc Zabkar
to keyboard and composed:
>In comp.sys.ibm.pc.hardware.misc Franc Zabkar <fza...@iinternode.on.net> wrote:
>> On 18 Nov 2006 21:19:53 GMT, Arno Wagner <m...@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.
Trent
id: <4s70cqF...@mid.individual.net>:
>In comp.sys.ibm.pc.hardware.misc Trent <no...@dev.nul.pissoff> wrote:
>> On 16 Nov 2006 15:02:04 GMT Arno Wagner <m...@privacy.net> wrote in Message
>> id: <4s3crcF...@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?
Trent
id: <4s9g5jF...@mid.individual.net>:
I expect an apology is forthcoming?
Trent
wrote in Message id: <0b5vl2ddh90fa7ba8...@4ax.com>:
>On Fri, 17 Nov 2006 05:20:07 -0500, Trent <no...@dev.nul.pissoff>
>wrote:
>
>>On 16 Nov 2006 15:02:04 GMT Arno Wagner <m...@privacy.net> wrote in Message
>>id: <4s3crcF...@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.
Trent
>Still I would say that many beep codes are handled totally
>independently of the processor. Certainly the "CPU Not detected" is,
>and same for "power supply overloaded".
Funny, I don't have a single motherboard in-house that will do beep codes
if no CPU is present. These range from old socket 7 PICMG to modern i945
based core 2 ATX systems. From VIA mini ITX C3 and C7 to Pentium M 5.25"
embedded boards.
Not a Single Fucking One.
Also from the 82801DB reference manual:
"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."
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.
>Others like "CPU fan not
>detected" are also probably independent of the processor.
Please elaborate.
>Obviously
>all of this is highly dependent on the individual BIOS and chipset of
>the system board.
If there is no CPU then the BIOS is completely irrelevant, as there will
be no code or data fetches from ROM.
Arno Wagner
And why would you do that?
Franc Zabkar
<hilla_n...@yahoo.com> put finger to keyboard and composed:
>On Fri, 17 Nov 2006 05:20:07 -0500, Trent <no...@dev.nul.pissoff>
>wrote:
>
>>On 16 Nov 2006 15:02:04 GMT Arno Wagner <m...@privacy.net> wrote in Message
>>id: <4s3crcF...@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.
Tony Hill
wrote:
>On Sat, 18 Nov 2006 19:00:43 -0500 Tony Hill <hilla_n...@yahoo.com>
>wrote in Message id: <0b5vl2ddh90fa7ba8...@4ax.com>:
>>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.
>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.
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.
>>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.
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.
>>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.
100% software compatible does *NOT* mean that it must ONLY be used in
100% the same way.
>>----------------------------
>>Tony Hill
>>hilla <underscore> 20 <at> yahoo <dot> ca
>
>You sig delimiter is improperly constructed.
??? Uhh, care to point to some "specification" for sig delimiting?!
Arno Wagner
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.
>>>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.
> 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.
>>>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.
> 100% software compatible does *NOT* mean that it must ONLY be used in
> 100% the same way.
All too true...
Arno
The little lost angel
<hilla_n...@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
Trent
wrote in Message id: <bbc4m2pbkopd02l31...@4ax.com>:
>On Mon, 20 Nov 2006 07:06:54 -0500, Trent <no...@dev.nul.pissoff>
>wrote:
>>On Sat, 18 Nov 2006 19:00:43 -0500 Tony Hill <hilla_n...@yahoo.com>
>>wrote in Message id: <0b5vl2ddh90fa7ba8...@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?
>>>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.
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? Fuck, 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:
>>"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?
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.
>> 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.
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.
>>>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.
>
>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.
>
>>>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.
>
>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.
>>>----------------------------
>>>Tony Hill
>>>hilla <underscore> 20 <at> yahoo <dot> ca
>>
>>You sig delimiter is improperly constructed.
>
>??? Uhh, care to point to some "specification" for sig delimiting?!
>----------------------------
>Tony Hill
>hilla <underscore> 20 <at> yahoo <dot> ca
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.
Trent
id: <4sdus9F...@mid.individual.net>:
You're right. Save your apology for the bitch that whelped you.
Trent
id: <4sev6vF...@mid.individual.net>:
If your brains were dynamite you wouldn't have enough to blow your toupee
off.
You know so little, why do you work so hard to prove it?
Arno Wagner
> On 20 Nov 2006 15:11:05 GMT Arno Wagner <m...@privacy.net> wrote in Message
> id: <4sdus9F...@mid.individual.net>:
>>In comp.sys.ibm.pc.hardware.misc Trent <no...@dev.nul.pissoff> wrote:
>>> On 18 Nov 2006 22:35:31 GMT Arno Wagner <m...@privacy.net> wrote in Message
>>> id: <4s9g5jF...@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
Arno Wagner
Having emotional problems?
Arno
Arno Wagner
You don't get it, do you? The 8042 has its own firmware and it is
not part of the system BIOS....
Arno
Tony Hill
a?n?g?e?l...@lovergirl.lrigrevol.moc.com (The little lost angel) wrote:
>On Mon, 20 Nov 2006 19:00:57 -0500, Tony Hill
><hilla_n...@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
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
wrote:
>On Mon, 20 Nov 2006 19:00:57 -0500 Tony Hill <hilla_n...@yahoo.com>
>wrote in Message id: <bbc4m2pbkopd02l31...@4ax.com>:
>>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/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.
>
>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? Fuck, 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!
<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.
>>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:
<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.
--
Franc Zabkar
<hilla_n...@yahoo.com> 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.sys.ibm.pc.hardware.systems/browse_thread/thread/e75baff40e678220/e31d990701839d94?lnk=st&q=insubject%3APlease+insubject%3Ahelp+insubject%3Awith+insubject%3Adead+insubject%3Asystem+author%3Atony+author%3Ahill&rnum=1#e31d990701839d94
>
><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
to keyboard and composed:
>In comp.sys.ibm.pc.hardware.misc Tony Hill <hilla_n...@yahoo.com> wrote:
>> On Mon, 20 Nov 2006 07:06:54 -0500, Trent <no...@dev.nul.pissoff>
>> wrote:
>>>On Sat, 18 Nov 2006 19:00:43 -0500 Tony Hill <hilla_n...@yahoo.com>
>>>wrote in Message id: <0b5vl2ddh90fa7ba8...@4ax.com>:
>> 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".
Trent
id: <4sgd1kF...@mid.individual.net>:
You really are a complete fucking imbecile, aren't you?
>The 8042 has its own firmware and it is
>not part of the system BIOS....
No shit, fucko, 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.
Trent
wrote in Message id: <s8v9m2pc3q3509ofs...@4ax.com>:
>On Tue, 21 Nov 2006 07:20:47 -0500, Trent <no...@dev.nul.pissoff>
>wrote:
>>On Mon, 20 Nov 2006 19:00:57 -0500 Tony Hill <hilla_n...@yahoo.com>
>>wrote in Message id: <bbc4m2pbkopd02l31...@4ax.com>:
>>>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/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.
>>
>>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? Fuck, 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?
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/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.
i848:
http://www.intel.com/design/chipsets/schematics/25366102.pdf
It's the latest one publicly available that I could find. Same fucking
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 fuck 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.sys.ibm.pc.hardware.systems/browse_thread/thread/e75baff40e678220/e31d990701839d94?lnk=st&q=insubject%3APlease+insubject%3Ahelp+insubject%3Awith+insubject%3Adead+insubject%3Asystem+author%3Atony+author%3Ahill&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.
Trent
<fza...@iinternode.on.net> wrote in Message id:
<i8scm2l4j28ebh46g...@4ax.com>:
>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.
Mark Conrad
<"nob...@nowhere.net"> wrote:
> Smell the power supply. If it smells like something is burned,
> probably it is.
That figures <g>