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

#76
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,087 posts
  • OS:98SE
  • Country: Country Flag

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

#77
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,844 posts
  • OS:98SE
  • Country: Country Flag

Donator


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:

#78
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,225 posts
  • OS:none specified
  • Country: Country Flag

'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.ntlw...name-field.html
the issues are TWO as I see it:
  • some boot code will check it nonetheless
  • 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...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, 12 August 2011 - 04:38 AM.


#79
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,844 posts
  • OS:98SE
  • Country: Country Flag

Donator

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

#80
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,225 posts
  • OS:none specified
  • Country: Country Flag

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.goog...boot.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, 12 August 2011 - 04:39 AM.


#81
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,225 posts
  • OS:none specified
  • Country: Country Flag
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" :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

Attached Files



#82
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,844 posts
  • OS:98SE
  • Country: Country Flag

Donator

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

#83
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,087 posts
  • OS:98SE
  • Country: Country Flag
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.
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.

#84
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,225 posts
  • OS:none specified
  • Country: Country Flag

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

#85
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,225 posts
  • OS:none specified
  • Country: Country Flag
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 Posted Image, though :whistle:.

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

jaclaz

Attached Files



#86
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,254 posts
  • OS:98SE
  • Country: Country Flag
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.

#87
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,844 posts
  • OS:98SE
  • Country: Country Flag

Donator

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:

#88
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,225 posts
  • OS:none specified
  • Country: Country Flag
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.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...ial Numbers.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

Attached Files



#89
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,225 posts
  • OS:none specified
  • Country: Country Flag
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. :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

#90
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,087 posts
  • OS:98SE
  • Country: Country Flag

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

#91
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,844 posts
  • OS:98SE
  • Country: Country Flag

Donator

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.

#92
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,087 posts
  • OS:98SE
  • Country: Country Flag

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

#93
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,844 posts
  • OS:98SE
  • Country: Country Flag

Donator

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.

#94
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,087 posts
  • OS:98SE
  • Country: Country Flag

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

#95
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,844 posts
  • OS:98SE
  • Country: Country Flag

Donator

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.

#96
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,225 posts
  • OS:none specified
  • Country: Country Flag
OK, I'll dump the 1232K and 1280K formats. :thumbup
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 :ph34r: , 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? :unsure:
Additionally (and regarding both the 640K and the two 320 K):
Did they ever existed formatted in FAT12?

jaclaz

Edited by jaclaz, 01 November 2011 - 04:50 AM.


#97
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,844 posts
  • OS:98SE
  • Country: Country Flag

Donator

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

#98
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,225 posts
  • OS:none specified
  • Country: Country Flag
Very good. :thumbup

Still an issue :( : Media Type :ph34r: :
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? :w00t:
The 640K should be 251/FB. :unsure: Can anyone confirm this?

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

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 :blushing: ):
http://msdn.microsof...1(v=vs.85).aspx

jaclaz

#99
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,844 posts
  • OS:98SE
  • Country: Country Flag

Donator

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.

#100
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,087 posts
  • OS:98SE
  • Country: Country Flag

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




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN