Hi Anonymous Coward,

Reading about your “2x mode” trick and MR-BIOS solution, I fully agree that your Cx5x86 problems are BIOS related.
Although I have more experience patching Award v4.50G 486 BIOSes from 1994/1995 for Am5x86 support, I can take a look at your Award v4.50 BIOS to see what is missing and if I can fix that.

Please put a dump of your BIOS(es) up here and tell us for which boards you like to have a Cx5x86 fix.

Cheers, Jan

It was a long time ago I was trying a 5x86 on other boards, but I think I found more or less the same... if it supported Cyrix DX2 it would work, if it didn't, you got nothing.

Chkcpu wrote on 2024-06-01, 11:08:

Please put a dump of your BIOS(es) up here and tell us for which boards you like to have a Cx5x86 fix.

Hi, Jan. Here you are.

Thanks for the BIOS.
It appears to be the #401A0-0112 Award v4.50 BIOS for the Asus VL/EISA-486SV1 board. An nice and interesting 486 EISA Socket 2 board. 😀
https://theretroweb.com/motherboards/s/asus-v … isa-486sv1#bios
Your BIOS is identical to the #401A0-0112 version on TRW.

I took a quick peek and this BIOS has indeed limited CPU support.
I see support for up to i486DX2, IBM486SLC2, and Cx486S2. So no Cx486DX/DX2/DX4 or Cx5x86 support. Did you try running a Cx486DX or Cx486DX2 on this board?

It will take me a while to do a detailed analysis. I’ll report back when I have more information.

Jan

I don't have any Cx486DX or DX2 handy. The closest I have is an ST486DX4. I will test tomorrow.
It's pretty amazing that the BIOS for the 486SV1 is from 1994, yet it doesn't really support any additional CPUs compared to what you'd find in a 1992 BIOS.

Anonymous Coward wrote on 2024-06-02, 14:51:

It's pretty amazing (...)

You seem to have misspelled "cheap" 😀 I always wondered how many of these mobos were using licenced, actually paid for, BIOSes. IIRC there were some no-name mobos that just stole the BIOS off some other product (it was a clone so little to no work needed, other than some ID string hack, to get it to work). And even for licenced software I wonder what the conditions were, was it per-piece or one time payment? Who exactly would be counting that anyway? So possibly it was a licence bought once and then used on anything that fit.

And then there were, possibly, some politics involved. Intel was figthing Cyrix, esp. in USA where they could actually get results (not to mention it was easier to spend some money to get those results), it's possible some brands who actually cared for the US market and their own image could be "persuaded" to have less Cyrix support in their products. UMC for example had to all but abandon sales of their 486 clone in US because of Intel.

Chkcpu wrote on 2024-06-02, 11:48:

I see support for up to i486DX2, IBM486SLC2, and Cx486S2. So no Cx486DX/DX2/DX4 or Cx5x86 support. Did you try running a Cx486DX or Cx486DX2 on this board?

It will take me a while to do a detailed analysis. I’ll report back when I have more information.

Jan

I haven't dug into it but--with those old BIOSes, do you think they get confused by the value in DX at reset when running on such a Cyrix CPU, or is it the code path when they divide 5/2 to see if it's a Cyrix and then start poking at it once it is?

Chkcpu wrote on 2024-06-02, 11:48:

Did you try running a Cx486DX or Cx486DX2 on this board?

I just tested a ST486DX4-100. That one seems to work without issue.

Is it running in full "cyrix" mode though, or only benchmarking at like 90% because it's in writethrough dumbest available to be intel compatible mode? Personally I've never had the DX2s fail to work, even in real old boards that only had DX/SX setting and probably came out before DX2s, but they are a bit more off the pace than AMD/Intel, whereas with full support they don't perform exactly the same but "trade blows" i.e. a little faster in some things, a little slower in others.

As the motherboard predates L1 writeback cache, the Cyrix chips have to run in write through mode.

I think I have found a workaround. When using a POST card on my SiS EISA motherboards with 06/06/92 AMIBIOS, I noticed that it always stops at 05h. Supposedly this code means the BIOS is trying to disable cache memory. Not clear if that's L1, L2 or both. In any case, I used Google Gemini AI to try to find a solution. It suggested bypassing the 05h routine by adding three NOPs to the binary. In my case specifically, that is:

0000DCB0 00 00 00 00 B0 05 E6 80 90 90 90 B0 06 E6 80 8C

90 in machine code is the same as NOP

It works. I can now run a Cyrix 5x86-133 in my system without issue. I'm not sure if there are any consequences to skipping the 05h test, but if so it's probably possible to patch the test to make it compatible with Cyrix.

Anonymous Coward wrote on 2026-08-05, 13:29:

It works. I can now run a Cyrix 5x86-133 in my system without issue. I'm not sure if there are any consequences to skipping the 05h test, but if so it's probably possible to patch the test to make it compatible with Cyrix.

Yes but using L1 in write through mode is a bummer!

I bet your 486SX-16 doesn't do L1 cache in writeback mode either!

Anonymous Coward wrote on 2026-08-05, 14:33:

I bet your 486SX-16 doesn't do L1 cache in writeback mode either!

Ha, I don't own any 486SX at all 😀

My answer was because a mate and me did similar experiments with my AE4 EISA board and a voltage adapter.
Even when we overcame the BIOS' timing settings that were auto-setup during processors performance detection the performance increments from 2x to 3x and even 4x have been so little!
We got best results with "486 DX2 100" @ 50 MHz FSB. Finally we kept my 486 DX 50 without any voltage adapter. It is fine for DOS and Windows NT 4.

That’s pretty strange. I have both Amd and cyrix 5x86 working on my board and they’re definitely faster than a dx2-100. The amd at 160 with tight timings is a real screamer. I just want the cyrix in there for the novelty

Of course, Am5x86 133 50x3 was faster than an Am/Cx 486 DX4 100 50x2.
It was a rarely used EISA machine. We neiter wanted to overclock nor to waste our only voltage interposer on that machine.
Compared to a 486 DX 50 we could not marginally improve the transfer rate from and to our Adaptec 2740W, it was at 18,5 MB/s already.
See SpeedSYS charts at Win95 Performance of 2740W / 2742W
And with our 3com 3C597 we also got no marginally improvements.

The real improvement on my AE4 board was adding a socket and populating it with a dirty tag ram. However the improvement was marginally at 50 MHz but not marginally at 40 or 33 MHz.

Anonymous Coward wrote on 2026-08-05, 13:29:

I think I have found a workaround. When using a POST card on my SiS EISA motherboards with 06/06/92 AMIBIOS, I noticed that it a […]
Show full quote

I think I have found a workaround. When using a POST card on my SiS EISA motherboards with 06/06/92 AMIBIOS, I noticed that it always stops at 05h. Supposedly this code means the BIOS is trying to disable cache memory. Not clear if that's L1, L2 or both. In any case, I used Google Gemini AI to try to find a solution. It suggested bypassing the 05h routine by adding three NOPs to the binary. In my case specifically, that is:

0000DCB0 00 00 00 00 B0 05 E6 80 90 90 90 B0 06 E6 80 8C

90 in machine code is the same as NOP

It works. I can now run a Cyrix 5x86-133 in my system without issue. I'm not sure if there are any consequences to skipping the 05h test, but if so it's probably possible to patch the test to make it compatible with Cyrix.

We've been DMing about this. In consulting the Cyrix 5x86 BIOS Writer's Guide it hints at this issue but does not elaborate on it.
In also explaining the issue to Gemini, it comes up the idea, which seems plausible: on all Cyrix write-back capable 486 CPUs, it is illegal to issue invd or wbinvd while CR0.CD=1 and CR0.NW=1; it will stall the CPU, and this is why CCR2.LOCK_NW exists.

Accordingly before the BIOS executes this code:

1seg000:8AD0 66 0D 00 00 00 60                          or      eax, 60000000h
2seg000:8AD6 0F 22 C0                                   mov     cr0, eax
3seg000:8AD9 0F 09                                      wbinvd

The 5x86 (or any write-back capable Cyrix 486) needs to be rendered safe as:

1mov eax,cr0
2or eax,40000000h ; CD=1
3and eax,0dfffffffh ; NW=0
4mov cr0,eax
5mov ax,0c2c2h
6out 22h,al
7in al,23h
8or al,4 ; LOCK_NW=1
9xchg al,ah
10out 22h,al
11xchg al,ah
12out 23h,al

This way, later when the BIOS tries to turn NW back on, it is blocked from doing so, and the unsafe wbinvd/invd does not happen.

Chkcpu wrote on 2024-06-02, 11:48:

I see support for up to i486DX2, IBM486SLC2, and Cx486S2. So no Cx486DX/DX2/DX4 or Cx5x86 support. Did you try running a Cx486DX or Cx486DX2 on this board?

Hello Chkcpu, what do you think about the above about Cyrix CPUs, in that any pre-Cyrix aware BIOS is inherently unusable on write-back capable CPUs until the LOCK_NW support is added?
It is this BIOS we're talking about now: https://theretroweb.com/motherboard/bios/mcci … e7300770952.rom
Note that it does look like it has some port 22h/23h code for Cyrixes, I don't believe that will have executed yet before the errant wbinvd while NW=1 in post code 5 executes. But it does mean, if patching this to set LOCK_NW=1, we might have to worry about the BIOS un-setting it later.
I think this will be a more permanent solution. Without LOCK_NW there's the risk that an invd or wbinvd executed after the system is up and running, will still lock it up.

Argh, as I continued the above gemini conversation it just talked in circles and eventually contradicted itself. But it seems there might really be something to it, with needing to avoid NW=1 on a non-write back capable chipset.

Hello Anonymous Coward,
Please give this (PATCHED-mcci-nice-super-eisa.rom in the zip) a try. I have tested in emulation but I don't have an interposer to test a 5x86 on pre-5x86 BIOS real hardware. If the post code 05 issue isn't fixed, you can do the same 3-byte NOP you did before to skip it. Because you were also looking for it, I also did a cosmetic fix to try and identify DX4WT (CPUID=048x), Am5x86WT (CPUID=04Ex) and Cx5x86 on the diag screen as well.

Note that the ROM checksum check is patched out due to frequently testing changes. If you want it back, change dcd7 from EB to 74, and recalculate and patch the checksum.

It has the following patches (the ZIP has the details):

00 - hook interpretation of DL value at reset
01 - test if it's a Cx5x86, and if so go to patch 02 for additional space
02 - turn off NW bit in CR0. turn on LOCK_NW bit in CCR2. should fix post code 05 issue?
03 - overwrite CPU name string selection routine. 80286, 486SLC, and 486DLC are replaced with Cx5x86, 80486DX4, and Am5x86. The Cx5x86 is detected explicitly. The other two are detected from DL value at boot (see patch 10).
04 - followup adjustment to CPU name string selection routine.
10 - overwrite DL value detection routine. bits 2 and 3 in CMOS register B3 are given a new meaning: 02h=DX2, 04h=DX4, 06h=Am5x86

Chkcpu - I hope you enjoy it as well!