Sounds like you sorted out the resistance measurements, good.
Huh, so they're not using the chip with the timers and gates to provide a signal to the speaker to provide a signal to the speaker. Wonder what they are using. Photos of top and bottom?
I've just about convinced myself that those two resistors are swapped round, but I still don't know the purpose of the 510 ohm one. The 7407 is 'open collector' so it can pull that trace down to ground when it's turned on, but can't pull it high. So a speaker cone would quickly move one way (when the line is pulled low) then move back when the 7407 turned off and current stops. A speaker is partly an inductor, so maybe the other resistor is to control the voltage spike as the signal turns on and off.
If you're using one of those little piezo speakers then I don't think any of that really matters and the resistors won't change how loud it is because they're very high resistance.
So, the speaker works, although the 33 ohm resistor is odd, along with the output staying low when the speaker is off, rather than just floating. With the 33 ohm resistor I'd worry about damage to the 7407. Looking at one datasheet it recommends a maximum of 40mA. I suspect the 1.6V you measure is because the current is limited going in to the 7407
But no indication that any of this is the cause of the halt at 0B.
Sounds like you sorted out the resistance measurements, good.
Huh, so they're not using the chip with the timers and gates to provide a signal to the speaker to provide a signal to the speaker. Wonder what they are using. Photos of top and bottom?
I've just about convinced myself that those two resistors are swapped round, but I still don't know the purpose of the 510 ohm one. The 7407 is 'open collector' so it can pull that trace down to ground when it's turned on, but can't pull it high. So a speaker cone would quickly move one way (when the line is pulled low) then move back when the 7407 turned off and current stops. A speaker is partly an inductor, so maybe the other resistor is to control the voltage spike as the signal turns on and off.
If you're using one of those little piezo speakers then I don't think any of that really matters and the resistors won't change how loud it is because they're very high resistance.
So, the speaker works, although the 33 ohm resistor is odd, along with the output staying low when the speaker is off, rather than just floating. With the 33 ohm resistor I'd worry about damage to the 7407. Looking at one datasheet it recommends a maximum of 40mA. I suspect the 1.6V you measure is because the current is limited going in to the 7407
But no indication that any of this is the cause of the halt at 0B.
Yes I don't feel comfortable having that resistor burning at the PCB for no good reason. I put back the capacitor and removed the 33 ohm resistor for now. No surprise, still 0B 0A. But at least not a second sun burning on my board 😀
I am out of ideas for now, apart from just improving the averall conditions for the board with fresh electrolytic caps and try with a fresh PSU.
Possibly reflow the 82C206. Thanks for all the support!
rasz_plwrote on 2022-02-07, 17:54:SMPS power supplies need some load to regulate properly (or modern sophisticated control logic)
16 ohms at 5V is barely 1.5W - y […] Show full quote
Regarding what happens when measuring the resistance between various decoupling capacitors when the PSU is connected (offline), then so far it is only on C23 I get these strange results.
Resistance to GND is close to 2kOhms on the C23 (positive pad) when the PSU is disconnected. When connected it is 16 ohms.
Same goes for the Vcc pad going in to the 33 ohm resistor. Close to 2kOhms when PSU is disconected. When connected it is 16 ohms.
SMPS power supplies need some load to regulate properly (or modern sophisticated control logic)
16 ohms at 5V is barely 1.5W - your Supply might simply have a load resistor inside to ensure proper output.
Regarding the burning 33 ohm resistor, probably this pin should be driven high then (under normal circumstances) to not have it burn up when the PC speaker is silent... so this could be yet another sign of the 82C206 gone bad.
206 doesnt drive speaker directly, 82C206 OUT2 should to to the chipset, and then a dedicated speaker pin on the chipset drives a discrete logic/transistor
I found a replacement part on fleabay, but it will take a couple of weeks for it to arrive at my doorstep. I hope the "82C206F" works as well?
Im not so sure about 206 being bad anymore 😀
now verified this BIOS POST codes match "Late Award BIOS (4-5x PnP)" http://mrbios.com/techsupport/award/postcodes.htm exactly despite this apparently not being PnP bios?
screwing RTC was hanging POST_7
"Verifies CMOS's basic R/W functionality"
means POST_B is 1.Verify the RTC time is valid or not checked, not it. Just resets date if corrupted.
2.Detect bad battery
3.Read CMOS data into BIOS stack area
4.PnP initializations including (PnP BIOS only)
Assign CSN to PnP ISA card
Create resource map from ESCD
5.Assign IO & Memory for PCI devices (PCI BIOS only)
thats a lot of stuff under one post code to go bad 🙁 will experiment with breaking them now one by one
Ahh yes that is some checks to pass before clearing POST code 0B 😀
Very cool that you found ways to simulate this, now that's what I call a test case!
Thanks for all your efforts! Meanwhile I continue with the electrical and physical troubleshooting of the board.
Well, rasz_pl is making progress on understanding the B section, so might be able to figure out why it halts. And I'm still suspicious about that hot spot you saw on the 206 a few days ago. Even if you allow for shifting the colours left a bit so the IR lines up, that hot spot is still just on the 206, and there's nothing there that should get that hot, that locally. The actual silicon will be somewhere near the middle, with fan out wires to the pins. So that much heat from the fan out, with nothing from the silicon, doesn't sound right. And now it's completely cold. Which it should be when running from the battery in standby mode, but I'm pretty sure there would be at least something there. So don't give up on it just yet.
Well, rasz_pl is making progress on understanding the B section, so might be able to figure out why it halts. And I'm still suspicious about that hot spot you saw on the 206 a few days ago. Even if you allow for shifting the colours left a bit so the IR lines up, that hot spot is still just on the 206, and there's nothing there that should get that hot, that locally. The actual silicon will be somewhere near the middle, with fan out wires to the pins. So that much heat from the fan out, with nothing from the silicon, doesn't sound right. And now it's completely cold. Which it should be when running from the battery in standby mode, but I'm pretty sure there would be at least something there. So don't give up on it just yet.
I am stubborn beyond what is considred as healthy so no giving up here 😀
Tomorrow I will get going with ChipQuik (low-melt solder) to easily get the PQFP package off the board and see what is going on underneath.
Careful with the ChipQuik low-melt alloy; if you want to resolder the same part back later on, the cleanup of the pads and of the chip pins must be exceptionally thorough. Any residue of ChipQuik left over will make the new solder joints brittle and prone to failure.
I/O, I/O,
It's off to disk I go,
With a bit and a byte
And a read and a write,
I/O, I/O
Careful with the ChipQuik low-melt alloy; if you want to resolder the same part back later on, the cleanup of the pads and of the chip pins must be exceptionally thorough. Any residue of ChipQuik left over will make the new solder joints brittle and prone to failure.
Ok, I will use the hot air station and Kingbo flux instead. Just make sure I don't melt stuff around it. I agree, I don't want to contaminate the board and maybe a touch of heat is just what that chip needs 😉
Without temp range or markers its hard to ascertain how hot it actually was
True, it's not calibrated, but when comparing e.g. this later photo: download/file.php?id=129746 with the hot-spot one: download/file.php?id=129676 then there's definitely a difference. The one with the hot-spot is actually making the other chips look cooler and is more sensitive in the one that doesn't show the hot-spot. So that spot was in an odd place, and there's been a change. So I'm suspicious.
How easy is it to mod a BIOS? I might be misunderstanding, but the first time battery power is applied to the 206 it sets a flag to say the battery failed. The BIOS finds this and so writes various default values, and (I assume) clears the battery fail flag. On the next boot, it should find the settings are valid, so skip over that. Is it possible to mod the BIOS to output a custom POST code just after it checks if the battery fail flag is set?
That way, LocalBus could turn everything off, connect a battery (once Q1 is fixed), then turn on. Assuming it hasn't already halted, the BIOS should find the battery fail flag, output a custom code, then set values and clear the flag. At some point later it halts. If the computer is then reset then on the second boot the BIOS shouldn't enter the set the values stage, so will just halt showing 0B.
So, if on the first boot is doesn't show the custom code then I think it would show the BIOS never detected the battery fail flag, or it halted before getting there. If on the second boot it still displays the custom code then it would show that either BIOS couldn't or didn't clear the battery fail flag. If on the first boot is shows the custom code, but not on the second, then that would show that the BIOS had been able to read and clear the battery fail flag, which I think would show that at least the CMOS bits of the 206 worked.
correction, its actually a mix of both "Late Award BIOS (4-5x PnP)" and "Late Award BIOS (4.5x-non PnP)" ? Its:
1.Verify the RTC time is valid or not
2.Test CMOS RAM Checksum if bad or Insert key depressed; load defaults.
Cant trigger this in Emulator by simply keeping Insert pressed while rebooting emulated machine. Might be due to the way 86box interacts with Windows API, or the way emulated keyboard is implemented so it wont respond without initialization? Hardcoded 86box to always return Insert key pressed, this still wasnt triggering CMOS clearing, but instead led to amusing discovery:
4E Manufacturing POST Loop or Display Messages. Reboot if manufacturing POST Loop Pin is set.
apparently thats how Award implemented 'Manufacturing POST Loop'? maybe its a functionality build into all keyboard controllers? and pulling one of their IOs results in keyboard pretending to have stuck Insert key? What is surprising here is that this "Insert key depressed; load defaults." is in fact implemented before proper keyboard initialization. Weird!
Anyway I edited bios file itself sprinkling some nops to force corrupt_cmos_crc to run
True, it's not calibrated, but when comparing e.g. this later photo
can you really do that? afaik uncooled microbolometers are always running relative to both ambient and observer object temperatures. This is why pictures without scale or markers are only good for things like quick construction diagnostics.
How easy is it to mod a BIOS? I might be misunderstanding, but the first time battery power is applied to the 206 it sets a flag to say the battery failed. The BIOS finds this and so writes various default values, and (I assume) clears the battery fail flag. On the next boot, it should find the settings are valid, so skip over that. Is it possible to mod the BIOS to output a custom POST code just after it checks if the battery fail flag is set?
wait, LocalBus has a programmer, if he also has spare chips we can mod it to do whatever we want, we dont even have to worry about BIOS checksum, all bad checksum does is display a message at the end and pause instead of loading master boot record.
would show that at least the CMOS bits of the 206 worked.
CMOS part is working because at POST_7 BIOs is actually writing to CMOS and verifying it can read back same thing it just wrote.
I think RTC must be running for the PCspeaker to make noise _unless_ chipset itself has some independent facility for that purpose? I can definitely program some basic procedure to beep out/flash on POST card a more elaborate message.
CMOS part is working because at POST_7 BIOs is actually writing to CMOS and verifying it can read back same thing it just wrote.
Ah. Not that then.
I think RTC must be running for the PCspeaker to make noise _unless_ chipset itself has some independent facility for that purpose? I can definitely program some basic procedure to beep out/flash on POST card a more elaborate message.
Other stuff is very cool. On this point, it seems that the board doesn't use the 206 for the speaker, even though 206 has the OUT2 and GATE2 pins for it. LocalBus tried cutting Vcc to the 206 and still got beeps.
But... and I've only just twigged this, so it may have an obvious reason...
Just tested, PC speaker works without any Vcc to the 82C206.
LocalBus, how did you cut power to the 206, and did you have the POST card in and note where it stopped? If there was no power to the 206 then shouldn't it have halted at 07?
LocalBus, how did you cut power to the 206, and did you have the POST card in and note where it stopped? If there was no power to the 206 then shouldn't it have halted at 07?
LocalBus, how did you cut power to the 206, and did you have the POST card in and note where it stopped? If there was no power to the 206 then shouldn't it have halted at 07?
yes, makes me think 206 ran on phantom power 😀
Back to the ghost in the machine.
Just to double check I'm reading some code right, is loc_16 in ChkCpu's listing where the BIOS halts. Reading through Post 7, if it fails to match the read/write then it returns with the carry flag set, which looks like that causes it to end up at loc_16, which is just:
1F000:01D1 loc_16: ; xref F000:01D8, 022D, 0256, 10E5 2F000:01D1 ,FA cli ; Disable interrupts 3F000:01D2 8B C5 mov AX, BP 4F000:01D4 BA 0080 mov DX, 80h 5F000:01D7 EE out DX, AL ; port 80h, POST checkpoint 6F000:01D8 EB F7 jmp short loc_16 ; (01D1)
Unless there's some cunning way out of that (which I missed the last time) then it looks like it'll be stuck there.
Just tested, PC speaker works without any Vcc to the 82C206.
LocalBus, how did you cut power to the 206, and did you have the POST card in and note where it stopped? If there was no power to the 206 then shouldn't it have halted at 07?
I disconnected my DMM which is connected in series over the removed Q1 PNP BJT, effectively removing the 5V Vcc supply to it. That would also remove the PWRSTB# voltage since there is no battery in the circuit either. It is only the PWRGD that is still connected to the 206.
Yes, the POST card was in and I still got 0B 0A - so it made no difference in this regard.
How easy is it to mod a BIOS? I might be misunderstanding, but the first time battery power is applied to the 206 it sets a flag to say the battery failed. The BIOS finds this and so writes various default values, and (I assume) clears the battery fail flag. On the next boot, it should find the settings are valid, so skip over that. Is it possible to mod the BIOS to output a custom POST code just after it checks if the battery fail flag is set?
wait, LocalBus has a programmer, if he also has spare chips we can mod it to do whatever we want, we dont even have to worry about BIOS checksum, all bad checksum does is display a message at the end and pause instead of loading master boot record.
That I do, and I also have an SST29EE010 flash rom I can use as test rom I guess?
I disconnected my DMM which is connected in series over the removed Q1 PNP BJT, effectively removing the 5V Vcc supply to it. That would also remove the PWRSTB# voltage since there is no battery in the circuit either. It is only the PWRGD that is still connected to the 206.
Yes, the POST card was in and I still got 0B 0A - so it made no difference in this regard.
first Arm1 working model, with a 6 MHz clock speed. It utilized so little power that, as one project engineer tells the story, one day they noticed the chip was running without its power supply connected. It was actually being powered by leakage from the power rails leading to the I/O chip.
What does the POST_B routine say about loading the BIOS defaults from ROM? But as concluded before, if the ROM access wasn't working properly, we would not get very far would we? Or are these default values addressed in a different way?
Just to rule out yet another part of the equation, I will program the SST29EE010 Flash ROM with the same BIOS ROM dump and see if it makes any difference... it would be a drop in replacement of the current EEPROM chip yes?
chip is so low power (made to run for years on small battery after all) it can power itself using parasitic/phantom power thru address/data pins
True, although when PWRGD comes up and system clock is running then the power usage will be much higher. Looking at a datasheet for a Samsung equivalent that gives the running current as max 30mA.
There now follows some random speculation, which might be best ignored...
It also gives the maximum input voltage as Vcc+0.5 so maybe input pins are clamped to that, so I assume that means that if an input is any higher then current will start flowing out of a Vcc pin, which will raise the voltage there. That would raise the PWRSTB# input, which would be needed to write/read. We know the IRQ14&15 appear to be stuck high, so possibly ~10mA was flowing in to those pins (happens to be where the hot spot was) to power the chip. Normal leakage current on input pins if the voltage is with 0V to Vcc is 10uA (1uA on the Opti datasheet).
Your list for POST_B looks to have a lot of stuff about resource allocation, do you think that might include somehow IDing IRQ assignments?
Maybe (and this mostly because I'm still obsessing about that hotspot on the 206)... Q1 failed, which cut a proper supply to the 206. The 206 was instead run by power coming in over IRQ14&15. That caused local heat problems and broke one of the input gates but otherwise left the chip undamaged and still able to be powered parasitically, so CMOS works. The broken interrupt input then causes a problem for mapping the PCI interrupts to the interrupt controller. The 822 has a register for mapping which of its IRQ outputs should be triggered for various inputs of the PCI INT[D..A]. So maybe (and having a quick look at the BIOS code, this gets way too hairy for me) the BIOS has a problem if it can't ID IRQ allocation because one of them is broken.
OTOH, looking at the mrbios listing of POST stages, all the interrupt testing comes later (stages 15-18). I don't see at what stage interrupts are actually enabled.
What does the POST_B routine say about loading the BIOS defaults from ROM? But as concluded before, if the ROM access wasn't working properly, we would not get very far would we? Or are these default values addressed in a different way?
AIUI, the defaults are stored in the BIOS code itself, which is being read from the ROM. So far no one's seen anything that looks corrupted and as far as I know the checksum is ok. Given that you can consistently get the same sensible looking output on the POST card, then it certainly looks like reading the ROM is fine.
Just to rule out yet another part of the equation, I will program the SST29EE010 Flash ROM with the same BIOS ROM dump and see if it makes any difference... it would be a drop in replacement of the current EEPROM chip yes?
Quick look at the datasheets and it should be fine. Only thing you may want to do is remove the pin 1 programming voltage Vpp select jumper entirely. The SST part has that as NC, and sometimes that means "don't connect", sometimes it means "not connected internally, so doesn't care". I haven't read the sheet closely, and it's probably not connected internally, so it should be fine. But since the jumper is just there then it's easy enough to remove.
Ok, exactly the same result with the SST29EE010 ROM, so at least it is consistent - and we have a subject for any modified BIOS ROM that we might come up with 😀
