rloew

On Bootable CD's Floppy Emulation

102 posts in this topic

@dencorso

I am posting here, though maybe it would be more pertinent to the "super-floppy" thread. :unsure: If needed, please move it there.

Just imagine:

Q.: What do you use to create a FAT 12 or 16 formatted image of a floppy or volume?

A: Excel. :w00t:

;)

jaclaz

P.S.:

Consider this an early pre-release version :ph34r: , I need some willing tester and some suggestions for "common" formats to include/add.

The "batch file" part is the one that may get a number of improvements, right now it creates a "truncated" image but the good thing is that it needs no "external" utilities (32 bit 2K or XP needed Vista :ph34r: and 7 should work allright also :unsure: but NOT 64 bit)

If we are allowed to use mksparse and fsz (and dsfi/dsfo) we could make images faster and, besides "truncated" also "sparse" and "full size" (the latter can be done even now with a few lines added to the batch).

The spreadsheets are protected (with no password) to avoid accidentally change formulas/data, but you can unprotect them allright.

Attachment removed, new version a couple posts below.

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

With a new DDO and a few Patches, I have created a Blu-Ray Disk that boots a 23GB A: Drive. I have solved the LBA issue so it should also work with the 50GB Blu-Ray Disks.

0

Share this post


Link to post
Share on other sites

@jaclaz: Great idea! Let's let this new sub-thread here for now... if it proves to evolve in a direction more apropriated to the Superfloppy thread, then I'll move it there.

@jaclaz and @RLoew: You two bring great news! :thumbup

@RLoew: Did you go renimatolog's way? I mean: is your new DDO a no-emulation El-Torito loader, which loads the remainder of the DDO?

BTW, do you realize that on a 23 GB Blu-Ray (or even in a 8.5 DVD+R DL) it's possible to create a complete live Win 98SE or ME, with all bells and whistles?

Maybe even with KernelEx and Aurora (= Firefox) 5? That opens all sorts of new possibilities, of course. :yes:

0

Share this post


Link to post
Share on other sites

BTW, do you realize that on a 23 GB Blu-Ray (or even in a 8.5 DVD+R DL) it's possible to create a complete live Win 98SE or ME, with all bells and whistles?

Maybe even with KernelEx and Aurora (= Firefox) 5? That opens all sorts of new possibilities, of course. :yes:

23 GB? I have 1,7 GB hdd on my Windows 98 machine, so even 1,5 GB would be enough for that.

0

Share this post


Link to post
Share on other sites

Sure. But mine is 7 GiB, with my rather big collection of installed applications. What I really meant is no minimization would be needed, in any case. :D

0

Share this post


Link to post
Share on other sites

Version 02 added, with a couple formulas fixed and a preliminary provision for the three "max CD super-floppy" formats.

Only the one corresponding to dencorso's image implemented (with a small change).

Open question :w00t::

  1. How many ROOT directory entries do we expect? (usually it's 512 if F8 media, 224 if F0, dencorso's image has 272 :w00t:)
    Maybe we can change this logic to "proportional to image size, with a minimum of 224"? (and a max of 512 if file is bigger than, say, 100 Mb or something like that?)

A different kind of question, this part is not fully clear to me :ph34r: :

  • How should cluster size calculated (vs. image size)?
    In dencorso's image there is a 32 sectors cluster, but scrap the "theoretical max size", provided that the actual max number of clusters in a FAT12 is 4086 (and in FAT 16 65526):
    http://www.pcguide.com/ref/hdd/file/partSizes-c.html
    (or what is the actual number) would it make more sense an image around 4086*16*512=33,472,512 instead of the current 37,748,736 (losing 3 Mb of space but have less slack space for DOS smallish files?)
    Or we should forget the whole thing about FAT12 and make the image FAT16?

jaclaz

P.S.: Attachment removed, see a few posts below ...

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

Please, could any of you be so kind and take some time to send me a PM or e-mail with a very detailed description of the goal of this endeavour as well as any usable information that could help me understand the boot process and especially the why of using a huge floppy image instead of the other classical way(s)? Admittedly, I've never delved too far in the boot process so there are many blank spots that need filled with information.

I have however started to build a simple application to create/edit floppy/HDD images, which should ideally avoid the use of that not-so-classy Excel sheet, so any help would be appreciated. In the mean time I'm gathering as much information as possible, but I need time to process since I'm a (very) slow thinker.

Thank you in advance!

Edited by Drugwash
0

Share this post


Link to post
Share on other sites

I have however started to build a simple application to create/edit floppy/HDD images, which should ideally avoid the use of that not-so-classy Excel sheet, so any help would be appreciated. In the mean time I'm gathering as much information as possible, but I need time to process since I'm a (very) slow thinker.

Maybe you could analyze the contents/formula's of the not-so-classy :whistle: 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.

jaclaz

0

Share this post


Link to post
Share on other sites

Oh, but I did. For the alpha version it's been a good start., but after reading a few web pages linked to in this very topic, I got more and more lost in the fog. There's no fixed standards, speculations are being raised and finding a reliable formula for all situations is not an easy task. Moreover, information comes from unknown sources so the level of trust is not too high.

For now, my app can read and display most of the attributes of a floppy image in ima format. I've tested with images created by UltraISO, which is a handy tool I've already had on my system. BTW, how come it has options to create 120MB and 240MB floppy images, while this topic is focused on 36MB images that aren't even listed in UltraISO's options?

Oh and don't worry - all my applications are open-source, therefore free of any charge and only bound by the GPL license - if anyone wondered. I'm poor, but still refuse to pray to the god of money. Anyway, this is off-topic.

0

Share this post


Link to post
Share on other sites

There's no fixed standards, speculations are being raised and finding a reliable formula for all situations is not an easy task.

Good moorning, Mr. de La Palice! :)

WHY would we be making speculations and tests, IF there were some actually valid standards (and if they were actually respected by everyone)? :unsure:

The 36 Mb limit is given by the actual limits of the geometry of 1024/2/36.

What Ultraiso makes is probably another thing, since they also make the Easyboot, it is possible that they use a loader as a no-emulation bootsector and later load the super-flopy image (just like it is perfectly possible with grub4dos and with isolinux/memdisk).

For the record I just checked the El-Torito reference:

http://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf

and it does state (page 14)

4.0 INT 13 and CD-ROMs

Once the system has selected the proper boot image, the INT 13 interface must recreate the Floppy/Hard disk. It is the

responsibility of the BIOS to create a valid geometry for the virtual disk and then present this geometry in function 08.

The INT 41 pointer is not valid at this time which means that software that uses INT 41 is not valid on a CD-ROM.

When the boot code is loaded, INT 13 must reverse the CHS addresses it receives creating a valid LBA address which

is then offset by the Load LBA. This procedure can emulate all standard Floppy/Hard disk transactions. The

remainder of this section assumes that the system is using the Initial/Default Entry, or has chosen a Section Entry.

4.1 INT 13 Function 08

This function normally gets the geometry information directly from the selected catalog entry. In the case of a floppy

simulation the geometry is well known and defined as follows:

Size Tracks x Heads x Sectors

1.44 Meg 50 x 2 x 12

2.88 Meg 50 x 2 x 24

1.2 Meg 50 x 2 x 0F

and (page 19):

1 Byte Boot media type. This specifies what media the boot image is intended to

emulate in bits 0-3. Bits 6 and 7 are specific to the type of system.

Bits 0-3 count as follows:

0 - No Emulation

1 - 1.2 meg diskette

2 -1.44 meg diskette

3 -2.88 meg diskette

4 -Hard Disk (drive C)

5-F-Reserved, invalid at this time

bits 4-5 - Reserved, must be 0

bit 6 - Image contains an ATAPI driver, bytes 8 & 9 refer to IDE interface

bit 7 - Image contains SCSI drivers, bytes 8 & 9 refer to SCSI interface

That can be read as it has been read till now.

rloew :thumbup found how evidently a number of BIOS programmers did not make:

0x1=1200 K i.e. 80/2/15

0x2=1440 K i.e. 80/2/18

0x3=2880 K i.e. 80/2/36

but rather:

0x1=m/2/15

0x2=n/2/18

0x3=o/2/36

For all we know :unsure: it is very possible that some BIOS programmers actually use (WARNING: just a speculation, as an example):

0x1=0x2=0x3= it's a floppy type of image, let's consider the first sector of the image as a bootsector and let's get the actual geometry from it's BPB

jaclaz

0

Share this post


Link to post
Share on other sites
bit 6 - Image contains an ATAPI driver, bytes 8 & 9 refer to IDE interface

bit 7 - Image contains SCSI drivers, bytes 8 & 9 refer to SCSI interface

I wonder where bit 8 and 9 reside in a one-byte media descriptor... :blink: But I'll try to digest that once beer gets out of my system. While I enjoy having fixed my broken roof, have a look at this alpha-stage tool try the newer version below. It can only read and display (partly) floppy image info, for now. It will be able to create/edit one later on when I would have figured out all the pieces of the puzzle.

[attachment removed - new version below]

Edited by Drugwash
0

Share this post


Link to post
Share on other sites
bit 6 - Image contains an ATAPI driver, bytes 8 & 9 refer to IDE interface

bit 7 - Image contains SCSI drivers, bytes 8 & 9 refer to SCSI interface

I wonder where bit 8 and 9 reside in a one-byte media descriptor... :blink: But I'll try to digest that once beer gets out of my system. While I enjoy having fixed my broken roof, have a look at this alpha-stage tool. It can only read and display (partly) floppy image info, for now. It will be able to create/edit one lateron when I would have figured out all the pieces of the puzzle.

That's NOT bit 8 & 9 inside byte #1.

It is actually byte 8 & 9:

....

8-9 Word Device Specification. For SCSI controllers byte 8 is the LUN and PUN of the CD

Drive, byte 9 is the Bus number. For IDE controllers the low order bit of byte 8

specifies master/slave device, 0 = master.

jaclaz

P.S.: Nice tool, but can we have "standard" names for the fields? (just to avoid misunderstandings)

File system is definitely NOT "Freedos 1.0" or "Windows Vista/7", etc. :w00t:

Sectors 16 and Sectors 32 are usually referred to as "Small sectors" and "Large Sectors".

"Hidden sectors" are also sometimes referred to as "Sectors Before" (and this IMHO better conveys the idea).

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

If you checked out UltraISO you'd notice that is the "friendly name" by which a file system is selected. Currently it doesn't respond to image file loading because I was too tired this morning at 6 so I had to wrap and go to sleep (yeah, bad habit, I know...). But when working, it should just be the friendly correspondent of OEM string.

Sectors are not 'small' or 'large', but the count is 16bit (when sector count doesn't exceed 0xFFFF) or 32bit when it does. So I'd rather modify to 16bit/32bit than use a misleading denomination (which actually made me wonder at first glance what this small/large is all about). Same goes for 'Sectors before' - I kept wondering what that meant until I found documentation that called it as it should: hidden.

Anyway, the source is bundled in the exe so it can be easily modified and recompiled if it's so critical. ;)

Beer is still not out of my system... for the simple reason I'm still pouring it in. :D

0

Share this post


Link to post
Share on other sites

@RLoew: Did you go renimatolog's way? I mean: is your new DDO a no-emulation El-Torito loader, which loads the remainder of the DDO?

Close. My entire DDO is in the El-Torito loader. I will probably switch to Floppy Emulation so the Real Floppy Drive will appear as B:.

BTW, do you realize that on a 23 GB Blu-Ray (or even in a 8.5 DVD+R DL) it's possible to create a complete live Win 98SE or ME, with all bells and whistles?

Maybe even with KernelEx and Aurora (= Firefox) 5? That opens all sorts of new possibilities, of course. :yes:

Unfortunately El-Torito emulation is Read-Only, even on BD-RE so you would have to customize your Win 98SE to the target machine on another medium, transfer it to a CD/DVD/BD, boot it and load it into a RAMDisk to run.

A much more complex DDO, similar to my BOOTMAN series, would be needed to Write to the CD/DVD/BD, and it would wear out much faster than Flash Drives.

There is also no need to use extended Floppy emulations as you can load a minimal system out of a standard Floppy Image and load your RAMDisk from an ISO-9660 FS.

@drugwash: There is probably only limited need for these extended emulations. It would be needed for transparency when working with Computers already having 24 Hard Drive Partitions defined. For me, the exercise gave me the information I needed to add an additional 256TiB to the data handling capacity of DOS.

0

Share this post


Link to post
Share on other sites

@Drugwash: It's wonderful to have you fully back! :thumbup

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 "discs", while their magnetic counterparts are "disks"... go figure! :wacko:

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.

0

Share this post


Link to post
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.