[*][2128-212C] Result of reading port 22h bit 0 must be 1[/list]
Now, I'm not sure what the last two options mean, but in any case my assumption was that one of those checks was failing, so I wrote a small assembly program that tests those values and bingo! The last one, where port 22h is read and a value of 1 is expected in bit 0 did not pass.
Since the value read from 22h is immediately discarded and not used anywhere else, this check must not affect anything else in the code. So, the patch was easy: I just replaced the JZ instruction that jumps away with a couple of NOPs, since the 1T timing for Cache Burst Read should be easily achievable with 15ns:
Perhaps they intended it to be a read of port 23h (checking bit 0 of whatever register index was previously selected)?
Being an accountant by profession with zero programming knowledge made it easy for me also understand how to edit the AMIBIOS for my OPTI 495XLC chipset-based motherboards (after a bit of trial and error using PCem).
My idea is to use the BIOS image from another motherboard manufacturer (A-Trend) on my Jetway motherboard - the reason for this has to do with the turbo switch functionality and the fact that it doesn't work at all when the PC is in "protected mode" (with EMM386.EXE load). I'm not sure whether this actually has to do with the chipset or whether this is something in the BIOS. I'm hoping to confirm this by trying out the other BIOS image. In other words, I want to see whether the A-Trend BIOS works "better" but, it has some options hidden which are unhidden on my Jetway motherboard and hence, why this post is quite helpful.
Apart from that, the Jetway BIOS just works very weird by disabling the turbo function when the turbo header is shorted but then disables (switches "off") the turbo LED (and enables the turbo function when the header is not shorted and then switches "on" the turbo LED). It's supposed to work the other way around. There must a register somewhere in the BIOS where one can flip this as I've seen in some of the MR BIOS documentation that they released different BIOS versions that also flipped the turbo switch functionality around.
Perhaps they intended it to be a read of port 23h (checking bit 0 of whatever register index was previously selected)?
That could indeed be the case, however in the chipset docs they clearly mention the need for writing to 22h before every access due to the index being reset after every read/write:
SiS wrote:
The index is reset after each data access. Every data access to port 23h must be preceded by an index write to port 22h, even if the same register is being accessed.
Then I thought it may be related to Cyrix CPUs, since it uses the same pair of I/O ports as the SiS chipset (22h/23h) for accessing some CPU registers (although a different range of values), and in other sections of the BIOS I noticed that reads of port 22h appeared to be followed by access of some Cyrix configuration control registers. However in the Cyrix 5x86 CPU BIOS Writer's Guide it says that:
Cyrix wrote:
Each port-23h data transfer must be preceded by a port-22h register index selection, otherwise the second and later port-23h operations are directed off-chip and produce external I/O cycles. Reads of I/O port 22h are always directed off-chip.
My guess right now is that the AMI BIOS is using port 22h as some undocumented status register (the range of values is probably restricted to avoid conflicts with the registers for both the SiS chipset and Cyrix CPUs). If that's the case, then what would be that last check that is performed to allow setting the Cache Burst Read Cycle to 1T? Well, the answer may be in the datasheet for the slightly older SiS460 chipset, direct ancestor of the SiS471. Here's what it says about reg. 51h:
Identical to the 471, with the exception that the Cache Burst Read Cycle should only be set to 1 (2T) for 386 CPUs which the 460 supports.
Knowing this, my (very speculative) theory about this is: with the SiS 460 and 471 chipset being so similar in terms of register configuration, this SiS 471 AMI BIOS probably inherited lots of legacy code from older 460 BIOS (the presence of stuff like 80286 or 486SLC/DLC in the table of supported CPUs could also be an indication of copy-pasting code from previous BIOSes by the developers). So, that section that gates the Cache Burst Read Cycle setting behind some checks would be a leftover from an older SiS460 BIOS that went unnoticed during testing (which given the problems with some of the other timing settings would be consistent with subpar QA on AMI's side).
Being an accountant by profession with zero programming knowledge made it easy for me also understand how to edit the AMIBIOS for my OPTI 495XLC chipset-based motherboards (after a bit of trial and error using PCem).
My idea is to use the BIOS image from another motherboard manufacturer (A-Trend) on my Jetway motherboard - the reason for this has to do with the turbo switch functionality and the fact that it doesn't work at all when the PC is in "protected mode" (with EMM386.EXE load). I'm not sure whether this actually has to do with the chipset or whether this is something in the BIOS. I'm hoping to confirm this by trying out the other BIOS image. In other words, I want to see whether the A-Trend BIOS works "better" but, it has some options hidden which are unhidden on my Jetway motherboard and hence, why this post is quite helpful.
Apart from that, the Jetway BIOS just works very weird by disabling the turbo function when the turbo header is shorted but then disables (switches "off") the turbo LED (and enables the turbo function when the header is not shorted and then switches "on" the turbo LED). It's supposed to work the other way around. There must a register somewhere in the BIOS where one can flip this as I've seen in some of the MR BIOS documentation that they released different BIOS versions that also flipped the turbo switch functionality around.
The turbo function is controlled by the OPTI chipset. My first suggestion would be to take a look at the datasheet if you haven't yet (attached below), section 4.15. Interestingly, it mentions that turbo mode is only supported when using 386 CPUs as the pin controlling it has another purpose for 486. It doesn't seem to mention anything about protected mode though. What's the setup your testing with?
Being an accountant by profession with zero programming knowledge made it easy for me also understand how to edit the AMIBIOS for my OPTI 495XLC chipset-based motherboards (after a bit of trial and error using PCem).
My idea is to use the BIOS image from another motherboard manufacturer (A-Trend) on my Jetway motherboard - the reason for this has to do with the turbo switch functionality and the fact that it doesn't work at all when the PC is in "protected mode" (with EMM386.EXE load). I'm not sure whether this actually has to do with the chipset or whether this is something in the BIOS. I'm hoping to confirm this by trying out the other BIOS image. In other words, I want to see whether the A-Trend BIOS works "better" but, it has some options hidden which are unhidden on my Jetway motherboard and hence, why this post is quite helpful.
Apart from that, the Jetway BIOS just works very weird by disabling the turbo function when the turbo header is shorted but then disables (switches "off") the turbo LED (and enables the turbo function when the header is not shorted and then switches "on" the turbo LED). It's supposed to work the other way around. There must a register somewhere in the BIOS where one can flip this as I've seen in some of the MR BIOS documentation that they released different BIOS versions that also flipped the turbo switch functionality around.
The turbo function is controlled by the OPTI chipset. My first suggestion would be to take a look at the datasheet if you haven't yet (attached below), section 4.15. Interestingly, it mentions that turbo mode is only supported when using 386 CPUs as the pin controlling it has another purpose for 486. It doesn't seem to mention anything about protected mode though. What's the setup your testing with?
I currently have a Cyrix 486DLC 40 MHz installed with 8 MB RAM and a Tseng Labs ET4000 16-bit ISA graphics card.
I must be honest; I haven't yet tried to test a real 486 in this PC to see if the turbo functionality work. My intention with this setup was to recreate my original PC that I bought back in 1993 (it came with the Cyrix CPU on the Jetway motherboard - J-402B).
But, here's the interesting part:
In protected mode the turbo button doesn't work. However, when I press Ctrl + Alt + -, it does slow down the system.
In real mode, the turbo button does work, together with the keyboard shortcut.
To quickly summarise. The original BIOS became corrupted some years ago and I tried for a long time to find a suitable replacement. Eventually a user with a 486 only version of the motherboard (which I now suspect is model number J-403) provided a BIOS which has the same options as my BIOS did and, for the most part, works perfectly. The only odd behaviour is the turbo functionality. More in this post: Help me identify and obtain a BIOS for my old 3/486 VL motherboard
What I've done now was to look for similar BIOS revisions. I eventually found one from the "BEK-tronic BEK-3739" motherboard (from TheRetroWeb). The only issue I had with this BIOS is that a lot of the options were hidden but, now I found a way to unhide them and make it "appear" like my BIOS (and what I also see in the manual). Unfortunately, with this BIOS, both in protected and real mode, the turbo switch doesn't function (the keyboard shortcut does). This is despite the Turbo Switch function being enabled in the Advanced CMOS Setup.
Thanks @jakethompson1 for this great guide. I used it to successfully add PS2 mouse support to my 386sx board.
I decided to nerd out today and create a AMIBIOS checksum calculator in python based on your find. It can also calculate the 2-byte addition required to make the checksum equal to zero so that it passes that check.
Example output on my PS2 modified bios:
1Checksum does not equal zero!!! 2Checksum: 16 32 byte addition needed to validate checksum: F0 FF
I then added F0 FF to the middle of large blank area of the bios at 0x6000. Can run it again to verify:
1Checksum equals zero 2Checksum: 0
I flashed and it works great. Nice to know if there is a bit-flip down the road (unlikely, I know) the bios should catch it.
