Code suggests keyboard controller.
I would check pins / traces from the at socket to the controller. Continuity test with a multimeter if you can.
Is the keyboard controller socketed? If it is remove and deoxit/ isopropyl clean it.

Thanks for the suggestion!

But I tested the board without any RAM modules installed and the POST cards also shows "04, 05" for last POST codes ("04" is for "Test memory refresh toggle" according to Award ver. 4.51PG POST codes) and I thought - maybe the problem is with the RAM or cache chips (also checked these with T48 and they're fine).

The traces to the keyboard controller's pins and the solder joints are fine and If the problem is really in the keyboard controller chip itself, then I have nothing more to do with this board as I don't have any spare keyboard controller chips 🙁

Actually I can desolder this allegedly problematic controller chip, solder a 40-pin socket and install some borrowed keyboard chip from another working motherboard 😁

Any beeps from the pcspeaker?

Pickle wrote on 2025-04-29, 19:28:

Any beeps from the pcspeaker?

Nope.

I've just replaced the keyboard controller with brand new (old stock) VIA-II VT82C42N chip, but unfortunately this did not resolve the problem. The POST code sequence when powered on is still the same: 0C, 01, 02, 03, 00, 04, 05 - hanging at 05. I can barely hear a very quiet noise from the PC-speaker - something like "popping" or "crackling".

Any ideas what to try next?

Are these VIA-II VT82C42N KB-controller chips same as VIA VT82C42N?

A CR2032 holder can be added easily by soldering it´s "-" connector to the ground trace of the mounting hole near the KBC from the backside. (Push the holder as far towards the ISA slots as possible while soldering.)
If you don´t need this mounting hole that is...

These mainboards are quite reliable and "humble" in general, they are still VERY picky about RAM sticks. Have you made sure you are using FPM sticks in a combination and organisation that´s documented in the manual?

Thank you for the input, majestyk.

majestyk wrote on 2025-07-12, 04:19:

A CR2032 holder can be added easily by soldering it´s "-" connector to the ground trace of the mounting hole near the KBC from the backside. If you don´t need this mounting hole that is...

I can solder a CR1225 battery holder in place of the original BR1225 battery, but I'm a "practical lazy" person, so I usually look to avoid unnecessary actions and that's why I left adding a CMOS battery holder aside 'til the motherboard is "alive". I have no idea if the missing CMOS battery could preven FIC 486-GVT-2 board from normal POSTing (I have a Zida s.7 430TX mobo which doesn't POST without healthy CMOS battery installed). Now I'm thinking for temporary soldering (with wires) of CR2032 battery holder just to test if the missing CMOS battery is the culprit.

majestyk wrote on 2025-07-12, 04:19:

These mainboards are quite reliable and "humble" in general, they are still VERY picky about RAM sticks. Have you made sure you are using FPM sticks in a combination and organisation that´s documented in the manual?

I already tried all of my 72-pin FP-RAM sticks and the result is always this hang at POST code "05", which seems to be before any memory check/initialization: 0C, 01, 02, 03, 00, 04, 05 (POSTing stops always here). So I don't think it's a memory related problem.

Does "Award PnP BIOS" (what a stupid alias) mean Award BIOS ver. 4.50(P)G? Or I really have to check the POST codes meanings to ones for Award BIOS ver. 4.51PG?

I assume your settings are like this?

majestyk wrote on 2025-07-12, 06:17:

I assume your settings are like this?

The attachment gvt2_dx2.JPG is no longer available

Thank you for the photo with the jumper settings.

Some time ago I compared the jumpers to the picture in this post and also according to the full version of the user's manual available at TRW site.

I'll compare the settings again to yours later and I'll write back.

P.S. The i486 DX2-66 CPU I'm using may be different. I think mine is P24S - SL Enhanced, write through cache. The CPU markings are these: &E5V1X SX911 . In cpu-world there's a note: "The processor requires 1x external clock", so definitely I have to check all the CPU related jumpers again.

majestyk wrote on 2025-07-12, 06:17:

I assume your settings are like this?

The attachment gvt2_dx2.JPG is no longer available

Once again, thanks for the picture with jumpers settings. Checked all of them and everything is set correct for 486DX2-66 (P24S - SL enh., WT cache).

Again tested the board with couple of different FP-RAM sticks and with no RAM installed - the result is all the same: POST codes 0C, 01, 02, 03, 00, 04, 05 (hang).

I still have no clue which are the valid explanations for Award 4.50G POST codes, but in both cases ("Award PnP BIOS" and 4.51PG) POST code "05" leads to KB-controller problem.

I don't know if VIA-II VT82C42N is later rebrand of VIA VT82C42N KB-controller chip or they're different, so that VIA-II VT82C42N chip is incompatible with this board while VIA VT82C42N works fine.

And what if some of the cache chips is bad? Can this damn thing boot without any cache and TAG chips installed?

What if the PAL chip PALCE16V8B is bad?

Still didn't tried with CMOS battery installed.

What can I try next?

Without any RAM my GVT-2 stops after 05-04, 00-C1.
It even starts with one single 72-pin stick with 8 chips and 4MB.

Without the PAL there´s absolutely no POST activity.

To rule cache out you can safely start the system with all cache and TAG chips removed.

My KBC (Intel Megakey) is also soldered so I can´t simulate what would happen without it.

majestyk wrote on 2025-07-12, 11:13:

Without any RAM my GVT-2 stops after 05-04, 00-C1.
It even starts with one single 72-pin stick with 8 chips and 4MB.

You know, that when POST code analyzer card is showing "05-04", the last POST code is "05" and "04" is the one before it. Also, by using the only button on the card you can see all the POST codes passed in both descending and ascending order.

So, your "05-04" POST codes, when no RAM is installed, are exactly the same as my last two POST codes. And maybe I have some issues with the RAM.

Can you check if the full stream of POST codes is like mine "0C, 01, 02, 03, 00, 04, 05 (hang)" (first to last) when you power on your board without any RAM installed?

majestyk wrote on 2025-07-12, 11:13:

Without the PAL there´s absolutely no POST activity.

Ok, PAL chip goes out of suspected components list.

majestyk wrote on 2025-07-12, 11:13:

To rule cache out you can safely start the system with all cache and TAG chips removed.

I'll try this, but I have no idea what to do with the jumpers for the cache setting.

majestyk wrote on 2025-07-12, 11:13:

My KBC (Intel Megakey) is also soldered so I can´t simulate what would happen without it.

Yeah, because of first confirmed suspect - the original soldered "(C) 1985-92 MEGATRENDS MEGA-KB-H-WP" KB-controller chip, I desoldered the original chip and installed a 40-pin DIP socket. After this I borrowed some socketed AMI KB-controller chip from even older 386SX board, but unfortunately I installed it shifted by one pin... And that's why I ordered two VIA VT82C42N replacement chips, but in the end I got new (old stock) VIA-II VT82C42N KB-controller chips instead of VIA VT82C42N (typical ali-baba-and-the-40-thievs situation).

I got so many problems and lost time with this cursed board. I already want to slam the damn board into the ground as hard as I can and never to deal with it again 😁

00, C1, be, 08, 07, 06, 05, 04, 00, 03, c0, end

Thanks for your cooperation and all the help for solving the problem!

majestyk wrote on 2025-07-12, 12:39:

00, C1, be, 08, 07, 06, 05, 04, 00, 03, c0, end

This definitely differs from my "0C, 01, 02, 03, 00, 04, 05 (hang)", but I'm using the original Award BIOS core 4.50G (ver. 3.03). I'll switch to Award BIOS core 4.51PG (ver. 3276GN1 beta) and check if something in the POST codes for it matches your pattern. But this will be another day. I really hate this board and I'm fed up with its problems for today 🙁

Don’t smash the board yet! 😉

I agree with pickle’s reply that POST 05 on the Award v4.50G BIOS is all about the motherboard keyboard controller.
In POST_05 the BIOS commands this type 8042 controller to perform a selftest and checks if the result is correct. It then commands the keyboard controller to assume its normal function and enables the controller. Again the result of these commands is checked.

If any of the above fails, POST is halted.

For troubleshooting, apart from replacing the keyboard controller and checking its power supply, I would look at the control and data lines between the controller and the VT82C482 “southbridge”. The I/O ports 60h and 64h used to talk to the keyboard controller usually run through this IC.

Happy tinkering!
Jan

The things I managed to exclude so far from the repair scope are: missing CMOS battery (even if no one gave a single line if this mobo will POSTing normally without it); bad or damaged KB-controller chip and the nearest traces to it; bad cache chip - yesterday I retested them again with my T48 programmer; bad PAL chip; bad or incompatible RAM modules. Many thanks to majestyk!

So I'm back to where I started: KB-controller problem - hanging at POST code "05".

Chkcpu wrote on 2025-07-12, 19:55:

Don’t smash the board yet! ;) […]
Show full quote

Don’t smash the board yet! 😉

I agree with pickle’s reply that POST 05 on the Award v4.50G BIOS is all about the motherboard keyboard controller.
In POST_05 the BIOS commands this type 8042 controller to perform a selftest and checks if the result is correct. It then commands the keyboard controller to assume its normal function and enables the controller. Again the result of these commands is checked.

If any of the above fails, POST is halted.

For troubleshooting, apart from replacing the keyboard controller and checking its power supply, I would look at the control and data lines between the controller and the VT82C482 “southbridge”. The I/O ports 60h and 64h used to talk to the keyboard controller usually run through this IC.

Happy tinkering!
Jan

Hi, Jan! Yesterday after all the tryouts with zero change in the final result (I would be glad even if the mobo stops POSTing at all when I try different things with it - at least this should point me at some more specific area to focus on) I had a little frustration with this damn board and I already wrote that I absolutely don't like it, when we discussed my "modified" (actually messed-up) Award BIOS 4.51PG beta version for it. And now you gave me a proper direction on which I have to focus my efforts, so I'll not break apart the mobo or scrap it 'til it's proven as 100% non-repairable. For now it's just a cursed "toy" to tinker with 😀

I know nothing about these "MCS-48" family controller chips and never had to deal with them before. Can you give me some info on which pins are these important data lines and about these I/O ports 0x60h and 0x64? Unfortunately I don't have a proper oscilloscope at home (just a cheapo chineese "digital oscilloscope" with very limited working range of 0 – 200 kHz, which is useless in PC part repairs) and my primary diagnostic tool is a descent digital multimeter. I also have some a 3.3/5 V logic tester probe, which I never used before, but I don't have an idea if it will be usable for those data lines testing.

P.S. So Award BIOS 4.50(P)G POST codes are same as 4.51PG, right? Then what version is this stupid "Award PnP BIOS", if it's probably for late 486 or early Pentium boards with PnP support?

analog_programmer wrote on 2025-07-13, 04:52:

I know nothing about these "MCS-48" family controller chips and never had to deal with them before. Can you give me some info on which pins are these important data lines and about these I/O ports 0x60h and 0x64? Unfortunately I don't have a proper oscilloscope at home (just a cheapo chineese "digital oscilloscope" with very limited working range of 0 – 200 kHz, which is useless in PC part repairs) and my primary diagnostic tool is a descent digital multimeter. I also have some a 3.3/5 V logic tester probe, which I never used before, but I don't have an idea if it will be usable for those data lines testing.

The attachment VIA_VT82C42_pinout.jpg is no longer available

P.S. So Award BIOS 4.50(P)G POST codes are same as 4.51PG, right? Then what version is this stupid "Award PnP BIOS", if it's probably for late 486 or early Pentium boards with PnP support?

First, I have to correct my previous remark about the connection of the keyboard controller to the VT82C482 chip. Looking at the System Block Diagram in the GVT-2 motherboard manual, it appears that the VT82C482 is just a buffer chip for the ISA Bus.

The BIOS, RTC, and 8042 KBC are all controlled by the main VT82C486A chip via the 'XD' bus. The VT82C486A even has an internal KBC, but it is not used here. However, this makes it very likely that the I/O port 60h/64h decoding for the KBC is done in the VT82C486A and that this chip selects the lines that address the 8042 KBC via the 8042’s A0 (9) and CS# (6) pins.

Because the communication between the Chipset and the 8042 KBC seems to be severed, a multimeter and a logic probe should be fine to troubleshoot what is broken here.
When the connections to GND (pin 20) and +5v (pin 40) are good, first check if Reset# (pin 4) goes high to let the KBC start.
The next check would be for a clock signal ( 6 to 12MHz) on pin 3. I don’t see an Xtal near the KBC, so I expect an external source like the FSB clockchip, to supply this clock signal. The logic probe should tell you if pin 3 has a signal, or is constantly low or high.
The same goes for the 8 Databus signals, pins 12-19. There should be activity on each of them, at least until POST is halted. If not, a continuity check with the corresponding dataline on the BIOS chip, using the multimeter, should reveal if a dataline is broken. I assume that there is no buffer chip in between that prevents this check. 😉
Then there also should be activity on the RD# (pin '8) and WR# (pin 10) lines, especially during POST 05!

I expect this gets you underway. Hopefully you have a know good KBC to start these tests with.

About the POST code lists, I find them often confusing.
The POST codes for the compressed Award v4.50PG and v4.51PG are practically the same. The “P” stands for PnP so these are the later S5/S7/Slot 1 Plug&Play BIOSes.
The “Award PnP BIOS” list seems to be for non-PnP BIOSes, like the uncompressed 486 and early S5 Pentium v4.50G BIOSes. So this incorrectly named list is mostly applicable for your GVT-2 case. 😉

Cheers, Jan

Chkcpu wrote on 2025-07-14, 19:45:

First, I have to correct my previous remark about the connection of the keyboard controller to the VT82C482 chip. Looking at the […]
Show full quote

First, I have to correct my previous remark about the connection of the keyboard controller to the VT82C482 chip. Looking at the System Block Diagram in the GVT-2 motherboard manual, it appears that the VT82C482 is just a buffer chip for the ISA Bus.

The attachment FIC 486GVT-2 Block Diagram.png is no longer available

The BIOS, RTC, and 8042 KBC are all controlled by the main VT82C486A chip via the 'XD' bus. The VT82C486A even has an internal KBC, but it is not used here. However, this makes it very likely that the I/O port 60h/64h decoding for the KBC is done in the VT82C486A and that this chip selects the lines that address the 8042 KBC via the 8042’s A0 (9) and CS# (6) pins.

Because the communication between the Chipset and the 8042 KBC seems to be severed, a multimeter and a logic probe should be fine to troubleshoot what is broken here.
When the connections to GND (pin 20) and +5v (pin 40) are good, first check if Reset# (pin 4) goes high to let the KBC start.
The next check would be for a clock signal ( 6 to 12MHz) on pin 3. I don’t see an Xtal near the KBC, so I expect an external source like the FSB clockchip, to supply this clock signal. The logic probe should tell you if pin 3 has a signal, or is constantly low or high.
The same goes for the 8 Databus signals, pins 12-19. There should be activity on each of them, at least until POST is halted. If not, a continuity check with the corresponding dataline on the BIOS chip, using the multimeter, should reveal if a dataline is broken. I assume that there is no buffer chip in between that prevents this check. 😉
Then there also should be activity on the RD# (pin '8) and WR# (pin 10) lines, especially during POST 05!

I expect this gets you underway. Hopefully you have a know good KBC to start these tests with.

This is great, thank you for all these detailed explanations!

I just checked with multimeter the connections for data lines between the KB-controller and the BIOS chip pins - respectively KBC - BIOS: 12 - 13, 13 - 14, 14 - 15, 15 - 17, 16 - 18, 17 - 19, 18 - 20, 19 - 21 and they're all good "beeping", so BIOS and KBC have to "talk" to each other.

The voltage on pin 40 of the KBC is +5 VC, ground on pin 20 is also OK. BIOS chip (NM27C512 with 28 pins) also receives +5 VDC at pin 28 (pin 32 on the BIOS socket is +5 VDC too), and ground at pin 28 is good.

Actually, KBC XTAL2 (pin 3) connection is passing through L7 (filter?) and how knows where it goes to, and XTAL1 (pin 2) is connected to ground, so this must be the schematic used for the frequency line:

As for the logic probe tests... There is a reason I've never used my cheapo 3.3 V/5 V logic tester probe before. It came without any "manual", schematic or even note and I can't find any clue on how to properly connect the four power pins to +5 VDC, +3.3 VDC and ground (there is a marking which pins are ground and which are positive power pins, but it's absolutely not clear which one of the two positive power pins is +5 VDC and which is +3.3 VDC). And I don't want to fry any motherboard because of this cheap tester. I'll be very happy if someone can clarify the power connections of this logic tester probe, this is how it looks like:

So, unfortumately the further logic/signals tests will be suspended 'til I figure out how to connect this stupid chineese "engineering marvel" 🔌

Chkcpu wrote on 2025-07-14, 19:45:

About the POST code lists, I find them often confusing.
The POST codes for the compressed Award v4.50PG and v4.51PG are practically the same. The “P” stands for PnP so these are the later S5/S7/Slot 1 Plug&Play BIOSes.
The “Award PnP BIOS” list seems to be for non-PnP BIOSes, like the uncompressed 486 and early S5 Pentium v4.50G BIOSes. So this incorrectly named list is mostly applicable for your GVT-2 case. 😉

Well, I knew it, that "Award PnP BIOS" sounds suspicious, but wait... not a PnP BIOS at all 😁 Actually, you reminded me (again) which Award BIOSes are PnP - if they have the letter "P" after the core version. Thanks for the clarification, I'll stick to POST codes for "PnP" non-PNP BIOS (the original ver. 3.03g for this board). I'll not use the latest beta BIOS (ver. 3.276GN1 ) with the 4.51PG core while I'm trying to fully revive the mobo.