Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 



dencorso

On Superfloppies and their Images

Recommended Posts

rloew    93

I never meant to say there were any problems from the POV of the standard. The "Number of Directory Entries" is two bytes, of course, so (if unsigned) 65,525 entries are allowed for. I just wished to point out that MS says there can be compatibility problems (most probably just with deprecated versions of some MS applications) when more than 512 entries are used. Then, I went ahead and typoed, and you cached my typo, as usual. And I was so certain of what I thought I had written, that only at this moment it dawned on me I had written "255" instead of "512". I'm sorry, I really do try to be as clear as best as I can, but more than once my typos conspire against me (and, BTW, that's why works meant for publication must have someone other than the authors revising them before going to press, although, nowadays, it doesn't always happen anymore). Thanks for the heads up! You rock! :thumbup

Actually they don't say there is a problem having more than 512 Entries, at least in this particular Article. They just assume that only 512 Entries are allocated, which obviously limits the number of files. I would not be surprised if many applications exist that would choke on more than 512 since all standard Formatters set 512 or less. It might be interesting to determine the absolute limit. it is easy for me to setup any limit I choose.

You are not the only one who has reviewed his writing multiple times and missed the same typo every time. I have done it too. As more and more Authors self-publish, there is going to be less and less review.

EDIT: The absolute limit appears to be 4096 Root Directory Entries. I have seen evidence that the Sector Offset into the Root Directory is limited to a Byte.

Edited by rloew

Share this post


Link to post
Share on other sites

jaclaz    943

OT :ph34r:, but just to keep things together as possible, the opposites of superfloppies (would they be "underfloppies"? :unsure::w00t: )

http://reboot.pro/8752/page__st__59

(I just happened to get by chance on that thread again, that I had completely forgotten)

jaclaz

Edited by jaclaz

Share this post


Link to post
Share on other sites
dencorso    542

Not underfloppies, no. :)

Subfloppies, of course! :P

But... that'd mean something with a total space less than 160 KB...

Share this post


Link to post
Share on other sites
jaclaz    943

But... that'd mean something with a total space less than 160 KB...

Exactlly, the "smallest" subfloppy (but with "large" capacity) I managed to produce has only 2560 bytes free, but is pretty FAST ;) in loading to --mem with grub4dos....

4096 bytes total size, gzips in 246 bytes. :thumbup

I might review it at the light of the new findings on this thread an maybe I can find a way to make it even smaller. :unsure:

jaclaz

Edited by jaclaz

Share this post


Link to post
Share on other sites
jaclaz    943

Hey, kids, noone wanting to play with me anymore? :(

I am almost finished with the spreadsheet :whistle: , but I just got a doubt. :unsure:

The three bytes jump code is actually part of the CODE and NOT of the BPB, right?

I mean, if I want to make a non-bootable bootsector :w00t: those three bytes should be 00 00 00, and ONLY when I decide to apply the bootsector CODE, then they will get (examples):

EB 3C 90 (MS)

EB 3C 90 (FREEdos)

EB 58 90 (some other bootsectors)

etc.

Or do you think that by default (if NO code is chosen) I should put a non-bootable bootsector code?

Same question goes for the "Magic Bytes" 55 AA:

http://linuxgazette.net/issue84/dashti.html

are they used only if the bootsector is bootable (thus CODE) or they define the sector as a bootsector (and thus they should also be 00 00 by default)?

Suggestions for a Public Domain or however freely redistributable bootsector code that can print a message (or display an image) welcome.

JFYI, I have also started working on a few batches, and then stopped and then started again....., and again, and again....

....I will do such things, ....

....What they are, yet I know not: but they shall be

The terrors of the bootsectors :ph34r:

jaclaz

Share this post


Link to post
Share on other sites
rloew    93

Hey, kids, noone wanting to play with me anymore? :(

I am almost finished with the spreadsheet :whistle: , but I just got a doubt. :unsure:

The three bytes jump code is actually part of the CODE and NOT of the BPB, right?

I mean, if I want to make a non-bootable bootsector :w00t: those three bytes should be 00 00 00, and ONLY when I decide to apply the bootsector CODE, then they will get (examples):

EB 3C 90 (MS)

EB 3C 90 (FREEdos)

EB 58 90 (some other bootsectors)

etc.

Or do you think that by default (if NO code is chosen) I should put a non-bootable bootsector code?

Same question goes for the "Magic Bytes" 55 AA:

http://linuxgazette.net/issue84/dashti.html

are they used only if the bootsector is bootable (thus CODE) or they define the sector as a bootsector (and thus they should also be 00 00 by default)?

Suggestions for a Public Domain or however freely redistributable bootsector code that can print a message (or display an image) welcome.

JFYI, I have also started working on a few batches, and then stopped and then started again....., and again, and again....

....I will do such things, ....

....What they are, yet I know not: but they shall be

The terrors of the bootsectors :ph34r:

jaclaz

The first three bytes are required. FileSystems do check it, even if not bootable. It does not need to point to actual code if it can never be booted.

It must be:

JMP SHORT

NOP

or

JMP LONG

The Magic Bytes are required regardless of Bootability. The BPB will not be read if the Magic Bytes are missing.

Making a Boot Sector that only Prints a message if Booted is a trivial exercise in Assembly Code, use Interrupt 10H.

Edited by rloew

Share this post


Link to post
Share on other sites
jaclaz    943

The first three bytes are required. FileSystems do check it, even if not bootable. It does not need to point to actual code if it can never be booted.

It must be:

JMP SHORT

NOP

or

JMP LONG

The Magic Bytes are required regardless of Bootability. The BPB will not be read if the Magic Bytes are missing.

Making a Boot Sector that only Prints a message if Booted is a trivial exercise in Assembly Code, use Interrupt 10H.

You make it sound a little bit too obvious and B/W for my tastes. :whistle:

There is a whole lot of shades of grey. :ph34r:http://reboot.pro/15878/

Experiments:

  1. make a "normal" floppy disk image with *any* bootsector starting with EB3C90 and ending with 55AA, write to it a simple .txt file.
  2. remove from it any boot code (optional).
  3. Replace 55AA with 00.
    • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
    • Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy.

[*]Replace EB3C90 with EB3C00.

  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
  • When in the VM, it fails with "General failure reading drive M" with DOS7.1, AND it cannnot be accessed properly by FREEdos

[*]Replace EB3C00 with EB5800.

  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
  • When in the VM, it fails with "General failure reading drive M" with DOS7.1, BUT it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy

[*]Replace EB5800 with EB0000.

  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
  • When in the VM, it fails with "General failure reading drive M" with DOS7.1, BUT it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy

[*]Replace EB0000 with 000000.

  • Image CANNOT be mounted by IMDISK.
  • When in the VM, it fails with "General failure reading drive M" with DOS7.1, BUT it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy

[*]Replace EB0000 000000 with EB0090.

  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
  • Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy, AND it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy

[*]Replace EB0090 with EB0190.

  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
  • Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy, AND it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy

[*]Replace EB0190 with 000000 AND re-add the Magic Bytes 55AA.

  • Image CANNOT be mounted by IMDISK.
  • When in the VM, it fails with "General failure reading drive M" with DOS7.1, BUT it can be accessed allright by FREEdos

[*]Replace 000000 with E90000.

  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
  • Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy, AND it can be accessed allright by FREEdos

[*]Leave the three bytes E90000 but remove the Magicbytes.

  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
  • Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy, AND it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy

I am attaching a set of such 1440K floppy images.

Preliminary conclusions :unsure:.

  1. under both DOS and XP the Magic Bytes are ignored and have NO influence whatsoever with reading/accessing the BPB, so they are part of the CODE (and not of the BPB) :w00t:.
  2. XP only checks if first byte is EB OR that first byte is E9 (the three one jump bytes are is part of the BPB)
  3. DOS 7.1 checks that first byte is EB and third is 90 (the three two jump bytes are part of the BPB) OR that first byte is E9 (the three one jump bytes are is part of the BPB)
  4. FREEdos ignores the three jump bytes and only checks for Magic Bytes (so , Magic Bytes is part of the BPB and NOT of the CODE, and the three jump bytes are part of the CODE and NOT of the BPB :ph34r: ) and it also has some kind of "sticky attitude" if it accesses another properly setup floppy, somehow the Magic Bytes are "ported over".

jaclaz

EBE955AA.zip

Share this post


Link to post
Share on other sites
rloew    93

The first three bytes are required. FileSystems do check it, even if not bootable. It does not need to point to actual code if it can never be booted.

It must be:

JMP SHORT

NOP

or

JMP LONG

The Magic Bytes are required regardless of Bootability. The BPB will not be read if the Magic Bytes are missing.

Making a Boot Sector that only Prints a message if Booted is a trivial exercise in Assembly Code, use Interrupt 10H.

You make it sound a little bit too obvious and B/W for my tastes. :whistle:

There is a whole lot of shades of grey. :ph34r:http://reboot.pro/15878/

They are required if you want general compatability. I never said you couldn't scrounge up something that could read them.

Preliminary conclusions :unsure:.

  1. under both DOS and XP the Magic Bytes are ignored and have NO influence whatsoever with reading/accessing the BPB, so they are part of the CODE (and not of the BPB) :w00t:.
  2. XP only checks if first byte is EB OR that first byte is E9 (the three one jump bytes are is part of the BPB)
  3. DOS 7.1 checks that first byte is EB and third is 90 (the three two jump bytes are part of the BPB) OR that first byte is E9 (the three one jump bytes are is part of the BPB)
  4. FREEdos ignores the three jump bytes and only checks for Magic Bytes (so , Magic Bytes is part of the BPB and NOT of the CODE, and the three jump bytes are part of the CODE and NOT of the BPB :ph34r: ) and it also has some kind of "sticky attitude" if it accesses another properly setup floppy, somehow the Magic Bytes are "ported over".

No Windows 9x tests?

The BPB is the block starting at Offset 0xB only. The Jump Bytes are part of the Code and FAT Validation. The Magic Bytes are for Boot Sector Validation only.

In a non-Bootable Partition or disk, the Jump Destination does not matter.

Share this post


Link to post
Share on other sites
jaclaz    943

No Windows 9x tests?

No, I thought that DOS 7.1 would have done for the moment. :unsure:

The BPB is the block starting at Offset 0xB only.

And what about this?

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/volume-boot-block-oem-name-field.html

Where does the actual BPB end?

Theoretically at 0x24 :w00t:

It seems like we have to consider the existence of a "real" BPB AND of an eBPB (extended Boot Parameter Block)

http://support.microsoft.com/kb/140418/en-us

(and consequently "divide" the set in BPB and eBPB)

The Jump Bytes are part of the Code and FAT Validation.

In a non-Bootable Partition or disk, the Jump Destination does not matter.

Yep :), but as seen we need to have at least EB0090 or E90000 even on a "no code" bootsector (just as you posted :thumbup ) for the tested MS OS's, while this is happily ignored by FreeDOS.

The Magic Bytes are for Boot Sector Validation only.

Yep :), but as seen we need to have at them for FreeDOS anyway, while the tested MS OS's happily ignore them.

Last two items seems to me like a nice contradiction (and no-end loop kind of situation).

On the other hand it provides a nice way to have volumes that are accessible/mountable only on FreeDOS (AND NOT on MS OS's)..... and another kind of volume that can be accessed only on MS OS's (AND NOT on FreeDOS) .... pretty much unuseful, if you ask me, but still some interesting news.

(and also a way to have a volume accessible from XP - and possibly later - MS OS 's, BUT NOT from DOS 7.x - and possibly earlier)

jaclaz

Edited by jaclaz

Share this post


Link to post
Share on other sites
dencorso    542

For PC-DOS 1.00 and 1.10 (and, I presume, for all the OEM MS-DOS 1.xx versions) there is no BPB, nor the Magic Bytes, *and* DOS uses the first byte of the first FAT (on FAT-12, BTW, the only FAT they know about) to establish what's the floppy format. This causes WinImage to be unable to open dikette images of such OSes, because WinImage relies on the existence of a BPB. When a correct BPB is artificially added to either a PC-DOS 1.00 or 1.10 bootable diskette image (and there is free space for a BPB in them), then WinImage will read them with no complaints, regardless of the existence of the Magic Bytes. This tests were performed with v. 8.5.0.8500 and 8.0.0.8000 of WinImage, so I believe it may be true, at least, for all of v. 8.x.x.x, and probably to earlier versions as well.

Share this post


Link to post
Share on other sites
rloew    93

No Windows 9x tests?

No, I thought that DOS 7.1 would have done for the moment. :unsure:

Not quite. Windows does it's own checking in IOS.VXD and VFAT.VXD so there is room for more discrepancies.

I have already created Partitions that looks like FAT12 to one and FAT16 to the other.

The BPB is the block starting at Offset 0xB only.

And what about this?

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/volume-boot-block-oem-name-field.html

Doesn't change anything but adds one more thing to worry about. I've seen the code that does these checks in my research.

Where does the actual BPB end?

Theoretically at 0x24 :w00t:

For FAT12 and FAT16. FAT32's BPB ends at 0x40.

It seems like we have to consider the existence of a "real" BPB AND of an eBPB (extended Boot Parameter Block)

http://support.microsoft.com/kb/140418/en-us

(and consequently "divide" the set in BPB and eBPB)

Some of the eBPB is also validated such as the Signature Byte. The ID is important to Windows for Volume discrimination.

The Jump Bytes are part of the Code and FAT Validation.

In a non-Bootable Partition or disk, the Jump Destination does not matter.

Yep :), but as seen we need to have at least EB0090 or E90000 even on a "no code" bootsector (just as you posted :thumbup ) for the tested MS OS's, while this is happily ignored by FreeDOS.

The Magic Bytes are for Boot Sector Validation only.

Yep :), but as seen we need to have at them for FreeDOS anyway, while the tested MS OS's happily ignore them.

Last two items seems to me like a nice contradiction (and no-end loop kind of situation).

On the other hand it provides a nice way to have volumes that are accessible/mountable only on FreeDOS (AND NOT on MS OS's)..... and another kind of volume that can be accessed only on MS OS's (AND NOT on FreeDOS) .... pretty much unuseful, if you ask me, but still some interesting news.

(and also a way to have a volume accessible from XP - and possibly later - MS OS 's, BUT NOT from DOS 7.x - and possibly earlier)

jaclaz

Another scheme to enforce DRM?

Share this post


Link to post
Share on other sites
jaclaz    943

For PC-DOS 1.00 and 1.10 (and, I presume, for all the OEM MS-DOS 1.xx versions) there is no BPB, nor the Magic Bytes, *and* DOS uses the first byte of the first FAT (on FAT-12, BTW, the only FAT they know about) to establish what's the floppy format. This causes WinImage to be unable to open dikette images of such OSes, because WinImage relies on the existence of a BPB. When a correct BPB is artificially added to either a PC-DOS 1.00 or 1.10 bootable diskette image (and there is free space for a BPB in them), then WinImage will read them with no complaints, regardless of the existence of the Magic Bytes. This tests were performed with v. 8.5.0.8500 and 8.0.0.8000 of WinImage, so I believe it may be true, at least, for all of v. 8.x.x.x, and probably to earlier versions as well.

I guess we are not targeting DOS 1.x, though, so I would say that we do need a BPB anyway.

Another scheme to enforce DRM?

Naaah, I don't think there is any conspiracy , just "normal" stupidity/crazyness :ph34r: of non-standards or undisclosed/undocumented properly ones.......

Back to business,

A non-bootable bootsector needs to:

  1. start with E9 (or EB0090) <- to comply with the MS DOS 7.x (and hopefully earlier) and XP (and hopefully later) OS
  2. have anyway the Magic Bytes 55AA <- to comply with FreeDOS "quirk"
  3. since the OEM name is only checked during booting there is no need for it
  4. valid BPB data (from 0xB to 0x24)

let's go on with the eBPB:

Field                  Offset   Length
----- ------ ------
Physical Drive Number 36 1
Current Head 37 1
Signature 38 1
ID 39 4
Volume Label 43 11
System ID 54 8

  1. Physical Drive Number is seemingly only meaningful for bootable devices (so it can stay 00 for the non-bootable one)
  2. Current Head is OK left as 00 in any case, though we may add to the description it's use as "dirty flag"
  3. Signature (NT Signature) any reason to prefer 0x28 over 0x29 or viceversa? (I remember seeing only 0x29 in "real life" bootsectors) <- needed for compatibility with NT (and hopefully later)
  4. ID is this "needed" or a 00000000 would do as well?
  5. Volume Label, even if it is not used anymore it could be set to something more meaningful than the "NO NAME"?
  6. System ID: Definitely "FAT12 " or "FAT16 "

Comments, ideas?

@rloew

Can you detail any findings you may have handy about IOS.VXD and/or VFAT.VXD behaviour?

jaclaz

Share this post


Link to post
Share on other sites
rloew    93

Another scheme to enforce DRM?

Naaah, I don't think there is any conspiracy , just "normal" stupidity/crazyness :ph34r: of non-standards or undisclosed/undocumented properly ones.......

Didn't say anyone actually did, but it is another opportunity.

Back to business,

A non-bootable bootsector needs to:

  1. start with E9 (or EB0090) <- to comply with the MS DOS 7.x (and hopefully earlier) and XP (and hopefully later) OS
  2. have anyway the Magic Bytes 55AA <- to comply with FreeDOS "quirk"
  3. since the OEM name is only checked during booting there is no need for it
  4. valid BPB data (from 0xB to 0x24)

EBxx90 is OK.

Valid BPB from 0xB to 0x40 for FAT32. DOS will support a FAT32 Superfloppy, Windows will not.

let's go on with the eBPB:

Field                  Offset   Length
----- ------ ------
Physical Drive Number 36 1
Current Head 37 1
Signature 38 1
ID 39 4
Volume Label 43 11
System ID 54 8

  1. Physical Drive Number is seemingly only meaningful for bootable devices (so it can stay 00 for the non-bootable one)
  2. Current Head is OK left as 00 in any case, though we may add to the description it's use as "dirty flag"
  3. Signature (NT Signature) any reason to prefer 0x28 over 0x29 or viceversa? (I remember seeing only 0x29 in "real life" bootsectors) <- needed for compatibility with NT (and hopefully later)
  4. ID is this "needed" or a 00000000 would do as well?
  5. Volume Label, even if it is not used anymore it could be set to something more meaningful than the "NO NAME"?
  6. System ID: Definitely "FAT12 " or "FAT16 "

Comments, ideas?

Signature must be 0x29 for proper operation with Windows 9x.

ID 00000000 is OK as long as only one Partition with that ID is mounted. Windows can get confused if more than one Partition share the same ID.

System ID can be "FAT32".

@rloew

Can you detail any findings you may have handy about IOS.VXD and/or VFAT.VXD behaviour?

I've mentioned most of my related findings in the last few Posts. Most of my research was concentrated on adding Terabyte support and Large Sector support.

I haven't done much research on Floppies or SuperFloppies. There are additional Kernel components involved with them as well.

Share this post


Link to post
Share on other sites
jaclaz    943

EBxx90 is OK.

An E90000 is not? :unsure:

Valid BPB from 0xB to 0x40 for FAT32. DOS will support a FAT32 Superfloppy, Windows will not.

.....

System ID can be "FAT32".

Yep, for the moment I am still in the FAT12/16 only realm.

ID 00000000 is OK as long as only one Partition with that ID is mounted. Windows can get confused if more than one Partition share the same ID.

Yes, hopefully you have only one of these mounted at a time, but generating a "random" ID is not a problem and "safer". BTW and OT, ever heard of a "collision"? :w00t:

Signature must be 0x29 for proper operation with Windows 9x.

Let's make it 0x29 then, though I still wonder WHAT used 0x28....

I've mentioned most of my related findings in the last few Posts. Most of my research was concentrated on adding Terabyte support and Large Sector support.

I haven't done much research on Floppies or SuperFloppies. There are additional Kernel components involved with them as well.

Yep, I was trying to avoid the need to dig up a Win9x to test, but I will do it like this, I wll make the non-bootable floppy sector based on the data we have till now, and then people may be able to test an image with it on a few systems ;).

thanks for the insights. :thumbup

jaclaz

Edited by jaclaz

Share this post


Link to post
Share on other sites
rloew    93

EBxx90 is OK.

An E90000 is not? :unsure:

Of course it is. I didn't mention it because you already had it covered when you said "Start with E9".

ID 00000000 is OK as long as only one Partition with that ID is mounted. Windows can get confused if more than one Partition share the same ID.

Yes, hopefully you have only one of these mounted at a time, but generating a "random" ID is not a problem and "safer". BTW and OT, ever heard of a "collision"? :w00t:

Of course I have. Collisions are a big problem if you clone a drive and have both present. My next release of RFDISK has built in checking and repair options for Collisions.

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.

×