@Drugwash: It's wonderful to have you fully back!
Even if jaclaz already gave a pointer for the
El Torito Standard, here's it again, just in case. A very simplified and handy version of ISO9660 is
here, too, as also is Andrew Smith's
Supplement to it the El-Torito Standard, although I don't think we'll be needing either for the following comments and considerations:
i) The El-Torito Boot CD/DVD is simplicity itself. Remember all Optical Media sectors are 2048 bytes ( = 0x800 bytes, in hexadecimal). El-Torito follows ISO9660 and its predecessors in counting the Optical Medium's sectors starting from 1. So one goes to sector 17 (= 0x11) and reads one sector. The first 80 bytes of this sector contain the El-Torito "Boot Record Volume Descriptor", the contents of which are described in Figure 7, p. 13 of the Standard. Of relevance, there's only one pointer, a dword (= 4 bytes) at offset 0x47 (or absolute disc offset 0x8847), which contains the *sector number* of the next structure, which is the "Booting Catalog".
ii) So, by getting the value at the absolute disc offset 0x8847 and multiplying it by 0x800, one gets the actual address of the "Booting Catalog", goes there and reads one sector. This sector contains two structures: the first 32 bytes are the "Validation Entry", which must be there, but is otherwise irrelevant to this nutshell description. Its contents are detailed in Figure 2, p. 9 of the Standard. The next 16 bytes are the really relevant structure, called "Initial/Default Entry", the contents of which are described in Figure 3, p. 10 of the Standard. Of relevance, there's only one pointer, a dword (= 4 bytes) at offset 0x08 (of this latter structure, in reality at offset 0x28 from the start of the sector), which contains the *sector number* of the next structure, which is the actual "boot diskette image or no-emulation boot code". Observe that the "Initial/Default Entry" only provides a pointer to the boot diskette image, and says nothing about it's size, which must be obtained from the image's BPB, at the boot sector.
Also in the" Initial/Default Entry" are the "Boot Indicator", which must be 0x88 and the "Media Type" byte, about which lots have already been said. There's also the "Load Segment", which is the segment of the Real Mode conventional memory where the boot sector(s) will be loaded (and that means 0x07C0 when left zeroed!) and the "Sector Count", whic is the number of *512 bytes* sectors from the image (which is presumed to be the image of a diskette, hence the 512 bytes sectors) to be loaded before transferring control to that code for booting the emulated diskette.
iii) Last, but not least, since I'm being punctilious here, all optical media are "dis
cs", while their magnetic counterparts are "dis
ks"... go figure!
And, in what regards FAT, the
English Wikipedia page and the
Starman's Pages should be enough for almost all purposes. Note, however, that we're beyond both when we create 36 kiB, 100 kB or 127 kiB FAT-12 diskette images.
My own way of creating FAT-12 images uses the following principles:
There are 4078 possible values representable in a FAT-12. This means (2^12) - 18, which is a pessimistic view, because it excludes 0, 1, and all values from 0xFF0 to 0xFFF, inclusive. See notes 10 and 11 in the File Allocation Table English Wikipedia page. Now, since the first possible cluster is 2, by definition, then the last one is 4079 (in doubt count your fingers from one hand, starting from two, and you'll arrive at 6! So, considering that there are really 5 fingers, when one starts from two, one always arrives at total count plus one, and 4078+1 = 4079). And 4079 is 0xFEF, which is the last value meant to be used. So far, so good.
However, the various OS use different maximum numbers of clusters for FAT-12: LINUX uses 4084 (see note 9 in the File Allocation Table English Wikipedia page), while Windows 9x/ME uses 4095 and MS-DOS uses 4086, according to RLoew's findings (
this post). This really boils down to the fact that there can be no more than 12 sectors per FAT-12. With 4086 we'd have 4086 clusters * 1.5 bytes per cluster = 6129 bytes. Adding 3 to that (the first three default bytes, usually 0xF0 0xFF 0xFF), we get 6132 bytes or 11.9765 sectors of 512 bytes, hence 12 sectors at most.
So, what then, is the biggest FAT-12 volume one may ever create? RLoew found out that using the "Large Sectors" count (or "Sectors 32", that is BPB+0x20) works, so we may have much more than 65536 sectors by setting BPB+0x13 to zero and using BPB+0x20 instead. So the limit is how many sectors the FAT-12 can hold. I settled on 4078 clusters * 32 kiB per cluster, so, to me, the maximum possible volume will have a net total of 133,627,904 bytes. But the filesystem structures do use space also, and we already know we need 25 sectors (1 boot sector plus 2 FATs) and the space for the root directory (which size is undefined, in principle). So, what I have been doing is to round the filesystem space to one cluster, and that gives me 64 -25 = 39 sectors for the directory, which would mean 39 *(512/32) = 624 directory entries (because each entry has 32 bytes)... Now, if I limited myself to 512 directory entries that would leave 7 unaddressable sectors in the cluster I set aside for the filesystem, as jaclaz led me to realize. So, the space needed to create a 133,627,904 bytes disk image is 133,660,672 if we wish to have a round number of clusters, which would be 4079. Of course I've made some decisions that lead to this particular value, so with different decisons it'll vary somewhat, but not much.
Frontpage
Forums
Tutorials
Members
Calendar
Subscription
Donate
Links
Contact 
Help
If needed, please move it there.
, I need some willing tester and some suggestions for "common" formats to include/add.
Back to top
Excel sheet, the idea behind it is exactly that of exploring the logic behind the values that existing apps, like FORMAT, mtools and the like calculate and use, or, if you prefer, have an easy test bed for learning in practice what you are asking for in theory.
But I'll try to digest that once beer gets out of my system. While I enjoy having fixed my broken roof, 
.
