[jaclaz]

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.ntlw...ystem-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"


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

Attached File(s)

•  hdfloppy.7z (1.7K)
  Number of downloads: 4

[dencorso]

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

[rloew]

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.

[jaclaz]

dencorso, on 21 August 2011 - 01:21 PM, said:

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:

• 6 Reserved sectors instead of 1
  
• 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

[jaclaz]

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 , though .

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

jaclaz

Attached File(s)

•  PTVIEW.html (7.22K)
  Number of downloads: 18

[Drugwash]

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.

[dencorso]

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.

[jaclaz]

The topic is not dead.

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.

One is the (hopefully) final version of the thingy discused here:
http://www.forensicf...iewtopic&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-d...l%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.

jaclaz

Attached File(s)

•  date_from_volser.zip (62.49K)
  Number of downloads: 18
•  Volser.zip (17.17K)
  Number of downloads: 18

[jaclaz]

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.c...ort/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....py_disk_formats
http://en.wikipedia....iki/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.

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

[rloew]

jaclaz, on 31 October 2011 - 06:53 AM, said:

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.c...ort/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....py_disk_formats
http://en.wikipedia....iki/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.

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.

[dencorso]

The 640K floppies used 512 byte sectors, and were 80/2/8. They were just a 80 cylinder version (DSHD) of the original 320K format. And they used 2 sectors/cluster. I don't see any reason to remove support for this image format, as it's uncommon but "well behaved".

The 1232K (JPN) and 1280K (JPN) were really unusual formats, used by the NEC PC-98 family.
I've read that they can be read from DOS, when one has a 3-mode FDD. I have no info as to whether it was actually possible to boot DOS from them, but I think it unlikely. Furthermore, I have no objection to removing support for those two (really odd) image formats.

[rloew]

dencorso, on 31 October 2011 - 05:12 PM, said:

The 640K floppies used 512 byte sectors, and were 80/2/8. They were just a 80 cylinder version (DSHD) of the original 320K format. And they used 2 sectors/cluster. I don't see any reason to remove support for this image format, as it's uncommon but "well behaved".

The 1232K (JPN) and 1280K (JPN) were really unusual formats, used by the NEC PC-98 family.
I've read that they can be read from DOS, when one has a 3-mode FDD. I have no info as to whether it was actually possible to boot DOS from them, but I think it unlikely. Furthermore, I have no objection to removing support for those two (really odd) image formats.

I would assume the 1280K is readable. The 1232K should also be readable if the track spacing is not modified. Assuming 512B Sectors, and readability, you should be able to boot from them.

[dencorso]

That's precisely the problem, RLoew: the track spacing is standard, however they don't use 512B sectors, but 1024B sectors instead.

1.25M (1232K)
-----------------------------
JPN Standard;   Type: 5.25 Inch.
77  Tracks;    8 Sectors/Track;
1   Sector/Cluster; *1024 bytes/sector*;
224 Root directory entries;
1,232  Total sectors on disk;
1,249,280 Bytes available for files.

1.28M (1280K)
-----------------------------
JPN NonStandard;   Type: 5.25 Inch.
80  Tracks;    8 Sectors/Track;
1   Sector/Cluster; *1024 bytes/sector*;
224 Root directory entries;
1,280  Total sectors on disk;
1,298,432 Bytes available for files.

jaclaz is implicitly referring to a list of supported floppy formats included in the floppy image creating spreadsheet he created (the latest version of which is some posts above). That list derives from various sources, including a list of floppy formats I compiled from many sources (and posted previously in the Floppy Emulation thread), from which I quoted the above excerpt.

[rloew]

dencorso, on 31 October 2011 - 11:32 PM, said:

That's precisely the problem, RLoew: the track spacing is standard, however they don't use 512B sectors, but 1024B sectors instead.

1.25M (1232K)
-----------------------------
JPN Standard;   Type: 5.25 Inch.
77  Tracks;    8 Sectors/Track;
1   Sector/Cluster; *1024 bytes/sector*;
224 Root directory entries;
1,232  Total sectors on disk;
1,249,280 Bytes available for files.

1.28M (1280K)
-----------------------------
JPN NonStandard;   Type: 5.25 Inch.
80  Tracks;    8 Sectors/Track;
1   Sector/Cluster; *1024 bytes/sector*;
224 Root directory entries;
1,280  Total sectors on disk;
1,298,432 Bytes available for files.

jaclaz is implicitly referring to a list of supported floppy formats included in the floppy image creating spreadsheet he created (the latest version of which is some posts above). That list derives from various sources, including a list of floppy formats I compiled from many sources (and posted previously in the Floppy Emulation thread), from which I quoted the above excerpt.

A low level driver would be able to read and write 1K Sectors but I doubt that the BIOS would try Sector sizes other than 512B. None of my BIOSes would even handle the 4K Sectors of my USB 3TB Hard Drive.
This would make the Disks unbootable without an alternate Device based DDO.

[dencorso]

Yeah, that's what I think, too. That's why I agree those 1024B sector formats should be removed from the floppy image creating spreadsheet. While they may be of historical interest, they are useless for boot floppies.

[jaclaz]

OK, I'll dump the 1232K and 1280K formats.
More generally only 512 Bytes/Sectors will be included (besides the booting aspect, I suspect that non 512 bytes/sector formats would have anyway problems in VM's and/or Virtual Drives).
For the record there are the 8.00" floppy formats:
http://support.micro.../kb/75131/en-us
that do have a different sector size, and they will be ignored also.


About the 640 Kb, it is OK as 80/2/8, and with 512 bytes/sector and with 112 Root Entries, I only wanted a confirmation that it has EITHER:

• Cluster size of 2 sectors and THEN a FAT of 2 sectors
  

  Floppy Formats	Size	Sectors	C	H	S	B/S	S/C	Re	Mt	Fatsize
  640K 	 655.360 	1.280	80	2	8	512	2	112	251	2
  

  
  
  OR:
  
• Cluster size of 1 sector and THEN a FAT of 4 sectors
  

  Floppy Formats	Size	Sectors	C	H	S	B/S	S/C	Re	Mt	Fatsize
  640K 	 655.360 	1.280	80	2	8	512	1	112	251	4
  

The issue is probably derived by a typo , as often happens when assembling together different sources with different data and trying to fill the gaps.

Another issue I am having is that in the list *appeared* (somehow) two different 320 K formats:

 
Floppy Formats	Size		Sectors	C	H	S	B/S	S/C	Re	Mt	Fatsize
320K (80/1/8) 	 327.680 	640	80	1	8	512	1	?	250	1
320K (40/2/8) 	 327.680 	640	40	2	8	512	1	112	255	1

Are they BOTH valid?
If yes, how many root entries in the 80/1/8 version? 64 or 112?
Additionally (and regarding both the 640K and the two 320 K):
Did they ever existed formatted in FAT12?

jaclaz

This post has been edited by jaclaz: 01 November 2011 - 04:50 AM

[dencorso]

The 640K size is the 8 sectors per track version of the common 720K size, from a time drives (or media) couldn't do 9 sectors per track reliably. It was the first format standard for the 3.5" floppies.
So, yes, 2 Sectors/Cluster and THEN a FAT of 2 sectors. It survived longer in Japan, but was used worldwide for a very short time.

The 320K size is the 2 sided version of the old 160K size, both also from a time drives (or media) couldn't do 9 sectors per track reliably.
So, yes, 2 heads and 40 tracks. It was the second format to be officially supported by PC-DOS, being introduced with v. 1.10. All later DOS versions support it natively up to V. 8.00, and I bet all Win NTs up to at least XP also do. And all DOS versions but 1.00 can boot from it.

So, yes, both the above existed in the wild as FAT-12 floppies, although the 640K never made it to the list of formats supported by DOS FORMAT. Of course, v. 7.xx and 8.00 should boot OK from a 640K floppy.

I think I once read a mention to a single-sided 80 track version of a 320K floppy in a post by Multibooter (yet I may be wrong), but that's the only reference I can think of for it, and it sure was never a common DOS floppy format. I'm positive this format can be dropped too. The sole single-sided formats that need support are 160K and 180K, because they are standard from very early on, which support was never dropped. I do still have a working MS-DOS 5.00 160K boot floppy I created just for fun more than 10 years ago. I've just booted from it and chkdsked it, to confirm it still works, while writing this.

[jaclaz]

Very good.

Still an issue : Media Type :
We have (for sure) the 3.5" "official" formats (as per given link on MS)

720K	1.44 MB	2.88 MB
F9	F0	F0
249	240	240

and the "official" 5.25" ones:

160K	180K	320K	360K	1.2 MB
FE	FC	FF	FD	F9
254	252	255	253	249

In the list *appeared" the 320K 80/1/8 with a Media Type of 250/FA. Is this possible?
The 640K should be 251/FB. Can anyone confirm this?

Maybe I found where I got some of the info:
http://www.win.tue.n.../fat/fat-1.html

Quote

Media descriptor byte

The ancient media descriptor type codes are:
For 8" floppies:
fc, fd, fe - Various interesting formats

For 5.25" floppies:
Value DOS version Capacity sides tracks sectors/track
ff 1.1 320 KB 2 40 8
fe 1.0 160 KB 1 40 8
fd 2.0 360 KB 2 40 9
fc 2.0 180 KB 1 40 9
fb 640 KB 2 80 8
fa 320 KB 1 80 8
f9 3.0 1200 KB 2 80 15

For 3.5" floppies:
Value DOS version Capacity sides tracks sectors/track
fb 640 KB 2 80 8
fa 320 KB 1 80 8
f9 3.2 720 KB 2 80 9
f0 3.3 1440 KB 2 80 18
f0 2880 KB 2 80 36

For RAMdisks:
fa

For hard disks:
Value DOS version
f8 2.0
This code is also found in the first byte of the FAT.

IBM defined the media descriptor byte as 11111red, where r is removable, e is eight sectors/track, d is double sided.

OT, but not that much , this may open some new "formats" (which I didn't even suspect existed ):
http://msdn.microsof...1(v=vs.85).aspx

jaclaz

[dencorso]

Well, I guess you've got the Media Type Byte figured all right.
And since fa 320 KB 1 80 8 is bona-fide, I guess it should be include, despite being super-obscure.
But I still think support for non-512B sectored formats is unneeded, even if they are documented enough.

[rloew]

dencorso, on 01 November 2011 - 09:24 PM, said:

Well, I guess you've got the Media Type Byte figured all right.
And since fa 320 KB 1 80 8 is bona-fide, I guess it should be include, despite being super-obscure.
But I still think support for non-512B sectored formats is unneeded, even if they are documented enough.

I have a working 1KB Sector Floppy Disk with only a few additional mods needed.
As I expected the BIOS will not boot the Disk, but a slightly non-standard format may make it possible to boot, if I can solve an internal Disk Geometry problem.