Put to sleep worked fine. for a second it said product id not available but then it showed up as activated. I guess that normal. Thanks again.
Thatz great zort. i will try with win 2008 and asus slic. i thought win 2008 vl work only with dell or Hp.. anyway good work guyz..
Just to clarify understanding: Normal OEM7 = Modded ACPITBL and OEM7 containing SLIC in place of original ACPITBL and EPA, with EPA moved to end. Abit OEM7 = OEM7 containing SLIC in place of original ACPITBL with modded ACPITBL at end. Black EPA OEM7 = Modded ACPITBL, OEM7 containing SLIC and Black EPA in place of original ACPITBL and EPA. What exactly constitues an SSV1 mod? What do you consider 'sensitive' modules and why particularly less than 3. I assume UTS64K.BIN would be one... Cheers Andy
The SSV1 method at Award: Acpitable was extracted AND released. SLIC was inserted as NoCompress rom. Acpitable was modified and added as last module. This was all done using Cbrom. All the other methods were developed, because available cbrom versions are not able to handle recently introduced modules. We called them sensitive modules, the offsets of them should be remained. The first were ‘init’ modules (GV3, minit). Later the PE32 modules, Abit was first, Gigabyte followed. They are specially formatted and dependant to others. You cannot just move them. UTS64K.BIN is not a sensitive module, but a sort of romhole. The weakness of the Award modular structure is when you release a module, the offsets of the modules behind are changed as well. Sensitive module= module that cbrom cannot handle correctly…..better remain its original offset at bios. It depends on what version of cbrom you are relate it. So the original SSv1 method wasn’t working anymore because if you’ve released the acpitable using cbrom the bios was unusable. The offsets of the modules behind are changed, the modules cbrom doesn’t know about got corrupt as result. The last version of cbrom is CBROM32_195.exe. If that version allows to extract / release acpitable module again, handling the ‘sensitive’ modules correctly, we can do SSV1 again……. Your explanation of the OEM7 derivates is correct. A genreal rule at modifiying bios: Keep the modular structure of a bios as original as possible.
Mod request GA-945GM-s2 F6 Asus successfull Vista behaved very odd on the the bios mod... First not activated then illega (at login)l then activated but Illegal and non genuine as the patch for Vista sp1 came allong all converted nicely in activated and genuine I do not understand at all but it works apearently nothing was wrong with the modding sorry for that by the way i used everest to see the slic after your answer it marked the ASUS notebook so your patch ad to be ok A thousand thanks
I think there's more than one issue. One being cbrom recognizing the kinds of modules. (Some new ones are formatted differently for example ending in FF instead of 00 or difference in module header and cbrom might not handle them right, making changes to them.) If the only issue was cbrom handling all the modules right then you could move them all yourself as one block right? But I thought some also had fixed entry points, and if they were moved, even if the module stays identical, the bios might not work because of the offset change. Is that incorrect and the only issue being if cbrom recognizes and formats the module properly? An example of a module to not move: Code: ******** EP45UD3R.F7 BIOS component ******** No. Item-Name Original-Size Compressed-Size Original-File-Name =============================================================================== 0. System BIOS 20000h(128.00K) 13DCDh(79.45K) EP45UD3R.BIN 1. XGROUP 0E130h(56.30K) 09B89h(38.88K) awardext.rom 2. ACPI Table 04EC9h(19.70K) 0196Eh(6.36K) ACPITBL.BIN 3. EPA 0168Ch(5.64K) 0030Dh(0.76K) AwardBmp.bmp 4. GROUP ROM[18] 04180h(16.38K) 02B97h(10.90K) ggroup.bin 5. GROUP ROM[20] 02210h(8.52K) 01A0Ah(6.51K) ffgroup.bin 6. YGROUP 0BE70h(47.61K) 0629Dh(24.65K) awardeyt.rom 7. GROUP ROM[22] 0F630h(61.55K) 014FCh(5.25K) tgroup.bin 8. GROUP ROM[23] 0F630h(61.55K) 0265Ch(9.59K) t1group.bin 9. GROUP ROM[24] 0F630h(61.55K) 00FC5h(3.94K) t2group.bin 10. GROUP ROM[ 0] 08320h(32.78K) 02D96h(11.40K) _EN_CODE.BIN 11. MINIT 15520h(85.28K) 1554Fh(85.33K) DS3_DDR2.BIN 12. PCI ROM[A] 03600h(13.50K) 0254Dh(9.33K) ICHAAHCI.BIN 13. PCI ROM 10000h(64.00K) 09E3Eh(39.56K) icharaid.BIN 14. PCI ROM[C] 07C00h(31.00K) 045B6h(17.43K) jmb10678.bin 15. PCI ROM[D] 0E800h(58.00K) 082D1h(32.70K) rtegrom.lom 16. LOGO1 00B64h(2.85K) 00520h(1.28K) dbios.bmp 17. LOGO 4B30Ch(300.76K) 134B5h(77.18K) ud3.bmp 18. GV3 0234Dh(8.83K) 00C31h(3.05K) PPMINIT.ROM 19. OEM0 02AEBh(10.73K) 01FCCh(7.95K) SBF.BIN (SP) NCPUCODE 20800h(130.00K) 20800h(130.00K) NCPUCODE.BIN Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 000316C0 E0 00 25 F7 2D 6C 68 30 2D 27 55 01 00 20 55 01 à.%÷-lh0-'U.. U. 000316D0 00 00 00 69 40 20 01 0C 44 53 33 5F 44 44 52 32 ...i@ ..DS3_DDR2 000316E0 2E 42 49 4E D0 9D 20 07 00 00 00 00 00 00 00 00 .BINÐ ......... 000316F0 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00 MZ.........ÿÿ.. 00031700 B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ¸.......@....... 00031710 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00031720 00 00 00 00 00 00 00 00 00 00 00 00 B8 00 00 00 ............¸... 00031730 0E 1F BA 0E 00 B4 09 CD 21 B8 01 4C CD 21 54 68 ..º..´.Í!¸.LÍ!Th 00031740 69 73 20 70 72 6F 67 72 61 6D 20 63 61 6E 6E 6F is program canno 00031750 74 20 62 65 20 72 75 6E 20 69 6E 20 44 4F 53 20 t be run in DOS 00031760 6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00 mode....$....... 00031770 91 85 EC C6 D5 E4 82 95 D5 E4 82 95 D5 E4 82 95 ‘…ìÆÕä‚•Õä‚•Õä‚• 00031780 D0 E8 8D 95 D4 E4 82 95 D0 E8 E1 95 D0 E4 82 95 Ðè•Ôä‚•Ðèá•Ðä‚• 00031790 D0 E8 D8 95 D4 E4 82 95 52 69 63 68 D5 E4 82 95 ÐèØ•Ôä‚•RichÕä‚• 000317A0 00 00 00 00 00 00 00 00 50 45 00 00 4C 01 03 00 ........PE..L... ... But I see it is listed in cbrom32 1.95: Code: cbrom32 V1.95 [12/14/07] (C)Phoenix Technologies 2001-2007 /minit : Add Intel memory module