All 3½-inch disks have a rectangular hole in one corner which, if obstructed, write-enabled the disk. A sliding detented piece can be moved to block or reveal the part of the rectangular hole that is sensed by the drive. The HD 1.44 MB disks have a second, unobstructed hole in the opposite corner which identifies them as being of that capacity.

From the software point of view, I think on XT machines MSDOS just looks at the BIOS data area and for AT machines the CMOS. DOS 5.0 might try CMOS if available and if not, the BIOS data area.

superfury wrote:

When I try to format a floppy disk in MS-DOS 5.0a, it seems to always detect the floppy disk as 360KB(telling me a 1.44MB disk image is a 360K disk), even if a 1.44MB or other non-360K disk image is mounted. Does it do something that's not supported by my emulation? My emulation does error our with ST0=40h when a disk error (invalid sector or other write fault) occurs. ST=80h with invalid commands, ST0(high 2 bits=0) when it succeeds.

Anyone knows why MS-DOS detects my floppy disk size wrong? What method does it use to detect the floppy disk size?

Floppy disk emulation code: https://bitbucket.org/superfury/x86emu/src/36 … ppy.c?at=master

I don't really understand... What does a "disk image" or "mounting" have to do with the way dos 5 formats disks? Or your "emulation"? What's your emulation?

Answering to the topic's title question "How does MS-DOS 5.0a format.com detect the correct floppy disk size to format", well, it doesn't detect anything. If you insert a DD floppy in a HD drive and run "format x:", it'll try to format it as HD. You need to specify the parameters if you want anything different than what's defined in BIOS.

The problem is: How does format.com know if it's dealing with a DD drive or HD/ED drive? It's currently trying to format all my disks as 360KB for some reason.

My floppy disk controller emulation: https://bitbucket.org/superfury/x86emu/src/eb … ppy.c?at=master

@konc: The C code given is code used in my emulator, to emulate a full floppy disk controller. For some reason the BIOS and/or MS-DOS detect the disk wrong (I've mounted a 1.44MB disk and MS-DOS reads and writes it without problems, but format.com ends up seeing it as a 360KB floppy disk, though I don't know how it actually comes to that conclusion.).

If the floppy disk (interrupt 13h or MS-DOS) handler retrieves those settings from the BIOS, how does the BIOS retrieve that information? How does it know what kind of drive it's talking to (5 inch or 3 1/2 inch and the exact floppy disk format to use(of course it can try to probe the disk for detecting when it overflows, like seeking back until 40 or 80 tracks is found)? I don't think the floppy disk controller actually has that information available (what kind of controller. Double Density probably is in one of the advanced ST registers (ST1-3)?

I found this in the BIOS that you and I are using:

; Notes:
; * High-density floppy disks (3.5" 1.44MB and 5.25" 1.2MB) are not supported due to lack of
; ROM space. You will need to use an external floppy controller BIOS for this. Another option
; is to run DR-DOS, which loads software support for high-density drives (this still requires a
; high-density controller, but no ROM required). There is also a DOS TSR called "2M-XBIOS" which
; adds this support to any DOS, but you cannot boot from a high-density disk.

I tried "format b:" on my emulator (with PC/XT mode and same BIOS and DOS as you) and indeed while it can read 1.44Mb disks when it formats it does it on a 360k format. My guess is since a) the bIOS does not support it and b) possibly MSDOS 5.0 does not support 1.44Mb either it "just works" for reading because I (the emulator) "know" that the floppy is 1.44 so when I see a request to read head 1 and sector 75 I do it, I know it is there. And the reason I am even getting that request is because the FAT tells me to and there is NO error checking code in either MSDOS or BIOS. Formatting however is a different issue because then MSDOS tells me, the emulator what format it wants and then it only knows about 360k.

I also tried configuring my emulator with 386 CPU (on an AT platform) using BOCHS BIOS and MSDOS 6.22 and when I say "format b:" it correctly tries 1.44Mb. This could be for any one of the following reasons though:

a) on an AT machine DOS queries the CMOS (and there I have it set to be 1.44Mb drive
b) DOS 6.22 has 1.44Mb support
c) BOCHS BIOS has 1.44Mb support.

I guess what I am trying to say superfury is that your code might just be correct as is.

I looked at the documentation most of my controller is based on:
http://www.isdaman.com/alsos/hardware/fdc/floppy.htm

It doesn't list anything to detect high/extended density vs sd disks. I think the user either has to explicitly specify it somewhere in a BIOS or OS, or taken from a source like the boot sector(requiring being properly formatted).

Another possibility could be that brute force method used on detecting 40 vs 80 tracks. Maybe the same can be done with the sectors to detect 18(HD) vs 36(ED) floppies? Also detection can be done by trying both sd and dd and whichever works is the format?

Also, what about dd vs hd disks in an 1.44M floppy drive? Can it be detected on an AT? (The line shouldn't be able to read(DIR bit 0), only PS/2 with no mode 30 devices? Or is this AT DIR too(the manual having an error there?

I think it also looks at the disk itself in certain circumstances. I've recently been formatting a few disks, and I found that if you format a disk with the wrong BIOS drive type (e.g. 1.44MB drive as 360kB) then when you fix that and later try to reformat that disk back to its proper size, FORMAT will still detect it as 360kB and try to keep the same format. I found you have to use the /F parameter to tell it to format as 1.44MB in order to override that detection.

Well, the problem is that when I add the /f:1.44 parameter, it gives an error and still aborts before formatting, even though it's a 1.44MB floppy disk image(verified using Winimage). So it somehow still thinks it's a 360K drive, even though it has a 1.44mB disk in it with information telling otherwise?

I do remember I managed to get it to use 1.44MB while testing some changes, but I can't remember exactly what caused it. Maybe the AT register(s)?

Btw, is the /f/F parameter case sensitive? I've been calling it with "/f:1.44" after the drive:
format a: /f:1.44

Does the F need to be uppercase? Also does the location matter?

Strangely enough, the formatting of DOS 3.3 or 5.0 used to work properly some time ago(maybe before implementing IDE hardware). I could disable it and try formatting again and see whaf it does.

Btw, I can install MS-DOS 5.0 partly up to formatting(booting floppy, detection, partitioning from the wizard, rebooting, then it starts to format the hard disk and after that refuses to detect it's own diskette(keeps asking to insert disk 1). Trying to quit to ms-dos ends up with an empty mode 2/3h with blinking cursor at 0,0 character coordinates. It won't continue. The hard drive is only partitioned.

Now that I think about it, I still have some old floppy lying around(in my bookcase besides my pc) that says it's MS-DOS 5.0 setup disk 1/2. Although the other disk went lost in time, it might still contain it's contents. (I vaguely remember that I or my dad were messing with tape. I do hope we haven't lifted it's write protection and erased it's contents. Might be a good verification subject for my emulator. Digitized it some years ago though, in a folder on my external 2TB harddisk.

Edit: Just took a look at the floppy. Unfortunately it isn't an original. Nor MS-DOS 5, it's 6.0 disk 1 according to it's label, and it's a normal floppy(no original OEM) (do remember two original disks of ms-dos 5.0 OEM (which didn't have any write enable option, since they weren't allowed to be written officially. I remember installing it on my pc though(around 1995 I think, since we were also messing with Windows 95 at the time). Can't remember whaf if looked like exactly though. Magbe something from Packard Bell(the pc it was installed on)?

Btw I tried using the ms-dos 5.0(a) setup disk 1 from vetusware with my emulator, but after partitioning and rebooting it tries to format the harsdisk and asks to insert disk 1 into drive a infinitely. Then, quitting using f3, i'm left with an eternal empty screen with blnking cursor at character 0,0. Are the flopppies corrupted, the fdc has an error or are the floppies incorrect?

It seems like the Turbo XT BIOS comes with some Ably-tech Unique 4-Drive Floppy disk controller BIOS (verified to run in x86EMU, but it currently gives a controller error when starting with 1.44MB disk mounted).

Anyone knows where to find some documentation on it? It might simply be erriring out because of my 1-instead-of-4 floppy reset hack (only 1 Sense Interrupt instead of 4 according to docs, based on the Turbo XT BIOS's bug).

No, few if any switches for Microsoft programs are case-sensitive. Position also doesn't matter in this case.

The DRIVPARM entry in CONFIG.SYS has the /I option I believe which could add support for 1.44MB floppies when the BIOS does not, but I'm not sure what version of DOS it was introduced in (seems to be in 6, not sure about 5.)

If you're unsure of your disks, try booting them in another emulator, then you'll know whether they are corrupt or not.

A four-floppy BIOS should be fine with only one disk, as long as it's configured as such (e.g. whatever the equivalent is to the CMOS setup.) If it only supports autodetection, then I believe there was some recent discussion that came to the conclusion that you can't autodetect a 1.44MB drive (because you can't distinguish it from another drive type) so BIOSes that use autodetection generally don't seem to support 1.44MB floppies.

In my quest to get four or more floppies into a single PC I have been informed about this open source floppy BIOS (end of the page, .bin for ROM, .tar.gz for source+ROM), which supports up to eight drives (four per controller across a primary and secondary floppy controller.) I have tried it in a real machine and it seems to work quite well (although I couldn't get the secondary controller to work properly as the ROM can't share IRQ/DMA between the floppy controllers.)

This ROM lets you hard-code the drive types, so you can do that and then you will know for sure the BIOS is aware of the correct drive types.

I've verified my generated 1.44MB image in Dosbox 0.74. It mounts and works when using the -size 18,2,80 parameter, as it cannot detect it's geometry automatically?

I think DOSBox can only autodetect the geometry if the file is a standard size. If your floppy image is not a standard size then you will have to specify the geometry manually as you have done.

It's a standard formatted as 80 cyclinders, 18 spt and 2 sides. It's also set in the boot sector correctly according to Winimage. The file size is also 1440KB (2x80x18x512 bytes),

Why isn't it detecting it?

Care to post the non-working floppy image somewhere for download and examination?

The code for generating is in the last commit to x86EMU. If you build it using the latest commit, just run it and in the bios settings menu, go to the disks menu, click/choose to create a floppy disk, choose the format(I'm testing using 1.44MB), type the name without .img and press enter to create(Direct Input mode still not working in the BIOS, still figuring out why).

https://bitbucket.org/superfury/x86emu.git

/basicio/staticimage.c contains the floppy generating support (empty image with boot sector filled and first FAT+Media descriptor at second sector).
/hardware/floppy.c contains the floppy disk emulation(no timing yet, instant completion of commands) and the table used for geometries, formatting the createn disks and other filters(like gap lengths on .img disks that work(with other values failing writes/reads/formatting, unless using the IGNORE flag on a incompatible system, identified using the global _ignore flag, which is set at initialization of the controller by the enulator) etc.).

Mounting a 1,474,560 byte image works fine for me under DOSBox, automatically identifying it as 1.44MB:

1C:\>imgmount a -t floppy test.ima
2Drive A is mounted as test.ima

I just used the Dosbox build from Dosbox.com's link to Sourceforge. Maybe it's bugged?

I see you've called it with -t floppy. I just called it using:
imgmount a test.img

Although, looking at some Dosbox fork (Dosbox-X?) tells me it will try to mount as hdd by default, which will fail? Can't it try floppy geometries first when using letter a/b or disk 0/1, then try hdd when -t isn't specified?

Yes it probably could try floppy geometries for drives A and B, so I guess you can make a patch for that and submit it. The DOSBox README says that IMGMOUNT will only autodetect the disk geometry when -t floppy or -t cdrom is specified, otherwise you have to supply the figures yourself.

I've found the bug preventing input during BIOS Menu's Direct Input mode and fixed it in the latest commit of x86EMU. This should make it easier to create the disk images.