myne wrote on 2026-06-06, 00:28:

yay
So... I was accidentally on the right track when I asked about the xtal 🤣

Well maybe it helped indirectly by making me wonder what's that OSC pin... 😁

Apparently most Sound Blasters don't use that as they have their own crystal oscillator, but AWE64 does need it. I guess it was some cost-saving measure.

myne wrote on 2026-06-06, 00:29:

Now you have to write a how to guide for the next guy in 6 years who googles "how do I...?"

I already wrote about it on this thread, where it might be easier to find than here.

ADD AN ISA SLOT TO A MOTHERBOARD ???? Gigabyte Ga-7ZX

Chkcpu wrote on 2026-05-31, 19:47:

Thanks for reporting your test values. So a 2.2V setting was not among them, but you found a nice 2.04V setting for a K6-2+! :) […]
Show full quote

Thanks for reporting your test values.
So a 2.2V setting was not among them, but you found a nice 2.04V setting for a K6-2+! 😀

I’m sorry to hear the board won’t boot. The CMOS backup battery inside the DALLAS or BENCHMARQ RTC chip is probably dead. This sometimes causes a board to stall early during the Power-On-Self-Test.
Do you have a POST analyzer card to see where the boot process hangs?

Cheers, Jan

Ok, I got the board working again. It must have been the RTC, because it posts now with the external battery hooked up. I continued testing. Here are more results (minus what is already documented in the manual):

(Previously tested)
JV4-5 OPEN JV6-7 CLOSED 1.93v
JV4-5 OPEN JV6-7-8 CLOSED 1.73v
JV4-5 OPEN JV7-8 CLOSED 2.04v
JV4-5 OPEN JV6-8 CLOSED 1.95v

(More tests)

JV4-5 OPEN JV6-7-8 OPEN 4.05V
JV5 CLOSED JV6-7-8 OPEN 3.60V
JV4 CLOSED JV6-7-8 OPEN 3.51V

JV5 CLOSED JV6 CLOSED 2.06V
JV5 CLOSED JV7 CLOSED 2.19V
JV5 CLOSED JV8 CLOSED 2.22V
JV5 CLOSED JV6-7 CLOSED 1.77V
JV5 CLOSED JV6-7-8 CLOSED 1.65V
JV5 CLOSED JV7-8 CLOSED 1.85V
JV5 CLOSED JV6-8 CLOSED 1.79V

JV4 CLOSED JV6 CLOSED 2.05V
JV4 CLOSED JV7 CLOSED 2.17V
JV4 CLOSED JV8 CLOSED 2.20V

So at this point it seems pretty clear that everything open gives you the highest voltage (I didn't want to push the P166MMX I had in there too much with further high voltage tests) then JV 5 drops the voltage by a certain factor, JV4 by a little more, probably JV4 and 5 both closed is going to bring it down even further, and the JV 8, 7, and 6 drop the voltage further incrementally more in that order, with combinations being additive.

So then just to be clear, even though I can derive the 2.2v for my K6-2, you would advise against running it on this motherboard, due to the heat issues on the voltage regulator? Bigger heatsink on it or active cooling probably wouldn't make a difference?

sizzlinbeef wrote on 2026-06-09, 17:52:

So then just to be clear, even though I can derive the 2.2v for my K6-2, you would advise against running it on this motherboard, due to the heat issues on the voltage regulator? Bigger heatsink on it or active cooling probably wouldn't make a difference?

Thanks for all Vcore test details! Now you have a lot of values to choose from. 😀

About the useability of the 2.2V setting for a K6-2, this depends a lot on the Power transistor that regulates the Vcore, and how it is cooled. Can you tell us the part number of transistor you did the voltage measurements on and also look at the other power transistor next to it?
This may help answering your question.

Note that under load the Pentium-MMX 233 can draw up to 6 Amps at 2.8V, but the K6-2/400 consumes up 11 Amps at 2.2V. The regulator transistor must be rated to handle this current, otherwise it will quickly fail.
Then there is the amount of heat that is generated and needs to be removed by the heatsink. On these boards, the power transistor that regulates the Vcore is usually supplied by the 5V rail from the PSU.
For the 2.8V Pentium-MMX the voltage has to be lowered by 2.2V, so at 6 Amps this will cause 13.2W of power to be generated in the regulator transistor.
For the 2.2V K6-2/400, this will amount to 2.8V times 11 Amps is 30.8W!

I hope this illustrates my concern for the linear regulator on this board. 😉
But if the regulator can take the current, a bigger heatsink and active cooling could make a difference.

Cheers, Jan

Both regulators are Linfinity LX8384-OOCP 9639.

And if going by the datasheet, where you calculate the maximum allowable thermal resistance of a heatsink, since the C/W goes into the negatives for the 30.8W of the K6-2, I'm guessing the answer is no, don't try it.

Chkcpu wrote on 2022-01-24, 21:44:

The x4 multiplier […]
Show full quote

The x4 multiplier

During POST, just after the BIOS has measured the CPU speed, there is a routine that determines the bus_speed (FSB). This bus_speed value is then used to program the chipset’s DRAM and L2 cache timing registers for optimum performance and stability.
The BIOS calcutates the bus_speed by dividing the CPU speed by the multiplier of the CPU. As shown above, the multiplier is stored in CMOS 3Fh bits 7,6 during CPU detection. These 2 bits can have 4 possible combinations:

The attachment Multi x4 bits defenition.png is no longer available

The 4th combination (both bits set) is not used in the original BIOS and can be used to indicate the x4 multiplier. For this to work, the code that divides the CPU speed by the multiplier has to be patched:

The attachment Multiplier x4 patch1.png is no longer available

At the start of this code fragment, the measured CPU speed is present in the BL register, and the variable at [BP+3Fh] holds a copy of CMOS register 3Fh. The CPU speed value is then placed in the AX register and the BL register is used to store the multiplier. In the original code this is done by checking bits 7 and 6 of [BP+3Fh] separately.
The patched code handles these bits together and performs some binary arithmetic to arrive at the correct x2, x3, or x4 multiplier value in BL. The DIV BL instruction at the end of this code fragment performs the actual AX/BL division and places the resulting bus_speed value in AL for further processing.

For the hexeditor, here are the 18 bytes long hex signatures of this x4 multiplier patch:

The attachment Multi x4 patch bytes.png is no longer available

If you had to make changes in the F-segment, remember to correct the last byte of the BIOS to make the checksum good again. 😉

In the next part of this Am5x86 patch story, I will focus on the 1995 uncompressed Award BIOS.

Jan

Hello Jan,

I'm trying to patch this BIOS (REV. G3): https://theretroweb.com/motherboards/s/soyo-sy-025j-k-l

But after some debugging, it turns out the bits get mangled some how. When the CPU support table is read, the 3F value is correctly read with bits 6 and 7 set, but by the time the speed is being calculated, bit 6 in BP+3Fh gets cleared. Do you know anything about this phenomenon?

Thanks
Eric

Oerg866 wrote on 2026-07-30, 07:39:

Hello Jan, […]
Show full quote

Hello Jan,

I'm trying to patch this BIOS (REV. G3): https://theretroweb.com/motherboards/s/soyo-sy-025j-k-l

But after some debugging, it turns out the bits get mangled some how. When the CPU support table is read, the 3F value is correctly read with bits 6 and 7 set, but by the time the speed is being calculated, bit 6 in BP+3Fh gets cleared. Do you know anything about this phenomenon?

Thanks
Eric

Hello Eric,

Thanks for your report.
I haven’t noticed this Award 1994/1995 BIOS behavior before, so I will investigate where and why the SY-025JKL G3 BIOS manipulates this bit 6 in the BP+3Fh variable.
I also like to know if this is an isolated case, so I will be checking other Award v4.50g BIOSes as well.

In the mean time, there is an alternate solution for the SY-025JKL boards. I have an up-to-date SiS471G BIOS from a Gemlight board and carefully adapted it for these Soyo boards, including the default chipset register programming from the original REV .G2. BIOS.
This 11/28/95 Rev J.1 BIOS is millennium compliant, supports HDD's up to 8GB, and supports all enhanced Intel/AMD/Cyrix 486/5x86 CPU's including L1 cache WB and x4 multiplier modes.
You can download this SY-25JKL_J1 BIOS from this thread:
Re: Fixing up an broken 486 I got from a local radio.

The only limitation of this BIOS is that it support only one IDE channel, just like the original G2 BIOS. The G3 is probably the only 025JKL BIOS revision that supports 2 IDE channels.

I will report back when I’ve completed my G3 BIOS investigation.
Cheers, Jan

Oh, ha! That's a very neat coincidence. I'll test this and report back. Thank you very much!

My investigation of leaked AWARD bios source shows that "canonically", bit 5 is supposed to be used to indicate a 4x multiplier. Upon further digging, this is how I implemented it in my ABIT PW4 mod BIOS, thus proving that I have stumbled on this problem before and I remember nothing at all. Early onset Alzheimer's, perhaps 😀

The IDE limitation is not an issue for me. I will be using it with an Adaptec VLB SCSI controller 😀

Chkcpu wrote on 2026-07-31, 10:01:

In the mean time, there is an alternate solution for the SY-025JKL boards. I have an up-to-date SiS471G BIOS from a Gemlight boa […]
Show full quote

In the mean time, there is an alternate solution for the SY-025JKL boards. I have an up-to-date SiS471G BIOS from a Gemlight board and carefully adapted it for these Soyo boards, including the default chipset register programming from the original REV .G2. BIOS.
This 11/28/95 Rev J.1 BIOS is millennium compliant, supports HDD's up to 8GB, and supports all enhanced Intel/AMD/Cyrix 486/5x86 CPU's including L1 cache WB and x4 multiplier modes.
You can download this SY-25JKL_J1 BIOS from this thread:
Re: Fixing up an broken 486 I got from a local radio.

Hello,

i can confirm that this BIOS works on this board, and it indeed runs the 5x86 at 160mhz successfully.

A mod I wish to do later is persuade this BIOS to accept PS/2 mice by backporting the IRQ12 handler, like I did for the PW4.

Oerg866 wrote on 2026-08-01, 14:45:

Hello, […]
Show full quote

Chkcpu wrote on 2026-07-31, 10:01:

In the mean time, there is an alternate solution for the SY-025JKL boards. I have an up-to-date SiS471G BIOS from a Gemlight boa […]
Show full quote

In the mean time, there is an alternate solution for the SY-025JKL boards. I have an up-to-date SiS471G BIOS from a Gemlight board and carefully adapted it for these Soyo boards, including the default chipset register programming from the original REV .G2. BIOS.
This 11/28/95 Rev J.1 BIOS is millennium compliant, supports HDD's up to 8GB, and supports all enhanced Intel/AMD/Cyrix 486/5x86 CPU's including L1 cache WB and x4 multiplier modes.
You can download this SY-25JKL_J1 BIOS from this thread:
Re: Fixing up an broken 486 I got from a local radio.

Hello,

i can confirm that this BIOS works on this board, and it indeed runs the 5x86 at 160mhz successfully.

A mod I wish to do later is persuade this BIOS to accept PS/2 mice by backporting the IRQ12 handler, like I did for the PW4.

Hello Eric,

Thanks for reporting back on the 25JKL_J1 BIOS. Nice that it even works at 4x40MHz! 😊

Oerg866 wrote on 2026-07-31, 10:59:

My investigation of leaked AWARD bios source shows that "canonically", bit 5 is supposed to be used to indicate a 4x multiplier. Upon further digging, this is how I implemented it in my ABIT PW4 mod BIOS, thus proving that I have stumbled on this problem before.

Looking at the Award v4.50G (1994/1995) BIOSes for socket 3, I see that Award started to use CMOS_3F for additional CPU data in 1994. The CMOS_3F bit definitions I’ve found are:
Bit 7 = clock tripling CPU
Bit 6 = clock doubling CPU
Bit 5 = reserved
Bit 4 = Green CPU (in late 1993/early 1994 BIOS versions, this is bit 5)
Bits 3-0 are reserved. However I've seen bits 0,1,2 beying used for error reporting.

When Award started to use CPUID in early 1995, bit 3 was defined as “CPU in L1 cache Write-Back mode”, and when Cx5x86/Am5x86 support was added in the second half of 1995, bit 5 was defined to indicate a clock quadrupling CPU. So your use of bit 5 for x4 mode in the PW4 mod was spot on!

The reason I didn’t use bit 5 to indicate x4 mode in my patch is because bit 5 was formally used to indicate Green CPUs with SMI support in early socket 3 BIOSes. By using the combination of bits 6 and 7 instead off bit 5, I could make a patch that worked on all 1994/1995 Award BIOS socket 3 versions.

Cheers, Jan

Chkcpu wrote on 2026-07-31, 10:01:

Thanks for your report. I haven’t noticed this Award 1994/1995 BIOS behavior before, so I will investigate where and why the SY- […]
Show full quote

Thanks for your report.
I haven’t noticed this Award 1994/1995 BIOS behavior before, so I will investigate where and why the SY-025JKL G3 BIOS manipulates this bit 6 in the BP+3Fh variable.
I also like to know if this is an isolated case, so I will be checking other Award v4.50g BIOSes as well.

In the mean time, there is an alternate solution for the SY-025JKL boards. I have an up-to-date SiS471G BIOS from a Gemlight board and carefully adapted it for these Soyo boards, including the default chipset register programming from the original REV .G2. BIOS.
This 11/28/95 Rev J.1 BIOS is millennium compliant, supports HDD's up to 8GB, and supports all enhanced Intel/AMD/Cyrix 486/5x86 CPU's including L1 cache WB and x4 multiplier modes.
You can download this SY-25JKL_J1 BIOS from this thread:
Re: Fixing up an broken 486 I got from a local radio.

The only limitation of this BIOS is that it support only one IDE channel, just like the original G2 BIOS. The G3 is probably the only 025JKL BIOS revision that supports 2 IDE channels.

I will report back when I’ve completed my G3 BIOS investigation.
Cheers, Jan

Since this came up in the thread - I wanted to say that I recently flashed this 1995 revision of the BIOS on my 486 that uses a Soyo 025-N2, and it will often hang after counting the memory. With the G2 BIOS - either original or modbinned - I could press escape during the memory test, and the boot process would continue.

With this one, it will usually hang and timeout with what I think is an HDD controller failure after pressing or not pressing esc - I only let it sit for a long time just once, so I am not 100% sure of the eventual error message.

I can still press del to enter the BIOS, exit without saving changes, and it may continue. Sometimes it takes three or more tries.

As far as I can tell, I haven't experienced issues with the system after getting past this roadblock. The boot process fades the energy star logo and continues. Games and software have run fine over the last couple of weeks.

If it is IDE controller-related, I am using a Promise EIDE 4030 Plus VLB caching controller. I dunno if this is some sort of race condition behind the scenes or what.

CkRtech wrote on 2026-08-01, 20:15:

Since this came up in the thread - I wanted to say that I recently flashed this 1995 revision of the BIOS on my 486 that uses a […]
Show full quote

Chkcpu wrote on 2026-07-31, 10:01:

Thanks for your report. I haven’t noticed this Award 1994/1995 BIOS behavior before, so I will investigate where and why the SY- […]
Show full quote

Thanks for your report.
I haven’t noticed this Award 1994/1995 BIOS behavior before, so I will investigate where and why the SY-025JKL G3 BIOS manipulates this bit 6 in the BP+3Fh variable.
I also like to know if this is an isolated case, so I will be checking other Award v4.50g BIOSes as well.

In the mean time, there is an alternate solution for the SY-025JKL boards. I have an up-to-date SiS471G BIOS from a Gemlight board and carefully adapted it for these Soyo boards, including the default chipset register programming from the original REV .G2. BIOS.
This 11/28/95 Rev J.1 BIOS is millennium compliant, supports HDD's up to 8GB, and supports all enhanced Intel/AMD/Cyrix 486/5x86 CPU's including L1 cache WB and x4 multiplier modes.
You can download this SY-25JKL_J1 BIOS from this thread:
Re: Fixing up an broken 486 I got from a local radio.

The only limitation of this BIOS is that it support only one IDE channel, just like the original G2 BIOS. The G3 is probably the only 025JKL BIOS revision that supports 2 IDE channels.

I will report back when I’ve completed my G3 BIOS investigation.
Cheers, Jan

Since this came up in the thread - I wanted to say that I recently flashed this 1995 revision of the BIOS on my 486 that uses a Soyo 025-N2, and it will often hang after counting the memory. With the G2 BIOS - either original or modbinned - I could press escape during the memory test, and the boot process would continue.

With this one, it will usually hang and timeout with what I think is an HDD controller failure after pressing or not pressing esc - I only let it sit for a long time just once, so I am not 100% sure of the eventual error message.

I can still press del to enter the BIOS, exit without saving changes, and it may continue. Sometimes it takes three or more tries.

As far as I can tell, I haven't experienced issues with the system after getting past this roadblock. The boot process fades the energy star logo and continues. Games and software have run fine over the last couple of weeks.

If it is IDE controller-related, I am using a Promise EIDE 4030 Plus VLB caching controller. I dunno if this is some sort of race condition behind the scenes or what.

Hi CkRtech,

This halt during POST just after the memory test is usually not a hang, but a delay while the BIOS is re-testing peripherals that produced an error on the first try. When it gives up, a message on the screen should indicate the faulty component.
If the fault is not preventing the BIOS from continuing POST, pressing F1 will continue the boot process.

The 25JKL-J1 BIOS was tested successfully on a SY-025N2 board, but that was with a dumb IDE-controller. Assuming your POST error is about the Harddisk, the 11/1995 J1 BIOS may cause this delay by being more thorough in testing the attached drives.

Now with your Promise EIDE4030plus caching controller, with its own BIOS and drive detection, it gets more complicated. But using conventional harddisks for drive 1 and 2 on the primary IDE channel, the J1 BIOS should be fine when setting these drives manually at CHS 1023/16/63/Normal (No LBA) in the STANDARD CMOS SETUP menu. (I assume the drives are larger than 528MB, otherwise use the lower Cylinders value of the drive.)

If this doesn’t help, you may need to play with the settings in the Promise Cache Setup Utility. Try if the Disk I/O Handler mode setting on Fast instead of Turbo helps. Also try the Cache Mode on Fast instead of Turbo.
The J1 BIOS has vastly improved CPU support, including L1 cache Write-Back support for any CPU that supports it.
Which CPU are you running now and how is it detected by the J1 BIOS? It is possible that the 4030plus Turbo settings are incompatible with the improved CPU support by the J1 BIOS.

Just some ideas, hope it helps.
Cheers, Jan

@Chkcpu:

AWARDs PS/2 mouse implementation is around 900 bytes in total (sans size optimization, of which there are potentially a *LOT*), which is exceedingly difficult to fit into a prebuilt 64KB ROM. Do you have any good info on how/where to find safe code caves?

For now I'm overwriting all of the "Uninitialized" memory ('Award Software, inc. Award Software, inc. Award Software, inc. Award Software, inc.') and the useless copyright markers scattered throughout...

Oerg866 wrote on 2026-08-03, 08:11:

@Chkcpu:

AWARDs PS/2 mouse implementation is around 900 bytes in total (sans size optimization, of which there are potentially a *LOT*), which is exceedingly difficult to fit into a prebuilt 64KB ROM. Do you have any good info on how/where to find safe code caves?

For now I'm overwriting all of the "Uninitialized" memory ('Award Software, inc. Award Software, inc. Award Software, inc. Award Software, inc.') and the useless copyright markers scattered throughout...

Hi Eric,

The uncompressed 64KB Award BIOS is indeed a fully packed piece of code and data. Apart from the spaces you mentioned, I see only one additional block for you purpose.

A Harddisk related chunk of data in the Bootblock is the Harddisk Information Table for all predefined Harddisk types. This table always starts at offset E401h and contains up to 47 entries of 16 bytes. This fixed data is only read by the BIOS and never written to. So this block could give you 752 bytes of uninterrupted space when only User definable Harddisk data is used.

Note that when using unused areas containing 'Award Software, inc.’ strings in the Bootblock, steer clear of the area where the BIOS stores the (User) Harddisk parameter tables in Shadow RAM.
In the 64KB Award BIOS they usually start at offset F019h. These tables are 16 bytes long for each supported IDE Harddisk, so they occupy 64 bytes when the BIOS supports both the primary and secondary IDE channel.

Cheers, Jan

Oh Hmmm yes I suppose nobody will miss the presets for archaic hard disk types. I'll expand my tooling to find this block automatically and then see where I stand space wise.

Thanks so much for your input!

Best
Eric

Oerg866 wrote on 2026-08-01, 14:45:

Hello, […]
Show full quote

Chkcpu wrote on 2026-07-31, 10:01:

In the mean time, there is an alternate solution for the SY-025JKL boards. I have an up-to-date SiS471G BIOS from a Gemlight boa […]
Show full quote

In the mean time, there is an alternate solution for the SY-025JKL boards. I have an up-to-date SiS471G BIOS from a Gemlight board and carefully adapted it for these Soyo boards, including the default chipset register programming from the original REV .G2. BIOS.
This 11/28/95 Rev J.1 BIOS is millennium compliant, supports HDD's up to 8GB, and supports all enhanced Intel/AMD/Cyrix 486/5x86 CPU's including L1 cache WB and x4 multiplier modes.
You can download this SY-25JKL_J1 BIOS from this thread:
Re: Fixing up an broken 486 I got from a local radio.

Hello,

i can confirm that this BIOS works on this board, and it indeed runs the 5x86 at 160mhz successfully.

A mod I wish to do later is persuade this BIOS to accept PS/2 mice by backporting the IRQ12 handler, like I did for the PW4.

I just noticed that, unlike the G3 BIOS, the 25JKL-J1 BIOS has an IRQ12 handler at offset D530h. It ends with an iret instruction at D5E9h, so it is only 186 bytes (0BAh) long and I’ve no idea if it covers PS/2 mice support.

Cheers, Jan

Oh wow, you're right!

I ran my python scripts on this BIOS and it gives me the following info:

1; AUTO-GENERATED
2
3
4; GENERIC DATA STRUCTURES AND LABELS 
5
6[...]
7CONST_BiosSupportedFeatures              EQU 01h
8
9[...]
10
11 SEGLBL ISR_IRQ12_PS2Mouse,                      SEG_15, G_15, 0d533h ; Segment 15
12 SEGLBL Wait_Refresh,                            SEG_15, G_15, 0edcch ; Segment 15
13 SEGLBL Mouse_CheckDataPacket,                   SEG_15, G_15, 0d56bh ; Segment 15
14 SEGLBL APM_Service,                             SEG_15, G_15, 08609h ; Segment 15
15 SEGLBL Int15h_Handler,                          SEG_15, G_15, 0d900h ; Segment 15
16 SEGLBL Int15_CheckMouse,                        SEG_15, G_15, 0d911h ; Segment 15
17
18[...]
19 SEGLBL DisableAOBFIrq,                          SEG_15, G_15, 0d888h ; Segment 15
20 SEGLBL EnableAOBFIrq,                           SEG_15, G_15, 0d896h ; Segment 15
21 SEGLBL SetupMouse,                              SEG_15, G_15, 08170h ; Segment 15
22 SEGLBL SetupMouse_SetIRQ12Handler,              SEG_15, G_15, 081b7h ; Segment 15
23
24[...]

So:

IRQ12 handler at 0D530h
Function SetupMouse at 08170h, including the IRQ12 handler setup.
Int15h handler at 0d900h including the mouse check at 0d911h

This 64KB BIOS is PS/2 capable! how cool is that 😀

This will help in debugging this automated patching method i'm attempting on the original SOYO BIOS for sure.

EDIT: Wait! It is not! the BiosSupportedFeatures byte at FFEC is set to 01! It needs to be changed to 81 to enable mouse support. But then it should just work 😀 I'll test this when I get the time

EDIT2: I can confirm that once that change is made and the checksum is patched, the BIOS works perfectly fine with PS/2 mice.

My patched one does not, and I don't know why, as SoftICE never breaks on the Int15h handler and it's kind of testing my patience 😀 But one thing at a time. If anything, this will be useful for many other BIOSes.

EDIT3: Oh, 86Box broke hardware breakpoints between 5.3 and 6.0, how fun. We march on 😀

Hello again,

I dug into the SOYO BIOS a bit more.

There's a function I found that is actually the one responsible for mangling these bits:

1BIOS_F:8465 CMOS_ApplyCPUFeatureBits proc near      ; CODE XREF: sub_F830B:loc_F83AD↑p
2BIOS_F:8465                                         ; sub_F830B:loc_F840B↑p ...
3BIOS_F:8465                 mov     al, 0BDh
4BIOS_F:8467                 mov     ah, dl
5BIOS_F:8469                 call    WriteCMOSByte
6BIOS_F:846C                 mov     ah, 0BFh
7BIOS_F:846E                 mov     al, ah
8BIOS_F:8470                 call    ReadCMOSByte
9BIOS_F:8473                 and     al, 7
10BIOS_F:8475                 or      al, dh
11BIOS_F:8477                 xchg    ah, al
12BIOS_F:8479                 call    WriteCMOSByte
13BIOS_F:847C                 retn
14BIOS_F:847C CMOS_ApplyCPUFeatureBits endp

It is referenced several times from this function that comes right after the CPU name list:

1BIOS_F:830B sub_F830B       proc near               ; CODE XREF: BIOS_F:0934↑p
2BIOS_F:830B                 push    ds
3BIOS_F:830C                 pushad
4BIOS_F:830E                 call    sub_F842F
5BIOS_F:8311                 jnz     short loc_F8316
6BIOS_F:8313                 call    sub_F844C
7BIOS_F:8316
8BIOS_F:8316 loc_F8316:                              ; CODE XREF: sub_F830B+6↑j
9BIOS_F:8316                 xor     eax, eax
10BIOS_F:8319                 mov     ds, ax
11BIOS_F:831B                 assume ds:nothing
12BIOS_F:831B                 push    word ptr ds:18h
13BIOS_F:831F                 mov     word ptr ds:18h, 8426h
14BIOS_F:8325                 cpuid
15BIOS_F:8327                 cmp     eax, 1
16BIOS_F:832B                 jnz     short loc_F8367
17BIOS_F:832D                 cmp     ebx, 756E6547h
18BIOS_F:8334                 jnz     short loc_F8367
19BIOS_F:8336                 cmp     ecx, 6C65746Eh
20BIOS_F:833D                 jnz     short loc_F8367
21BIOS_F:833F                 cmp     edx, 49656E69h
22BIOS_F:8346                 jnz     short loc_F8367
23BIOS_F:8348                 call    sub_F843D
24BIOS_F:834B                 mov     eax, 1
25BIOS_F:8351                 cpuid
26BIOS_F:8353                 and     al, 0F0h
27BIOS_F:8355                 cmp     ax, 470h
28BIOS_F:8358                 jnz     short loc_F8364
29BIOS_F:835A                 mov     ax, 58BDh
30BIOS_F:835D                 xchg    ah, al
31BIOS_F:835F                 mov     al, 0BDh
32BIOS_F:8361                 call    WriteCMOSByte
33BIOS_F:8364
34BIOS_F:8364 loc_F8364:                              ; CODE XREF: sub_F830B+4D↑j
35BIOS_F:8364                 jmp     loc_F840E
36BIOS_F:8367 ; ---------------------------------------------------------------------------
37BIOS_F:8367
38BIOS_F:8367 loc_F8367:                              ; CODE XREF: sub_F830B+20↑j
39BIOS_F:8367                                         ; sub_F830B+29↑j ...
40BIOS_F:8367                 cmp     eax, 1
41BIOS_F:836B                 jnz     short loc_F83B2
42BIOS_F:836D                 cmp     ebx, 68747541h
43BIOS_F:8374                 jnz     short loc_F83B2
44BIOS_F:8376                 cmp     ecx, 444D4163h
45BIOS_F:837D                 jnz     short loc_F83B2
46BIOS_F:837F                 cmp     edx, 69746E65h
47BIOS_F:8386                 jnz     short loc_F83B2
48BIOS_F:8388                 mov     eax, 1
49BIOS_F:838E                 cpuid
50BIOS_F:8390                 mov     dx, 50C3h
51BIOS_F:8393                 and     al, 0F0h
52BIOS_F:8395                 cmp     ax, 430h
53BIOS_F:8398                 jz      short loc_F83AD
54BIOS_F:839A                 mov     dx, 58C3h
55BIOS_F:839D                 cmp     ax, 470h
56BIOS_F:83A0                 jz      short loc_F83AD
57BIOS_F:83A2                 mov     dx, 90C5h
58BIOS_F:83A5                 cmp     ax, 480h
59BIOS_F:83A8                 jz      short loc_F83AD
60BIOS_F:83AA                 mov     dx, 98C5h

61BIOS_F:83AD
62BIOS_F:83AD loc_F83AD:                              ; CODE XREF: sub_F830B+8D↑j
63BIOS_F:83AD                                         ; sub_F830B+95↑j ...
64BIOS_F:83AD                 call    CMOS_ApplyCPUFeatureBits
65BIOS_F:83B0                 jmp     short loc_F840E
66BIOS_F:83B2 ; ---------------------------------------------------------------------------
67BIOS_F:83B2
68BIOS_F:83B2 loc_F83B2:                              ; CODE XREF: sub_F830B+60↑j
69BIOS_F:83B2                                         ; sub_F830B+69↑j ...
70BIOS_F:83B2                 cmp     eax, 1
71BIOS_F:83B6                 jnz     short loc_F840E
72BIOS_F:83B8                 cmp     ebx, 20434D55h
73BIOS_F:83BF                 jnz     short loc_F840E
74BIOS_F:83C1                 cmp     ecx, 20434D55h
75BIOS_F:83C8                 jnz     short loc_F840E
76BIOS_F:83CA                 cmp     edx, 20434D55h
77BIOS_F:83D1                 jnz     short loc_F840E
78BIOS_F:83D3                 mov     eax, 1
79BIOS_F:83D9                 cpuid
80BIOS_F:83DB                 or      ebx, ebx
81BIOS_F:83DE                 jnz     short loc_F840E
82BIOS_F:83E0                 or      ecx, ecx
83BIOS_F:83E3                 jnz     short loc_F840E
84BIOS_F:83E5                 and     ah, 0Fh
85BIOS_F:83E8                 cmp     ah, 4
86BIOS_F:83EB                 jnz     short loc_F840E
87BIOS_F:83ED                 and     al, 0F0h
88BIOS_F:83EF                 mov     dx, 10B0h
89BIOS_F:83F2                 cmp     al, 20h ; ' '
90BIOS_F:83F4                 jz      short loc_F840B
91BIOS_F:83F6                 mov     dx, 50C6h
92BIOS_F:83F9                 cmp     al, 50h ; 'P'
93BIOS_F:83FB                 jz      short loc_F840B
94BIOS_F:83FD                 mov     dx, 10C9h
95BIOS_F:8400                 cmp     al, 10h
96BIOS_F:8402                 jz      short loc_F840B
97BIOS_F:8404                 mov     dx, 50CBh
98BIOS_F:8407                 cmp     al, 30h ; '0'
99BIOS_F:8409                 jnz     short loc_F840E
100BIOS_F:840B
101BIOS_F:840B loc_F840B:                              ; CODE XREF: sub_F830B+E9↑j
102BIOS_F:840B                                         ; sub_F830B+F0↑j ...
103BIOS_F:840B                 call    CMOS_ApplyCPUFeatureBits
104BIOS_F:840E
105BIOS_F:840E loc_F840E:                              ; CODE XREF: sub_F830B:loc_F8364↑j
106BIOS_F:840E                                         ; sub_F830B+A5↑j ...
107BIOS_F:840E                 call    sub_F842F
108BIOS_F:8411                 jnz     short loc_F841E
109BIOS_F:8413                 call    sub_F845B
110BIOS_F:8416                 jnz     short loc_F841E
111BIOS_F:8418                 mov     dx, 80BFh
112BIOS_F:841B                 call    CMOS_ApplyCPUFeatureBits
113BIOS_F:841E
114BIOS_F:841E loc_F841E:                              ; CODE XREF: sub_F830B+106↑j
115BIOS_F:841E                                         ; sub_F830B+10B↑j
116BIOS_F:841E                 pop     word ptr ds:18h
117BIOS_F:8422                 popad
118BIOS_F:8424                 pop     ds
119BIOS_F:8425                 assume ds:nothing
120BIOS_F:8425                 retn
121BIOS_F:8425 sub_F830B       endp

I will try to parse this function mentally tomorrow, and hopefully figure out how to adapt it for 5x86 purposes...

OK I got it.

There is no table modification necessary in this BIOS, but the check above has to be extended to handle the 5x86.

This is an ammendment to the original function which also checks the IDs of the 5x86 CPUs.

Then I had to find a code cave to put this ammended function in and define CPU_5X86_STRING_TABLE_INDEX with an index in the CPU support table that points to an "Unknown" string or something like that.

1    ORG 0h
2AMDCheck5x86:
3    ; Previous condition holds true, so in case we land here from there
4    ; skip our ammended checks
5    jz short AMDCheck5x86_Exit
6
7    cmp ax, 04E0h
8    jnz short AMDCheck5x86_Exit
9    jmp short AMDCheck5x86_SetID
10    cmp ax, 04F0h
11    jnz short AMDCheck5x86_Exit
12AMDCheck5x86_SetID:
13    mov dh, 038h ; <- 3F flags, writeback + smi (is that last one correct even? no clue)
14    mov dl, ((CPU_5X86_STRING_TABLE_INDEX * 2) OR 081h) ; <-- put back the cache and coprocessor bits 
15
16AMDCheck5x86_Exit:
17    call CMOS_ApplyCPUFeatureBits
18    retn

I gave this part of the code a name for my script tooling:

1BIOS_F:83A5 FinalizeCPUSetup_IncompleteAMDCheck:
2BIOS_F:83A5                 cmp     ax, 480h
3BIOS_F:83A8                 jz      short loc_F83AD
4BIOS_F:83AA                 mov     dx, 98C5h
5BIOS_F:83AD
6BIOS_F:83AD loc_F83AD:                              ; CODE XREF: FinalizeCPUSetup+8D↑j
7BIOS_F:83AD                                         ; FinalizeCPUSetup+95↑j ...
8BIOS_F:83AD                 call    CMOS_ApplyCPUFeatureBits
9BIOS_F:83B0                 jmp     short FinaliseCPUSetup_Exit

And I then do this to make a change at address 840B to jump to our code:

1    ORG (offset FinalizeCPUSetup_IncompleteAMDCheck)+8
2    ; instead of CMOS_ApplyCPUFeatureBits
3    call AMDCheck5x86

Hacky BS alert but it works 😀

Right after that we can put:

1CPUSTR_5x86:    db 'AMD 5x86',0

And then modify that index in the CPU string table.

1    ORG (offset CPUNameTable)+(CPU_5X86_STRING_TABLE_INDEX * 2)
2    dw CPUSTR_5x86

I chose a value of 6 here:

1BIOS_F:81D2 CPUNameTable dw offset a80486dx      ; DATA XREF: GetCPUString+13↑r
2BIOS_F:81D2                                         ; "80486DX"
3BIOS_F:81D4                 dw offset a80486dx      ; "80486DX"
4BIOS_F:81D6                 dw offset a80486dx      ; "80486DX"
5BIOS_F:81D8                 dw offset a80486dx      ; "80486DX"
6BIOS_F:81DA                 dw offset a80486sx      ; "80486SX"
7BIOS_F:81DC                 dw offset a80486sx2     ; "80486SX2"
8BIOS_F:81DE                 dw offset aUnknown      ; "Unknown"
9BIOS_F:81E0                 dw offset aUnknown      ; "Unknown"
10BIOS_F:81E2                 dw offset aP24t         ; "P24T"
11BIOS_F:81E4                 dw offset aP24t         ; "P24T"
12BIOS_F:81E6                 dw offset aP24t         ; "P24T"
13BIOS_F:81E8                 dw offset aCx486s       ; "Cx486S"

Which ends up at address 81DE.

Lastly, implement an extension for the 4x multiplier, I chose to use the bit 5 here, but that's just personal preference 😀 your way may be better, Jan

Here is the original:

1BIOS_F:20F4 CalculateBusSpeed:                      ; CODE XREF: sub_F1F54+167↑j
2BIOS_F:20F4                                         ; sub_F1F54+183↑j ...
3BIOS_F:20F4                 xor     bh, bh
4BIOS_F:20F6                 mov     ax, bx
5BIOS_F:20F8                 mov     bl, 1
6BIOS_F:20FA
7BIOS_F:20FA orig_NotX4:
8BIOS_F:20FA                 test    byte ptr [bp+3Fh], 80h
9BIOS_F:20FE                 jz      short loc_F2104
10BIOS_F:2100                 mov     bl, 3
11BIOS_F:2102                 jmp     short orig_DoCalc
12BIOS_F:2104 ; ---------------------------------------------------------------------------
13BIOS_F:2104
14BIOS_F:2104 loc_F2104:                              ; CODE XREF: sub_F1F54+1AA↑j
15BIOS_F:2104                 test    byte ptr [bp+3Fh], 40h
16BIOS_F:2108                 jz      short orig_DoCalc
17BIOS_F:210A                 mov     bl, 2
18BIOS_F:210C
19BIOS_F:210C orig_DoCalc:                            ; CODE XREF: sub_F1F54+1AE↑j
20BIOS_F:210C                                         ; sub_F1F54+1B4↑j
21BIOS_F:210C                 div     bl
22BIOS_F:210E                 add     al, 3
23BIOS_F:2110                 mov     dh, al
24BIOS_F:2112                 mov     dl, bl
25BIOS_F:2114                 mov     si, offset unk_F2132
26BIOS_F:2117                 mov     cx, 8
27BIOS_F:211A                 nop
28BIOS_F:211B                 call    RoundOffClock
29BIOS_F:2120                 retf
30BIOS_F:2120 sub_F1F54       endp

1CalculateBusSpeed_o866:
2    xor bh, bh
3    mov ax, bx
4
5    ; Is this quadruple clock?
6    test byte ptr [bp+3Fh], 20h
7    jz short NotX4
8    mov bl, 4
9    FAR_JMP 0F000h, orig_DoCalc
10NotX4:
11    FAR_JMP 0F000h, orig_NotX4

This is put right after the other patch code we had. Not sure if far jumps are necessary, but the original is a far function that ends with a retf. God knows where that ends up, so best to play it safe.

And of course, override the start of that function

1    ORG offset CalculateBusSpeed
2    FAR_JMP 0F000h, CalculateBusSpeed_o866

FAR_JMP is a macro that generates a far jump which MASM is a little allergic towards:

1FAR_JMP     MACRO SEGMENT, OFFSET
2            DB 0EAh
3            dw OFFSET
4            dw SEGMENT
5            ENDM

And with that, we get here:

I'll clean this up a little and put it on my github later.

In case it wasn't clear, the labels are all auto-generated by IDAPython scripts (that you can also find on my github - but beware they're messy and out of date), which is a big help. As are the code cave address, but in this post I've manually inserted them for clarity...

Hi Eric,

I’ve completed the disassembly of the SY-025JKL/025MNP Rev G3 BIOS and found the place where the CMOS_3Fh bit 6 for the multiplier is mangled.
I was about to write a reply but saw you already beat me to it. 😉

This 03/1995 BIOS is one of the last Award socket 3 BIOSes that still uses the 1994 style code for CPU detection, before Award started to use tables with CPUID values. So this G3 BIOS mainly depends on the reset ID for CPU detection.
But in this BIOS, the function that detects the P24D via hardcoded CPUID instructions is expanded to support the Enhanded Am486DX2/DX4 and several UMC 486 models. This is the function you referenced as sub_F830B. I call this function “Check_CPUID”. 😉

Before December 1994, the only supported Am486DX4 was the NV8T model without CPUID and the reset ID of a 486DX2. Because the Am486DX2-80 was the fastest DX2 model, the 1994 Award BIOS detected an Am486DX4 by its clock speed. If this speed was > 90MHz, it must be an Am486DX4-100. This logic did not interfere with the Intel DX4 detection because the iDX4 has a different reset ID.
Now that the G3 BIOS has support for the Enhanced Am486DX4 SV8B via CPUID, the writers of this G3 BIOS tried another logic to distinguish the Am486DX4 NV8T from the SV8B.

Near the end of sub_F830B, at loc_F840E, the BIOS checks if the CPU is an iDX4 (sub_F842F) and if it supports SMI (sub_F845B) . When it finds a DX4 without SMI, it must be an Am486DX4 NV8T. The BIOS then loads DX with 803Fh and applies these CPUFeaturesBits, effectively setting the BIOS_up_ID to 3Fh and multiplier bits to x3 to indicate an Am486DX4.

When using my Reset table patch from earlier in this thread, the Am5x86 is portrayed as an iDX4 with an x4 multiplier. Although the Am5x86 has SMI and the corresponding CMOS_3F bit 4 is set, the sub_F830B function resets this bit at the beginning via a call to F844C and sets it again only when a matching CPUID is found. The above new Am486DX4 detection is now in the way because the SMI bit is not set again for the Am5x86, effectively reducing this CPU to an Am486DX with a x3 multiplier.

The solution is simple, just replace the call at BIOS_F:841B with 3 NOP instructions. This will restore the Am5x86 to a x4 multiplier, albeit without enhanced PM.

Your solution of adding the Am5x86 to the “Check_CPUID” (sub_F830B) function is certainly more elegant! 😀
Some remarks about your patch:

1) By using CMOS_3F bit 5 for a clock quadrupling CPU, the bit definitions are now:
Bit 7 = clock tripling CPU
Bit 6 = clock doubling CPU
Bit 5 = clock quadrupling CPU
Bit 4 = Green CPU (=SMI support)
Bit 3 = L1 cache WB Enabled CPU
Bits 2-0 are reserved. However I've seen bits 0,1,2 being used for error reporting.

Note the function of bit 3. When the Am5x86 reports a 04Exh signature, it is in Write-Through mode and bit 3 must not be set. Set bit 3 only if a 04Fxh signature, indication L1 cache WB mode, is found.

2) The old > 90MHz Am86DX4 detection logic is still present in the G3 BIOS (offset 20D9h and further), so you can overwrite the code at F840E-F841D and use it for the Am5x86 detection.

In my next reply, I will send you my disassembly listing and some further info about this G3 BIOS. Hopefully this will be useful.

Cheers, Jan