Jump to content
HWBOT Community Forums

I.nfraR.ed

Members
  • Content Count

    2241
  • Joined

  • Last visited

  • Days Won

    8

I.nfraR.ed last won the day on November 14

I.nfraR.ed had the most liked content!

Community Reputation

173 Excellent

1 Follower

About I.nfraR.ed

  • Rank
    robot overlord

Converted

  • Location
    Bulgaria

Converted

  • Occupation
    Web Developer

Converted

  • realname
    Ivan

Recent Profile Visitors

12612 profile views
  1. 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.
  2. 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.
  3. 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...
  4. 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.
  5. 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
  6. 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
  7. 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
  8. 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.
  9. 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
  10. 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.
  11. 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
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...