Hodgkinson wrote:
You see those big clumps of caps near the processor? If I remember rightly the reason why we were given the board was because the original caps were leaking. That's our repair job (Including the rather more concerning point that all the caps that we used there are not low-ESR - The only ones we had - Whereas the originals were low-ESR).
Hmm, the pictures were sort of informative, maybe not in the way you were hoping.
That's a Via KT133A-based board; I had one too not too long ago (no real problems with the Matrox G200 installed in it, heh). It probably has the 686B southbridge with the obscure issue that can potentially cause major headaches with PCI peripherals. That
might be the issue with your USB card.
Or, depending on the chipset of the USB card, you could be running into a hardware quirk with the USB chipset... by awkward coincidence, Via is the manufacturer with a quirk that I'd expect to find on an add-on card, NECs seem to be the baseline for 'known good.' [I'd also assume the vendor drivers for Windows address or avoid the quirks, since the issues I'm thinking of appear to have been 'discovered' with *NIX... so that'd be more reason to question the PCI business first.]
On a similar note, I’m afraid I’m similarly inclined with regards to BIOS updates - From what we've heard there a last-minute resort if nothing else works, and are prone to ruining systems (Well, the last firmware update - As included on the CD and instructed in the manual - Made my MP4 player revert to Spanish menu's every time it was turned on. Fortunately I could take that one back for a refund)
Dodgy MP3 players aside, most BIOS updates just include patches pushed by (and tested by) the chipset vendor, CPUIDs for compatibility with newer processors, and fixes for any braindeadness in the configuration utility.
That board is worth about US$1 now, the final BIOS release probably happened 3 years ago, and some of the 686B's quirks could be mitigated in device configuration registers that get set by the BIOS. You might as well apply that last update and see if anything (particularly data integrity re: the USB card) magically improves.
Heh, on the subject of stuff not working, whenever you use the onboard USB, the machine never powers-off the PSU. Windows shuts down and there's a click, but the PSU stays on - Every single time. Don’t use the on-board USB, and it powers-off fine (Guessing it’s also a BIOS issue…).
See above; that is just plain odd, though. I'm not of a mind to try to figure out how the capacitor swap might contribute.
Anyhow, back to the graphics card:
I found some vague references to KT133A AGP VDDQ issues, but they aren't really clear. You'd also think a more modern 8x card that has to accept down to .8v would be tolerant in that regard.
It never hurts to turn the "Spread Spectrum" BIOS options off, if they aren't, particularly any relating to the AGP bus while you're questioning an AGP card.
As to the voltage question... I admire your tenacity, but if you're going that far, have you taken readings directly off the pins of the monitoring chip? I used to think the monitors had a huge margin of error as well, but after my little DDR2 adventure (admittedly on a much newer board, where such features might have developed much tighter tolerances) I'm inclined to suspect they might actually accurately reflect conditions at their point on the PCB. (Which, if a bias is being introduced somewhere, might be the reality for the other components on that PCB...)
Along with all that, I'd still try to find some way to test whether it actually is the card's graphics memory. Good luck with that, let us know if you ever find a way. :-?
