Continuation of my repair marathon. In this video it's about partially successful repair of the Mainboard Gigabyte GA-486VF Gigabyte GA-486VF @ UH19: www.win3x.org/uh19/motherboard...
I couldn't get this mainboard completely running yet, but I will come back to it as soon as possible. Two days of the repair marathon were just too short to do such deep investigations and to be able to fix all five mainboards. I think, that I was too tired in the end to have good ideas. But please, don't be worried, if I have any news on this one, I'll do a short update.
This is definitely the best repairing channel on youtube for vintage hardware! Thank you for all your work and sharing this here. Love all your vids. Cheers from Austria 🇦🇹
Die Retourkutsche ;) Thank you Peter, but I think, it's not quite true, there are plenty of repairing channels out there, which are really good. But what I told about your channel is really true, there is not much of what you can find on YT in regards of retro-CPUs, what would be on par with your work. No jokes.
@@necro_ware After seeing a whole lot of your videos now I would like to agree with Mr. CPU Galaxy. You are definitely the best PC hardware repair channel. There are some awesome channels out there like Branchus Creations (he fixes incredibly dead Mac boards). Or Adrian Black who loves going down the rabbit hole to it's end. But they are not so centered on IBM compatible hardware, more Mac and homecomputer stuff. Especially Adrian, who is incredibly good, is quite often a bit out of his depth when it comes to PC stuff. I'll let you know when I find somebody who makes you look like noob. :P Until that you're the best :P
@@catriona_drummond thank you very much! I'm glad, that my channel matches your taste, but still, a lot has to happen to be the best. I'm still very happy to be just good ;)
I had an issue with an old Packard Bell PC regarding cache. When I added 32Kbx8 at 15ns to the board with a TAG chip the system would freeze after the BIOS tests passed. I checked all of the cache ICs and they all passed testing with no issues. So I gave up on it and left the cache off of the system. Later I decided to come back and try again. But instead of 15ns ICs I used 20ns ICs. The chips were still 32Kb x8. And with that, the board started working fine. I have no idea as to why the faster chips wouldn't work but the slower ones did. I would have assumed the exact opposite to be true, honestly. But I thought I would share my experiences with strange cache issues. Maybe you have already tried this, but did not document it in the video. Either way, I am super impressed with your ability to fix these boards, and wish to applaud you. I have two boards here that I cannot get to function that I wish I had someone who could fix them, but I don't have anyone close by to help me with them any longer.
Thank you for sharing it. I tried different ICs with 15ns and 20ns latency, unfortunately nothing worked. But I'll try to analyze this issue further. As in your case, may be your 15ns ICs were just faulty? Could that be?
@@necro_ware that is always possible when working with old hardware. I did test them and they passed testing, so I cannot rightly say. But it is interesting how a part that works in one system and passes all tests causes another system to fail completely.
Spitzen Arbeit! Wie immer. Freue mich auf jedes Video. Den LT38C41 gibt es glücklicherweise für relativ kleines Geld als Ersatzteil. Das L2 Cache Problem ist wirklich merkwürdig. Da das Board gar nicht damit läuft, werden wohl die Bits kräftig durchgewürfelt und erzeugen 'Datenmüll.
Vielen Dank. Ja, der Controller sollte ersetzbar sein. Wobei, neu kann ich den nicht kaufen, weil ich kein passendes ROM dafür habe und ohne wird es nicht funktionieren. Der Controller muss ja wissen, dass der ein Tastatur Controller ist :) Was den Cache angeht, da muss wieder mit dem Oszi dran, sowas ist nicht unbedingt einfach herauszufinden und ich werde wohl mehr Zeit brauchen....
I'm trying to get better, but I am still highly disappointed by my editing skills, so I hope my repair skills are at least better :D Thank you very much!
Thanks for your videos. Interestingly, I've got exactly the same problem on a similar motherboard. Mine has the same model number, but has 4 72pin memory slots. It boots fine with cache disabled and hangs at the exact same point with any cache configuration. The difference is that my board used to work before I tried to replace the cache chips (wanted to try 512kB instead of 256). I sort of suspect that a static discharge destroyed something in the chipset, but I'm not sure 100%.
Yes, this is my fear about this board as well. I will have to take some time later and analyse it with the oscilloscope. Such problems are not the easiest task to do, that's why I had to make a break here.
I had a similar problem with cache, but on an Opti base motherboard. The problem was solved by starting in turbo mode. Just shorted two pins and it started booting.
@@UnclePriff Tried that already. With turbo, without turbo, also with different FSB settings as well. Unfortunately, all the same. I don't think I will be able to solve it without making an oscilloscope session ....
when the cursor pauses on the parallel port configuration, the value changes. at one point it was 3BC, and another it was a more common 378. this can indicate something causing the base address to change from installed devices. if you weren't moving expansion cards around, that's a bit strange.
I was playing around with different controllers as well, as I made the recordings, so that's all right. If you are interested, what was the issue, just watch the last part of the repairathon, where I come back to this board.
So close mate I think if I could make a suggestion with the cache I have heard of the flatpak chipset controllors being a issue but also a combo of that and cpu but again it wouldn't surprise me if there is some kind of easy silly problem to fix like a dodgy trace or connection of some form but I am sure you will find the answer and I could be completely wrong but I will await to see what the issue is I am speculating about my ideas but none the less you are more qualified to say none the less. cheers
С кэшем надо ещё в BIOS установки сделать. Объём тег-кэш должен соответствовать режиму, WB требует в 2 раза большего объёма, чем WT. П.С. До начала загрузки ОС, на всех материнских платах, кэш отключён. With the cache, you still need to do the installation in the BIOS. The volume of the tag cache must correspond to the mode, WB requires 2 times more volume than WT. P.S. Before starting OS loading, on all motherboards, the cache is disabled.
Всё установленно как надо, тэг в порядке, кэш в режиме WT. 10 раз проверял, перепроверял. Думаю, что на шине данных какая-то дичь... будет время на осцилоскопе покручу. Но спасибо за идеи!
You need a TAG-SRAM for this to work. If i could see it correctly all cache DIPs are of the same type. That wont work. The extra Socket is for an TAG SRAM type of DIP. And if not inserted correctly, it can even damage your SRAM chip.
That's unfortunately not correct. Tag SRAM is the same SRAM as any other and not some kind of special chip. You just need to pay attention which size it has. If you install up to 128K cache, it's sufficient to have 8K TAG, but allowed to have more. If you have 256K or more, you need 32K TAG. That's what I have used here, 8 + 1 SRAM chips 32K each. You are right in regards of polarity though, if you put the ICs the other way around, they will die with high probability. This mainboard has a defect, it's definitely not because of wrong configuration or wrong cache ICs whatsoever. Meanwhile I have a trace, why this might fail. I'll try to make an update video, when I have some time again.
@@necro_ware I had many experiences with the TAG-RAM being special and overheating in normal Sockets. And i had the same problem in our school because my techear didnt know about this either. Only after correcting this issue the system was able to boot. Again. And the TAG-RAM in the wrong socket ran very hot. Dont forget that many mainboards of this time dont want to see cache at all (Fake) or want to have their special fake cache installed. If not installed, they wont boot either. Packard Bell sold many of thos with fake Cache and without an upgrade option. And no, they where not installed the wrong way around. On nearly every mainboard i saw the TAG-Ram had a diferent model number than the cache itself. And i had many 486 grade motherboards. I tunded them like crazy.
As you may be can think, it's not the first time for me too, Hubert. Just believe me, the mainboard is already running again and it was not the issue. Still thank you very much for your feedback, I guess any idea is better, than no idea at all....
@@necro_ware Thats pretty Ok. And it is not as i would not believe you either. I only want to say you should be careful, especially with cache. Many mainboards of this age are garbage or dont support cache at all. Or use fake cache modules etc. And there are these phenomenons i have had at this time.
@@huberthans4312 All of this mainboards are still a lot younger, than me :D And I'm tinkering with them as long as I can remember. I can ensure you, that the cache I used in this video is not fake, I repaired already hundreds of boards and the chips I showed were all salvaged and tested over the years and not ordered from Asia. Also this mainboard supports (this) cache just fine. The mainboards, which were often fakes and didn't work properly with cache were PC Chips. I always try to keep far away from the products of that company. There you can get all kind of mind blowing surprises indeed. Once again SRAM is SRAM and there is nothing like SRAM-TAGs. The reason why companies used another chips for TAGs is, because TAG size can be smaller, than the actual cache ICs. If slow cache ICs were used, then at least the TAG should have had faster timings, than the rest. It was all about saving money, that's why they used different chips for that. SRAM was quite expensive, and if you needed faster ICs, then at least you could take smaller ones. In my case I have already all ICs in 32K and with 15ns latency, which is more, than enough for FSB of 33MHz, which I'm using on that board. Anyway, as I already said, this board is running again. The issue for the cache was dead address line. Also I found, why the replacement keyboard controller was not working. Now the board is fully functional again and I tested it already with DX2-80. As soon as I'll have some time, I'll do an update video on this topic.
Hi, maybe a cache timing Problem? Can you test 7ns chips? I know, 15ns just be OK for 33mhz bus, but its only for testing. Timing settings in BIOS can also have an affect.
15ns is the fastest I have and I really think, that 15ns is already more, than enough for 33MHz FSB. Even 20ns is fully sufficient. I put this board to the side for a little time and will come back later to it again. Since I made this marathon, I already got some ideas, which I should check..... Sometimes it just need some time. Honestly, working on 5 mainboards in one weekend is a bit exhausting. May be I was just a bit tired, as I was struggling to make it working..... ;)
15ns might be ok, left bank is bank0 and here are the jumper settings: www.motherboards.org/files/manuals/47/486vs8a.pdf. Please check out page 20. I hope you tried not china Fake Chips ;-)
@@patrickbonner3764 I tried many ICs and I have no China SRAMs anyway :) I had the jumper setting from UH19 project already, see the link in the video description. However, thank you fro the PDF. I'll upload it directly to UH19, if you don't mind.
Great work. Regarding cache, I would consider putting 7 or 8 ns chips in there. Also, what about fiddling with cache settings in BIOS? I mean putting chips in and disabling cache in BIOS etc. What about 64kB cache - did it also give that result? Is it possible to set cache timing in BIOS?
Thank you. 15ns ICs are the fastest I have, but for 33MHz FSB, they should be more, than enough. Playing around with BIOS settings didn't help. I tried 64KB cache, just in case, but it is officially not supported by this board. Only 128-256KB. I still think, it's some kind of defect, but I need more time to analyse it. Such a marathon is just to short for deeper investigation. I'll come back to this board as soon as possible and will make some analysis with oscilloscope. It was just not doable in two days :)
adding a keyboard controller to these boards simply either disables the chipset one or the chipset disables the other one . needless to say it 99 percent of time wont hurt the board
Maybe the board had fake cache chips.. So the bios could be also locked for the real cache chips. Maybe you need another bios rom for that board with those real cache installed.
I tested multiple BIOS versions. Also Gigabyte was not famous for faking something. Furthermore, this mainboard was really high end for it's time with support for DX4, Cyrix, 3V, WB and WT Cache. I'm sure there is something broken.... I just need some more time for investigation. Two days marathon was just too short to repair 5 mainboards :D
