I.nfraR.ed Posted November 29, 2019 Posted November 29, 2019 (edited) 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 Edited November 29, 2019 by I.nfraR.ed 1 Quote
digitalbath Posted November 29, 2019 Posted November 29, 2019 I will try the NVMM bpl on my Delta2.The delta2 board needs the 4.xx version for the right RAM auto timing detection. With a 3.xx version the board detects falshe auto timings and therefore does not boot with every ram stick. Manually set timings work without problems. Maybe that's why not every 4.xx version works on the older boards. Quote
I.nfraR.ed Posted November 29, 2019 Posted November 29, 2019 (edited) 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. Edited November 29, 2019 by I.nfraR.ed Quote
digitalbath Posted November 29, 2019 Posted November 29, 2019 Okay, I have followed your suggestion and overwritten the second block with 0. The board does not boot with 4.85 and 4.08. 4.31 is going well. Performance is comparable to 4.40.Now we have three working versions for the newer boards: 4.31, 4.35 and 4.40 Quote
I.nfraR.ed Posted November 29, 2019 Posted November 29, 2019 (edited) 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 Edited November 30, 2019 by I.nfraR.ed Quote
I.nfraR.ed Posted December 1, 2019 Posted December 1, 2019 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 2 2 Quote
Tzk Posted December 2, 2019 Posted December 2, 2019 You're using custom romsips? Looks interesting... I've forgot to put PLOP into my Asus bios... Might to that too. The Asus is picky about USB booting sometimes. What's left to do now is search for romsips and test them. I extracted some if them from DFI beta bios and noticed that some revisions only got minor differences. So that might be a good starting point. Our only chance is to A/B test different sips and compare bandwidth and stability. A very time consuming task... Quote
I.nfraR.ed Posted December 2, 2019 Posted December 2, 2019 (edited) 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. 3 hours ago, Tzk said: You're using custom romsips? Looks interesting... I've forgot to put PLOP into my Asus bios... Might to that too. The Asus is picky about USB booting sometimes. What's left to do now is search for romsips and test them. I extracted some if them from DFI beta bios and noticed that some revisions only got minor differences. So that might be a good starting point. Our only chance is to A/B test different sips and compare bandwidth and stability. A very time consuming task... 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. Edited December 2, 2019 by I.nfraR.ed Quote
Tzk Posted December 2, 2019 Posted December 2, 2019 I've got several romsip tables but haven't found one which uses your 2nd line. Merlins romips all got 40h at offset 11h and most other romsips i checked have a different 2nd line (offset 10h to 1Fh). DS 4 also works best for me on TCCDs and Infineon BT-5. Haven't tested on Winbonds yet. Also didn't test different SR yet and stuck to the default (10). I'm still trying to get 2x512mb TCCDs stable above 240MHz, but something is holding me back. Also CL2.5 seems to work better than CL3 which doesn't make sense. Right now i'm a bit short on time to work things out, but my plan is to try to combine different romips or (like you did above) to test single settings for bandwidth and stability. There must be a way to get TCCDs stable at or above 250MHz... Quote
I.nfraR.ed Posted December 2, 2019 Posted December 2, 2019 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... Quote
I.nfraR.ed Posted December 2, 2019 Posted December 2, 2019 (edited) I've tested some values, but don't have more time today. Got some strange results. AA is faster, but also limits the maximum bootable FSB frequency. Difference in AIDA is negligible. Tests done at 11x220, all manual timings. Maybe need to test more values. Trying to run 1M at 260MHz resulted in a lockup. Haven't tried higher Vdimm though. 270MHz is pretty much the limit on this board with BH-5 DC and haven't managed to overcome it. It's not stable at 270MHz. It would be a lucky run if 1M finishes all loops. Pi 4M AIDA FSB 55 03m 25.415s 3459/3463/3449/65.5 270 MHz 22 03m 24.824s 3460/3462/3451/65.3 270 MHz AA 03m 23.923s 3460/3462/3450/65.3 260 MHz Also tried 00 and it was somewhere between 22 and 55, perhaps it is something like "auto". I've also seen DD, FA and FF in 133/166 stock tables. Edited December 2, 2019 by I.nfraR.ed Quote
Thorn Posted December 2, 2019 Posted December 2, 2019 (edited) Thank you for the new Bios you made for the NF7. The USB-Boot option is great! Edited December 3, 2019 by Thorn Quote
I.nfraR.ed Posted December 3, 2019 Posted December 3, 2019 (edited) It's me again Key-in for the FSB frequency. It is supposed to be in DEC, but it appears to be using something like index or whatever. It's not in HEX either. Will play a bit with it to see if I can make it completely working. Maybe use DFI Ultra-D bios as an example or the "Delay IDE Initial" in NF7 bios. Don't have more time before work though. PS: Unfortunately it appears they have used some sort of mapped values, since 187 entries cover the whole range from 100 to 300 and it skips some of the frequencies. Transforming it into a key-in option still uses that table and it is in fact an index and not a direct value. Don't think I will be able to change that, but at least the technique can be used with other (custom) options, where the value saved in cmos register is the same value used for the actual "timing". For example, tREF would have the same issue as the FSB, but those which don't use a key-value map could be transformed. Not that I see any benefit, except you won't need the menu item labels. You loose the "auto" option, so you either allow the user to input 0 (will be treated as auto in the ISA ROM code) or limit the minimum to 1, which then doesn't allow an "auto" option. Not really user-friendly. Initially I thought that it might be possible to somehow shift it from 0-255 to 100-355, but in theory 255 (as a direct value) should be the maximum possible (FF in the register). Won't happen without additional logic in the bios - basically take the exact value and add 100. Not really usable in ISA option ROM, because it is too late. Has to happen much earlier before POST. Wonder if it will work for AGP frequency though. Guess I will be back to ROMSIP testing, but will share what I did for the key-in method later, so we have it documented. Edited December 3, 2019 by I.nfraR.ed 1 Quote
digitalbath Posted December 9, 2019 Posted December 9, 2019 I compared 4 diffrent NVMM versions. NVMM 4.31 - 02/24/04 NVMM 4.34 - 03/23/04 NVMM 4.35 - 07/02/04 NVMM 4.40 - 04/29/04 I tested it with modified ED55 romsips from Infrared on my Delta2 board. They work very well on Delta2. Thanks a lot for this.Version 4.31 and 4.34 are very similar and work best when the interface is off. Version 4.35 is the worst, but works better with interface on than 4.31 and 4.34.My best results were achieved with version 4.40. It is similar to 3.19. Both 4.40 and 3.19 work well with interface on. The differences are probably only a few MHz. nvmm434-cpc-on.bpl 1 Quote
I.nfraR.ed Posted December 10, 2019 Posted December 10, 2019 (edited) Sorry for the delay, guys. Had a lot to do at work and was too tired. Haven't turned the s.A system on since last time I wrote in the thread. Have some free time at work now, so I will try to briefly explain about the key-in menu. Let's take an example item. The typical item looks like this (25 bytes): 00 00 00 0B FF FF 1F 00 75 1F 00 01 0B 00 00 1F 00 E1 01 00 00 00 00 00 00 According to the info I've shared earlier, first 2 bytes are status. First byte is visibility, second byte is type/function. To convert an item to key-in, I've found that you need to set the second byte to 0B. According to the info, it should be 0x0100 (or 00 10, because it is little endian order), but it didn't work. 0Bh was mentioned in polygon's PDF and it worked. Next 2 bytes are label index and label group index. In my example we have 00 (first label) in 0B (12th group in _EN_CODE.BIN). We leave it untouched. Next is chipset reg and mask, for a regular custom item, chipset reg (04h,05h) is always FF FF. Some of the stock items have them set to point to the actual chipset register. 06h, 07h is Chipset mask. All the documents say it needs to be the same as CMOS Mask. Haven't tried if it is actually the case. 08h is CMOS reg, 09,0A is the CMOS mask. 0Bh is the index to the first label for the item menu and 0Ch is the label group. In this case we set both to 00. I think they are ignored anyway, but we don't need them 0Dh, 0Eh is itemMin 0Fh, 10h is itemMax If we want to support values from e.g. 1 to 15 (1h to Fh), we change these to 01 00 0F 00. 11h, 12h is position on the screen. The modified item would be 00 0B 00 0B FF FF 1F 00 75 1F 00 00 00 01 00 1F 00 E1 01 00 00 00 00 00 00 Keep in mind I write this from memory without actually trying it atm. Hopefully the offsets are correct, but you can experiment. Edited December 10, 2019 by I.nfraR.ed 2 Quote
digitalbath Posted December 21, 2019 Posted December 21, 2019 I have modded a BIOS for the ASUS A7N8X-E, based on the latest official 1013 BIOS.There are still small points to be improved, but so far it is going well for me and without problems. USE AT YOUR OWN RISK! I TAKE NO RESPONSIBILITY FOR ANY DAMAGE THIS BIOS CAUSES changelog: * BPL version 3.19 * [ED55] romsips from Infrared , many thanks! * Soft L12 Mod * AMD Athlon XP-M name * added tRC; tRFC; tREF; DIMM Drive Strength and DIMM Slew Rate options * CPU Interface optimal / aggressive selectable on manual settings * changed Fullscreen Bitmap 1013_ED55.zip 2 Quote
digitalbath Posted January 24, 2020 Posted January 24, 2020 (edited) I did tests at romsips and found the following: In my opinion, the first line in the romsips contain coding for the FSB values. In the end, there are usually these values: 0C0C 1010 1414 1818 What struck me is that there is always a jump by 4 values. These 4 values should always be a jump by 33MHz: 100-133-166-200. One value results in 8.33 MHz. If so, then these values (in hexadecimal) should result in: 01 = 8.33MHz 02 = 16.66MHz 03 = 25.00MHz 04 = 33.33MHz 05 = 41.66MHz 06 = 50.00MHz 07 = 58.33MHz 08 = 66.33MHz 09 = 75.00MHz 0A = 83.33MHz 0B = 91.66MHz 0C = 100.00MHz 0D = 108.33MHz 0E = 116.66MHz 0F = 125.00MHz 10 = 133.33MHz 11 = 141.66MHz 12 = 150.00MHz 13 = 158.33MHz 14 = 166.66MHz 15 = 175.00MHz 16 = 183.33MHz 17 = 191.66MHz 18 = 200.00MHz 19 = 208.33MHz 1A = 216.66MHz ... fits perfectly. Now you just have to test it. I do this by changing the values of the rompsips in the main BIOS after the BPL module. One of these four romsips is responsible for the fail-safe boot. the order is usually: 1414 1414 = 166MHz 0C0C 0C0C = 100MHz 0C0C 0C0C = 100MHz 0C0C 0C0C = 100MHz I changed it to: 1414 1414 = 166MHz 0D0D 0D0D = 108.33MHz 0E0E 0E0E = 116.66MHz 0F0F 0F0F = 125MHz after flashing (winflash): A start with the Ins key pressed:So my theory should be correct. Edited January 24, 2020 by digitalbath 1 Quote
I.nfraR.ed Posted January 25, 2020 Posted January 25, 2020 (edited) Yes, I thought there's no point in changing the failsafe tables, so I left them untouched. Also tried to leave these values in the other tables, but in fact it didn't matter if I put them all the same or keep the stock values, when using the same table for all straps. What bugged me when I was trying is that some stock bioses have them mixed on some tables, like 0C10 1414. It was DFI, IIRC. Good work decoding that, though! Edited January 25, 2020 by I.nfraR.ed Quote
digitalbath Posted January 26, 2020 Posted January 26, 2020 Yes, the failsafe tables can left untouched. I just used them to profe my theory. I found the mixed tables only on DFI boards (Lanparty B, U400S-AL ). I wonder why did they do this... ... and why do their tables differ from others? i hope i can learn more about it through more tests ... 1 Quote
digitalbath Posted January 27, 2020 Posted January 27, 2020 i just found the mixed values on an Epox 8rda bios from 2003/03/05. It seems, they used them earlier than dfi. The romsips from earlier nForce2 boards (8rda, NF7v1) looks more similar to our modded romsips than the stock romsips from newer boards. EPOX also used more romsips tables like DFI. Quote
Thorn Posted January 27, 2020 Posted January 27, 2020 (edited) Oskar Wu was working for Abit before he went over to DFI. Maybe Epox just "borrowed" some Romsip code. " Right after Abit got the NF7 and AN7 series board going is when DFI made their move, recruited Wu and started the LanParty lineup.Abit carried on for sometime afterwards taking the work Wu had done for them and marching ahead with what they had but no one else could advance it like he could. " Edited January 27, 2020 by Thorn Quote
Mr.Scott Posted January 28, 2020 Posted January 28, 2020 3 hours ago, Thorn said: Oskar Wu was working for Abit before he went over to DFI. Maybe Epox just "borrowed" some Romsip code. Hide contents " Right after Abit got the NF7 and AN7 series board going is when DFI made their move, recruited Wu and started the LanParty lineup.Abit carried on for sometime afterwards taking the work Wu had done for them and marching ahead with what they had but no one else could advance it like he could. " Wu worked for Epox before he went to Abit. 1 1 Quote
Thorn Posted January 28, 2020 Posted January 28, 2020 regardless, to me digi seems like an adventurer. Go for it 1 Quote
digitalbath Posted January 28, 2020 Posted January 28, 2020 6 hours ago, Mr.Scott said: Wu worked for Epox before he went to Abit. Nice, to find his fingerprints on several boards Quote
Thorn Posted February 3, 2020 Posted February 3, 2020 (edited) I stumbled across two things from the past which I can hardly believe: The 293-MHz Shuttle AN35N Ultra 400 (yes, the cpu is SS-cooled and the NB/SB H2O, but the screenshot says it's under full load!) https://web.archive.org/web/20051126073133/http://www.rhcf.com/sisubb/ultimatebb.php?ubb=get_topic;f=32;t=000065;p=2#000028 and this review where 2.9V was enough juice for Mushkin LV2 BH5 @ 253-MHz. The only mods he did was to put larger heatsinks on the NB/SB and the PLL-chip. https://web.archive.org/web/20040207083758/http://www.lostcircuits.com/motherboard/dfi_nfii_ultrab/7.shtml Legit? ? Edited February 3, 2020 by Thorn Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.