Jump to content

Exploring "SETUP /P I;S=detectbus" and Grub4Dos: 8½ times Win98se on USB-drive


deomsh

Recommended Posts

12 hours ago, deomsh said:

No other differences :ph34r: 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. :worship:

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" :w00t: 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 by jaclaz
Link to comment
Share on other sites


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

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 :w00t:) :

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

On 2/11/2020 at 10:45 AM, jaclaz said:

About CHS/LBA balancing all you need is here (shameless plug :w00t:) :

Nice tools, I have just tested them. Thnx  :hello:

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

  • 2 weeks later...

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:

  1. Batch-file now like rd2hdf32.g4b (see below)
  2. Added dialog for writing a Volume Label (Grub4Dos vol --write and Windows' SCANDSKW.EXE compatible).
  3. Dialogs time bound.
  4. 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 by deomsh
Addition ; Update ; batchfile corrections & updates
Link to comment
Share on other sites

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? :unsure:

You give partnew command the LBA addresses and it auto-translates them to CHS values, maybe there is an issue with the used geometry? :dubbio:

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 by jaclaz
Link to comment
Share on other sites

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? :unsure:

You give partnew command the LBA addresses and it auto-translates them to CHS values, maybe there is an issue with the used geometry? :dubbio:

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. :cool:

Link to comment
Share on other sites

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 :unsure: 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. :cool:

Good. :)

jaclaz 

Link to comment
Share on other sites

  • 2 weeks later...

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:

  1. 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).
  2. 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 by deomsh
Addition ; Update ; batchfile corrections & updates
Link to comment
Share on other sites

  • 2 weeks later...
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

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

  • 1 month later...

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.:ph34r:

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. :cool: Even copying a directory containing 5,000 files. :crazy:

Updates of both files: in the posts of February, 27 and March, 11

 

Link to comment
Share on other sites

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.:ph34r:

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. :cool: Even copying a directory containing 5,000 files. :crazy:

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 :thumbup , (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

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 :thumbup , (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. :w00t:

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). :ph34r: Still only 20KB left on my msfn account.........

https://imgur.com/gallery/g8Awwwf

Enjoy! -_-

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...