Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

On Superfloppies and their Images

- - - - -

  • Please log in to reply
161 replies to this topic

#126
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

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....e84/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, 11 January 2012 - 01:56 PM.

Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.


How to remove advertisement from MSFN

#127
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,651 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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:
  • make a "normal" floppy disk image with *any* bootsector starting with EB3C90 and ending with 55AA, write to it a simple .txt file.
  • remove from it any boot code (optional).
  • 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:.
  • 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:.
  • 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)
  • 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)
  • 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

Attached Files



#128
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag


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

  • 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:.
  • 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)
  • 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)
  • 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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#129
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,651 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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.ntlw...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.micro...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, 12 January 2012 - 12:56 PM.


#130
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,014 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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.

#131
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag


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.ntlw...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.micro...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?
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#132
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,651 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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:
  • start with E9 (or EB0090) <- to comply with the MS DOS 7.x (and hopefully earlier) and XP (and hopefully later) OS
  • have anyway the Magic Bytes 55AA <- to comply with FreeDOS "quirk"
  • since the OEM name is only checked during booting there is no need for it
  • 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
  • Physical Drive Number is seemingly only meaningful for bootable devices (so it can stay 00 for the non-bootable one)
  • Current Head is OK left as 00 in any case, though we may add to the description it's use as "dirty flag"
  • 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)
  • ID is this "needed" or a 00000000 would do as well?
  • Volume Label, even if it is not used anymore it could be set to something more meaningful than the "NO NAME"?
  • 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

#133
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag


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:

  • start with E9 (or EB0090) <- to comply with the MS DOS 7.x (and hopefully earlier) and XP (and hopefully later) OS
  • have anyway the Magic Bytes 55AA <- to comply with FreeDOS "quirk"
  • since the OEM name is only checked during booting there is no need for it
  • 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
  • Physical Drive Number is seemingly only meaningful for bootable devices (so it can stay 00 for the non-bootable one)
  • Current Head is OK left as 00 in any case, though we may add to the description it's use as "dirty flag"
  • 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)
  • ID is this "needed" or a 00000000 would do as well?
  • Volume Label, even if it is not used anymore it could be set to something more meaningful than the "NO NAME"?
  • 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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#134
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,651 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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, 13 January 2012 - 01:55 PM.


#135
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag


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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#136
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,651 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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.

Yes :), that is expected (collisions when cloning in some situations), I was talking of actual "by chance" collisions, more curiosity than anything else, the ID is 4 bytes, thus min 00000000 and max FFFFFFFF, i.e. 4,294,967,296 available values, but 4,294,967,296 to 1 against though pretty rare is not "nearly impossible", and since the ID/Volume serial is not "random" but is calculated, as seen on the little "reversing" spreadsheet I made:
http://www.msfn.org/...297#entry980297
chances are much bigger that that. :ph34r:

jaclaz

#137
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag


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.

Yes :), that is expected (collisions when cloning in some situations), I was talking of actual "by chance" collisions, more curiosity than anything else, the ID is 4 bytes, thus min 00000000 and max FFFFFFFF, i.e. 4,294,967,296 available values, but 4,294,967,296 to 1 against though pretty rare is not "nearly impossible", and since the ID/Volume serial is not "random" but is calculated, as seen on the little "reversing" spreadsheet I made:
http://www.msfn.org/...297#entry980297
chances are much bigger that that. :ph34r:

jaclaz

I have never noticed an accidental non-cloned collision. Since they are typically generated from the current date, a non-cloned collision can only occur in one of four ways.

1. Using a formatter that zeroes the ID or sets it to a specific value.
2. Using Partitions formatted with different algorithms. Rare unless #1 is true.
3. Sharing disks with someone else who formatted at the exact same time.
4. Formatting two partitions within a second of each other. This happened when I first added my anti-collision code to RFDISK. It updated multiple Partitions to the same ID..
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#138
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,651 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

3. Sharing disks with someone else who formatted at the exact same time.

I was saying something slightly different, the Volume serial is a form of hash of actual date/time, i.e. the same serial can be generated on different date/times.

If we use some fantasy it is not difficult to increase dramatically probabilties of a collision.

Let's say that an employee in a Swiss watchmakers company :w00t: was told to format a floppy and save to it his morning work just before lunch (or let's assume that a batch including a format command was scheduled to run every day at EXACTLY 12:30 ;)).
Notwithstanding the high level of precision of the guy (or of the scheduler) while the actual job is started exactly at 12:30,00, the actual format command is executed with a delay variable between 0 and 99 hundreths of second.
Another employee of the same company is tasked every month to store the images of the floppies, and, in order to identify them uniquely, uses the volume serial.

What will happen on August 1st, 1992? (with data of July 1992) :unsure:

The probabilities field is a highly slippery one :ph34r: , but my guess is that probabilities of a collision in this scenario are very, very high, actually you have a very high probability of having at least one collision. :w00t:

See the attached spreadsheet.....

Happy F9ing ....

jaclaz

Attached Files



#139
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,014 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

@jaclaz: I just found some minor mistakes in Known_floppies.xls: :ph34r:

The 320k formats use 1 (not 2) sectors per FAT-12, and the 360K uses 2 (not 3) sectors per FAT-12.
All FAT-12 formats above 180k and below 1.2 M use 2 sectors per cluster.

The Table below is quoted from Thom Hogan's "The Programmer's PC Sourcebook", 1st. ed., Microsoft Press, 1988 (ISBN 1-55615-118-7) Section 2, p. 61.

Attached File  Twain3.gif   68.86KB   11 downloads



#140
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,651 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

@jaclaz: I just found some minor mistakes in Known_floppies.xls: :ph34r:

That's good, can you post a copy if the spreadsheet with the corrections (manually typing the correction replacing the formula and making the cell, say, RED background?

The 320k formats use 1 (not 2) sectors per FAT-12, and the 360K uses 2 (not 3) sectors per FAT-12.

I'll check . (and see what I can do with the formula)

All FAT-12 formats above 180k and below 1.2 M use 2 sectors per cluster.

Hmmm. :unsure:

jaclaz

#141
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,014 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

Here's an interesting read: All Those Floppy Disk Formats… by Tim Paterson himself. And it's on-topic too, because it confirms 10 sectors per track is the absolute maximum for Double-Density floppies. There is a controverse point in it, however, because there Tim says that the 9-sector formats were already present in PC-DOS 1.1, which not only contradicts Undocumented DOS (as pointed out in the last comment there by os2museum) and the table by Thom Hogan I posted above, but is, in fact, a mistake, verifiable by simply running PC-DOS 1.1 format, which can only format 160 k and 320 k floppies. The 9-sector formats really were introduced with PC-DOS 2.0, and not before, although I do believe Tim's statement that they knew it was viable perhaps since PC-DOS 1.0 times.

#142
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag
I have created two new formats using 1KB Sectors. A 10 Sector per Track (1.6MB) Bootable HD Floppy and an 11 Sector per Track (1.76MB) Non-Bootable HD Floppy.
A mixed format could hold 1.759MB and be Bootable. A 1.92MB Floppy using three 4KB Sectors per Track can be created, but is very unreliable.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#143
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,651 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
Find attached a revised version of KFF spreadsheet.
I corrected the issue by "forcing" anything in the 639<n<2399 sectors size to have 2 sectors per clusters.
This leaves open a possible mistake (still to be verified) about media type 250, but I don't think it is a "real issue".
I re-added the image making part <- please do test it. and report.

The spreadsheet still misses some features, like the 2K/XP vs. DOS reserved sectors emulation for biggish images and a few more, including some switch to more finely choose label, and label type (BS, BS+FS, FS only and 08 vs. 28 type) and possibly a few more bits, but it should be basically working.
I am removing anyway the previous attachment in post #111

For NO apparent reason :w00t: attached is also a small batch to view bootsector contents and make BPB data "human redable".

Clever :unsure: parts:
  • it uses built-in FC.EXE to do the binary reading, no need for external tools ;)
  • the output (left part - hex text) can be copied and pasted directly in Tiny Hexer or similar
  • all variables are defined in the batch as seen on screen (useful for derivative work) and the FULL variable contains the hex text
  • very handy to quickly show contents of a FAT1x bootsector

Limits:
  • only XP and later
  • NOT (yet) duly tested with "strange" characters in text fields like OEM_String, Volume_Label or System_ID
  • Experimental (release 0.01 ALPHA)

Have fun. :)

jaclaz

Attachment view_bs_001.zip removed, see below.

Attached Files


Edited by jaclaz, 29 January 2012 - 11:16 AM.


#144
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,014 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

Great! :yes: Thanks! :thumbup

Bug report:

N:\>view_bs N:\noname.bs  => works as expected.
N:\>view_bs n:\noname.bs  => works as expected.
N:\>view_bs .\noname.bs  => works as expected.
N:\>view_bs \noname.bs  => works as expected.
But...
N:\>view_bs noname.bs => gives instead:
noname.bs
File "N:\noname.bs" does not exist or is not 512 bytes in size !

Press any key to continue . . .
You need to supply a target bootsector to view!

view_bs.cmd - small batch file to view BPB data of bootsectors
by jaclaz - version 0.01 ALPHA

Usage:
view_bs.cmd <FAT1x bootsector file>

Examples:
view_bs.cmd test_01.bs
view_bs.cmd C:\BS_tests\test_01.bs
view_bs.cmd "C:\A stoopidly long path containing spaces\a stoopid file name.bs"

Target bootsector file MUST be 512 bytes in size.
Press any key to continue . . .

N:\>

noname.bs is a bootsector, and is exactly 512 bytes long.
N: is a 768 MiB gavotte ramdisk
OS: Win XP SP3

Now, just in case:

C:\>view_bs noname.bs
noname.bs
File "C:\noname.bs" does not exist or is not 512 bytes in size !

Press any key to continue . . .
<etc.>


#145
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,651 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
Strange. :w00t:

It works here. :yes:
I tried in both a FAT32 and a NTFS volume (in case the issue is due to the fact that the file is stored directly in the $MFT) but it still does work.

Try replacing:

IF NOT EXIST %1 GOTO :ERROR1
FOR /F "tokens=3" %%A IN ('DIR "%~1"^|FIND /I "%~1"') DO IF NOT %%A==512 GOTO :ERROR1

with:

IF NOT EXIST "%~dpnx1" GOTO :ERROR1
FOR /F "tokens=3" %%A IN ('DIR "%~nx1"^|FIND /I "%~nx1"') DO IF NOT %%A==512 GOTO :ERROR1

but it shouldn't make any difference :unsure:.

Create an :ERROR2 at the end

:Error2
ECHO 2 File "%~dpnx1" does not exist or is not 512 bytes in size 2^^!
ECHO.
PAUSE
GOTO :Usage

and change one of the the two lines to point to :ERROR2 instead of :ERROR1, let's see which one creates the exception.

Post the output of:

DIR noname.bs


Try replacing:

FOR /F "tokens=3" %%A IN ('DIR "%~nx1"^|FIND /I "%~nx1"') DO IF NOT %%A==512 GOTO :ERROR1

with:

IF NOT "%~z1."=="512." GOTO :ERROR1


jaclaz

Edited by jaclaz, 28 January 2012 - 04:53 AM.


#146
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,014 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

Strange. :w00t:

It works here. :yes:
I tried in both a FAT32 and a NTFS volume (in case the issue is due to the fact that the file is stored directly in the $MFT) but it still does work.

Try replacing:

IF NOT EXIST %1 GOTO :ERROR1
FOR /F "tokens=3" %%A IN ('DIR "%~1"^|FIND /I "%~1"') DO IF NOT %%A==512 GOTO :ERROR1

with:

IF NOT EXIST "%~dpnx1" GOTO :ERROR1
FOR /F "tokens=3" %%A IN ('DIR "%~nx1"^|FIND /I "%~nx1"') DO IF NOT %%A==512 GOTO :ERROR1

but it shouldn't make any difference :unsure:.

Yet it does:

N:\>nview_bs n:\noname.bs
n:\noname.bs
File "n:\noname.bs" does not exist or is not 512 bytes in size !

Press any key to continue . . .
Terminate batch job (Y/N)? y

N:\>nview_bs N:\noname.bs
N:\noname.bs
File "N:\noname.bs" does not exist or is not 512 bytes in size !

Press any key to continue . . .
Terminate batch job (Y/N)? y

N:\>nview_bs .\noname.bs
.\noname.bs
File "N:\noname.bs" does not exist or is not 512 bytes in size !

Press any key to continue . . .
Terminate batch job (Y/N)? y

N:\>nview_bs \noname.bs
\noname.bs
File "N:\noname.bs" does not exist or is not 512 bytes in size !

Press any key to continue . . .
Terminate batch job (Y/N)? y

N:\>nview_bs noname.bs
noname.bs
File "N:\noname.bs" does not exist or is not 512 bytes in size !

Press any key to continue . . .
Terminate batch job (Y/N)? y


#147
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,014 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

Now, using instead:

IF NOT EXIST %1 GOTO :ERROR1
FOR /F "tokens=3" %%A IN ('DIR "%~1"^|FIND /I "%~1"') DO IF NOT %%A==512 GOTO :ERROR2
I get:

N:\>eview_bs noname.bs
noname.bs
2 File "N:\noname.bs" does not exist or is not 512 bytes in size 2!

Press any key to continue . . .
Terminate batch job (Y/N)? y
All the other forms work, obviously, since they already did before...

N:\>DIR noname.bs
 Volume in drive N is RamDisk
 Volume Serial Number is 1234-5678

 Directory of N:\

28/01/2012  04:49 PM               512 noname.bs
               1 File(s)            512 bytes
               0 Dir(s)     804,265,984 bytes free


#148
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,014 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

Try replacing:

FOR /F "tokens=3" %%A IN ('DIR "%~nx1"^|FIND /I "%~nx1"') DO IF NOT %%A==512 GOTO :ERROR1

with:

IF NOT "%~z1."=="512." GOTO :ERROR1

:D

N:\>oview_bs noname.bs
noname.bs
EB 27 90 03 01 14 00 00 00 00 00 00 02 02 01 00 Jump_Bytes:        EB2790
02 70 00 80 02 FF 01 00 08 00 02 00 00 00 00 00 OEM_String:      "........"
00 00 00 00 00 00 00 CD 19 FA 8C C8 8E D8 33 D2 Bytes_per_Sector:    512
8E D2 BC 00 7C FB B8 60 00 8E D8 8E C0 33 D2 8B Sectors_per_Cluster: 2
C2 CD 13 72 69 E8 85 00 72 DD 2E 83 3E 03 7C 08 Reserved_Sectors:    1
74 06 2E C6 06 64 7D 02 BB 00 00 2E 8B 0E 03 7C Number_of_FATs:      2
51 B0 09 2A C1 B4 00 8B F0 56 33 D2 33 C0 8A C5 Max_Root_Entries:    112
2E F6 36 64 7D 8A E8 8A F4 8B C6 B4 02 CD 13 72 Small_Type_Sectors:  640
2D 5E 59 2E 29 36 05 7C 74 1F 8B C6 2E F7 26 65 Media_Type:          255
7D 03 D8 FE C5 B1 01 51 BE 08 00 2E 3B 36 05 7C Sectors_per_Fat:     1
7C 05 2E 8B 36 05 7C EB C0 EA 00 00 60 00 BE 67 Sectors_per_Head:    8
7D E8 02 00 EB FE 32 FF 2E AC 24 7F 74 0B 56 B4 Sectors_Before:      0
0E BB 07 00 CD 10 5E EB EF C3 E9 33 FF BB 00 00 Large_Sectors:       0
B9 04 00 B8 01 02 CD 13 1E 72 33 8C C8 8E D8 BF Disk_Number:         0
00 00 B9 0B 00 26 80 0D 20 26 80 4D 20 20 47 E2 Current_head:        0
F4 BF 00 00 BE 8B 7D B9 0B 00 FC F3 A6 75 0F BF NT_Signature:        0
20 00 BE 97 7D B9 0B 00 F3 A6 75 02 1F C3 BE 1B Volume_Serial:      CD19FA8C
7D E8 A2 FF B4 00 CD 16 1F F9 C3 0D 0A 4E 6F 6E Volume_Label:     "3.|"
2D 53 79 73 74 65 6D 20 64 69 73 6B 20 6F 72 20 System_ID:        "`.3"
64 69 73 6B 20 65 72 72 6F 72 0D 0A 52 65 70 6C Magic_bytes:        55AA
61 63 65 20 61 6E 64 20 73 74 72 69 6B 65 20 61
6E 79 20 6B 65 79 20 77 68 65 6E 20 72 65 61 64
79 0D 0A 00 01 00 02 0D 0A 44 69 73 6B 20 42 6F
6F 74 20 66 61 69 6C 75 72 65 0D 0A 00 4D 69 63
72 6F 73 6F 66 74 2C 49 6E 63 20 69 62 6D 62 69
6F 20 20 63 6F 6D 30 69 62 6D 64 6F 73 20 20 63
6F 6D 30 05 C6 06 77 2F FF 83 7E FC 00 75 0B 80
7E F7 3B 75 05 C6 06 76 2F FF 89 EC 5D CA 04 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
All other forms also work, of course (but I tested them, all the same).
Here's noname.bs, just in case:

Attached Files



#149
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,651 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

All the other forms work, obviously, since they already did before...

N:\>DIR noname.bs
 Volume in drive N is RamDisk
 Volume Serial Number is 1234-5678

 Directory of N:\

28/01/2012  04:49 PM               512 noname.bs
               1 File(s)            512 bytes
               0 Dir(s)     804,265,984 bytes free

Here it is :unsure::

28/01/2012 04:49 PM 512 noname.bs

With your settings size is 4th token (and not 3rd which happens when you have 24h time set).
But then why the other forms of filename work baffles me.

Attached version 002 with the %~z1 approach, please re-test, so that I can remove version 001.

jaclaz

Attachment removed, see below.

Edited by jaclaz, 29 January 2012 - 11:16 AM.


#150
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,014 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

Yes. The new version works beautifully! You may remove the previous one. :yes:




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users