Becausethe BIOS_uP_ID is used in multiple places during POST to make decisions depending on the CPU model, the most effective way to add Am5x86 support to a 1994 BIOS is to let the BIOS think it is a DX4. This can be done with a small change to the Reset_ID table and works for the Enhanced Am486DX4 as well.
To know which Reset_IDs to use for the Am5x86 patch, we need AMD document 19720.
This AMD 486 BIOS Development Guide tells us the Reset_ID for each Am486 model, but also shows that specific models can have more than one Reset_ID depending on multiplier and L1 cache WT/WB settings at reset.
This patch uses the 2nd table item, originally for the DX4, now for the Am5x86 in x4 mode. The CMOS_3F_data byte for this item has both bits 7 and 6 set to indicate x4 mode. This will be explained later on.
The 4th table item, originally for a Pentium, can be overwritten without consequence on this socket 3 BIOS, and is used for the new AMD/Intel DX4 item.
Doing the patch this way, the 3rd table item for the Cx486DX is already in sequence and can remain unchanged.
If your 1994 Award BIOS is slightly older, you may find that the Reset_ID 1480h-148Fh for the DX4 ODP is missing and that the DX4 byte sequence AB, 90, 80, 04, 8F, 04 is at the beginning of the table. However, the above Am5x86 patch will still work in this case, only the DX4 ODP is and remains unsupported.
But look-out for a changed CMOS_3Fh bit definition for Green CPU from bit 4 to bit 5 in older BIOSes. The patch has to be adjusted accordingly in this case, and this is how the same Am5x86 patch looks when you find the DX4 byte sequence to be AB, A0, 80, 04, 8F, 04 in your BIOS.
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:
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.
Unfortunately, the copy of this BIOS on Ultimate Retro is corrupt. Its missing the first half with all the POST routines. ?
If you have a good dump of this BIOS, I very much like a copy for Ultimate Retro and for myself. ?
Well I am doubly embarrassed, because I messed up both the board name (MB-1433UHT-A is correct) *and* I was the one who dumped the BIOS that is on Ultimate Retro... guess I will remember to pull the chip from the board to read it in the future.
However, in the CPU support list (offset 172BAh) I see additional Am486DX2PLUS and Am486DX4PLUS strings for the Enhanced AMD DX2/4 CPUs. There is probably some hardcoded CPUID detection for these models somewhere because I see no support for them in the Reset_ID table.
I will look further into that. Maybe a nicer Am5x86 patch, using the Am486DX4PLUS string, is possible in this BIOS.
This board revision at least the one I'm testing seems to read with the multimeter as lowest vcore (undocumented no jumper setting) around 2,4 volts so most K6-2/+ cpus are not possible without power mosfet circuit mod but at least a K6-2 450 with 2,4v exist and the K6-3 400 2,4v (to risk I might try the K6-2 550 2,3v). For the freqs there's a JP6 that seems related to higher multipliers but probably functional on later revisions. Maybe the bios is compatible with different pcb but this pcb rev seems not giving much space for many cpu. The FSB should go up to 75Mhz I have to try that even if the K6-3 400 is already a powerful cpu and can work @ 66Mhz bus. ?
I'm not sure but I think this is the right place to ask my question(s). I will try to describe the background for them as detailed as possible. If questions arise I will try to answer them as soon as possible.
So my questions are:
- Is there any reason known why a newer BIOS could have such impact on performance and could this be patched (generally, not just for the HOT-599)?
- would it be possible to correct the monitoring issues in the newer HOT-599 BIOS by correcting the text strings and fixing the values shown? (I have stepped through the BIOS file and found the text strings, so I guess I could possibly replace them myself, but besides my non-existent capabilities in BIOS modding this is a 2 MBit BIOS with another build up compared to the usual 1 MBit ones. So I am unsure if I could get it to work again after my "modding". This is also a "just one try for free" thing for me as I have neither a flash programmer nor another board capable of flashing a 2 MBit BIOS for the case I mess it up)
- Is it possible to add support for K6-2+ and III+ CPUs to the HOT-599? According to the manufacturer this board does not support them and it really doesn't POST with a K6-2+. I don't know if there is any HW specific reason for this but maybe this could be done.
thank you for your comprehensive reply!
I will have another look at these timing stuff in the newer BIOS but I'm pretty sure I checked this already and everything was set to fastest as far as I could judge it.
Also the VGA setting was (shown as) 100 MHz all the time. I will check this again.
One thing I didn't do after flashing is loading BIOS defaults. Maybe this one got me fooled.
I know that there is one particular setting at which some voltage regulators virtually shut off, this is mostly the one at the switchover point from the lower region (something like 1.3V up to 2.0V) to the higher region (2.0V and up). But on this board this should not apply. The regulator is 5 Bit but only four of them are configurable. Documented settings even start at 2.2V, though. I will have a second look at this one, but I'm pretty sure I've tested with the 2.0V and 2.1V setting including double checking with a voltmeter already.
I admittedly didn't do much testing with the K6-2+ as it didn't POST on the first try (CPU is known good) and the manufacturer clearly stated that these aren't supported at all. Maybe I got distracted too easily by this "knowledge".
As soon as I can take some time I will have a look into this, too.
I can configure the drive geometry, but the max heads I can set is 15 (fdisk in Linux says it should be 240 ) . Cylinders (30533) and Sectors/Track (63) I can set just fine though. Maybe this is overly optimistic, but I am going to see if I can change the type used for max heads from 4 bits to something else?
Anyway, this is all irrelevant because breaking the 8GiB HDD barrier involves a major rewrite of the Interrupt 13h Harddisk interface and this is way beyond my expertise in any BIOS, Award, AMI, or otherwise. It involves adding the IBM/Microsoft Int 13h extensions to the Harddisk interface.
if the that menu when you right click doesn't come up correctly you can always use the menu bar and have FileSystem module highlighted and click Action then File and then Replace as is..
This BIOS file type is not capsuled and usually not write protected. It is most common for ASUS P67 and Z68 mainboards.
That is why it should be no problem to get an accurately modded BIOS flashed into the BIOS chip by using the ASUS standard tool named "EZ Flash".
Flashing an ASUS BIOS file with the extension ".CAP"
These types of ASUS' BIOS files are capsuled and write protected, which makes it impossible to flash a modded .CAP BIOS the usual way.
There are at least 2 options how to solve this problem:
Seems fairly comprehensive good job although when doing it this part should be in my opinion the rule use the EFI loading for all the extra .kext, good enough for Apple to use for their extras good enough for everyone else. Plus it makes it easier to change things around rather than the obsession there seems to be with getting everything in the BIOS.
A small correction here. It should be recommended to always keep a Defaults in firmware, either the stock MP3,1 one included or something you plan on using. The Defaults.plist in ESP will be used first if its in place but the one in firmware will be available if there is ever a problem with oz finding ESP.
This only happens when am using hdmi port, is a kernel panic. But if i use a DVI port only i have no problem. So, to use a HDMI port i have to patch AplleHDAController: 0a0c -> 0c0c
Some one knows about this issue on HD4600???
MB: GA-Z97N-WIFI
Ozmosis 1479
I have an Asus P8Z77-V Pro mobo, and I downloaded the following files the Hackintosh-Forum.de site. I assumed they would be generally configured correctly for the motherboard. I am currently running a PM patched 2104 BIOS with a working Clover installation. Triple boot, Mac/Windows/Linux.
I tried the bios that matched what I had first, flashed via Flashback and booted the machine. No post whatsoever. The MEMOk light and a light on the left of my ram started flashing alternately. I pressed the MemO button to see if it would go - no dice. Reset bios settings with jumper on board, tried again - still nothing.
I then found this guide on rolling your own, so decided I would have a go and create my own rom file. I used the files attached to this guide, but looked at what was installed on the 2108 rom and pretty much copied it. I created my own kext ifs files, added those and my own Ozmosis defaults which pretty much was left default other than filling in serials numbers etc for iMessage.
3a8082e126