I.nfraR.ed

My table is based on one of the 200MHz DFI tables. There are several such tables and they differ in this byte only (if we ignore the multiplier table). One strange thing - initial NF7 bios doesn't have this first part of the tables...

It's not really custom, it's from DFI. I've started to play with values and noticed one particular byte changes and it seems to have some effect on stability, but might also hurt performance. Going down to 22 improves stability at speeds close to my maximum 270MHz FSB. I've left it at 55 for now, until I do more tests. This one is also a direct value and can be seen/changed in wpcredit. I think it is b0/d0/f3 around offset 68, but don't have a running system right now to check. The thing that helped most seems to be drive strength and slew rate. 4/7 works better than default 3/10. PS: As for ROMSIP tables, first line changes are only 0Ch, 0Dh, 0Eh, 0Fh. Didn't see a difference between 0C 10 14 14 and 18 18 18 18. Ultimately, I think we can make one bios for TCCD, one for BH-5 (or maybe SR/DR memory) and one for lower FSB chips with much tighter tables. Similar to DFI NF4 Ultra-D. It seems they couldn't produce a bios that works best for both type of memory, that's why several variants were made. I don't think it is possible to make all memory chips happy with a single bios. What might help is read changelogs of official bioses, extract modules, compare and see the changes, hoping to find something interesting. Sometimes plop boot manager is stuck at initializing the USB, but most of the times it works. And it is now possible to install Windows from USB stick on the NF7, which is a huge plus for me. It's incompatible with acronis boot manager though.

Attached is my custom bios for Abit NF7/NF7-S v2.0. I think it should work on v1.x as well, since I've had reports that my older mod bioses work. I will continue with testing ROMSIPs. Changelog, ROMSIP and ISA OROM source code also included in the zip. NF7D_X1-1T.zip

Yes, it seems NVMM from AMI bios is incompatible with Award, since all 3 (4.08, 4.62 and 4.85) didn't POST on NF7 and for you. But I have the same problem with the rest which are working with failsafe and perhaps something like 166MHz FSB, but not with 200+. Will have to try with another bios or exchange the ROMSIP and see if there's a difference. While it works 260+ with NVDAMC 3.19, I could not POST at 200+ with NVMM - everything else equal. NF7 is an older board though. Maybe boot and decompression blocks matter too. Or it is just a compatibility issue with my RAM, although I have tried other modules, not just BH-5. Edit: BTW, changing BPL modules, I've noticed that the next block contains a bunch of DRAM IC part numbers, e.g. NT5DS16M8AT-6, NT256D64S8HA0G-6, M2G9JAJATT9F081AAD, MPMA82D-68KX3-MAA, MPMA82D-68KX3-MBA, HYS64D32300GU-6, DDR32Mx8AT-5, 68L3223DTM-CC4, TS64MLD64V3F5, NT256D64S88ABG-6, 64D16301GU5B, HYMD264 646B8J-D43f, MPXA82D-68KX3-MBA, MPXB62D-68KX3-MBA Maybe worth checking this module. I tried to change the whole block from another motherboard, but it didn't work. Comparing the different "tables" for a given IC between NF7 and AN7 there are some differences. Most of the bytes are the same and the length is the same. Gigabyte 7N400 has CMX256A-3200C2, CMX512-3200LL

Back when I tested XP with ACPI on Ryzen, I've made an autohotkey script (simple loop) to auto-press Enter for me, since Crosshair VI Hero doesn't have a PS/2 port. What I did is install AutoHotkey, then place the script in the startup folder, which would make it execute after booting into Windows. Then made the acronis image. All this on a board with PS/2. Now, when I restore it on the Crosshair, the script runs upon first boot and sends Enter key every 10 seconds, which activates the default "New Hardware Detected" dialogs button and hopefully it is "Next", which will install the drivers. At least it worked for me. Once you have a working usb mouse, you can stop the script and remove it from the Startup folder. I believe AHK can read window titles and button labels, then select action based on that, but I haven't spent too much time to learn it. Might help someone. enter.ahk

Ok, just remember to rewrite the extra block with 00 on the 4.08. Edit: 4.08 doesn't work on NF7, 4.31 works with failsafe defaults only. So far all of the NVMM from AMI-based bioses don't even POST on my board.

3 more versions. Will add if I find others. NVDAMC 3.03 05/19/2003 NVDAMC 3.16 08/18/2003 NVMM 4.31 02/24/2004 NVMM 4.08 09/29/2003 Edit: Added NVMM 4.08, but I haven't removed the block after FF AA AA BA 00 FF FF FF FF, just to try both variants, because I don't know what is it. I've removed another AMI-specific block though and padded with 00 until the end. Its release date is the same month as NVDAMC 3.19. Since the 4.35 from MSI board with NF2 bios ends with the above sequence, I guess the extra block is not needed and might even break something, but I will try it nevertheless and report back. This is the oldest NVMM I've found and there might be a chance it works fine on older boards. nvdamc-316.bpl nvmm-431.bpl nvdamc-303.bpl nvmm-408.bpl

Yes, probably needs the newer Southbridge, or there's some other code in the bios that is required in order to make it work. 4.40 from the Abit board at least boots on NF7 with failsafe defaults, while 4.62 and 4.85 didn't even POST. I've found other 3.xx versions in some bioses and will extract them, but don't expect to be any different than what we have so far with 3.19. Haven't found a newer NVDAMC though, last one seems to be 3.19.

NVMM 4.85 extracted from Asrock K7NF2-RAID (nForce2) AMI bios. But it didn't boot on NF7. I have copied everything between EA (this is a jmp instruction, I think) and FF AA AA BA 00 00 FF FF FF FF where it seems to end. Then padded everything with zeros until the end for the total of 19KB. nvmm-4.85.bpl

That 4.62 didn't boot. It's 16KB vs 19KB for the rest. I also had to fill the non-overriden part with zeros. 4.40 worked, but can't POST even at manual 166MHz FSB, it only works at failsafe default for me.

I wonder if there's some interconnection with other modules/code in the bios. And by replacing it we get the 100% out of it.

Hmm, never thought to check that board! I can probably borrow more things from it for the NF7-S v2. Some of the Shuttle boards also use the NVMM 4.40.

It can be only one thing - running some light load on the cpu while not benching. Perhaps stops automatically when higher load (above certain threshold) is detected.

There are some results (numbers) he shared at the end of the first post on the linked page, but I'm skeptical about that, maybe something is/was completely broken on the MSI from the beginning. Sadly, pictures are gone. https://forum-en.msi.com/index.php?topic=84715.90

The v4.35 has tighter timings (primary and secondary/alpha), that's why it is not compatible with many sticks. Perhaps something else, too. I've read the changelog of B72c from BOSSKILLER and there are things I don't know how to do: Will have to compared to unmodded bios (or the previous B62). There are more items missing in the Advanced BIOS Setup screen in the NF7 bios. CPU L1 Cache and CPU L2 Cache are showing in modbin and everything with the items seems fine in the system bios, but they don't show up runtime, just like the EPA Logo option. Trying to figure out how to fix this.

I'm trying to make use of some existing items for custom option. NF7 bios has Small Logo (EPA) option in Advanced BIOS Features setup screen. However, it is only visible in modbin and not in the actual bios. It is set to "visible" and the default option is "Disabled". Original option looks like this 00 00 02 04 89 F8 40 00 3E 40 00 01 00 00 00 01 00 C3 02 00 00 00 00 00 00 So I have moved it under the rest of the custom options and since I still have SuperBypass labels, decided to connect them to the option. Modded item is basically the next item from the custom labels, with it's 3 options, mask and cmos register. 00 00 0A 0B FF FF 03 00 79 03 00 0B 0B 00 00 02 00 81 02 02 00 02 00 00 00 Modbin shows it correctly - labels are the correct ones, default option is selected, position in the menu is correct. But after flashing the bios and going to the setup screen, the option is still not there. It is still hidden/removed, but this time the broken EPA logo shows in the right top corner. So I kind of disconnected it, but can't use it, since some subroutine from bios code hides it/deletes it. The ID is changed, but I can't move it to other place in the binary. Next item starts with 0x20, which according to the struct I've posted on the previous page is "PMITEM", whatever that means. 20 00 EB 0E FF FF E0 00 63 E0 00 09 0F 00 00 04 00 2D 00 00 00 00 00 19 00 Here's what I think is the whole advanced bios features setup screen, or at least significant part of it. Not sure if the $SpeCR %ml$ heading is the start of the setup screen or the end of the previous one. Most of the labels are similar, my modded one starts at 0x2bc - the last one. There's only one with FF FF in column 5 and 6 - in offset 0x145. Also 2 items don't have 00 in second column - offsets 0x96 and 0x2a3. Wonder what this is... Edit: This 0x3 in the second column means a KEY_IN item, I think. This is is a popup menu for the previous option "Delay IDE Initial" with options from 0 to 15.

It's a little cleaner, but has one additional jump. It probably gets compiled to almost the same thing in both cases anyway. I was searching for a "table" solution, there's this thing called jump table, but I didn't understand it 100%. Ideally I would want something like this - an array or a key-value pair, etc. But I don't know how to do that in ASM. const setTrfc = val => { const trfcTable = [0x0010, 0x0020, 0x0040 ... 0x1264]; const value = trfcTable[val]; writePciReg(...); }; const cmosValue = readCmosReg(0x77); (cmosValue > 0) && setTrfc(cmosValue);

There's my option rom. I've fixed tRC to support up to 31 and switched SR and DS. Added the full list of options for tREF. Everything works as expected. PS: Too bad we can't use the IDE options. So the modding kind of ends here. If only we had separate _ITEM.BIN... The only thing left to try is integrate memtest as an ISA option ROM and control it with some menu item, e.g. EPA logo if you have that in the bios. NF7_ISA_OROM_v1.ASM

The Option ROM message works, but I guess the code executes too fast to show something. Removed the far return to bios and it now displays it. I will need to add some artificial delay to make it visible.

The message is nice, but nothing shows on the real machine Will get the tREF done, fix tRC range and that will be for now. Then port it to AN7, should be able to just copy and paste most of the things.

Works in QEMU, will test on the mobo in the evening code end codeend: popa popfd ; return far to system bios routine retf print_string: ; Routine: output string in SI to screen mov ah, 0eh ; BIOS tty Print xor bx, bx ; Set display page to 0 (BL) jmp .getch .repeat: int 10h ; print character .getch: mov al, [cs:si] inc si test al, al ; Have we reached end of string? jnz .repeat ; if not process next character .end: ret ; String ends with 0x0d (Carriage return) and 0x0a (linefeed) to ; advance cursor to the beginning of next line text_string db 'ABIT NF7 v2 OC OPTION ROM v1.00', 0dh, 0ah, 0 ; use 00h as the padding bytes until we reach the ROM size ; The last byte (512th) will be the patch_byte for the checksum ; patch_byte is calculated and automagically inserted below times (ROM_SIZE_IN_BYTE-$) db 0 PREV_CHKSUM = 0 repeat $ load CHKSUM byte from %-1 CHKSUM = (PREV_CHKSUM + CHKSUM) mod 0x100 PREV_CHKSUM = CHKSUM end repeat ; store the patch_byte store byte (0x100 - CHKSUM) at ($-1) call of the print routine MAIN: ; save all registers for later restore pushfd pusha mov si, text_string ; Put string position into SI call print_string Got the print code from stackoverflow: https://stackoverflow.com/questions/49001298/option-rom-code-failing-to-print-intended-string-using-qemu-emulation Perhaps we can simplify the code by using call instead of near jumps. Basically define all SET functions at the end of the ROM, read CMOS for each setting and if not 0 (Auto) call set_timing. Edit: no NIC ROM to reduce clutter qemu-system-x86_64 -net none -option-rom NF7_OPTION.BIN Now with color

At least it is perfectly readable. I don't know how to optimize that, so will probably use your code, since I was going to write the same long "switch". For any other setting I want to use the direct value, yes. For DS and SR we need "doubling" the bits, so the direct value e.g. A turns into AA. Don't know if there's a more efficient/shorter way of doing it compared to the bitshifts I'm currently using. I would do it the same way on C++ or javascript. That's where my knowledge for bitwise operations ends All in all, I think we got the code on the "next" level, compared to the patch ROM of tictac for example. We now have fully functional bios items, while his code only sets things unconditionally. The memtest idea could work. Control if it runs with an option in bios (you can use EPA logo, for example).

And I will use the movzx I also experimented with printing text from the ROM to the screen and it worked, but I did something wrong with the return, since it was stuck at it and didn't continue. One more day and we will have everything working, then I will try again. PS: so maybe xor ebx, ebx mov bl, al is actually a little bit faster, although I'm not sure if the compiler optimizes it further. Maybe check compiled binary in both cases.

Yes, I mask ebx before setting it, but it's in the code at home. Sorry about that. Same for slew rate. writePciReg 0x80000464, ebx, 0x00FF00FF ; 67, 65 writePciReg 0x80000470, ebx, 0x00FF00FF ; 73, 71 and ebx, 0x00FFFFFF ; <-- here writePciReg 0x8000047C, ebx, 0xFFFF00FF ; 7D writePciReg 0x80000480, ebx, 0xFFFF00FF ; 81

Yes, I copy al to bl or bh, depending on the situation. mov bl, al will replace the whole bl with what is inside al. Don't know which method for clearing (zero-ing) ebx is best and most efficient one. Currently using xor ebx, ebx Here's my code for drive strength and slew rate with some comments. set_slew_rate: ; read slew rate from CMOS readCmosReg 0x78, 0xF0 ; for example cmos data is 7 -> al is 0111 0000 ; need to set 0,0,4 reg 64, 66, 7C cmp al, 0 je set_drive_strength ; else xor ebx, ebx mov bl, al ; bl is 0111 0000 shr bl, 4 ; bl is 0000 0111 or bl, al ; bl is 0111 0111 mov al, bl ; save bl shl ebx, 16 ; shift bl to higher 16bit segment mov bl, al ; ebx is 0000 0000 0111 0111 0000 0000 0111 0111 writePciReg 0x80000464, ebx, 0xFF00FF00 ; 66, 64 writePciReg 0x8000047C, ebx, 0xFFFFFF00 ; 7C set_drive_strength: ; read drive strength from CMOS readCmosReg 0x78, 0x0F ; for example cmos data is 7 -> al is 0000 0111 ; need to set 0,0,4 reg 65, 67, 71, 73, 7D, 81 cmp al, 0 je codeend ; else xor ebx, ebx mov bl, al ; bl is 0000 0111 shl bl, 4 ; bl is 0111 0000 or bl, al ; bl is 0111 0111 mov al, bl ; save bl shl ebx, 24 ; shift bl to highest 8bit segment for reg 67 mov bh, al ; ebx is 0111 0111 0000 0000 0111 0111 0000 0000 writePciReg 0x80000464, ebx, 0x00FF00FF ; 67, 65 writePciReg 0x80000470, ebx, 0x00FF00FF ; 73, 71 writePciReg 0x8000047C, ebx, 0xFFFF00FF ; 7D writePciReg 0x80000480, ebx, 0xFFFF00FF ; 81 I could eventually even combine adjacent SR and DS, but that means more "if" statements. Attached is my current code - everything except tREF. for drive strength I could have copied al to bh instead and use smaller bitshift on the ebx, but I'm not sure if it matters. Currently, I save both DS and SR in one CMOS register, that's why I need to left shift for the one and right shift for the other in order to "double" the value. If I save them in separate CMOS registers (both in the lower 4 bits), then I could use a common macro for the "doubling". I will also probably switch the CMOS mask for them, so they are in the same order as in the mask for writePciReg (like you have them in the correct order). As for tRC, I' will have to correct that in my bios, option rom and in the PCR file. Thanks! I've somehow overlooked it, since memset has up to 15 only. It doesn't read tRP correctly anyway (IIRC reads one of tRCD-R or tRCD-W). NF7_OPTION.ASM