Please help with dead system
in [Chips]
|
From: Franc Zabkar on 18 Nov 2006 01:00 On Sat, 18 Nov 2006 04:16:19 GMT, a?n?g?e?l(a)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 ><fzabkar(a)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. - Franc Zabkar -- Please remove one 'i' from my address when replying by email.
From: Arno Wagner on 18 Nov 2006 16:19 In comp.sys.ibm.pc.hardware.misc Franc Zabkar <fzabkar(a)iinternode.on.net> wrote: > On 18 Nov 2006 02:38:27 GMT, Arno Wagner <me(a)privacy.net> put finger > to keyboard and composed: >>In comp.sys.ibm.pc.hardware.misc Franc Zabkar <fzabkar(a)iinternode.on.net> wrote: >>> On 17 Nov 2006 23:54:02 GMT, Arno Wagner <me(a)privacy.net> put finger >>> to keyboard and composed: >> >>>>In comp.sys.ibm.pc.hardware.misc Trent <none(a)dev.nul.pissoff> wrote: >>>>> On 16 Nov 2006 15:02:04 GMT Arno Wagner <me(a)privacy.net> wrote in Message >>>>> id: <4s3crcFthuckU1(a)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. > 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
From: Arno Wagner on 18 Nov 2006 17:35 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. Arno
From: Franc Zabkar on 18 Nov 2006 18:38 On 18 Nov 2006 21:19:53 GMT, Arno Wagner <me(a)privacy.net> put finger to keyboard and composed: >In comp.sys.ibm.pc.hardware.misc Franc Zabkar <fzabkar(a)iinternode.on.net> wrote: >> On 18 Nov 2006 02:38:27 GMT, Arno Wagner <me(a)privacy.net> put finger >> to keyboard and composed: > >>>In comp.sys.ibm.pc.hardware.misc Franc Zabkar <fzabkar(a)iinternode.on.net> wrote: >>>> On 17 Nov 2006 23:54:02 GMT, Arno Wagner <me(a)privacy.net> put finger >>>> to keyboard and composed: >>> >>>>>In comp.sys.ibm.pc.hardware.misc Trent <none(a)dev.nul.pissoff> wrote: >>>>>> On 16 Nov 2006 15:02:04 GMT Arno Wagner <me(a)privacy.net> wrote in Message >>>>>> id: <4s3crcFthuckU1(a)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.
From: Tony Hill on 18 Nov 2006 19:00
On Fri, 17 Nov 2006 16:23:50 +1100, Franc Zabkar <fzabkar(a)iinternode.on.net> wrote: >On Thu, 16 Nov 2006 20:30:54 -0500, Tony Hill ><hilla_nospam_20(a)yahoo.com> put finger to keyboard and composed: >>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. > >Just to be clear, you don't mean *all* the POST beep codes, do you? 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 hilla <underscore> 20 <at> yahoo <dot> ca |