Yep. It appears pretty standard compression scheme (LZSS?), so quite probably this is some available code to reuse. But I am even more newbie than you about compression algorithm! No. I used my own (Python) code I wrote based on your earlier description (which I was debugging). Obviously it choked on this BIOS, so I amended the code to catch this... and the code simplifies itself a lot You are right I should go after the ASM snippet, which should not be very long , to check if my guess was correct.
Please do. It "duplicated" about 2-3 times in different modules and slightly different, but do the same job. Shouldn't be a problem to find them. Right. You still need to pull decompression code from BIOS to make sure your compression works properly... Unless you have alternative method to recover BIOS. Shouldn't be a problem to modify my code. Will wait until you complete above though.
Apokrif, I would like to say you did great work with Dell bioses, my respect. And I'm sorry that I had not much time to answer your PM's or to support you. I was very busy with skinning the forums at to get familiar with the new style variables of vbulletin......I almost did no mod last 2 months......I'll leave the forums, check my signature....when I'm back I'll try to get the details...keep up our great work, nice to have you here at MDL, another expert! CU, Yen....
(de)compression tool need to be modified to support old compression method. I wrote early - I will do it if he pull ASM decompression code from BIOS. Not sure about 8200 A09 though.
I want to give feedback, that the phoenixtool120 was able to add a slic in my Dell C810-A12 BIOS successfully!!!!!! Win7 is now acrivated. Thanks!! Greets Obelix
Great thread! Started with the pre-made bios for an old Dell Optiplex GX280 and Dell Optiplex 745. Finally moved on and used the Phoenixtool to make a Dell Latitude D510 A04 which reports SLIC 2.1. Many Thanks!!!!
Sorry for the delay, I had to prioritize... Of course it was not a big deal to find the code, as you said... Code: Offsets are from GX110A09.hdr ; ds:si -> start of chain type pre-A (Z?) ; es:di -> where to store uncompressed module ; bl = module index to find and uncompress 0005B074: FC cld 0005B075: ; (3) 0005B075: 8BC6 mov ax,si 0005B077: C1E804 shr ax,004 0005B07A: 8CDA mov dx,ds 0005B07C: 03D0 add dx,ax 0005B07E: 8EDA mov ds,dx 0005B080: 83E60F and si,00F 0005B083: AD lodsw 0005B084: 8BD0 mov dx,ax 0005B086: FECB dec bl 0005B088: 7404 je 00005B08E -------- (2) 0005B08A: 03F2 add si,dx 0005B08C: EBE7 jmps 00005B075 -------- (3) 0005B08E: ; (2) 0005B08E: 03D6 add dx,si 0005B090: 2AED sub ch,ch 0005B092: ; (6) 0005B092: 3BF2 cmp si,dx 0005B094: 732B jae 00005B0C1 -------- (4) 0005B096: AC lodsb 0005B097: A80F test al,00F 0005B099: 750B jne 00005B0A6 -------- (5) 0005B09B: C0E804 shr al,004 0005B09E: 8AC8 mov cl,al 0005B0A0: FEC1 inc cl 0005B0A2: F3A4 repe movsb 0005B0A4: EBEC jmps 00005B092 -------- (6) 0005B0A6: ; (5) 0005B0A6: 8AC8 mov cl,al 0005B0A8: 80E10F and cl,00F 0005B0AB: FEC1 inc cl 0005B0AD: 2AE4 sub ah,ah 0005B0AF: C1E004 shl ax,004 0005B0B2: AC lodsb 0005B0B3: 8BDE mov bx,si 0005B0B5: 8BF7 mov si,di 0005B0B7: 2BF0 sub si,ax 0005B0B9: 4E dec si 0005B0BA: F3 repe 0005B0BB: 26 es: 0005B0BC: A4 movsb 0005B0BD: 8BF3 mov si,bx 0005B0BF: EBD1 jmps 00005B092 -------- (6) 0005B0C1: ; (4) 0005B0C1: C3 retn Exactly the same code appears a second time at 00068F94 Due to the 000054h offset introduced by HDR format, the corresponding in-memory offsets are paragraph aligned (end with 0) When I compare the code with the similar one from Dimension 4600, clearly they are from the same breed (so your tools will serve while upgraded), I found a small improvement in the newer (inc cx vs. inc cl, 1 byte less) but I did not find the +1 offset when copying I found by hand-decoding Clearly it is THE problem with those old machines: no belt, and no suspender either
Indeed. Well, we are in to some more complexity... In fact, unlike my earlier thoughts, the HDR format does not fully match with the compression algorithm Sorry for the confusion, so I will try to put it more clearly. The Optiplex GX260 and the machines from that generation (around 2002, like Dimension 4500) use the very same A format for HDR as described in the beginning, just packaged in a different way inside the EXE, which is pure DOS, not PE/hybrid; the MZ header indicates a small size (around 40KB); the HDR is packed using gzip and appended at the end. I believe those machines are powerful enough to run Vista/Seven once memory sticks are in enough number! To disambiguate: assuming the $RBUT01 header, at 0054h we found the first module length stored with 16 bits, then 01 (this is typical of A format), then F0 00 which translates to 'lit 0F", followed by 15 (decimal) bytes "Copyright 1985-" (the year may vary, I've seen 1986), then 02 04 which translates to "cpy 3@-4", copying 3 bytes from offset -4 ("198"). Those earlier machines I am describing in depth lately are from the previous generation (around 2000, Optiplex GX110, GX150, Dimension 8100); they are using a simpler compression scheme for the modules; and the .EXE is a single piece (the MZ header indicates a big size, around 300KB) just compressed; once uncompressed the romfile can be accessed directly, you do not even need to recompress the result! However I doubt those machines are powerful enough to run Seven in satisfactory conditions. Once extracted into .HDR format, the inner format for the chain is different: there is no "module type" at all, only the length directly followed by the compressed bytecodes. To disambiguate: assuming the $RBUT01 header, at 0054h we found the first module length stored with 16 bits, then E0 which translates to 'lit 0F", followed by 15 (decimal) bytes "Copyright 1985-", then 02 04 which translates to "cpy 3@-4", copying 3 bytes from offset -4 ("198"). Note that there is no "dup" operator in this scheme, and since "dup" is an impossible operator to begin with, clearly E0 can only be interpreted this way (and thus can be used as a good hint about the format.) As you found out, Dimension 8200, also Dimension 4300 or Optiplex GX240 (around 2001) are somewhat an hybrid: the EXE is a composite as above (small DOS program with .gz appended, like the first one above), and the HDR chain is like the A kind, with the module type byte. However, the compression used is the simple one... I believe those machines are powerful enough to run Seven (indeed there is one mod request pending), so we definitively need to do something with the simple scheme! To disambiguate: assuming the $RBUT01 header, at 0054h we found the first module length stored with 16 bits, then 01 typical of A format for the chain, then E0 which translates to 'lit 0F", followed by 15 (decimal) bytes "Copyright 1985-", then 02 04 which translates to "cpy 3@-4", copying 3 bytes from offset -4 ("198"). Again the E0 opcode is good to figure what is happening; also note that 01 is not a possible opcode either since there is nothing to copy from.
Nice read atapuerca, but I would not consider GX240 machines for use with Seven, thay are barely good to run XP (especially that they have only 2 memory slots, and piddly 1.7 P4 processor & 16Mb graphics with AGP 2x) I really think that the lowest Dell model that is OK for Seven is Gx270 (which works fine even with onboard Intel graphics, and even better with nVidia 6200 low profile AGP) sebus
There is already a D630 mod out anyway so if you need a reference use that one. Also the new 1.20 version of Andy's tool will insert a SLIC into most Dell BIOSes.
Hi Thanks for this. Apokrif - may I be so bold as to ask if you will be updating the compression tool for this simpler format. Andy