chacha wrote on 2025-03-06, 22:45:

Some good news ! […]
Show full quote

Some good news !

So, lets start:
- BIOS flash ran perfectly, using uniFlash, and it boots without issues then (and faster + bios has more options)
( I haven't tried bigger HDD yet)
- I finalized my undervolt motdto have exactly 2.2V, and while I was away I received my K6-IIE 400 (AFR).
- Installed, and with BF0/1 out => it boots at 233MHz ! Nice start !
- Then I tried to set multiplier to 2x because I am expecting this CPU to actually run at 6x if 2x set... no POST 😒
- I tried to pull-up in case it was the same problem as with the MMX CPU, no change.
- other configuration does work (underclock even more)
- Then I did the BF2 mod => short to ground
- TADA ! --==> CPU now runs at 5.5x 66 | 366MHz <===--

I can see a very significant improvment in general performances, thats nice !
But as you probably can guess I'd like it to run at 400MHz 😀 .

But I cannot figure out why it wont run at normal speed.
I tried other jumper configuration ,with BF2 shorted, and they all does work, so there is no pull up/ down issue.

I thought it can be a VRM issue ... but 366MHz seems verry stable, I would expect 400MHz to at least POST.
And as its a linear voltage regulator, lowering the voltage might actually increase power dissipation (not sure how K6 regulate tho..). I added a bigger capacitor at the transistor output and it did not change anything.
I ordered a more recent replacement Transistor, in theory it should accept 4 more amps than this one.
I am tempted to try to feed this transistor with the PSU 3.3V instead of MB 5V to lower the voltage difference...

Or maybe it has nothing to do with the hardware and this CPU just does not has the 2x => 6x feature ?
I will receive the K6-III+ 400ATZ, I hope that one will work.
I expect it to be stronger, in particular because it should be able to cache the whole RAM, but also it should require less current.

If anyone has idea on how to achieve 400MHz... I am ready for trials 😀
I dont think it can be BIOS related at that stage isn't it ?

Hello chacha,

Great to hear that the Unicore BIOS for the 8500TVX works. 😀

From your CPU-Z picture I see that the K6-2/400 is definitely one with the improved CXT core and supports the x2 -> x6 multiplier remap. You can test this by setting the K6-2 to 360MHz (60 x 6).

The 03/16/2000 BIOS does support the K6-2CXT at x6, so I it is very likely that the 400MHz non-POST issue is due to the VRM limitation.
If so, then a K6-2+ or K6-III+ should work at 400MHz because of its lower power consumption.

I will keep my fingers crossed. 😉
Cheers, Jan

0xDEADBEEF wrote on 2025-03-08, 01:37:

I have received modified BIOS for Shuttle HOT-566 via PM, sadly cannot respond because I am a noob here. So thank you so much, it works great.

Hi 0xDEADBEEF,

Thanks for reporting back on the patched HOT-566 BIOS.
I’m glad to hear it works great.

Can you tell a bit more about which CPU you are running and at what speed?
I’m also curious about the Vcore setting you are using. Is it done manually via the jumpers, or Auto via the BIOS logic?

Greetings, Jan

I am using jumpers since the old bios didnt detect CPU properly. It is AMD K6-2 500 AFX (2.2V core), works at 6*75=450MHz and the BIOS now displays correct frequency. I had to re-detect the HDD (64GB CF card) after BIOS update and set to LBA.
The jumper block is under GUS so I am not going to mess with it.
The system is configured with GUS Classic, SB AWE64/32MB, Voodoo2, Matrox Millenium II, 3com network, Hercules, primarily DOS system but running Win98SE for network and large disk support.
I need to hack PCI chipset regs to enable Hercules on ISA because video card range is not forwarded to ISA by defualt (I did it once back in 90s for my VIA MVP3)
Thanks again!

0xDEADBEEF wrote on 2025-03-08, 20:42:

I am using jumpers since the old bios didnt detect CPU properly. It is AMD K6-2 500 AFX (2.2V core), works at 6*75=450MHz and th […]
Show full quote

I am using jumpers since the old bios didnt detect CPU properly. It is AMD K6-2 500 AFX (2.2V core), works at 6*75=450MHz and the BIOS now displays correct frequency. I had to re-detect the HDD (64GB CF card) after BIOS update and set to LBA.
The jumper block is under GUS so I am not going to mess with it.
The system is configured with GUS Classic, SB AWE64/32MB, Voodoo2, Matrox Millenium II, 3com network, Hercules, primarily DOS system but running Win98SE for network and large disk support.
I need to hack PCI chipset regs to enable Hercules on ISA because video card range is not forwarded to ISA by defualt (I did it once back in 90s for my VIA MVP3)
Thanks again!

Thanks for the details about your HOT-566 system, that’s a nice setup!

Note that, because the patched BIOS has a fix for the UDMA bug, you can now tick the DMA box in Device Manager for correct UDMA 2 support on your 64GB CF card when running Win98.
The BIOS summary screen should also indicate your 64GB drive using UDMA 2 mode now, the maximum for this i430TX chipset.

I will publish this patched 566WAQ0D HOT-566 BIOS on my Unofficial K6-2+/K6-III+ page at the next update.

Cheers, Jan

Sphere478 wrote on 2025-01-10, 14:58:

Mr Jan, I have a bios request.

Orange pc 530

OrangePC 530 pinout, bios update, vram upgrade

Any update?

Are you able?

Sphere478 wrote on 2025-03-10, 13:25:

Sphere478 wrote on 2025-01-10, 14:58:

Mr Jan, I have a bios request.

Orange pc 530

OrangePC 530 pinout, bios update, vram upgrade

Any update?

Are you able?

Hi Sphere478,

No, I haven’t found anything about the 530 BIOS on-line.

So you may have to get the BIOS from the OrangePC 530 card or application software somehow. Hopefully you can get the card working and proceed from there.

From the 620 I know the cards Award BIOS was just a file in the OrangePC Application software. But from your threads about the 530, I noticed an MR BIOS in a ROM chip? Could this be that cards BIOS, or is it the VGA ROM?
Let me know what you find.

Cheers, Jan

Chkcpu wrote on 2025-03-10, 18:23:

Hi Sphere478, […]
Show full quote

Sphere478 wrote on 2025-03-10, 13:25:

Sphere478 wrote on 2025-01-10, 14:58:

Mr Jan, I have a bios request.

Orange pc 530

OrangePC 530 pinout, bios update, vram upgrade

Any update?

Are you able?

Hi Sphere478,

No, I haven’t found anything about the 530 BIOS on-line.

So you may have to get the BIOS from the OrangePC 530 card or application software somehow. Hopefully you can get the card working and proceed from there.

From the 620 I know the cards Award BIOS was just a file in the OrangePC Application software. But from your threads about the 530, I noticed an MR BIOS in a ROM chip? Could this be that cards BIOS, or is it the VGA ROM?
Let me know what you find.

Cheers, Jan

It’s a project for a future date, but in the meantime I’m collecting info, resources and preparing.

I’ll ask about software in the thread. See if anyone can help.

If it says MR bios, I’m guessing that’s the bios.

Vga bios may be built into the system bios ROM.

Chkcpu wrote on 2021-11-24, 17:55:

#Part 3 – What to patch in an uncompressed Award BIOS […]
Show full quote

#Part 3 – What to patch in an uncompressed Award BIOS

After two episodes of preliminaries, it is time to start patching! 😀

1) Let’s start with the Year 2094 bug. A well known bug in 1994-1995 Award BIOSes.
Actually this bug and its fix were already addressed here recently by jakethompson1, but I will also show it here for completeness sake.
This bug causes the year to jump forward to 2094 at each boot-up whenever the date was set to 1-1-2000 or later.

At POST 0B, the BIOS checks if the RTC uses valid values by reading the CMOS registers for seconds, minutes, hours, day, month, year, and century. It then uses a short table with maximum and minimum values for each of these 7 registers.
The minimum values table contains the hex numbers: 00, 00, 00, 01, 01, 94, 19, and this is the binary signature you have to look for. If you don’t find this signature, your PC should be free of this bug.

The error is in the routine that walks this table, but the fix is setting the minimum year from 1994 to 2000 by changing the last 2 bytes in this table.
The new table should become: 00, 00, 00, 01, 01, 00, 20 to fix this bug.

Note that this silly bug appeared in mid 1994 when Award tried to make the BIOS millennium compliant. Before that, the BIOS didn’t do any century checking, and when Award fixed this bug by the end of 1995, they simply removed this century check again! 😉

2) The 2nd bugfix is for the 2GB Harddisk size display limit bug.

At the beginning of 1994, the IDE Harddisk support of most BIOSes was still limited to 504MB.
But Award fixed that, and all Award BIOSes dated July 1994 or later correctly support the LBA assisted translation, up to the 8 GB limit of the traditional BIOS Int 13h interface.
There is however a bug in the BIOSes dated before January 1996 that limits the harddisk size display, on the BIOS Setup and boot screens, to 2015 MB.

Whenever a drive is 2016 MB or larger, the display starts to count from zero again. The same happens at 4032 and 6048 MB.
This looks a lot like the an actual 2 GB limit but is only a cosmetic bug in the harddisk size display routine, and it doesn't affect the BIOS support for these larger drives.
For these Award v4.50(P)(G) BIOSes, just use the HDD AUTO DETECTION feature to Setup the drive, select the option with LBA at the end, and disregard the incorrect HD size display.
Or, you could read on and patch this bug yourself! 😉

I have found 2 variations of this buggy code in the Award v4.50(P)(G) BIOS, but both variations use the same calculation method and therefore have the same bug. This piece of code takes the Cylinder, Head, and Sector count of the drive in question, multiplies them and divides the result by 2048 to arrive at the number of MB. In the buggy code a between result gets truncated and as a consequence the end result rolls over to zero every 2016MB.
For this bugfix I rearranged the multiplication order so the truncation doesn’t happen and this new code fitted nicely in the same space, so you only have to overwrite the old code by the new.

This is the first variation, and below you’ll see how the buggy and the fixed code look in my disassembler listing of a 03/10/95-ALI-1439G-1437-2A4KC000-00 BIOS.

The attachment 2GB limit bugfix_1.png is no longer available

So the 21 bytes long hex signatures of this first bug and its patch are as follows:
Buggy1: 8B,86,94,00,32,ED,8A,8E,96,00,F7,E1,8A,8E,9B,00,F7,E1,B9,00,08
Patch1: 8A,86,96,00,8A,8E,9B,00,C0,E1,02,90,F6,E1,F7,A6,94,00,B9,00,20
The checksum of this patch1 is 29h less than the buggy1 code, so if this is the only patch you make, add 29h to the last byte of the BIOS to make the F-segment checksum correct again.

And this is the second variation of this bug, as found in the 11/03/94--2C4X6H01-00 BIOS.

The attachment 2GB limit bugfix_2.png is no longer available

This code is even 3 bytes longer and so is its patch.
The 24 bytes long hex signatures of this second bug and its patch are as follows:
Buggy2: 8B,86,94,00,32,ED,8A,8E,96,00,F7,E1,8A,8E,9B,00,C1,E1,03,F7,E1,B9,09,3D
Patch2: 8A,86,96,00,32,ED,8A,8E,9B,00,C0,E1,02,F6,E1,8B,8E,94,00,F7,E1,B9,00,20
The checksum of this patch2 is 29h less than the buggy2 code, so if this is the only patch you make, add 29h to the last byte of the BIOS to make the F-segment checksum correct again.

In the next part I will talk about what can be changed in the uncompressed Award BIOS, to have better Am5x86-133 support.

Jan

Finally, the year 2094 and 2gb HDD bug solved for my EXP4045 motherboard. Thank you!

486guy wrote on 2025-03-13, 11:03:

Chkcpu wrote on 2021-11-24, 17:55:

#Part 3 – What to patch in an uncompressed Award BIOS […]
Show full quote

#Part 3 – What to patch in an uncompressed Award BIOS

After two episodes of preliminaries, it is time to start patching! 😀

1) Let’s start with the Year 2094 bug. A well known bug in 1994-1995 Award BIOSes.
Actually this bug and its fix were already addressed here recently by jakethompson1, but I will also show it here for completeness sake.
This bug causes the year to jump forward to 2094 at each boot-up whenever the date was set to 1-1-2000 or later.

At POST 0B, the BIOS checks if the RTC uses valid values by reading the CMOS registers for seconds, minutes, hours, day, month, year, and century. It then uses a short table with maximum and minimum values for each of these 7 registers.
The minimum values table contains the hex numbers: 00, 00, 00, 01, 01, 94, 19, and this is the binary signature you have to look for. If you don’t find this signature, your PC should be free of this bug.

The error is in the routine that walks this table, but the fix is setting the minimum year from 1994 to 2000 by changing the last 2 bytes in this table.
The new table should become: 00, 00, 00, 01, 01, 00, 20 to fix this bug.

Note that this silly bug appeared in mid 1994 when Award tried to make the BIOS millennium compliant. Before that, the BIOS didn’t do any century checking, and when Award fixed this bug by the end of 1995, they simply removed this century check again! 😉

2) The 2nd bugfix is for the 2GB Harddisk size display limit bug.

At the beginning of 1994, the IDE Harddisk support of most BIOSes was still limited to 504MB.
But Award fixed that, and all Award BIOSes dated July 1994 or later correctly support the LBA assisted translation, up to the 8 GB limit of the traditional BIOS Int 13h interface.
There is however a bug in the BIOSes dated before January 1996 that limits the harddisk size display, on the BIOS Setup and boot screens, to 2015 MB.

Whenever a drive is 2016 MB or larger, the display starts to count from zero again. The same happens at 4032 and 6048 MB.
This looks a lot like the an actual 2 GB limit but is only a cosmetic bug in the harddisk size display routine, and it doesn't affect the BIOS support for these larger drives.
For these Award v4.50(P)(G) BIOSes, just use the HDD AUTO DETECTION feature to Setup the drive, select the option with LBA at the end, and disregard the incorrect HD size display.
Or, you could read on and patch this bug yourself! 😉

I have found 2 variations of this buggy code in the Award v4.50(P)(G) BIOS, but both variations use the same calculation method and therefore have the same bug. This piece of code takes the Cylinder, Head, and Sector count of the drive in question, multiplies them and divides the result by 2048 to arrive at the number of MB. In the buggy code a between result gets truncated and as a consequence the end result rolls over to zero every 2016MB.
For this bugfix I rearranged the multiplication order so the truncation doesn’t happen and this new code fitted nicely in the same space, so you only have to overwrite the old code by the new.

This is the first variation, and below you’ll see how the buggy and the fixed code look in my disassembler listing of a 03/10/95-ALI-1439G-1437-2A4KC000-00 BIOS.

The attachment 2GB limit bugfix_1.png is no longer available

So the 21 bytes long hex signatures of this first bug and its patch are as follows:
Buggy1: 8B,86,94,00,32,ED,8A,8E,96,00,F7,E1,8A,8E,9B,00,F7,E1,B9,00,08
Patch1: 8A,86,96,00,8A,8E,9B,00,C0,E1,02,90,F6,E1,F7,A6,94,00,B9,00,20
The checksum of this patch1 is 29h less than the buggy1 code, so if this is the only patch you make, add 29h to the last byte of the BIOS to make the F-segment checksum correct again.

And this is the second variation of this bug, as found in the 11/03/94--2C4X6H01-00 BIOS.

The attachment 2GB limit bugfix_2.png is no longer available

This code is even 3 bytes longer and so is its patch.
The 24 bytes long hex signatures of this second bug and its patch are as follows:
Buggy2: 8B,86,94,00,32,ED,8A,8E,96,00,F7,E1,8A,8E,9B,00,C1,E1,03,F7,E1,B9,09,3D
Patch2: 8A,86,96,00,32,ED,8A,8E,9B,00,C0,E1,02,F6,E1,8B,8E,94,00,F7,E1,B9,00,20
The checksum of this patch2 is 29h less than the buggy2 code, so if this is the only patch you make, add 29h to the last byte of the BIOS to make the F-segment checksum correct again.

In the next part I will talk about what can be changed in the uncompressed Award BIOS, to have better Am5x86-133 support.

Jan

Finally, the year 2094 and 2gb HDD bug solved for my EXP4045 motherboard. Thank you!

Hi 486guy,

Great to hear that my modding guide helped you to solve the EXP4045 BIOS bugs.
Welcome to the league of BIOS patchers! 😉

Cheers, Jan

Chkcpu wrote on 2025-03-13, 12:56:

Hi 486guy, […]
Show full quote

486guy wrote on 2025-03-13, 11:03:

Chkcpu wrote on 2021-11-24, 17:55:

#Part 3 – What to patch in an uncompressed Award BIOS […]
Show full quote

#Part 3 – What to patch in an uncompressed Award BIOS

After two episodes of preliminaries, it is time to start patching! 😀

1) Let’s start with the Year 2094 bug. A well known bug in 1994-1995 Award BIOSes.
Actually this bug and its fix were already addressed here recently by jakethompson1, but I will also show it here for completeness sake.
This bug causes the year to jump forward to 2094 at each boot-up whenever the date was set to 1-1-2000 or later.

At POST 0B, the BIOS checks if the RTC uses valid values by reading the CMOS registers for seconds, minutes, hours, day, month, year, and century. It then uses a short table with maximum and minimum values for each of these 7 registers.
The minimum values table contains the hex numbers: 00, 00, 00, 01, 01, 94, 19, and this is the binary signature you have to look for. If you don’t find this signature, your PC should be free of this bug.

The error is in the routine that walks this table, but the fix is setting the minimum year from 1994 to 2000 by changing the last 2 bytes in this table.
The new table should become: 00, 00, 00, 01, 01, 00, 20 to fix this bug.

Note that this silly bug appeared in mid 1994 when Award tried to make the BIOS millennium compliant. Before that, the BIOS didn’t do any century checking, and when Award fixed this bug by the end of 1995, they simply removed this century check again! 😉

2) The 2nd bugfix is for the 2GB Harddisk size display limit bug.

At the beginning of 1994, the IDE Harddisk support of most BIOSes was still limited to 504MB.
But Award fixed that, and all Award BIOSes dated July 1994 or later correctly support the LBA assisted translation, up to the 8 GB limit of the traditional BIOS Int 13h interface.
There is however a bug in the BIOSes dated before January 1996 that limits the harddisk size display, on the BIOS Setup and boot screens, to 2015 MB.

Whenever a drive is 2016 MB or larger, the display starts to count from zero again. The same happens at 4032 and 6048 MB.
This looks a lot like the an actual 2 GB limit but is only a cosmetic bug in the harddisk size display routine, and it doesn't affect the BIOS support for these larger drives.
For these Award v4.50(P)(G) BIOSes, just use the HDD AUTO DETECTION feature to Setup the drive, select the option with LBA at the end, and disregard the incorrect HD size display.
Or, you could read on and patch this bug yourself! 😉

I have found 2 variations of this buggy code in the Award v4.50(P)(G) BIOS, but both variations use the same calculation method and therefore have the same bug. This piece of code takes the Cylinder, Head, and Sector count of the drive in question, multiplies them and divides the result by 2048 to arrive at the number of MB. In the buggy code a between result gets truncated and as a consequence the end result rolls over to zero every 2016MB.
For this bugfix I rearranged the multiplication order so the truncation doesn’t happen and this new code fitted nicely in the same space, so you only have to overwrite the old code by the new.

This is the first variation, and below you’ll see how the buggy and the fixed code look in my disassembler listing of a 03/10/95-ALI-1439G-1437-2A4KC000-00 BIOS.

The attachment 2GB limit bugfix_1.png is no longer available

So the 21 bytes long hex signatures of this first bug and its patch are as follows:
Buggy1: 8B,86,94,00,32,ED,8A,8E,96,00,F7,E1,8A,8E,9B,00,F7,E1,B9,00,08
Patch1: 8A,86,96,00,8A,8E,9B,00,C0,E1,02,90,F6,E1,F7,A6,94,00,B9,00,20
The checksum of this patch1 is 29h less than the buggy1 code, so if this is the only patch you make, add 29h to the last byte of the BIOS to make the F-segment checksum correct again.

And this is the second variation of this bug, as found in the 11/03/94--2C4X6H01-00 BIOS.

The attachment 2GB limit bugfix_2.png is no longer available

This code is even 3 bytes longer and so is its patch.
The 24 bytes long hex signatures of this second bug and its patch are as follows:
Buggy2: 8B,86,94,00,32,ED,8A,8E,96,00,F7,E1,8A,8E,9B,00,C1,E1,03,F7,E1,B9,09,3D
Patch2: 8A,86,96,00,32,ED,8A,8E,9B,00,C0,E1,02,F6,E1,8B,8E,94,00,F7,E1,B9,00,20
The checksum of this patch2 is 29h less than the buggy2 code, so if this is the only patch you make, add 29h to the last byte of the BIOS to make the F-segment checksum correct again.

In the next part I will talk about what can be changed in the uncompressed Award BIOS, to have better Am5x86-133 support.

Jan

Finally, the year 2094 and 2gb HDD bug solved for my EXP4045 motherboard. Thank you!

Hi 486guy,

Great to hear that my modding guide helped you to solve the EXP4045 BIOS bugs.
Welcome to the league of BIOS patchers! 😉

Cheers, Jan

The only issue I have with this motherboard is I get a checksum error usually on my first boot. Already connected an external battery but still. This board has a Dallas 12887 chip. I’m not sure what’s wrong with it.

When will the next modding episode be? 😀

486guy wrote on 2025-03-13, 14:16:

Chkcpu wrote on 2025-03-13, 12:56:

Hi 486guy, […]
Show full quote

486guy wrote on 2025-03-13, 11:03:

Finally, the year 2094 and 2gb HDD bug solved for my EXP4045 motherboard. Thank you!

Hi 486guy,

Great to hear that my modding guide helped you to solve the EXP4045 BIOS bugs.
Welcome to the league of BIOS patchers! 😉

Cheers, Jan

The only issue I have with this motherboard is I get a checksum error usually on my first boot. Already connected an external battery but still. This board has a Dallas 12887 chip. I’m not sure what’s wrong with it.

Do you only get the “CMOS checksum error – Defaults loaded” message, or the “CMOS battery failed” message as well?

If you don’t see this “CMOS battery failed” message, then the external battery connection works and the system should keep the time when switched off.
In this case the “CMOS checksum error – Defaults loaded” message should be gone after selecting SAVE & EXIT in the BIOS Setup.

Let us know if you see a different behavior on your EXP4045.

You can also try a different BIOS. The latest EXP4045 BIOS is Rev 2.3 and I’ve patched this BIOS for Am5x86 support including x4 mode and L1 cache WB.
You can download it from:
Re: Cpu write back cache causing issues.

Cheers, Jan

Edit: Wait, you say that you have a Dallas 12887 on this board? The EXP4045 should have an M5818 or 6818A or equivalent RTC chip next to the BIOS chip.
https://theretroweb.com/chips/4559
I don’t think the Dallas supports an external battery.

Chkcpu wrote on 2025-03-14, 10:20:

Do you only get the “CMOS checksum error – Defaults loaded” message, or the “CMOS battery failed” message as well? […]
Show full quote

486guy wrote on 2025-03-13, 14:16:

Chkcpu wrote on 2025-03-13, 12:56:

Hi 486guy, […]
Show full quote

Hi 486guy,

Great to hear that my modding guide helped you to solve the EXP4045 BIOS bugs.
Welcome to the league of BIOS patchers! 😉

Cheers, Jan

The only issue I have with this motherboard is I get a checksum error usually on my first boot. Already connected an external battery but still. This board has a Dallas 12887 chip. I’m not sure what’s wrong with it.

Do you only get the “CMOS checksum error – Defaults loaded” message, or the “CMOS battery failed” message as well?

If you don’t see this “CMOS battery failed” message, then the external battery connection works and the system should keep the time when switched off.
In this case the “CMOS checksum error – Defaults loaded” message should be gone after selecting SAVE & EXIT in the BIOS Setup.

Let us know if you see a different behavior on your EXP4045.

You can also try a different BIOS. The latest EXP4045 BIOS is Rev 2.3 and I’ve patched this BIOS for Am5x86 support including x4 mode and L1 cache WB.
You can download it from:
Re: Cpu write back cache causing issues.

Cheers, Jan

Edit: Wait, you say that you have a Dallas 12887 on this board? The EXP4045 should have an M5818 or 6818A or equivalent RTC chip next to the BIOS chip.
https://theretroweb.com/chips/4559
I don’t think the Dallas supports an external battery.

I get the “checksum error” and “cmos battery failed” randomly from cold start mostly. Mostly, I don’t get these error messages when rebooting either CTRL + ALT + Del or shorting the reset pins on the motherboard. BIOS settings are saved though including date & time.

Now that you mentioned about the Dallas 12887 not supporting an external battery. That makes sense because this rtc chip already has an internal battery. Previous owner of my EXP4045 motherboard must have changed the rtc chip. I do have three (3) 6818 used chips that I bought a long time ago that I never get the chance to test until now. But they won’t work with this board. When I get to the BIOS setup, seconds time is not moving at all so I just use the Dallas one. I will try it again tomorrow when I get home.

I have tried the v2.3 bios firmware from theretroweb but I always get the “..F1 to continue..” whether theres error or no. It won’t let me boot to my floppy or ide drive without pressing F1.

It looks like my EXP4045 motherboard does support the Dallas 12887 chip after all as per the silkscreen on the board under the chip. It says “DS12887/147818A”. I can’t find any datasheet for the 147818A so the three mc146818P I have might not be compatible or they’re just not working anymore??

I have just tested the v2.3 BIOS again and it is indeed stuck at “..F1 to continue..”.

486guy wrote on 2025-03-17, 02:23:

It looks like my EXP4045 motherboard does support the Dallas 12887 chip after all as per the silkscreen on the board under the chip. It says “DS12887/147818A”. I can’t find any datasheet for the 147818A so the three mc146818P I have might not be compatible or they’re just not working anymore??

You are right, it does say it supports the Dallas DS12887!
I don’t know what a 147818A is either, but probably a variant of the 146818A.

On https://theretroweb.com/motherboards/s/dataexpert-exp4045 I see 4 pictures of the EXP4045 and 3 of them have an ALi M5818 fitted and the 4th a W85C178. Both these RTC chips are drop-in replacements of the Motorola MC146818A.

The Dallas DS12887 has both the 32.768kHz crystal and the battery internal. The 146818A chips don’t have that, so the EXP4045 has them on the board as well to support either RTC. Nice!
The 32kHz crystal (Y2) is a bit far from the RTC chip though, near the edge of the board, so there is probably a buffer circuit to carry a sufficiently strong clock signal to the RTC chip.
The Dallas doesn’t use this external clock, so it may be a good idea to check this 32kHz signal on pin 2 or 3 of the RTC. Your 146818P chips need this signal to work. On the other hand, these 146818P’s may not be compatible with the EXP4045 afterall. 😉

I have just tested the v2.3 BIOS again and it is indeed stuck at “..F1 to continue..”.

The “Press F1 to continue” message should only be display when an error is detected.
And you don’t see a fail or error message displayed above the Press F1 message? Strange..

Cheers, Jan

The “Press F1 to continue” message should only be display when an error is detected.
And you don’t see a fail or error message displayed above the Press F1 message? Strange..

Yes, there’s no error and pressing F1 continues just fine.

Chkcpu wrote on 2025-03-14, 10:20:

. . […]
Show full quote

.
.

You can also try a different BIOS. The latest EXP4045 BIOS is Rev 2.3 and I’ve patched this BIOS for Am5x86 support including x4 mode and L1 cache WB.
You can download it from:
Re: Cpu write back cache causing issues.
.
.

I thought the available v2.3 firmware on retroweb is the one you already patched. I'm wrong so i downloaded the patched one and tried it but still the same issue. I still need to press F1 to continue.

Hello !
I confirm that my MB-8500TVX (rev 2.1) is PERFECTLY working with a K6-II(400), and a K6-IIIE+(400) with the unofficial BIOS, as soon as VRM are delivering enough power 😉
I modded the VRM in order to deliver 1.7v, but also using 3.3V as input instead of 5V .
It lowered the heat from the (linear) regulater A LOT, and also reduced electrical noise on sound-card and Voodoo.
On that board, with slow L2 cache, the K6-III gave a massive performance increase.
A big Win ! Thank you very much.

Now I will try to mod the FSB to reach 500MHz, by changing the PLL board.

But on BIOS side => Its done and perfect !

chacha wrote on 2025-03-21, 09:05:

Hello ! I confirm that my MB-8500TVX (rev 2.1) is PERFECTLY working with a K6-II(400), and a K6-IIIE+(400) with the unofficial B […]
Show full quote

Hello !
I confirm that my MB-8500TVX (rev 2.1) is PERFECTLY working with a K6-II(400), and a K6-IIIE+(400) with the unofficial BIOS, as soon as VRM are delivering enough power 😉
I modded the VRM in order to deliver 1.7v, but also using 3.3V as input instead of 5V .
It lowered the heat from the (linear) regulater A LOT, and also reduced electrical noise on sound-card and Voodoo.
On that board, with slow L2 cache, the K6-III gave a massive performance increase.
A big Win ! Thank you very much.

Now I will try to mod the FSB to reach 500MHz, by changing the PLL board.

But on BIOS side => Its done and perfect !

Hello chacha,

Thanks for reporting back on the MB-8500TVX Unicore BIOS.
Great to hear it works so well! I will send it through to TRW.

Quite something, those mods you did. I hope you can pull-off that PLL mod as well.
Even 450MHz would be great, but 500MHz on a VX board, amazing!! 😊

Cheers, Jan

Hello Jan!

I got another nice early ATX board MSI MS-5136 TR8

https://theretroweb.com/motherboards/s/msi-ms … 136-ver-1.0-tr8
The board has an undocumented 2.2v setting so i inserted amd k6-2 cpu -)

it's booting with k6-2 cpu with default bios WI7C but there is some issues
incorrect cpu detecting, like MMX cpu 66mhz -)
memory performance reduced to FPM mode (?) according to SpeedSys.

ide controller on this board is dead so i can not check hdd size. using external pci controller.

Could you please create a k6-2 fix for this board?