Jump to content
HWBOT Community Forums


  • Content Count

  • Joined

  • Last visited

  • Days Won


Tzk last won the day on August 16

Tzk had the most liked content!

Community Reputation

41 Excellent

About Tzk

  • Rank
    kitchen robot


  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Here's how i did it. My item labels are at the very end of en_code.bin and my item strings and mapping for the option rom are in the textfile. Maybe this saves some work on your end? I haven't written the actual code for the isa option rom yet, that's the next thing i'll do. _EN_CODE-26.BINNew Text Document.txt
  2. I'll also stick to two bios versions for CMD. We'd probably need to hook into the bios code way earlier to make it work. As we just need to swap BPL that's the easiest option. And besides that i can only think of a single case when you'd need 2T anyways: max fsb and max mhz runs. For everything else 1T is better. For Tref we must use a big switch... You can't map a Tref value like 4708 (cmos register will contain 1Ah) properly to 6412h through math. So it's simpler to just store the value inside the option rom and use a huge switch. For Trc, Trfc, DS and SR it'll work with math. I mapped Auto to 00h and 1 to 01h. For DS and SR 15 to 0Fh and for Trc and Trfc 31 to 1Fh. I haven't messed with the IDE values yet and will possibly do this when i got Trc, Trfc and Tref working.
  3. I like your thinking... Do these values look somewhat familiar? I opted to not use values below 516 as even at 100Mhz (DDR200) the default value for 7.8ns ram is 780 cycles.
  4. So setting CMD after POST is a nogo then. I finally decided to switch my bios settings from data scavenged rate, superbypass and autoprecharge to Trc, Trfc and Tref. i already got them working in bios, next is the option rom. So i got Data strength, slew rate, Trc, Trfc and Tref in bios. Still i haven't managed to add new settings and i fear it's just too complex to get it done on the compiled bios. So i'll try to recycle other bios options next. Have you tried to for example use the Cylinder, Head, Sector and Landing Zone (display) fields of the harddrives? I got 20 items in total for this... (5 items for 4 drives each).
  5. 87: 03 99: 31 9A: 65 F9: 45 Used my modded bios on A7N8X DLX v2.0 with BPL3.19 1T taken from Taipan 0.3 bios.
  6. And a thought regarding the Tref: Shouldn't the refresh time (in nanoseconds) stay the same when we use different dram clocks? I guess that Tref is set in clocks (not time), so when changing fsb it should also change. Various dram chip datasheets state that Tref must be ~7.8us ( =7800ns). So if we calculate how many clocks it takes to last 7.8us at a given frequency, then we should find Tref, no?! 200MHz = 5ns -> 7800ns / 5ns = 1560 clocks -> 618h 166Mhz = 6ns -> 7800ns / 6ns = 1300 clocks -> 514h 133Mhz = 7.5ns -> 7800ns / 7.5 = 1040 clocks -> 410h 100Mhz = 10ns -> 7800ns / 10ns = 780 clocks -> 30Ch I dumped all chipset registers with WCPRedit at different FSBs while i kept all other settings equal (multi, volts,....). I used the Asus stock 1008 bios with 3.02BPL. And i think i found something: B0D0F1 (the function which does also store the alpha timings) at offset 60h and 61h. I assumed little endian notation: 200Mhz: 1A06h -> 061Ah -> 1562 (clocks?!) 166Mhz: 1605h -> 0516h -> 1302 133Mhz: 1104h -> 0411h -> 1041 100Mhz: 0D03h -> 030Dh -> 781 Looks VERY similar to above, doesn't it?! So, i conclude that offsets 60 and 61 may be Tref I tried several values (100Mhz to 245Mhz in small steps) and plotted everything. Here's the result for my A7N8X. It's very interesting to see that Asus actually increases the time between refreshs at 100/133/166/200Mhz. These are visible as the four highest points on the grey curve. And it looks like Asus does more refreshs above 200mhz with the most refreshs occuring at ~225Mhz. Above that they're decreasing the refreshs again. The (JEDEC) standard value for ddr1 is 7800ns, while more refresh should increase stability but decrease bandwidth. / I noticed that some people use way higher values on S.939. On my Asus i got 1560 cycles at DDR400 while some users on DFI Ultra-D use 3000 to 4000 at DDR600. That'd translate to 2000-2600cycles at 200Mhz. So there might be performance left, depending on the exact chips we use. Here's the data for the diagram, i also calculated the absolute and relative delta between actual and calculated value per frequency. What matters most are the first three columns though.
  7. Very nice, congrats! Looks like my effort to document everything paid off already. I'm still investigating if it's possible to add new items. Luckily Asus increased the number of bios items when going releasing newer bios versions. 1006 got 212 items, 1007 213 and 1008 has 214 items. But (and that's the bad part): the system.bin changes are all over the place. It looks like the code interacts heavily with the items, the item offsets and the misterious codeblocks in front and directly after the item strings. It looks like even a single added items string shifts a lot of offsets in the code as the following strings and mysterious blocks are moved by 25bytes. There are also changes inside those blocks which is why i think those blocks aren't neccessarily code, but some kind of lookup table (just like the label groups in _EN_CODE.bin). However i'm currently not able to see any scheme on how this was done. It's either too complex to understand it while looking at hex files or the changes are done at several places simultaneously which will make it almost impossible to tweak the hex file by hand to get new items. If only we had the sources of those bios files... EDIT: What about the Head, Landing and Blocks items you see when you select the submenu for drives? Do we need these? That'd give us 10+ items to work with.
  8. Yep, that's the only thing missing to be able to fully customize the bios. I'd love to add a ton of items just like on the DFI bios... I even wondered what happens if i try to port some of the bios item blocks (those confusing code blocks + the item strings) from DFI to Asus... No clue if the Gigabyte is a decent board. I guess you'd have to mod a bios for it anyways as there are only a few modbios available.
  9. It basically doesn't matter which option is listed first. You can specify a default value for both "load optimised defaults" and in case the cmos was cleared. So Auto doesn't need to be 00h. I just did this for convenience and to have Auto listed as first (topmost) option on all items in bios. You could possibly simplify the code on the DS and SR settings by just reading the cmos value and applying it directly onto the data register. Maybe with a bit shift to fill all neccessary bits. So basically: read cmos use helper variable to store setting apply helper variable to data register (ebx) bitshift helper, apply again (repeat if neccessary) then apply data as before onto desired pci register This would, if done smart, fully eliminate the need for the huge compare+jump table. Except for the auto settings (which is still 00h and should be applied anyways). I'm not sure if it's worth to mess with the settings which got only few options anyways (auto precharge, DSR, SuperBypass). However the slewrate and DS settings would significantly reduce the filesize.
  10. Correct. You only need to specify the heading label and the first selection on the lookup table of the label group. If you got 5 bios items you want to fully label, then you'll have 10 pointers on the label group: 5 pointers for the heading labels and 5 pointers for the selectable options. The bios will handle reading the other available selections via the # of selections on the bios item string in system.bin. And this is the reason why all selection labels must be of equal length. The two empty lines (offset 5A60 and 5BE0) are just for padding and to make it a bit easier to read. You could just leave them out. However that'd obviously change your label position and thus the pointers on the lookup table. If you need to padd the selectable options themselves then use 20 instead of 00. You only got 00 directly in front of the start of a label.
  11. Just edited the post above to include the addition of labels in _EN_CODE.bin... Yes, you could probably just somehow modify it to just change the data based on the input value instead of using this (huge) switch. It's the first time i've written assembler, so i'm more or less happy that it works. It was an even bigger mess before i added the macro...
  12. Correct. Just give me a few minutes, i'm on the way of writing everything down
  13. Ok, checked and confirmed everything is working. So here's my ISA option rom for the A7N8X. I use cmos registers 75h, 76h and 77h to store my custom settings. As all settings only got 16 values i use 4 bits of every register to store a single setting: 75h: F0h is Drive Strength, 0Fh is Slewrate 76h: F0h is Super Bypass, 0Fh is Data Scavenged Rate 77h: F0h is Auto Precharge Everything else is in the comments of the ISA option rom. If you got questions, as always, just ask I used FASM to write this, so load this into FASM, hit compile and you get the option rom (4096bytes) which you can just include in your bios via cbrom.exe bios.bin /isa option-rom-file.bin. Note that this won't do anything unless you implement the bios items to actually store data in cmos register 75h to 77h. A7N8X-ISA-option-rom-v4.ASM Next up i probably need to write down how i modified the bios itself... So first i needed new labels for the available selections of the new items. To get these, i created a new label group in _EN_CODE.bin. _EN_CODE.bin works like this: At the start of the file you got a lookup table for the different label groups which points at the label group header. Below is my _EN_CODE.bin where i marked the available groups in yellow. If you'd have a look at for example offset 049Ch, 14C4h and so on, you'd find the label group headers there. Note that the label pointers are stored in little endian, so least significant byte first. You can just add another group and the bios will recognize it. In this case you could add your label directly after F05B (offset 5BF0h). Just remember to count the label number and note it down. We'll need this later when we modify the bios item in system.bin. Now, let's jump to the last group to see how it looks like. The last group is F05B and thus we jump to offset 5BF0h: Note that the first byte is 0A which is the number of sublabels this group has. In this case we got 10 labels and thus the value stored here is 0Ah. These 10 sublabels are again pointer to the actual label text and (of course) again in little endian notation. So the first label is 705A which translates to offset 5A70h. If we have a look at this offset, we read "Super Bypass" which is the actual item label text the bios will display. Note that every label must be preceeded by 00h and if you need spaces, you must use 20h instead of 00h. That's why "Super Bypass" is followed by 2020h and then a single 00h right in front of the next label. If you add a pointer for a new sublabel, always make sure to point to the label start and not the 00h right in front of it. Now if you want to create a group of selectable items, make sure all items got the exact same length. So if one items got a longer name, you'll need to fill all other options with spaces (use 20h for this, not 00h!) until all options got the same total length. You only need to point to the first label on the sublabel lookup table, the bios will read the following selection labels automatically. It also doesn't matter where you store the group+pointers relative to your labels. As long as the offsets are correct, it'll work. Next up is the system.bin with the bios item strings as we need to make the bios use our newly added labels. On the PDF i linked we find this: The bytes we're interested in are marked in yellow. To the left there's the pointer to the label of the option itself, in the middle there's the pointer to the available/selectable options and to the right there's the number of selectable options available. What we need to do now is to insert the position of our group in _EN_CODE.bin (1st, 2nd, 3rd group etc) into the bios item string and the position of our label inside that group. So inserting 05 06 would read the 5th label from the 6th label group. This applies for the item itself and also the selections. We also need to tell the bios how many options are available, else it won't read all labels correctly. Note: I'm not sure if the bios started counting at zero or 1. Iirc the 2nd group gets 01 as pointer. So better doublecheck this with a known to be working option on the bios. If everything went smoothly, we now got an option in bios which has the correct name and selections available. If you want to test this fast, just add system.bin and _EN_CODE.bin to a bios file with cbrom and open it with modbin. If modbin displays the menu tree correctly, there's a good chance at the bios will work. No other modules are needed inside the bios for this first test. What now needs to be done is to tell the bios which Cmos register it should write to. This is done by changing the "E8h" index shown above. That's the cmos register the bios will write to. Make sure you don't choose a register which is already in use! I used r/w everything (windows tool) on the stock bios to see the content of all Cmos registers before choosing 75h to 77h on my mod. The masks mentioned next to it allows to for example only write the first or last 4bits of the register. So if you want to store two settings on a single register, choose masks 0Fh on the first and masks F0h on the 2nd bios item. The selections will write the register content in increasing order. So if your selection labels are named linke this: Auto Ten twenty hundred Then Auto will write a zero, ten will write a 1, twenty a 2 and hundred a 3 to the cmos register. I always chose Auto as first item, so i can just check if the register is 0 in my option rom. And if yes, i just skip the custom code.
  14. I investigated the bios item strings in system.bin further and i noticed something. Before and after each bunch of strings, there's some "code". The code before each bunch seems to indicate where the strings start. On Asus the system.bin includes the bios items starting at 10000h, so i assumed that the code doesn't assume this offset. So i copied everything to a new file (10000h offset now gone) and tried my luck. Note that each bunch of bios items seems to start with 246D 6C24h which translates to $ml$ (marked in yellow). I then noticed that the immediately following codeblock seems to have increasing numbers following each other. And it looks like that these numbers actually indicate where the bios items are saved. For example the blue box at offset 1ACh has B602h in it which is an address written in little endian (least significant byte first). So we swap bytes: B602h -> 02B6h. And guess what, the corresponding bios item string starts at 02B6h (big blue box at the bottom). This is the same for the other boxes i marked. I don't know what the numbers inbetween the small boxes do, but they seem to point to the codeblock following after the bios items. So i assume this is a lookup table for the bios items and some other setting. My current conclusion is: I tried adding new bios items before and that bricked the bios file. I assume that it broke because i tried to add new items at the start (near initial offset 10000h). This would cause all following $ml$ blocks to have an offset, as i had to insert a few bytes. Now, that'd break all following lookup tables and i'd miss the new item on the corresponding lookup table. So it looks like we'd need to: 1. insert a new item, 2. add it to the lookup table 3. add the following setting pointing to the end of the segment and 4. correct any offset we broke by inserting some bytes. But first, we need to figure out what the 2nd codeblock directly after the item strings does.
  15. Well, i'm still looking for SuperBypass... Everything else works and i need to test it with Winbond Sticks. But before trying this, i'll document how i did it and upload the source of my ISA option rom somewhere. So you guys can either do this mod yourself or at least i know in a few months how i did it. It shouldn't be too difficult to port this to other Asus boards, at least when they also got 5 unused settings in bios.
  • Create New...