jaclaz Posted February 10, 2020 Share Posted February 10, 2020 (edited) 12 hours ago, deomsh said: No other differences The "good" one gives exactly same results as giving find --set-root /hdd-512mb-img-gz first. I tried that too earlier. Both GRAB1TXT and GRAB2.TXT are identical However, your correction of the C/H/S counting did the trick. I added the partition table and first few lines of the boot sector, with corresponding bytes of the original image. Jaclaz, you are a genius, correcting the CHS/LBA unbalance solved the problem. Naah, I only happen to know quite a few things on a very narrow set of data (like you know this or that set of 512 bytes). The CHS/LBA being not balanced is more or less as old as partitioning, the fact is that until a certain point *everything* was CHS based and after a certain point *almost anything* was LBA based, whenever both come into play, if they are not balanced/corresponding, it is likely that issues arise. Though this specific case is actually "queer", the difference between "absolute" or "relative" path should be not influencing the mounting, so the only possible explanation is (very much similar to your hint about timing) due to using the "find" (or "find --set-root") before mounting, it should mean that *somehow* finding the file allows for a different parsing mechanism, but it remains "queer". It is like there is a difference between "cold mounting" (i.e. mapping a file that has not been accessed before) and "hot mounting" (i,e. mapping a file that has been already accessed by some other grub4dos command, it is like grub4dos is "taken by surprise by the contents of the file" and tries to "invent" a suitable set of partition data (and failing at it). The origin is of course the unbalanced partition data (GIGO paradigm) still it is baffling. If you still have the "bad" image, can you try: root (fd0) ls /hdd-512mb.img.gz and ls (fd0)/hdd-512mb.img.gz before the mapping? (I mean instead of find or find --set-root) jaclaz Edited February 10, 2020 by jaclaz Link to comment Share on other sites More sharing options...
deomsh Posted February 10, 2020 Author Share Posted February 10, 2020 First "ls"-command instead of "find" root (fd0) Filesystem type is fat16, using whole disk ls /hdd-512mb.img.gz Hdd-512mb.img.gz map --mem --unsafe-boot --heads=32 --sectors-per-track-63 /hdd-512mb.img.gz (hd0) Autodetect number-of-heads failed. Use the specified 32 Autodetect sectors-per-track failed. Use the specified 63 floppies_orig=2, harddrives_orig=0, floppies_curr=1, harddrives_curr=1 map --hook parttype (hd0,0) Partition type for (hd0,0) is 0x06. geometry (hd0) drive 0x80(LBA): C/H/S=520/32/63, Sector Count/Size=1048320/512 cat --hex --skip=446 (hd0)+1 000001BE: 80 01 01 00 06 1F BF 08 3F 00 00 00 C1 FE 0F 00 ; ........?....... 000001CE: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................ 000001DE: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................ 000001EE: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................ 000001FE: 55 AA ; U. Second "ls"-command instead of "find" ls (fd0)/hdd-512mb.img Hdd-512mb.img.gz map --mem --unsafe-boot --heads=32 --sectors-per-track=63 /hdd-512mb.img> Autodetect number-of-heads failed. Use the specified 32 Autodetect sectors-per-track failed. Use the specified 63 floppies_orig=2, harddrives_orig=0, floppies_curr=1, harddrives_curr=1 map --hook parttype (hd0,0) Partition type for (hd0,0) is 0x06. geometry (hd0) drive 0x80(LBA): C/H/S=520/32/63, Sector Count/Size=1048320/512 cat --hex --skip=446 (hd0)+1 000001BE: 80 01 01 00 06 1F BF 08 3F 00 00 00 C1 FE 0F 00 ; ........?....... 000001CE: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................ 000001DE: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................ 000001EE: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................ 000001FE: 55 AA ; U. I tested the ls-command as you asked, no difference. Always the "good" mapping (although unbalanced, as you teached me). "Timing" was just an idea. The whole problem is *somehow* USB-FDD related. If I boot from USB-FDD, but the image is located on an USB-HDD usually the Memdrive has Partition ID 0x06. If I boot from USB-HDD, but the image is located on an USB-FDD things are much worse. Sometimes I first have to map the USB-FDD before Grub4Dos finds the image! 12 hours ago, jaclaz said: The CHS/LBA being not balanced is more or less as old as partitioning, the fact is that until a certain point *everything* was CHS based and after a certain point *almost anything* was LBA based, whenever both come into play, if they are not balanced/corresponding, it is likely that issues arise. I have used used Partition Magic many years, always complaining about this "thing". But the corrections the program wanted usual make things worse. I have to investigate the CHS/LBA balancing further, because I never succeeded to boot from Winimage IMA-images with MBR, mapped to a Memdrive. IMA-images without MBR gave no problem, but had always the Grub4Dos MBR with Partition ID 0x0E (which as such is not a problem in case of Win9x). Link to comment Share on other sites More sharing options...
jaclaz Posted February 11, 2020 Share Posted February 11, 2020 10 hours ago, deomsh said: I tested the ls-command as you asked, no difference. Always the "good" mapping (although unbalanced, as you teached me). "Timing" was just an idea. The whole problem is *somehow* USB-FDD related. If I boot from USB-FDD, but the image is located on an USB-HDD usually the Memdrive has Partition ID 0x06. If I boot from USB-HDD, but the image is located on an USB-FDD things are much worse. Sometimes I first have to map the USB-FDD before Grub4Dos finds the image! I have used used Partition Magic many years, always complaining about this "thing". But the corrections the program wanted usual make things worse. I have to investigate the CHS/LBA balancing further, because I never succeeded to boot from Winimage IMA-images with MBR, mapped to a Memdrive. IMA-images without MBR gave no problem, but had always the Grub4Dos MBR with Partition ID 0x0E (which as such is not a problem in case of Win9x). So, all in all, it is a timing problem of sort, that the execution of another program accessing the file (or possibly the device [1]) solves. About CHS/LBA balancing all you need is here (shameless plug ) : http://reboot.pro/topic/2959-chs-lba-translations/ get the v2 version here: http://reboot.pro/topic/2959-chs-lba-translations/?p=74116 jaclaz [1] I mean, if on the same device (floppy-like) where the hdd-512mb.img.gz resides there is another file, let's say pleasels.me and upon boot, you run: ls (fd0)/pleasels,me and then you map the image what happens? Or - maybe - only: ls (fd0)/ would do. Link to comment Share on other sites More sharing options...
deomsh Posted February 12, 2020 Author Share Posted February 12, 2020 On 2/11/2020 at 10:45 AM, jaclaz said: About CHS/LBA balancing all you need is here (shameless plug ) : Nice tools, I have just tested them. Thnx On 2/11/2020 at 10:45 AM, jaclaz said: [1] I mean, if on the same device (floppy-like) where the hdd-512mb.img.gz resides there is another file, let's say pleasels.me and upon boot, you run: ls (fd0)/pleasels,me and then you map the image what happens? Or - maybe - only: ls (fd0)/ would do I have run all the tests, anything goes as soon the USB-FDD is accessed once. Even ls (fd0)/pleasels.me did the trick, grub gave error "file not found" (will only work in menu.lst with errorcheck off). Also map the image again in the same Grub-session (in earlier drafts of Part 8½ I mapped first a floppy image right before hdd-512mb-img.gz - but thought it would be to experimental for my menu.lst). I also tested loading hdd-512mb-img-gz from a real floppy after booting form USB-FDD. Exactly the same story. Without earlier drive access by Grub4Dos always the "bad" 0x0E mapping. As soon there has been "real floppy" drive access (nice: one can hear it) everything is fine with the 0x06 mapping. Link to comment Share on other sites More sharing options...
deomsh Posted February 26, 2020 Author Share Posted February 26, 2020 (edited) After the problems with the DOSBox images, I used Jaclaz' guidelines to make a Hard disk from a Grub4Dos Ramdrive. It seems that Partnew doesn't write to cylinder boundaries. Although Windows 98SE Setup doesn't complain, my MS-DOS util's do. So I wrote a correction in a Grub4Dos batch file. Since the Grub Util FAT seems only good for floppies, I wrote some batch lines to format the drive to FAT16 too. It's al in ONE file. Will make and format ALWAYS (hd0,0), first attached real hdd will be mapped to last hd. --------------------------------------------------------------------------------------------------------------------------- rd2hdf16.g4b --------------------------------------------------------------------------------------------------------------------------- !BAT # Make FAT16 hdd-image: active first partition; range 33-2047 MB debug off set /a SIZE=%1 if %SIZE%=="" && goto :validate if %SIZE%>=2048 && goto :validate if %SIZE%<=32 && goto :validate goto :makeimg :asksize set /a SIZE= echo Disk size in range 33-2047, integer numbers only echo Actual image size will be adjusted to cylinder boundaries! set /p:60 /a SIZE=Enter disk size and press ENTER in 60 seconds: if %SIZE%=="" && goto :validate if %SIZE%>=2048 && goto :validate if %SIZE%<=32 && goto :validate goto :makeimg :validate echo Input is not a valid number, try again set /p:60 CONTINUE=Try again? choose Y or N and press ENTER: if /I "%CONTINUE%"=="Y" && goto :asksize goto :eof :makeimg if %SIZE%<=2047 && set /a heads=128 if %SIZE%<=2016 && set /a heads=64 if %SIZE%<=1008 && set /a heads=32 if %SIZE%<=504 && set /a heads=16 set /a sectmax=%SIZE% * 2048 set /a sectrack=63 set /a secthidd=63 set /a cylinder=%sectmax% / %heads% / %sectrack% set /a sectbal=%cylinder% * %heads% * %sectrack% set /a sectpart=%sectbal% - %secthidd% set /a rdsize=%sectbal% * 512 # Set rdbase >=50MB. Be aware: Grub4Dos can write the batchfile to (rd) set rdbase=52428800 set /A partid=0x06 map --rd-base=%rdbase% map --rd-size=%rdsize% map --unsafe-boot --heads=%heads% --sectors-per-track=%sectrack% (rd)+1 (hd0) map --hook partnew --active (hd0,0) %partid% %secthidd% %sectpart% # Create FAT16 on (hd0,0) rootnoverify (hd0,0) set jump=xEB\x3C\x90 set oemname=GRUB4DOS set bytpersec=x00\x02 # Set sectors/cluster according to win95 standards set /a ptstart=*0x82A8 set /a ptlength=*0x82B0 set /a disksize=%ptlength% * 512 if %disksize%<=2147483648 && set secclust=x40 if %disksize%<=1073741824 && set secclust=x20 if %disksize%<=536870912 && set secclust=x10 if %disksize%<=268435456 && set secclust=x08 if %disksize%<=134217728 && set secclust=x04 # if %disksize%>=33554432 && set secclust=x02 # if %disksize%<=16777216 && set secclust=x02 # if %disksize%<=4299162 && set secclust=x01 set mediabyt=xF8 set fatsz16=x00\x01 set sectrack= set sectrack=x3F\x00 set /A headslow=%heads% set numheads=%headslow:~1,3%\x00 # Set FAT's set volumeid=x78\x56\x34\x12 set magicbyt=x55\xAA set writefat=%mediabyt%\xFF\xFF\xFF # Write Bootcode jump (3 bytes) write ()+1 \%jump% # Write Bios Parameter Block # Write oemname(8) bytesect(2) secclust(1) rsrvsect(2) write --offset=0x03 ()+1 %oemname%\%bytpersec%\%secclust%\x01\x00 # write numfats(1) rootentr(2) totsect(2) mediabyt(1) fatsz16(2) sectrack(2) numheads(2) write --offset=0x10 ()+1 \x02\x00\x02\x00\x00\%mediabyt%\%fatsz16%\%sectrack%\%numheads% # Write hiddsec(4) from MBR dd if=(hd0)+1 of=()+1 bs=1 count=4 skip=0x1C6 seek=0x01C # Write totsec32(4) from MBR. If Volume >= 65536 sectors ! dd if=(hd0)+1 of=()+1 bs=1 count=4 skip=0x1CA seek=0x020 # write --offset=0x24 ()+1 \x80\x00 # Write Extended Boot Record # Write drvnum(1) rsrv(1) extbtsign(1) volumeid(4) vollabel(11) filsystype(8) write --offset=0x24 ()+1 \x80\x00\x29\%volumeid%NO\x20\NAME\x20\x20\x20\x20FAT16\x20\x20\x20 # Write Magic Bytes (2) write --offset=0x1FE ()+1 \%magicbyt% # Write FAT's write ()1+1 \%writefat% write ()257+1 \%writefat% # Write Volume Label to first Directory entry clear echo Volume Label maximum 11 signs set /p:60 /u VOLLABEL=Write Volume Label and press Enter in 60 seconds: write ()513+1 \xE5\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x21 if /i "%VOLLABEL%"=="" && goto :novollab set /u VOLLABEL=%VOLLABEL:~0,11% write ()513+1 %VOLLABEL% :novollab clear echo echo FAT sub-type: FAT16 echo Number of FAT's: 2 set /a secpclus=0%secclust% echo Sectors per cluster: %secpclus% echo Sectors per FAT: 256 set /a clusters=%ptlength% - 256 - 256 - 1 - 32 / %secpclus% echo Total clusters: %clusters% echo FAT start sector: 1 set /a drvspace=%clusters% * %secpclus% / 2 set /a mbspace=%drvspace% / 1024 echo %drvspace% KB total disk space (%mbspace% MB rounded down). echo debug on uuid () echo vol () pause --wait=60 To continue anyway: press a key.... debug off :eof --------------------------------------------------------------------------------------------------------------------------- The FAT part has some weaknesses: Volume ID is not according to standards. Can be changed easily with command uuid --write. If desired, a Volume Label can be written with vol --write, after running rd2hdfat16.g4b Update: Batch-file now like rd2hdf32.g4b (see below) Added dialog for writing a Volume Label (Grub4Dos vol --write and Windows' SCANDSKW.EXE compatible). Dialogs time bound. Added a disk size command-line argument. Use: rd2hdf16.g4b SIZE (in MB). Example: rd2hdf16.g4b 33 will make (hd0,0) 33MB in memory, FAT16 formatted. Size is rounded down to cylinder boundaries Update 2 --rd-base set to 50MB, edited one #comment. Edited April 25, 2020 by deomsh Addition ; Update ; batchfile corrections & updates Link to comment Share on other sites More sharing options...
jaclaz Posted February 27, 2020 Share Posted February 27, 2020 (edited) Nice. JFYI, grub4dos batches support both decimal and hex values in variables, i.e.: set /a mynum=64 set mynum mynum=64 set /A mynum=64 set mynum mynum=0x40 set /a mydec=0x40 set mydec mydec=64 i.e. (example): if "%secclust%"=="\x40" set /a secpclus=64 if "%secclust%"=="\x20" set /a secpclus=32 if "%secclust%"=="\x10" set /a secpclus=16 if "%secclust%"=="\x08" set /a secpclus=8 if "%secclust%"=="\x04" set /a secpclus=4 if "%secclust%"=="\x02" set /a secpclus=2 could become: set /a secpclus=0%secclust:~1,3% About partnew not writing to cylinder boundaries, I am not sure what you mean? You give partnew command the LBA addresses and it auto-translates them to CHS values, maybe there is an issue with the used geometry? Or is it a bug (that needs to be reported to the Authors)? 13 hours ago, deomsh said: The FAT part has some weaknesses: Volume ID is not according to standards. Can be changed easily with command uuid --write. If desired, a Volume Label can be written with vol --write, after running rd2hdfat16.g4b JFYI, and as a side-side note, if you want an entirely "kosher" filesystem. Volume ID/serial is not (entirely) "random" on FAT (DOS), see: https://msfn.org/board/topic/152097-on-superfloppies-and-their-images/?do=findComment&comment=973205 https://msfn.org/board/topic/152097-on-superfloppies-and-their-images/?do=findComment&comment=987748 https://www.forensicfocus.com/Forums/viewtopic/t=2134/ https://msfn.org/board/topic/152097-on-superfloppies-and-their-images/?do=findComment&comment=980297 jaclaz Edited February 27, 2020 by jaclaz Link to comment Share on other sites More sharing options...
deomsh Posted February 28, 2020 Author Share Posted February 28, 2020 13 hours ago, jaclaz said: FYI, grub4dos batches support both decimal and hex values in variables, i.e.: I know about set /a and set /A, but I am not so far with the "%" and" ~%"-"thing". I am happy with my simple if-statement in the case you mentioned, but I am afraid I will have to use the more advanced methods I want to read out Number of Heads from the MBR, adding 1 and convert to \X..-byte values to be able to use write to write the value directly in the Boot sector. Not to speak from Sectors/track with 6-bits value in the mixed Cylinder-Sectors/track-byte. That's the main reason I choose one batch file. 14 hours ago, jaclaz said: About partnew not writing to cylinder boundaries, I am not sure what you mean? You give partnew command the LBA addresses and it auto-translates them to CHS values, maybe there is an issue with the used geometry? Or is it a bug (that needs to be reported to the Authors)? It´s partition alignment to cylinders as far as I understand this subject (see error 108 in https://www.win.tue.nl/~aeb/partitions/partition_types-2.html ). I don´t think it´s a bug and it should only be a problem in very rare cases AND if one wants to use Partition Magic (in my case for error check, the program cannot be used to partition Grub4Dos disk in memory because of the stupid reboot feature). In following text I compare the output of Partinfo. The first is the example you was so kind to give me in your post of januari 31. Th second is the result of repartitioning the same drive in memory with Fdisk. Ther third is the output of my batch. The maximum disksize is 256 MB, like in your example. PARTINFO.EXE in case of partnew ===================================================================== Disk 0: 261 Cylinders, 32 Heads, 63 Sectors/Track. The BIOS supports INT 13h extensions for this drive. ========================== Partition Tables ========================= Partition -----Begin---- ------End----- Start Num Sector # Boot Cyl Head Sect FS Cyl Head Sect Sect Sects --------- - ---- ---- ---- ---- -- ---- ---- ---- --------- --------- 0 0 80 0 1 1 06 260 2 2 63 524225 Error #108: Partition didn't end on cylinder boundary. ucEndHead expected to be 31, not 2. Error #108: Partition didn't end on cylinder boundary. ucEndSector expected to be 63, not 2. ============================================================================== Disk 0: 256.9 Megabytes ============================ Partition Information =========================== Volume Partition Partition Start Total Letter:Label Type Status Size MB Sector # Sector Sectors ------------- --------------- -------- ------- --------- - --------- --------- FAT16B Pri,Boot 256.0 0 0 63 524225 ---------------------------------------------------------------------------------------------- PARTINFO.EXE in case of FDISK ===================================================================== Disk 0: 261 Cylinders, 32 Heads, 63 Sectors/Track. The BIOS supports INT 13h extensions for this drive. ========================== Partition Tables ========================= Partition -----Begin---- ------End----- Start Num Sector # Boot Cyl Head Sect FS Cyl Head Sect Sect Sects --------- - ---- ---- ---- ---- -- ---- ---- ---- --------- --------- 0 0 80 0 1 1 06 259 31 63 63 524097 ============================================================================== Disk 0: 256.9 Megabytes ============================ Partition Information =========================== Volume Partition Partition Start Total Letter:Label Type Status Size MB Sector # Sector Sectors ------------- --------------- -------- ------- --------- - --------- --------- FAT16B Pri,Boot 255.9 0 0 63 524097 Free Space Pri 1.0 None - 524160 2016 ---------------------------------------------------------------------------------------------- PARTINFO.EXE in case of rd2hdfat16.g4b (using 32 instead of 16 Heads in case of 256MB) ===================================================================== Disk 0: 260 Cylinders, 32 Heads, 63 Sectors/Track. The BIOS supports INT 13h extensions for this drive. ========================== Partition Tables ========================= Partition -----Begin---- ------End----- Start Num Sector # Boot Cyl Head Sect FS Cyl Head Sect Sect Sects --------- - ---- ---- ---- ---- -- ---- ---- ---- --------- --------- 0 0 80 0 1 1 06 259 31 63 63 524097 ============================================================================== Disk 0: 255.9 Megabytes ============================ Partition Information =========================== Volume Partition Partition Start Total Letter:Label Type Status Size MB Sector # Sector Sectors ------------- --------------- -------- ------- --------- - --------- --------- C:NO NAME FAT16B Pri,Boot 255.9 0 0 63 524097 Thanks to Grub4Dos simple integer calculator I had an easy job to adjust the given the given disksize (in MB) to multiples of Heads * Sectors/track. 14 hours ago, jaclaz said: JFYI, and as a side-side note, if you want an entirely "kosher" filesystem. Volume ID/serial is not (entirely) "random" on FAT (DOS), see: I know it's some number calculated of date/time while formatting. But for a Memdrive Volume ID I thought it's not realy needed and to be too much work. Or am I wrong? My next purpose is rd2hdf32.g4b. Link to comment Share on other sites More sharing options...
jaclaz Posted February 28, 2020 Share Posted February 28, 2020 Yep, everything is good then . the 524225 was chosen to fill the disk to the brim, without taking into account CHS boundaries, but with the "right" 524097 the partnew coonversion is correct, good, it is the classic GIGO case, not a fault of grub4dos partnew. the use of :~ to get substrings is identical to the CMD.EXE (Win2K and later) expansion, as a rule of thumb a sequence of IF conditional executions is only "ugly", and usually slower in execution, but it won't actually make any difference in practice in such a small/simple script. And no, there is no actual *need* to use the same date/time algorithm as DOS does, as a matter of fact since the volume is in RAM, and you won't normally have two of them the serial/volume ID could be also be "fixed", but I believe that - to be on the safe side - it should be set to non-0 values as it is likely that before or later you will find some tool/program that for some reasons checks that and panics if it finds a 00000000. 6 hours ago, deomsh said: My next purpose is rd2hdf32.g4b. Good. jaclaz Link to comment Share on other sites More sharing options...
deomsh Posted March 11, 2020 Author Share Posted March 11, 2020 (edited) I have finished my batchfile for FAT32 (to make a Grub4Dos Ramdrive, map it to a harddrive and format with FAT32). In comparison with my FAT16 batchfile: skipped mapping of first attached real hdd to last hd (if needed set elsewhere). Further: Asked inputs time limited. rdbase set higher to avoid problems during execution of the g4b-batchfile. Sectors per FAT no longer a constant, but depend on disksize. Set to the same amount as FORMAT.EXE would set them. Writing backup of Bootsectors. Choice to write valid Volume Label to first Directory entry (compatible with MS-DOS7.1, Win98se AND with Grub4Dos vol --write). ---------------------------------------------------------------------------------------------------------------------------------------------- rd2hdf32.g4b ---------------------------------------------------------------------------------------------------------------------------------------------- !BAT # Make FAT32 hdd-image: active first partition; range 33-3400 MB debug off set /a SIZE=%1 if %SIZE%=="" && goto :validate if %SIZE%>=3401 && goto :validate if %SIZE%<=32 && goto :validate goto :makeimg :asksize echo Disk size in range 33-3400, integer numbers only echo Actual image size will be adjusted to cylinder boundaries! set /a SIZE= set /p:60 /a SIZE=Enter disk size and press ENTER in 60 seconds: if %SIZE%=="" && goto :validate if %SIZE%>=3401 && goto :validate if %SIZE%<=32 && goto :validate goto :makeimg :validate echo Input is not a valid number, try again set /p:60 CONTINUE=Try again? choose Y or N and press ENTER: if /I "%CONTINUE%"=="Y" && goto :asksize goto :eof :makeimg if %SIZE%<=3400 && set /a heads=128 if %SIZE%<=2016 && set /a heads=64 if %SIZE%<=1008 && set /a heads=32 if %SIZE%<=504 && set /a heads=16 set /a sectmax=%SIZE% * 2048 set /a sectrack=63 set /a secthidd=63 set /a cylinder=%sectmax% / %heads% / %sectrack% set /a sectbal=%cylinder% * %heads% * %sectrack% set /a sectpart=%sectbal% - %secthidd% set /a rdsize=%sectbal% * 512 # Set rdbase >=50MB. Be aware: Grub4Dos can write the batchfile to (rd) set rdbase=52428800 set /A partid=0x0B map --rd-base=%rdbase% map --rd-size=%rdsize% map --unsafe-boot --heads=%heads% --sectors-per-track=%sectrack% (rd)+1 (hd0) map --hook partnew --active (hd0,0) %partid% %secthidd% %sectpart% # Create FAT32 on (hd0,0) rootnoverify (hd0,0) set jump=xEB\x58\x90 set oemname=GRUB4DOS set bytpersec=x00\x02 # Set sectors/cluster according to Microsoft Standards set /a ptstart=*0x82A8 set /a ptlength=*0x82B0 set /a disksize=%ptlength% if %disksize%>=66601 && set secpclus=x01 if %disksize%>=532841 && set secpclus=x08 set mediabyt=xF8 set sectrack= set sectrack=x3F\x00 set /A headslow=%heads% set numheads=%headslow:~1,3%\x00 # Math for sectors per FAT, FAT32 double! set /a secclus=0%secpclus% set /a dsksize=%ptlength% set /a tmpval1=%dsksize% - 32 set /a tmpval2=256 * %secclus% + 2 set /a tmpval2=%tmpval2% / 2 set /a sectpfat=%tmpval1% + %tmpval2% - 1 / %tmpval2% set /A sectpfat=%sectpfat% if "%sectpfat:~5,1%">="0" && set fatsz32=x%sectpfat:~4,2%\x%sectpfat:~2,2%\x00\x00 && goto :mirroring if "%sectpfat:~4,1%">="0" && set fatsz32=x%sectpfat:~3,2%\x0%sectpfat:~2,1%\x00\x00 :mirroring # enable mirroring all: 0x0000, disable: 0x0080 set extflags=x00\x00 set volumeid=x78\x56\x34\x12 set magicbyte=x55\xAA # Set FAT32: FAT start chains set writefat=%mediabyt%\xFF\xFF\x0F\xFF\xFF\xFF\x0F\xFF\xFF\xFF\x0F # Write FAT32 sector 0 # Write Bootcode Jump (3 bytes) write ()+1 \%jump% # Write FAT32 Bios Parameter Block # Write oemname(8) bytpersec(2) secpclus(1) rsvdsect(2) write --offset=0x03 ()+1 %oemname%\%bytpersec%\%secpclus%\x20\x00 # Write numfats(1) rootentr(2) totsect(2) mediabyt(1) fatsz16(2) sectrack(2) numheads(2) write --offset=0x10 ()+1 \x02\x00\x00\x00\x00\%mediabyt%\x00\x00\%sectrack%\%numheads% # Write hiddsec(4) from MBR dd if=(hd0)+1 of=()+1 bs=1 count=4 skip=0x1C6 seek=0x01C # Write totsec32(4) from MBR. If Volume >= 65536 sectors ! dd if=(hd0)+1 of=()+1 bs=1 count=4 skip=0x1CA seek=0x020 # Write FAT32 Extended Boot Record, first part Write fatsz32(4) extflags(2) fsver(2) rootclus(4) fsinfo(2) bkbootsc(2) reserved(12) write --offset=0x24 ()+1 \%fatsz32%\%extflags%\x00\x00\x02\x00\x00\x00\x01\x00\x06\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 # Write FAT32 Extended Boot Record, second part # Write drvnum(1) rsrv(1) extbtsign(1) volumeid(4) vollabel(11) filsystype(8) write --offset=0x40 ()+1 \x80\x00\x29\%volumeid%NO\x20\NAME\x20\x20\x20\x20FAT32\x20\x20\x20 # Write Magic Bytes(2) sector 0 write --offset=0x1FE ()+1 \%magicbyte% # Write FAT32 sector 1 write ()1+1 RRaA write --offset=0x1E4 ()1+1 rrAa\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 # Write Magic Bytes(4) sector 1 write --offset=0x1FC ()1+1 \x00\x00\%magicbyte% # Write Magic Bytes(2) sector 2 write --offset=0x1FE ()2+1 \%magicbyte% # Write backup FAT32 (normally to sectors 6-8) dd if=()+1 of=()6+1 bs=1 count=512 skip=0x000 seek=0x000 dd if=()1+1 of=()7+1 bs=1 count=512 skip=0x000 seek=0x000 dd if=()2+1 of=()8+1 bs=1 count=512 skip=0x000 seek=0x000 # Write FAT's set /a offsetf1=32 write ()%offsetf1%+1 \%writefat% set /a offsetf2=%sectpfat% + %offsetf1% write ()%offsetf2%+1 \%writefat% # Write Volume Label to first Directory entry clear echo Volume Label maximum 11 signs set /p:60 /u VOLLABEL=Write Volume Label and press Enter in 60 seconds: set /a startdir=%offsetf2% + %sectpfat% write ()%startdir%+1 \xE5\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x21 if /i "%VOLLABEL%"=="" && goto :novollab set /u VOLLABEL=%VOLLABEL:~0,11% write ()%startdir%+1 %VOLLABEL% :novollab clear echo FAT sub-type: FAT32 echo Number of FAT's: 2 set /a secpclus=0%secpclus% echo Sectors per cluster: %secpclus% set /a sectpfat= %sectpfat% echo Sectors per FAT: %sectpfat% set /a clusters=%ptlength% - %sectpfat% - %sectpfat% - 32 / %secpclus% echo Total clusters: %clusters% echo FAT start sector: 32 set /a drvspace=%clusters% * %secpclus% / 2 set /a mbspace=%drvspace% / 1024 echo %drvspace% KB total disk space (%mbspace% MB rounded down). debug 1 echo uuid () vol () pause --wait=60 To continue anyway: press a key.... debug 0 :eof ---------------------------------------------------------------------------------------------------------------------------------------------- Sadly I have not much possibilities to attach files, only 20KB left......... Update: I found a small bug if less than 11 characters where given in the Volume Label part. Windows SCANDSKW.EXE didn't like this and wrote as correction a "-" for an empty place. I cured this to pre-write ten "20"'s instead of zero's to the first directory entry ("E5" is not changed, is needed for compatibility with Grub4Dos vol --write. Otherwise "error 15: File not found" if the first directory entry is empty). I added a disk size command-line argument. Use: rd2hdf32.g4b SIZE (in MB). Example: rd2hdf32.g4b 400 will make (hd0,0) 400MB in memory, FAT32 formatted. Size is rounded down to cylinder boundaries. Update 2 --rd-base set to 50MB; set max SIZE to 3400 (MB); edited one #comment. Edited April 25, 2020 by deomsh Addition ; Update ; batchfile corrections & updates Link to comment Share on other sites More sharing options...
deomsh Posted March 22, 2020 Author Share Posted March 22, 2020 On 3/11/2020 at 10:36 PM, deomsh said: # Set rdbase >=37MB. Be aware: Grub4Dos can write the batchfile to (rd); because of --unsafe-boot? set rdbase=38797312 Today I tested my rd2hdf16.g4b without the --unsafe-boot switch. Doesn't make any difference, rdbase still has to be set to a minimum of 37MB, or DISKEDIT will find somewhere in (hd0) the content of the batchfile, together with the command-line of the batchfile. *Somehow* Grub4Dos needs more than 32MB for safe operation with my g4b batch-file. Link to comment Share on other sites More sharing options...
jaclaz Posted March 22, 2020 Share Posted March 22, 2020 So, everything is good. Only as a side note, this approach to input checking is not exactly "correct": Quote :validate echo Input is not a valid number, try again set /p:60 CONTINUE=Try again? choose Y or N and press ENTER: if /I "%CONTINUE%"=="" && goto :eof if /I "%CONTINUE%"=="N" && goto :eof if /I "%CONTINUE%"=="Y" && goto :asksize :makeimg I mean, what happens if I input "T" by mistake? Usually you "force" a negative result for all input BUT the one you check for that would change the result, *like* Quote :validate echo Input is not a valid number, try again set /p:60 CONTINUE=Try again? choose Y or N and press ENTER: if /I "%CONTINUE%"=="Y" && goto :asksize goto :eof :makeimg jaclaz Link to comment Share on other sites More sharing options...
deomsh Posted March 22, 2020 Author Share Posted March 22, 2020 Thanks a lot. Indeed, the second dialog wasn't typo-proof. I made corrections to the batch-files above. Link to comment Share on other sites More sharing options...
deomsh Posted April 25, 2020 Author Share Posted April 25, 2020 I discovered problems while copying from a Grub4Dos command-line to rd2hdf16.g4b/rd2hdf32.g4b based memdrives , map --rd-base is still not high enough. I am working on a copy-tool using Grubutil fat to copy to FAT-devices. My copy-part is based on COPYFF.BAT I found on https://www.rmprepusb.com/tutorials/grubutils - I hope that's not a problem. First I tested on USB drives only, which gave no real problems. Lately i started testing copying to Grub4Dos (rd) to (hd) mapped devices. It appeared that even 42MB wasn't 'good'. Copying stopped at about 400 files and fat dir gave out of memory errors afterwards. On https://www.rmprepusb.com/tutorials/grub4dos/grub4dos-internal-variables-and-functions I found, (md)-related, using above 50MB the Grub4Dos memory area 'to be ultra safe!'. Also wenv/insmod is mentioned loading files above the 32MB memory area. With map --rd-base set to 50MB all copy problems while using Grub4Dos, where gone. Even copying a directory containing 5,000 files. Updates of both files: in the posts of February, 27 and March, 11 Link to comment Share on other sites More sharing options...
jaclaz Posted April 26, 2020 Share Posted April 26, 2020 9 hours ago, deomsh said: I discovered problems while copying from a Grub4Dos command-line to rd2hdf16.g4b/rd2hdf32.g4b based memdrives , map --rd-base is still not high enough. I am working on a copy-tool using Grubutil fat to copy to FAT-devices. My copy-part is based on COPYFF.BAT I found on https://www.rmprepusb.com/tutorials/grubutils - I hope that's not a problem. First I tested on USB drives only, which gave no real problems. Lately i started testing copying to Grub4Dos (rd) to (hd) mapped devices. It appeared that even 42MB wasn't 'good'. Copying stopped at about 400 files and fat dir gave out of memory errors afterwards. On https://www.rmprepusb.com/tutorials/grub4dos/grub4dos-internal-variables-and-functions I found, (md)-related, using above 50MB the Grub4Dos memory area 'to be ultra safe!'. Also wenv/insmod is mentioned loading files above the 32MB memory area. With map --rd-base set to 50MB all copy problems while using Grub4Dos, where gone. Even copying a directory containing 5,000 files. Updates of both files: in the posts of February, 27 and March, 11 Very good news, In the comments to the original copyff.bat Steve mentioned that there were issues with "huge" number of files, it is very possible that you found how to avoid it. Indirectly, that report provides however a valid "test", if your modified copying batch can copy the XP CD's /I386 folder in an XP ISO, you have solved a long standing issue , (though it is also possible that at the time the limitation was another one linked to the grub4dos version, but I doubt it). jaclaz Link to comment Share on other sites More sharing options...
deomsh Posted April 26, 2020 Author Share Posted April 26, 2020 7 hours ago, jaclaz said: Very good news, In the comments to the original copyff.bat Steve mentioned that there were issues with "huge" number of files, it is very possible that you found how to avoid it. Indirectly, that report provides however a valid "test", if your modified copying batch can copy the XP CD's /I386 folder in an XP ISO, you have solved a long standing issue , (though it is also possible that at the time the limitation was another one linked to the grub4dos version, but I doubt it). jaclaz Yes, I have red the comments. Sadly enough I didn't solve the issues. Reason: there are no issues (except not copying LFN), at least not with grub4dos-0.4.6a-2019-09-09. Only thing I changed: renaming copyFF.bat to copyFF.g4b to make batch file working. I used following commands: (fd1) because of my real floppy drive (fd0); and only enough space on (hd0,5) for the iso: From Grub4Dos Command-line: grub> --------------------------------- map (hd0,5)/WXPhome.ISO (0xff) map --hook copyff.g4b (fd1) 0x1A0000 /I386 map --floppies=2 root (fd1) --------------------------------- To be sure: this is the content of my copyFF.g4b ---------------------------------------------------------------------------------------- copyFF.g4b ---------------------------------------------------------------------------------------- !BAT # Usage call (bd)/copyff.bat (fd0) 0x1A0000 /I386 # 1st param - e.g. (fd0) or (fd1) = virtual drive to create in memory must be fd0 or fd1 # 2nd param - e.g. 0x1A0000 - size of virtual drive # 3rd param (optiona) - e.g. /I386 - subfolder to start copy from debug off errorcheck off # initialise filecounter # write 0x60000 0 # stop 'hit Q to continue' messages pager off #512MB = 0x100000 #850MB = 0x1A0000 #1GB = 0x200000 set FD=%1 map --mem (md)0x300+%2 %FD% map --hook insmod (bd)/fat debug on clear echo Copy (0xff) contents to virtual drive %1 (size=%2), starting at %3... fat mkfs %FD% if NOT "%3"=="" fat mkdir %FD%%%3 debug -1 pause --wait=3 debug off root (0xff) set cd=%3 call :cpa echo Finished! goto :eof :cpa clear echo Copying files in folder: %cd% ::Change source root root (0xff)%cd%/ ls | call :copyfiles echo Finished folder %cd% goto :eof :copyfiles if "%1"=="" goto :eof ::If is a directory cat --length=0 /%1 || goto :sub-dir ::copy file echo %cd%/%1 fat copy /%1 %FD%%%cd%/ > nul || echo Error: %cd%/%1 # Filecount printed # debug on # calc *0x60000++ # debug off shift goto :copyfiles :sub-dir setlocal fat mkdir %FD%%%cd%/%1 set cd=%cd%/%1 call :cpa endlocal shift goto :copyfiles ---------------------------------------------------------------------------------------- Here are the results (pictures taken by daylight AND my first IMGUR experience EVER). Still only 20KB left on my msfn account......... https://imgur.com/gallery/g8Awwwf Enjoy! Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now