## Edit + Gain Size In Clean FDUBCD Floppy Image Under Windows

If you have a tutorial or tip related to the UBCD, why not share it with other users here?

Moderators: Icecube, StopSpazzing

Message
Author
Posts: 832
Joined: Sat May 08, 2010 5:26 am

### Edit + Gain Size In Clean FDUBCD Floppy Image Under Windows

Edit And Gain More Free Space Size In A Clean FDUBCD Floppy Image Under Windows

The goal of this tutorial is to edit the FDUBCD.IMG 2880KB FAT12 floppy image so to have more space available in it, and maybe to make it work a little bit faster - though, probably unnoticeable faster - while maintaining the maximum compatibility possible.

This tutorial will use freeware/donationware GUI tools under Windows.

The method is aplicable for any floppy image, like for example the standards 1440KB, 2880KB or any other. For UBCD51a3 (and up), the modifications, as shown in the tutorial, were already made. In any case, further customizations can be made using the same method.

Is there any other method? Sure.
Is there any "better" method? Probably.
If you have any suggestions or feedback, those are always welcome; specially, if you know about any other tool that could be used instead of the ones in this tutorial to get to the final goal (even if it uses a different approach).

There is NO need to have a real physical floppy drive.

Required Items/Tools:

_ The original 2880KB standard FAT12 FDUBCD.IMG floppy image;
_ RoadKil's Boot Build (portable version available);
_ HxD Hex eDitor (portable version available);
_ ImDisk (or the ol' VFD, if you already have it installed).

_ (Un)compression tool, like for example 7-zip, for all the extraction/expansion/decompression/test tasks of zip / gzip / iso / img formats.

(Please, don't ask here for the links to their websites. These tools are very easy to find, if you just want to.)

In this tutorial, I get into the details about the steps for RoadKil's BootBuild and for HxD, just to make it clear and easy for more inexperienced users, but I'm not explaining so many details for ImDisk. This is NOT because ImDisk is easier. In fact, BootBuild and HxD have portable versions (which I recommend for this tutorial); but it might be "tricky" to correctly install ImDisk. The reason NOT to detail ImDisk is because explaining its correct installation, all its concepts and specially how to avoid/reduce problems with it, is probably out of the scope of this tutorial, and could need an additional tutorial by itself. Having said that, ImDisk GUI is simple enough to use.

So, my recommendation would be, in case you have problems with ImDisk (like for example correctly installing it), try to find a solution, and test it, before starting with this tutorial.

Don't get discarriaged by the number of steps of the tutorial; it's not really too much time-consuming, and it should be easy to follow. The number of steps of the tutorial comes from the (maybe too) detailed explanations.

It could be also a good idea to learn about the concepts used in this tutorial, but for a user to successfully follow the tutorial this is not an "absolute" requirement. Moreover, for many users those concepts might result boring or useless.

Before starting, download the required items and tools (almost all are portable), "correctly" install ImDisk (please read its website's documentation for instructions on installing it) and have a backup of the original FDUBCD.IMG floppy image (or the original UBCD.ISO image).

Some last recommendations before starting. Read carefully the complete tutorial at least once before starting doing anything, follow the steps closely, and be aware that this type of customizations are "not for everyone". If you have never customized UBCD before, then probably this is not the ideal place to start doing so.

DISCLAIMER: YOU and only YOU are the only exclusive responsible for anything you do in your copy of UBCD with this info/tutorial, and for any undesired consequences. Feedback is welcome anyway.

Tutorial's Steps:

1_ Use RoadKil's BootBuild to retrieve the boot sector from fdubcd.img.

Open BootBuild -> File -> Import from File -> select fdubcd.img -> Open.

The default values for a standard 2880KB FAT12 floppy image should be displayed in BootBuild. When opening your floppy image file, if you happen to see different values from the expected ones, then the most probable reason is because that specific floppy image file has in its boot sector different values from the ones shown here.

Code: Select all


Bytes Per Sector: 512
Sectors Per Cluster: 2
Reserved Sectors: 1
Media Descriptor: 1.44M+ "FD"
Sectors Per Track: 36
Total Sectors: 5760

Serial Number: (none, blank)
Sectors per FAT: 9
Number of FATs: 2
Hidden Sectors: 0
Max Root Entries: 240
Physical Number: 0
Signature: 41


2_ Alter the values in RoadKil's BootBuild.

Don't worry about your original fdubcd.img. The values you are going to change are not being immediately saved, until you explicitly select a (new) file where to save them.

We want to change "Number of FATs" to "1" and "Max Root Entries" to "96".

Code: Select all


Bytes Per Sector: 512
Sectors Per Cluster: 2
Reserved Sectors: 1
Media Descriptor: 1.44M+ "FD"
Sectors Per Track: 36
Total Sectors: 5760

Serial Number: (none, blank)
Sectors per FAT: 9
Number of FATs: 1
Hidden Sectors: 0
Max Root Entries: 96
Physical Number: 0
Signature: 41


3_ Save the new modified boot sector to a new file.

File -> Export to File -> Change the name of the file to be saved -> Save.

It is recommended to use a relevant name so to clearly identify the new boot sector.

Since the new file is not a complete image, but only a boot sector, it is recommended to save the file with the ".bin" extension, instead of the common ".img" extension.

For example, save the new boot sector as "FDUBCD1FAT96ROOTS.BIN".

Although the button for "saving" might say "Open", it actually saves when you have selected the function to "export to file".

This "export" function saves the complete 512B boot sector; not only the structural values that being display in the UI of BootBuild.

Now you can close BootBuild with File -> Exit.

4_ Open HxD and start a new hex file with File -> New.

5_ Select Edit -> "Insert bytes...".

6_ Under the "Bytecount", from the 3 available possibilities "hex", "dec", "oct", select "dec" (decimal).

7_ To the right side of "Bytecount", insert the value

Code: Select all


" 3 "   (without the quotation marks)


in the box. Under the "Fill pattern" -> "Hex-values:", insert the code:

Code: Select all


" F0 FF FF "   (without the quotation marks)


This code is the capital letter "F" with the number "zero", then a space, then double "F", another space and then yet another double "F".

8_ Press "OK". The value "F0 FF FF" is inserted in the main hex editor window of HxD. The cursor blinks to the right side of the third value. This is important, because the next following values should be inserted in the correct position.

Code: Select all


Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  F0 FF FF                                         ðÿÿ


9_ Select Edit -> "Insert bytes...". Under the "Bytecount", from the 3 available possibilities "hex", "dec", "oct", select "dec" (decimal).

To the right side of "Bytecount", insert the value:

Code: Select all


" 2947581 "   (without the quotation marks)


in the box.

Under the "Fill pattern" -> "Hex-values:", insert the code

Code: Select all


" 00 "   (without the quotation marks)


This code is a double zero.

10_ Then press "OK". The value "00" is repeatedly inserted in the main hex editor window of HxD. The cursor blinks to the right side of the last value. This is important, because the next following values should be inserted in the correct position.

Code: Select all


Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

...
...
...

002CF9D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
002CF9E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
002CF9F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................


[/size]

11_ Once again, select Edit -> "Insert bytes...". Under the "Bytecount", from the 3 available possibilities "hex", "dec", "oct", select "dec" (decimal).

To the right side of "Bytecount", insert the value:

Code: Select all


" 1024 " (without the quotation marks)


in the box.

Under the "Fill pattern" -> "Hex-values:", insert the code

Code: Select all


" F6 "   (without the quotation marks)


This code is the capital letter "F" and the number "six".

12_ Then press "OK". The value "F6" is repeatedly inserted in the main hex editor window of HxD.

Code: Select all


Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

...
...
...

002CFDD0  F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6  öööööööööööööööö
002CFDE0  F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6  öööööööööööööööö
002CFDF0  F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6  öööööööööööööööö


[/size]

13_ Select File -> Save.

Change the name of the file to be saved to some filename easy to identify, with the classical ".img" extension; for example, "TAIL.IMG". Then press "OK" so to save the file.

14_ Close the just-saved "TAIL.IMG" file, but leave HxD open.

15_ Select "Extras" -> "File tools" -> "Concatenate...".

Click on "Add..." and select the first file we saved from BootBuild, "FDUBCD1FAT96ROOTS.BIN"; then click "Open". The "FDUBCD1FAT96ROOTS.BIN" file is added to the list.

Click once again in "Add..." and select the file we just saved from HxD, "TAIL.IMG"; then click "Open". The "TAIL.IMG" file is added to the list.

16_ In the "Output File name:" box, select the name you want to use for the new modified floppy image, for example "FDUBCD1FAT96ROOTS.IMG" (Note that I am not using "bin" as file extension, as I used before, from BootBuild).

You can click on the "Browse" button (...) to browse to a specific location to save the file. In that case, it is better to browse to the desire location before typing the file name to be saved.

17_ Press "OK". The new (empty) floppy image file is saved. You can close HxD now.

18_ Close all windows of Windows Explorer. Open ImDisk. Mount the new floppy image file "FDUBCD1FAT96ROOTS.IMG" with the following settings:

Code: Select all


Image File: <path\to\> "FDUBCD1FAT96ROOTS.IMG"
Drive letter: "A"
Device Type: Floppy
Select "Removable media"


19_ Mount the original fdubcd.img with the following settings:

Code: Select all


Image File: <path\to\> "fdubcd.img"
Drive letter: "B"
Device Type: Floppy
Select "Removable media"


Close ImDisk, leaving the floppy images mounted.

20_ Now open Windows Explorer, and "show all hidden and system files". Select "A:" and using its properties, add a suitable Volume Label (for example "FDUBCD142").

21_ Open "B:". Copy one-by-one the following files, in this same order , from "B:" to "A:".

21.1_ Kernel.sys
21.2_ Command.com
21.3_ Config.sys
21.4_ Autoexec.bat
21.5_ Diskid.txt
21.6_ Each of the rest of the files in the root, if there is any, one-by-one.
21.7_ Each of the folders in the root, one-by-one (meaning, do NOT select all the folders in the root altogether as a group to copy them in just one pass).

NOTE1: This operation also generates a "defragmented" floppy image, with better compression potential.

NOTE2: The method used in this tutorial does NOT change the original bootstrap code of FDUBCD.IMG. Hence, the same original "system" files from the original FDUBCD.IMG floppy image should be copied into the new modified floppy image. If you want/need a different set of "system" files ( different OS ), you need to start this tutorial from a floppy image that already contains the desired OS, so to copy (transfer) the relevant "system" files into the new modified floppy image. Of course, there are also different additional methods, but they are not covered by this specific tutorial.

22_ Close all Windows Explorer windows, and Unmount the floppy images from ImDisk. There is NO need to save the floppy image as a new additional "third" separate image. ImDisk already updated the modified floppy image in "a:" with the new files while you were transferring them. Close ImDisk. Check in Windows Explorer that the floppy images are NOT displayed. If they are still displayed in Windows Explorer after Unmounting them from ImDisk, it is recommended to close Windows and reboot.

23_ Optional step. If you know how to edit the "VolumeLabel" in the boot sector, you could optionally do it. This is:

_ not escential; and,
_ involves explaining several additional technical details.

So I decided to leave this optional step outside the scope of this tutorial; at least for now. So for those that want to skip this optional step, simply go on to the next step, 24_.

For those users that would like to try it anyway, in a nutshell:

23.1_ Use HxD to find the "VolumeLabel" you inserted in the above step 20_ (in the example, "FDUBCD142"). For the new floppy image we are building in this tutorial, the most probable location for it would be at offset (h) 1400.
23.2_ Select 11 bytes. For our example, that would be from offset (h) 1400 to offset (h) 140A.
23.3_ Edit -> Copy
23.4_ Position the cursor at offset (h) 002B and select 11 bytes, from offset (h) 002B to offset (h) 0035, both included.
23.5_ Edit -> “Paste write” (Do NOT select paste insert in this step).
23.6_ Save the new modified floppy image and close HxD.

24_ Do you have a backup of your original "FDUBCD.IMG" floppy image? This is the last opportunity to make it, before overwriting the original. Now you can copy the newly created "FDUBCD1FAT96ROOTS.IMG" file to "FDUBCD.IMG" in the adequate folder, so to run the appropriate scripts to remaster (rebuild) UBCD with the new modified FDUBCD.IMG floppy image.

Posts: 832
Joined: Sat May 08, 2010 5:26 am

### Re: Edit + Gain Size In Clean FDUBCD Floppy Image Under Wind

Technical Background:

Just to avoid confusions with the tutorial, I'll present here the basic concepts used to achieve our final goal. If this is of no interest for you, simply skip this "Technical Background" section and go read the tutorial.

The floppy image of UBCD has the following format:

_ 2880KB unformatted size;
_ 5760 total sectors;
_ 512B per sector;
_ FAT12 filesystem;
_ 1 boot sector;
_ 1.5B per entry in the FAT (see (A) bellow);
_ 3070 max FAT entries;
_ 32B per root directory entry;
_ 2 (twin) FATs occupying 9 sectors each;
_ 240 max root directory entries occupying 15 sectors in total;
_ 34 "non-data" sectors;
_ 5726 "data" sectors;
_ 2 sectors per cluster, each cluster's size is 1KB;
_ 2863 usable data clusters (before filling it with any file).

(A) Being a FAT12 floppy image, and being 1B = a set of 8 bits, then 12 bits = 1.5B (bytes).

From the characteristics above, there are some of them that are part of the FAT12 specification, and they can't be altered.

Other values are VERY much used as the "default and only" possible number, even when the specifications allow to use other values too. For example, "a sector is 512B in size" is the default for FAT12 floppies, and other values *are* allowed too; but the 512B sector size is SUCH a common practice, SO "traditional", that some tools assume this value as the only possibility and will fail if this value was to be changed.

The third category of values is the one including "the recommended ones". These values are also "standard" and "very common" (and there are valid reasons to be so). These values can be changed to adapt the floppy to special situations. Two of this type of parameters are:

_ the amount of FATs, generally 2; and
_ the maximum amount of root directory entries, usually 240 entries for a standard 2880KB FAT12 floppy.

I won't get into the uses of those concepts and more in depth explanations here; there is better "search-able" info out there .

The UBCD DOS floppy is only used in RAM, and it functions "almost" as "read-only". So the second FAT (usually for recovery purposes) is not really used.

In addition, if no additional customization is made directly to FDUBCD.IMG (the UBCD DOS floppy image), the amount of root entries actually being used is about 12 (meaning, there are several files and several folders in the root of the floppy, "a:\", and they are a total of 12). If UBCD will use only 12, there is no real need for the standard 240 maximum entries. To be technically correct here, I have to add one additional root entry needed, to those 12 files/folders, since one additional hidden root entry is used for the "VolumeLabel" attribute of the floppy.

(Just be clear, in relation to the "max root directory entries"; *under* the root directories, there is no “practical” limit in the amount of subdirectories or files, except that the total number of files and directories can't be more than the total number of data clusters available.)

Both these characteristics - each FAT and the amount of max root entries - are also occupying sectors, from the total 5760 available. Since FDUBCD is not really making useful utilization of those occupied sectors, we are going to actually use those sectors as additional available data area (clusters).

Before getting into the actual work, I want to explain one more value, since it is used in the calculations.

As already mentioned, each FAT12 of this floppy uses 9 sectors, and there are 2863 usable data clusters.

According to the FAT specifications, for each data cluster in the data area, each FAT must have a correlated entry (please, do not confuse these "FAT entries" with the "root directory entries" mentioned before). Each entry in the FAT12 requires 1.5B (see the calculation above), and (again, because of the FAT12 specifications) each complete FAT needs 2 entries ("reserved entries"), so those 2 entries are not available for this correlation between FAT entries and data clusters.

Code: Select all


( 512B per sector ) x ( 9 sectors per FAT ) / ( 1.5B per entry )

-  ( 2 reserved entries per FAT )

=    3070   entries per FAT


(Just to make it clear; when there are 3070 entries "per FAT", that does NOT mean that for 2 FATs we can have double that amount, 6140 entries. Both FATs are "twins", and each entry in the first FAT is duplicated in the second FAT. For this calculation, you should read “per FAT” as “in each twin FAT”.)

This value means that the maximum number of data clusters that this FAT can allocate ("manage" or "handle" in the correlation mentioned before) is 3070. If a floppy has equal or less _data clusters_ , then these _9 sectors_ occupied by the FAT12 are able to handle them. In case the amount of data clusters would be greater than 3070, then this FAT would need to be increased to occupy more than 9 sectors, so to be able to allocate (handle) all the data clusters, according to the correlation requirement.

Our floppy image has 2863 data clusters (see above, basic values), so this amount of data clusters, being less than 3070, can be allocated by the 9 sectors of each FAT12.

Could we make this FAT12 a little bit smaller? Could we "steal" some sectors from this FAT12 in favor of additional data clusters? Let's try it with 8 sectors per FAT12, instead of the current 9.

Code: Select all


( 512B per sector ) x ( 8 sectors per FAT ) / ( 1.5B per entry )

-  ( 2 reserved entries per FAT )

=    2728.666...   entries per FAT


But we already have 2863 data clusters (plus the amount we would be expecting to gain from using 1 less sector per FAT), which is _greater_ than 2728 entries per FAT. Conclusion: this _smaller_ FAT12 of only 8 sectors could not be enough to handle (allocate) all the available data clusters.

Let's review the original standard 2880KB FAT12 FDUBCD.IMG floppy image.

The standard 2880KB FAT12 floppy has:

_ 5760 unformatted 512B sectors, and they are used as:

_ 1 boot sector;
_ 9 sectors for the first FAT;
_ 9 sectors for the 2nd FAT;
_ 15 sectors for 240 root directory entries;

which gives a total of 34 "non-data" sectors, leaving

5760 - 34 = 5726 data sectors,

usable as

5726 / 2 = 2863 clusters for data

in these 2880KB floppy.

Now, the two parameters we are going to change from the original FDUBCD.IMG are:

_ only one FAT12 (instead of two) of 9 sectors; and,

_ the max number of root entries, instead of the current 240.

So, which possible values can we use for the max number of root entries?

Code: Select all


( 512B per sector ) / ( 32B per root entry )

=  16   root entries per sector


In theory, since we use only 12 (+1) root entries for FDUBCD (see above the explanation), we could potentially use just one sector to allocate a _maximum_ of 16 root entries.

Let's make the same presentation we did before, this time for our modified floppy with only 16 max root entries:

_ 5760 unformatted 512B sectors, and they are used as:

_ 1 boot sector;
_ 9 sectors for the first (and only) FAT;
_ 1 sector for 16 root directory entries;

(which gives a total of 11 "non-data" sectors, leaving

5760 - 11 = 5749 data sectors,

usable as

5749 / 2 = "2874.5" clusters for data.

But, FAT doesn't accept "half clusters", hence we get 2874 data clusters plus 1 additional "useless" sector.

Repeating this for several cases:

Code: Select all


1 root sector(s)
16 root entries
2874 usable data clusters
1 unusable sector(s)

2 root sector(s)
32 root entries
2874 usable data clusters
0 unusable sector(s)

3 root sector(s)
48 root entries
2873 usable data clusters
1 unusable sector(s)

4 root sector(s)
64 root entries
2873 usable data clusters
0 unusable sector(s)

5 root sector(s)
80 root entries
2872 usable data clusters
1 unusable sector(s)

6 root sector(s)
96 root entries
2872 usable data clusters
0 unusable sector(s)

...



You get the point. It is VERY recommended to calculate the number of entries so to avoid "unusable" sectors. In theory, you could leave the floppy with unusable sectors. In practice, some tools won't "like it", and you can read about this in several technical websites (you may find this issue as matching the cluster limit with the end of the floppy or something similar).

Since the counterpart, the "usable" sectors, is the same for each pair (1/2 root entries sectors, 3/4 root entries sectors, 5/6 root entries sectors...), it just makes sense to have the "unusable sector" as an additional sector available for more root entries.

So the above first modification is not the "best" choice. Instead of 16 max root entries (which, as I said, it could be enough for 12 (+1) root files and directories), I'll take the second example of the above table, with 32 max root entries, 2 "root sectors", zero "unusable" sectors and 2874 usable clusters.

If the current structure of FDUBCD doesn't change, specially in relation to the amount of required root directory entries, then this modified floppy with only 1 FAT and only 32 max root directory entries should be adequate for FDUBCD.IMG.

Now, during the boot process of the UBCD floppy, are there any additional functions (like decompressing archives for example) that could increase the demand on root entries (meaning, more files and/or folders in the root directory of the floppy)? Is the original amount of files, all that will ever exist in the floppy? AFAIK, there is no need for more than 32 root entries in FDUBCD.

To be clear, in those rhetorical questions in the previous paragraph I am talking about the *amount* of files or folders, not about their total size.

What would happen if any user makes customizations on this floppy image (adds too many files/folders to the root)? It would be difficult to identify that the problem is the number of max root entries (32 in the chosen example).

With the "risk" of such a case, wouldn't it be better to leave it as 240 max root entries? "Nah, too much". Let's find a balance, that could give an acceptable and versatile amount of max root entries, without “spending” too many “potential data sectors or data clusters”.

For example, a FreeDOS boot floppy (like Balder/Odin) could be a "rule for comparison", to have some kind of order of magnitude. I'm not taking for comparison a full complete HDD installation of FreeDOS, but only a typical Balder/Odin boot or install floppy. These boot floppies would have between 60 and 70 files (closer to the top limit, and some times even more than that amount) in the root of the floppy. The fact that those FreeDOS boot floppies are usually based on 1440KB (and not 2880KB as FDUBCD.IMG) is irrelevant to the root entries limit.

So, while we could choose just 32 max root entries for FDUBCD.IMG, I'd rather choose 96 max root entries. This amount is enough for a Balder/Odin FreeDOS boot floppy, is also enough for the current FDUBCD.IMG, and leaves some versatility for future developments in FDUBCD.IMG, avoiding "too close" chances to have some special customization failing because of the limit on root directory entries.

As mentioned before, the original FDUBCD.IMG floppy has the following characteristics:

Code: Select all

_ 2880KB unformatted size;
_ 5760 total sectors;
_ 512B per sector;
_ FAT12 filesystem;
_ 1 boot sector;
_ 1.5B per entry in the FAT;
_ 3070 max FAT entries;
_ 32B per root directory entry;
_ 2 (twin) FATs occupying 9 sectors each;
_ 240 max root directory entries occupying 15 sectors in total;
_ 34 "non-data" sectors;
_ 5726 "data" sectors;
_ 2 sectors per cluster, each cluster's size is 1KB;
_ 2863 usable data clusters (before filling it with any file).

The modified floppy will have the following characteristics:

Code: Select all

_ 2880KB unformatted size;
_ 5760 total sectors;
_ 512B per sector;
_ FAT12 filesystem;
_ 1 boot sector;
_ 1.5B per entry in the FAT;
_ 3070 max FAT entries;
_ 32B per root directory entry;
_ 1 FAT occupying 9 sectors;
_ 96 max root directory entries occupying 6 sectors in total;
_ 16 "non-data" sectors;
_ 5744 "data" sectors;
_ 2 sectors per cluster, each cluster's size is 1KB;
_ 2872 usable data clusters (before filling it with any file).

Just for the more curious users (but too lazy to calculate it by themselves ), here are the characteristics of the previous "32 max root directory entries" choice:

Code: Select all

_ 2880KB unformatted size;
_ 5760 total sectors;
_ 512B per sector;
_ FAT12 filesystem;
_ 1 boot sector;
_ 1.5B per entry in the FAT;
_ 3070 max FAT entries;
_ 32B per root directory entry;
_ 1 FAT occupying 9 sectors;
_ 32 max root directory entries occupying 2 sectors in total;
_ 12 "non-data" sectors;
_ 5748 "data" sectors;
_ 2 sectors per cluster, each cluster's size is 1KB;
_ 2874 usable data clusters (before filling it with any file).