VOGONS


First post, by feipoa

User metadata
Rank l33t++
Rank
l33t++

The AT PSU +5V pin P9.6, and only P9.6, seems to be overheating intermittently. It is on a DTK PKM-0033S motherboard which had some barrel battery leakage at one point. P9.6 gets up to 76 C, while P9.4, for example, will only be at 50 C, meaning that the other 5 V pins are not overheating. P9.6's temperature seems to slowly rise and fall, from 50 C to about 76 C over the course of a few minutes. It will burn your finger if touching the while plastic casing around wire. I have not noticed this in any other 486 motherboard. The problem is very repeatable and cyclic. The memory chips do not feel hot and MemTest passes without error.

Anyone experienced this before and know what to do about it? Perhaps one of the decoupling SMD capacitors is suffering from low-voltage breakdown and causing this strange shorting behavior?

From the attached image, you can see a fuse, inductor, and capacitor. At least I think that is a fuse. It has 3A written on it and may be opening and closing as the temperature rises, which would explain the cyclic behavior, but not what is causing the short.

Attachments

Last edited by feipoa on 2014-11-10, 04:55. Edited 3 times in total.

Plan your life wisely, you'll be dead before you know it.

Reply 1 of 539, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Well, F1 doesn't appear to be a PTC thermistor, so it is unlikely causing the cycling temperatures. Removing the capacitor CB3 did not eliminate the heating issue on the PSU's 5V line.

The little circuit shown in the above photo is such that Vcc from the PSU goes through L4, then in series through F1, then to Keyboard power pin 5. CB3 branches off at the L4-keyboard junction and goes to GND. Removing the keyboard after boot did not stop the cyclic heating issues.

Could the Voodoo Banshee be drawing so much cyclic current? I recapped the three 10 uF electrolytic caps which had any trace of battery acid on them. There are no bulging caps in the PSU. This issue only happens with this DTK board. I'm stumped.

Plan your life wisely, you'll be dead before you know it.

Reply 2 of 539, by JaNoZ

User metadata
Rank Member
Rank
Member

It is due to a bad connection in the connector, there is resistance or sometimes contact which cause small spark and cause heat.
Check it.
The f1 is just a small fuse, we also use them at work, it will just blow not recover.
Clean the contacts inside and on the mobo, also re-solder the connector at the mobo and maybe the inside wire to the inside connector pin.
If this will not solve you will burn the mobo, and capacitors and ic can go bad due to spikes on the 5v line.
Replace the psu.

Reply 3 of 539, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Replace the connectors on both sides. It's a bit strange that the other three red wires don't take over the load (are they not connected on one of the sides?)

1+1=10

Reply 4 of 539, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Thanks for the comments. I was using the term "fuse" very loosely. A PTC thermistor can sometimes be used in place of a fuse and would have explained this cyclic behavior, however F1's terminals remain shorted throughout the cyclic temperature process. So I am left to think it is just a regular fuse leading to the keyboard's Vcc.

Before any resoldering of connectors, I'll pull another AT PSU out from some other case. I don't think it is the PSU because this problem only occurs on this motherboard.

h-a-l-9000, I was thinking the same thing you were, so I checked the voltage on all four 5V pins of just an unconnected PSU, and they checked out OK. However, perhaps the connection between the other 5V pins is weak or loose. It is possible that connection to the other three 5V pins is made as the contact/wire heat up (75C), which drops the temp back down to 50 C, then when it gets cold again the contact is lost, causing the one good 5V pin to heat up again. This would mainly occur due to dissimilar metal types though.

Janoz, the board isn't so dirty with battery acid. The resistance between Vcc and GND is about 420 ohms when the PSU is not connected, which is pretty normal.

Plan your life wisely, you'll be dead before you know it.

Reply 5 of 539, by JaNoZ

User metadata
Rank Member
Rank
Member

I was talking about the at psu.
Check if the red 5v pins on the mobo are all connected to the same internal circuit, like should read 0ohms in between , and also check if the 5v wires of the at psu connector are all 0ohms and dont have any resistance in between.
Also i really would resolder the at power connector again, sometime you just cannot see solder cracks visible with the eye.
Btw clean the at power contacts with alochol and look for any visible burn marks that would have been led by bad connection an sparking causing the heat.
Also i think that a current draw of sparking 500mamps on a 5v can cause a heatup.

Reply 6 of 539, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Mystery solved. I removed all the connectors from P8 and P9. The red 5V pins looked like the first attached photo. They springiness of the connector is gone. I used pliers to re-bend the connector. The connector will probably flatten again as this PSU is my AT test-all supply. Anyone know the part number off-hand for these connectors?

I also cleaned the contacts of the MB and PSU connectors. No more 75 C. It is more like room temperature now.

As an odd consequence of fixing this, I can no longer use the maximum memory/cache timings for an AMD X5-160 without getting HIMEM errors. 486's are weird!

Attachments

Plan your life wisely, you'll be dead before you know it.

Reply 7 of 539, by carlostex

User metadata
Rank l33t
Rank
l33t

Yeah i just gave up on my 486 system and assembled a socket 7 system instead. As for me i gave up on AT PSU's as well. I found quite decent ATX PSU's with the -5V rail and got one of those in my 386 system.

Reply 8 of 539, by nforce4max

User metadata
Rank l33t
Rank
l33t

Typical in some ways when it comes to 486 era machines, a lot of cutting corners and age related issue so it is a wonder that people are able to get as many working machines as they do. SS7 is the way to go now days 😀

On a far away planet reading your posts in the year 10,191.

Reply 10 of 539, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Well, the board does work well with 256KB cache, the fastest settings, and AMD X5-160 - it is 1024KB cache and the fastest settings which now are not happy with the cooler PSU connector.

I've had trouble with SiS 496/497 boards working with 1024K, fastest timings, and AMD X5-160, but this particular DTK board was working like a champ until fixing the PSU connector overheating issue.

The only capacitor which ever felt hot was the small SMD capacitor shown in the OP photo. I could try replacing it.

I have already recapped the two larger caps near the CPU and the 3 electrolytic caps closest to the PSU connector, but there are quite a few SMD caps. I might temporarily remove all but one 5V line from the PSU connector to let it heat up again just for troubleshooting purposes.

Plan your life wisely, you'll be dead before you know it.

Reply 11 of 539, by 133MHz

User metadata
Rank Oldbie
Rank
Oldbie

The connector heating up was causing a voltage drop which means that the components were getting less than the full Vcc the supply was putting out. Now that you fixed them the voltage is a bit higher which might explain the instability at tighter timings. That's weird since it's usually the exact opposite - higher voltage leads to more overclocking headroom.

You could go through your PSU stash and look for the one with the lowest voltage on the +5V line or (better) find a really old one with voltage adjustment potentiometers if you are so inclined. 😉

http://133FSB.wordpress.com

Reply 12 of 539, by feipoa

User metadata
Rank l33t++
Rank
l33t++

I tried removing the other 5V pins to let the pin P9.6 heat up again, but 1024K, 40 MHz, fastest timings failed HIMEM still. The only other item of suspicion for why 1024K, 40 MHz, fastest timings no longer passes HIMEM could be because I accidently inserted the CPU in the wrong orientation for about 5s and powered up. I caught it pretty quickly though and there was no burning odor. 1024K was inserted in the MB at the time, but I am now using a different set of cache as a precaution. I am also using different RAM.

I am currently measuring 4.92 V on the 5V line w.r.t. GND. I am not sure what the issue is with the 1024K with fastest timings at 40 MHz. 1024K at 33 MHz and fastest timings passes HIMEM. 512K and 256K doubled-banked pass HIMEM at 40 MHz and fastest timings as well. It is just 1024K, 40 Mhz, and fastest timings which are not passing HIMEM now, but they did pass previously.

Oddly, MemTest passes two full rounds at 1024K, 40 MHz, fastest timings, but HIMEM does not. This is particularly strange since Memtest catches a lot more errors than HIMEM. Any chance HIMEM is faulty? HIMEM will pass at 1024K, 40 Mhz, and fastest timings if the timings are greatly reduced.

To add to the confusion, CTCM7 is unable to report 1024K L2 cache, however cachechk sees it. CTCM7 reports the correct amount of L2 cache when 512K or 256K are installed w/fastest timings at 40 MHz. CTCM7 also reports the correct cacheable L2 memory range for 256/512K in WT mode, that is 128MB for 512K and 64MB for 256K. For 256KB in WB mode, CTCm7 correctly reports 32MB chacheable L2 range. However, for 512K in WB mode, CTCM reports 128MB chacheable range, which is incorrect; it should be 64MB. For 512K/WB, CTCM7 thinks 1024K is installed, whereas CTCM correctly reports 512K.

1024K has always given me issues on PCI 486 boards. Has anyone been successful with HIMEM, CTCM, CTCM7, and Memtest using the fastest settings with an AMD X5-160? For a UMC 8881/8886 board, the fastest cachechk7 L1/L2/Ram-read/Ram-Write should be 165 / 75 / 48 / 83 MB/s, respetively. For a SiS 496/497 board, fastest cacheck7 L1/L2/Ram-read/Ram-Write should be 165 / 75 / 51 / 83 MB/s, respectively.

I suppose if I can't get this working with 1024K, 40 MHz, fastest timings, I will leave it as a 512K double-banked system in WT mode for 128 MB cacheable. I had been hoping for 128MB in WB mode with 1024K though.

EDIT: disabling the L2 cache and leaving the RAM at fastest settings passes HIMEM at 40MHz, so the issue is related to the cache controller not being able to handle the speed.

Last edited by feipoa on 2013-07-08, 12:53. Edited 1 time in total.

Plan your life wisely, you'll be dead before you know it.

Reply 13 of 539, by feipoa

User metadata
Rank l33t++
Rank
l33t++

And the plot thickens! 512KB L2 only works with the AMD X5-160 w/fastest BIOS settings when using double-banked UMC-branded cache. Winbond 15ns and 10ns causes HIMEM errors, but UMC passes without issue. This is very repeatable. Still, ISSI 1024KB works fine with AMD X5-133 using the fastest settings.

I'm starting to think that the 5 seconds of incorrect CPU insertion upset the cache controller on the motherboard just enough to disallow fastest setting at 40 MHz/1024KB.

Seeing how 1024K/40Mhz passes MemTest 2 rounds, but not HIMEM, I am wondering if anyone has experience with such a setup and found it perfectly stable in DOS/Windows? I am using HIMEM from Win98SE/DOS 7.1, so it is XMS version 3.0.

Again, 486's are weird, but I suppose figuring them out is half the fun.

Plan your life wisely, you'll be dead before you know it.

Reply 15 of 539, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Switching to a different AMD ADZ CPU didn't help. Some time ago I had an Intel DX4 CPU inserted incorrectly for some 15-20 seconds (in a different motherboard). The smell was horrible. The CPU survived and works well but the MB was dead.

Something has happened to this DTK board. It was not a fluke that it worked well w/AMD X5-160/1024K/fastest setting previously. I tested it for several days. I suppose if I was really ambitious I could replace every single component, DIP, through-hole, SMD one-by-one to find the fault, but I am not so ambitious.

Plan your life wisely, you'll be dead before you know it.

Reply 16 of 539, by JaNoZ

User metadata
Rank Member
Rank
Member

So probably the um8881 was stressed and gives up on tight timings.
Can you try cooling the chip down with a tec or freeze spray and see if it stays stable when it should vomit at that moment.

Seems/ed a nice board, it is a shame so many people here do kill their hw running with the wrong orientation.
It is not so hard to put it in the right way and take care.

Reply 17 of 539, by feipoa

User metadata
Rank l33t++
Rank
l33t++

The DTK PKM-0033S doesn't use the UM8881/8886, it uses a SiS 496/497. I've been working with this board over the past few days. I have hacked up the Zida Tomato 4DPS BIOS v1.72f to work on this DTK board. Now the DTK board seems to work with two 64 MB FPM sticks, 1024K, fastest timings, AMD X5-160. No HIMEM errors, Windows 98SE seems functional. I've tested a few graphics cards, USB cards, Intel NIC, PCI audio, ISA audio, and ISA ethernet cards without crashes. A max of three 64 MB FPM sticks work. The system doesn't turn on with four.

I removed the Funworld logo from the 4DPS BIOS and replaced it with the standard AWARD EPA logo. The important hack to the BIOS was the IRQ routing table. If you leave the standard 4DPS routing table in the BIOS and use it on the DTK board, the BIOS cannot seem to assign any IRQ to the PCI cards. The 4DPS BIOS was the closest match I could find to the DTK board - same chipset, same super I/O, no VLB. The only thing lacking is the 4DPS board has 3 PCI slots, whereas the DTK has 4. However, only 4 PCI masters are allowed. With the onboard IDE being 1 master, I think only 3 PCI slots are really usable. This particular 4DPS version fixes the 8 GB HDD size limitation, although I am still using an Ultra ATA PCI card on this system.

awdbedit was used to alter the IRQ routing table, but unfortunately I don't know all the INTA/B/C/D values used on the original DTK BIOS because the DTK BIOS won't open with awdbedit for whatever reason. I can open both BIOSes with MODBIN, but that only shows me the IRQ #'s used (see attachments). I am still stuck with the 4DPS INTA/B/C/D routing information. I need to somehow figure out how to interpret the HEX inside the DTK BIOS to find out what the INT's are and then put those into the 4DPS BIOS.

For now, the 4DPS BIOS works on the DTK with just altering the IRQ 6,7,8 numbers using awdbedit. IRQ's 9, 10, 11 get assigned to the PCI cards and the cards work in Win98SE, but PCI steering in Win98SE claims there is an error in the IRQ routing table - the consequence of this is probably just that Windows cannot reassign IRQs and we are stuck with what the BIOS presents.

Does anybody know a way to view the IRQ routing table for the DTK BIOS? I need the INT A/B/C/D values.

I also cannot use PCI slot #4. I was hoping to use it for a USB card for use with a USB/PS2 mouse, but since the system cannot assign an IRQ, it can't be used. But in reality, even with the DTK original BIOS, I got a hang-up when trying to use the 4th PCI slot as well.

When running the PCI bus at 40 MHz and using an ISA sound card, I found that using 1/4 clock setting for the ISA bus fixes crashing issues. Using the 7.1x MHz keyboard speed for the ISA bus caused eventual crashes when playing an mp3 in loop.

Now onto the good stuff. The 4DPS BIOS has a working PS/2 port. So I socketed the keyboard controller on the DTK board, and also socketed the 7406 inverter. I then proceeded to hook-up a HOLTEK keyboard controller in the exact same manner as on the 4DPS board. Note that the original 7406 inverter shown on the top right had some slight rewiring to change the double-inverter (buffer) used with a single keyboard to an inverter when used with a mouse configuration. Basically, I've hooked everything up just as it appears on the Holtek-HT6542B spec sheet for PS/2 mouse support. This is how the 4DPS boads have it hooked up.

I used mouse.com/test.exe to test the PS/2 mouse, but the system will hang right when I try to move the mouse or hit a click. Keyboard works fine though. I'm not sure what I'm doing wrong. I tried this with both the 4DPS and DTK BIOSes. My next step will be to try different PS/2 mice and check the wiring for a 4th time.

Attachments

Plan your life wisely, you'll be dead before you know it.

Reply 18 of 539, by feipoa

User metadata
Rank l33t++
Rank
l33t++

So far I have been successful in installing Win98SE and NT4.0 using a PCI SCSI controller. On the other hand, when using the Promise Ultra100 TX2 controller with an IDE drive and you go to shutdown Win98SE, the HDD powers down then up again before displaying "it is now safe to turn off your computer" message appears. I'm not sure if this is a Win98 issue, a Promise Ultra100 issue, or a motherboard-Promise conflict, or a grumpy HDD.

With the SCSI controller, Win NT4.0 installed without a hick-up, using the fastest RAM/cache timings, 1024K-WB, and 2x64MB RAM. Cautionary note - just because your computer works with the fastest BIOS timings using an AMD X5-160, doesn't mean the Cyrix 5x86-120 can also use the fastest timings. The Cyrix seems to have so much faster cache and memory performance w/40MHz FSB that sometimes wait states need to be injected. This seems to apply when using 512 or 1024K cache. 486's are fussy to optimise.

I'll re-investigate this PS/2 mouse issue some time. After using a serial mouse on this DTK board, I now appreciate how much smoother the tracking PS/2 mice provide.

The Secondary IDE port is non-functional. I'm not sure if this is due to using a different board's BIOS, or if it is a hardware issue. I never checked the secondary IDE port with the original BIOS. The primary onboard IDE port works fine w/Master+Slave.

Attachments

  • MODBIN_PS2.png
    Filename
    MODBIN_PS2.png
    File size
    14.33 KiB
    Views
    12004 views
    File license
    Fair use/fair dealing exception
Last edited by feipoa on 2013-12-02, 11:49. Edited 1 time in total.

Plan your life wisely, you'll be dead before you know it.

Reply 19 of 539, by NJRoadfan

User metadata
Rank Oldbie
Rank
Oldbie

I'm not surprised the onboard IDE is buggy, Many of those early PCI boards used the CMD-640 chip which never worked right. I was looking at doing the same mouse mod on one of my EISA boards which use PS/2 Mouse compatible AMI KEY controllers. I never found a clear explanation of how the keyboard controller is switched between "PS/2 Mode" and "AT Compatible Mode". Holtek and AMI's datasheets doesn't say how its switched. Did you wire up IRQ12 to the keyboard controller? Also, does the BIOS properly set the INT 11 BIOS Equipment flags? Most OSes directly probe for the mouse, but I know CuteMouse uses this to detect PS/2 mice.