dencorso

On Superfloppies and their Images

162 posts in this topic

Another question you posed and that remained unanswered:

The MS standard (fatgen.pdf v. 1.03) has BPB_TotSec16 for BPB+0x10 and BPB_TotSec32 for BPB+0x1D, and I think this is good, in that it does not create ambiguity. I do think "Total Sectors (16)" and "Total Sectors (32)" are good labels. Of course, everybody else will disagree, but life is like that. :}

As far as I know the OEM Field at Offset 3 is not part of the BPB. The BPB that is used internally starts at Offset 0xB. That would make the two fields above BPB+8 and BPB+0x11 respectively.

Total Sectors (16) takes priority over Total Sectors (32) so only one is relevant in any given situation. I just list "Total Sectors" in my Software as having both would be an invalid combination.

Due to bugs in the standard Boot Code and extended features I have added, I have my own Versions of the Boot Codes as well.

0

Share this post


Link to post
Share on other sites

Another question you posed and that remained unanswered:

The MS standard (fatgen.pdf v. 1.03) has BPB_TotSec16 for BPB+0x10 and BPB_TotSec32 for BPB+0x1D, and I think this is good, in that it does not create ambiguity. I do think "Total Sectors (16)" and "Total Sectors (32)" are good labels. Of course, everybody else will disagree, but life is like that. :}

As far as I know the OEM Field at Offset 3 is not part of the BPB. The BPB that is used internally starts at Offset 0xB. That would make the two fields above BPB+8 and BPB+0x11 respectively.

Very true. You're right, of course. :yes:

0

Share this post


Link to post
Share on other sites

've revised the bootsector sheets and they are correct, byte-by-byte. An interesting fact is that, when the FreeDOS bootsector is compared to the one present in the released floppy image version of FreeDOS 1.0 Final (2006-08-11), the bootstrap code in both is identical, but they have different OEM names, the one in your worksheet using the already classic FreeDOS, while the FreeDOS 1.0 Final (2006-08-11) floppy has "LINUX4.1" (attached).

Yes/No. :unsure:

I just tested, see here:

http://reboot.pro/15123/

the FreeDOS and it has another OEM name, FRDOS4.1. :w00t:

You can call the 2nd sector whatever you want :), but if the theme is "making a filesystem from scratch" you will have to create the 2nd sector too. ;)

About the OEM field being part or not (it is not) of the BPB (already cited):

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

the issues are TWO as I see it:

  1. some boot code will check it nonetheless
  2. the stoopid volume tracker of WIn9x/Me writes "crazy" OEM names

a good example of the latter is the DOS 8.0/WinME floppy embedded in XP/2003's diskcopy.dll:

http://www.911cd.net/forums//index.php?showtopic=16745

*-v4VIHC

I have no idea if it can happen that it creates non-batch compatible string (like one containing ! or & or <>, etc.) :ph34r:

Stiil trying to get an agreement:

  • Size in sectors (small-16)
  • Size in sectors (large-32)

or

  • Number of sectors (small-16)
  • Number of sectors (large-32)

(just to be homogenous with other field names, you don't have "Total FAT(s)" or "Total Heads" ....)

jaclaz

Edited by jaclaz
0

Share this post


Link to post
Share on other sites
  • Number of sectors (small-16)
  • Number of sectors (large-32)

I agree to the above, gladly.

The image that has "LINUX4.1" is bona-fide: see for yourself <link>

the stoopid volume tracker of WIn9x/Me writes "crazy" OEM names

It can be prevented in virtually all cases by adding these three binary values:

All disks 02 00 90

Every disk FE 01 55 AA

PC-DOS1 00 00 EB 2F 14

to the key:

MyComputer\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\NoVolTrack

For more details see this post elsewhere, and, of course, KB148637.

0

Share this post


Link to post
Share on other sites

The image that has "LINUX4.1" is bona-fide: see for yourself <link>

Yep, I was not doubting it in the least :), only re-marking that our good FreeDOS friends have not much "order" or "tidyness" in what they release.

As soon as the good guys at reboot.pro will have finished playing with the board in order to make it "better" (please read as "ruining senselessly an otherways perfectly working setup to add some completely unneeded eye-candy" :whistle:) you will be able to have a look at what I needed to do in order to get a "right" SYS.COM.

Here is a google cache:

http://webcache.googleusercontent.com/search?q=cache:W6Y1ReYKsDsJ:reboot.pro/15123/

Fixed (seemingly):

http://reboot.pro/15123/

After my little odissey (and probably somehow thanks to it ;)), the file was fixed, thanks to the good FreeDOS guy :thumbup , and the current version (august 10, 2011):

http://www.fdos.org/kernel/sys/

has also RX-DOS and DE (stoopid Dell RMK):

/OEM : indicates boot sector, filenames, and load segment to use

/OEM:FD use FreeDOS compatible settings

/OEM:DR use DR DOS 7+ compatible settings (same as /OEM)

/OEM:PC use PC-DOS compatible settings

/OEM:MS use MS-DOS compatible settings (up to 6.x)

/OEM:W9x use MS Win9x DOS compatible settings (7.x+)

/OEM:Rx use RxDOS compatible settings

/OEM:DE use DEll Real Mode Kernel settings

default is /OEM:AUTO, select DOS based on existing files

About Volume track, sure :), that key is useful to set it in "your own" Win9x/Me, I was trying to say that most people won't have it, and thus you can easily get an image (or bootsector) with "absurd" OEM field contents (and the original MS floppy image mixup is a proof of how common this can be, basically any "MS-DOS floppy" made on XP the "standard way" will have such a botched OEM).

jaclaz

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

In the course of an only seemingly unrelated test I made, I found a few "quirks" that need to be taken into account.

In the attachment there are 4 image files.

All of them are exactly 1,475,072 bytes in size, i.e. the "standard" 1.44 Mb floppy + 1 sector (for the MBR).

They represent (or should represent) a very small hard disk image.

They were created as follows:

fsz hdfloppy.img 1475072

(this created an empty files filled with 00's of the exact size).

After having filled partition table first entry manually and the "Magic bytes" (and adding a dummy disk signature of 12345678 - you never know) I saved the image as:

hdfloppyUF.img i.e. UnFormatted

I mounted a copy of hdfloppyUF.img in VSS services and formatted the volume with the Windows XP Format.

this is hdfloppyFVSS.img i.e. Formatted under VSS

I mounted a copy of hdfloppyUF.img IMDISK as "Auto" - it resulted as "Floppy" - formatted it with the IMDISK Format option (that however calls Windows Format)

this is hdfloppyFIMF.img i.e. Formatted under IMdisk as Floppy

I mounted a copy of hdfloppyUF.img IMDISK as "Hard Disk Volume", formatted it with the IMDISK Format option (that however calls Windows Format)

this is hdfloppyFIMHV.img i.e. Formatted under IMdisk as HardDisk Volume.

Preliminary notes:

Under IMDISK (obviously since the MBR is "skipped alltogether") the MBR partition table is left "as it was" (partition type 01)

Under VSS the Windows Format does a strange thing, which I already noticed in other occasions with partition type 06, see here:

http://reboot.pro/3191/page__st__26

the partition type is changed to 0E which confirms something between the lines of this:

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/determining-filesystem-type.html

it seems like WIndows XP attempts to "protect" the very common FAT12 01 type from being accessed by older filesystems, since it sets a 0E type, it "cuts off" MS-DOS <=6.22

I thought that this was only 06->0E but evidently the new paradigm is something like "anything FAT1x is 0E" :w00t::ph34r:

The number of "Reserved sectors" IN BOTH hdfloppyFVSS.img and hdfloppyFIMHV.img are 6 instead of the usual 1 (but it of course remains 1 in hdfloppyFIMF.img.

This can affect the spreadsheet/batch/Drugwash's app behaviour when selecting the F0 (240) or F8 (248) media.

The hdfloppyFIMHV.img sets correctly "Sectors Before" (1) and (maybe) "Sectors per track" (63) - this could be a "defaulT" needs to ask Olof - but gives a (wrong) Number of Heads (1).

The hdfloppyFVSS.img sets correctly "Sectors Before" (1) but NOT "Sectors per track" (1) and gives a (wrong) Number of Heads (1).

this is hdfloppyFIMF.img does not set (comprehensibly) "Sectors Before", that remain 0, and sets "Sectors per track" (18) and "Number of Heads" (2) correctly, but his probably is because of some hardcoded in FORMAT, this test must be repeated with a non-standard floppy size.

As always ideas, comments, suggestions, further tests and reports are welcome. :)

jaclaz

hdfloppy.7z

0

Share this post


Link to post
Share on other sites

You've created perhaps the most uncanny disk image I've ever heard of, in that it has 2,881 sectors! I think most if not all "normal" disks have an even sector number. dubbio.gif

Yet I don't think it ought to affect in any way your interesting findings.

But, just to stay on the safe side, would you try it with a full unused 1st track, but for the MBR (that is, the MBR plus 17 unused sectors before the partition)?

I'd do it myself, but I won't be able to, since I'll have some errands to make right away, sorry...

0

Share this post


Link to post
Share on other sites

I have added an Image Option to the next release of my RFORMAT Program. This will create a truncated Image File for any of the recognized formats and options in one step.

0

Share this post


Link to post
Share on other sites

But, just to stay on the safe side, would you try it with a full unused 1st track, but for the MBR (that is, the MBR plus 17 unused sectors before the partition)?

I'd do it myself, but I won't be able to, since I'll have some errands to make right away, sorry...

Naah, it would be unconnected.

The image was made with an arbitrary HS of 64/32, but was mounted on VSS (which should default to 255/63).

I will try with VDK and with a .pln descriptor, to see if it makes any difference, but I don't think so, the relevant parts should remain unchnaged:

  1. 6 Reserved sectors instead of 1
  2. 01->0E ( and as said the 06->0E was already confirmed on a completely different occasion and using an "orhtodox" disk image and HS geometry)

jaclaz

0

Share this post


Link to post
Share on other sites

Tried with a more "orthodox" image, see attached HTML PTVIEW.

The third partition, exactly 1 cylinder in size, and default 255/63 HS geometry is FAT12 (and keeps the 01 Partition Type).

Actually I made this by re-formatting the partition (already formatted as NTFS) in Explorer.

The actual "virtual device" has anyway an odd number of sectors harhar.gif, though :whistle:.

The number of "reserved sectors" were made to 8 this time. :w00t::ph34r:

jaclaz

PTVIEW.html

0

Share this post


Link to post
Share on other sites

Nice job moving my posts to this topic: reply subscription has gone with the wind and the topic slipped through the cracks of my mind.

However, I have not worked on BootMaker in a long time, being busy with other projects and that crappy thing called "real life". Looks like the topic has not returned from the summer holiday though. I mainly posted now to make sure I get back the reply subscription, so don't sweat it.

0

Share this post


Link to post
Share on other sites

Sorry for the collateral damage (your reply subscription)! :(

All that moving posts around was a complicated thing to do, which I hope I won't need to do ever again...

I keep interested in this thread, of course, but I think we've made a lot of progress already, then other matters became more pressing... and "real life" intervened, too.

But I trust this tread is on hiatus, but still alive. :yes:

0

Share this post


Link to post
Share on other sites

The topic is not dead. :no:

No "real" news on the Excel thingy, I have found (on another board) a willing member that proposed to correct/better/refine it.

Unfortunately, although he produced a very good work, expecially in correcting a few formulas that were wrong, he changed it so deeply (and in some cases IMHO senselessly) that the final result (which is not actually final anyway) has diverged from the original goal I had set (in my perverted mind) and is IMHO as-is UNusable/UNuseful.

Due to the divergencies between us the development has stopped abruptly. :(

In the meantime and as "side-apps", I have developed two pretty much useless spreadsheets. :w00t:

One is the (hopefully) final version of the thingy discused here:

http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=2134

And the other one is simply a calculator for Volume Serial.

I wish to thank for the insights Craig Wilson, Author of this nice .pdf:

http://www.digital-detective.co.uk/

http://www.digital-detective.co.uk/documents/Volume%20Serial%20Numbers.pdf

In the tradition of my half-@§§ed spreadsheets, they are protected (to avoind unwantingly typing where you really shouldn't) but with blank password and there is NOT any actual instruction on the use of them, basically if you cannot figure out what they are for and how they work it means you don't *need* to use 'em ;).

An interesting side-note is that I wasn't able to enter the (rather complex) formula in cells B17 and B33 of "volser.xls" in Excel (Office "XP") and as well I cannot actually edit it in this version of Excel.

Using Spread32, in all the beauty of it's 1,458,176 bytes, I had no problems whatsoever. :whistle:

jaclaz

date_from_volser.zip

Volser.zip

0

Share this post


Link to post
Share on other sites

Delving deeper in the various "strange" floppy formats around, I have hit a couple of "oddities".

The "640K" format seems like having incorrect info.

According to my calculations it should have 80/2/8 geometry and 2x4 FAT Sectors (IF it has a cluster size of 1 sector) or 2x2 FAT sectors (IF it has a clustersize of 2 sectors).

In any case it should have a sector size of 512 bytes.

The actual VERY scarce docs I can find seem however to convey that the sector size is/was different, i.e. 256 bytes.

Some folks (and particularly Multibooter) may appreciate this .pdf:

http://www.tamsinc.com/storage/2085/support/2085man.pdf

Of course it is possible to "invent" both the above described formats, but did they ever exist (formatted in FAT12, I mean)?

Something similar happens for the two sizes marked 1232K (JPN) and 1280K (JPN):

Theyshould be connected with the PC98:

http://en.wikipedia.org/wiki/List_of_floppy_disk_formats

http://en.wikipedia.org/wiki/NEC_PC-9801

http://euc.jp/articles/pc9800.en.html

Whilst on them the "math" seems OK, I am failing to understand how they were actually formatted, as they had a 1024 bytes sector size.

Is the bootsector made by the "normal" 512 bytes and followed by 512 00's to fill the 1024 byte sector?

I am starting to suspect that anything with a sector size different from 512 bytes either never was formatted with FAT12/16 or used modified *something* and that in any case it won't be of any practical use as an image. :unsure:

Or if you prefer, I am thinking to remove these three image formats from the list of known formats, AND to remove any support for sector size different from 512 bytes.

jaclaz

0

Share this post


Link to post
Share on other sites

Delving deeper in the various "strange" floppy formats around, I have hit a couple of "oddities".

The "640K" format seems like having incorrect info.

According to my calculations it should have 80/2/8 geometry and 2x4 FAT Sectors (IF it has a cluster size of 1 sector) or 2x2 FAT sectors (IF it has a clustersize of 2 sectors).

In any case it should have a sector size of 512 bytes.

The actual VERY scarce docs I can find seem however to convey that the sector size is/was different, i.e. 256 bytes.

Some folks (and particularly Multibooter) may appreciate this .pdf:

http://www.tamsinc.com/storage/2085/support/2085man.pdf

Of course it is possible to "invent" both the above described formats, but did they ever exist (formatted in FAT12, I mean)?

Something similar happens for the two sizes marked 1232K (JPN) and 1280K (JPN):

Theyshould be connected with the PC98:

http://en.wikipedia.org/wiki/List_of_floppy_disk_formats

http://en.wikipedia.org/wiki/NEC_PC-9801

http://euc.jp/articles/pc9800.en.html

Whilst on them the "math" seems OK, I am failing to understand how they were actually formatted, as they had a 1024 bytes sector size.

Is the bootsector made by the "normal" 512 bytes and followed by 512 00's to fill the 1024 byte sector?

I am starting to suspect that anything with a sector size different from 512 bytes either never was formatted with FAT12/16 or used modified *something* and that in any case it won't be of any practical use as an image. :unsure:

Or if you prefer, I am thinking to remove these three image formats from the list of known formats, AND to remove any support for sector size different from 512 bytes.

jaclaz

The link you gave appears to be for a proprietary HP disk format, so anything goes. The 640KB PC Format was 512 Byte Sectors with 80/2/8 Geometry. 256 Byte Sectors cannot be supported without extensive modifications. I have patched DOS to handle up to 32KB Sectors, and Windows 9x to handle 4KB Sectors. Unmodified Windows 9x will read a 2KB/Sector FAT Partition if it is on a CD. The USB based 3TB Hard Drives use 4KB/Sector, to avoid the 32Bit Address Limt, so a minor Patch is needed to use them.

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.