FORMATting a phantom B: diskette leads to SvarCOM reload failure

[mateuszviste]

reported by Willy Spiegl: apparently he boots his system from a SvarDOS floppy and then tries to format the floppy. He complained that afterwards COMMAND.COM fails to reload.

It's two cases, really:

1. FORMAT A: leading to SvarCOM being unable to respawn is normal and expected, since it was booted from A: in the first place. Once FORMAT is done with its job, SvarCOM's RMOD will try to reload A:\COMMAND.COM, but this file vanished so the system is bricked. Nothing to fix there.

2. FORMAT B: is a slightly different story. I assume this is a single-diskette system, so drive B: is most probably a phantom drive. In such configuration I'd expect DOS to print out its "insert a diskette in drive B:...", and then, once the job is done, ask for a diskette in A: again. But here it does not happen:

Not sure who is to blame in this yet... EDR? FORMAT? SvarCOM?

[boeckmann]

This whole Set_Floppy_Media_Type with the bunch of INT13 calls seem to have been implemented to support formatting floppy disks not matching the drives default geometry. For instance formatting a 360K in a 1.2M. Never dealt with such issues before (don't even have a real floppy disk other than 1.44M).

As MS format does not do this, it smells like the MS-DOS kernel takes care of it in its SetDeviceParameters IOCTL...

[boeckmann]

Indeed the MS-DOS kernel seems to do "some magic". Looks like SetDeviceParameters IOCTL eventually triggeres a SETDASD, which in turn calls INT13,17h.

[mateuszviste]

For instance formatting a 360K in a 1.2M.

it's a nice feature, but wonky in practice (ie. such formatted floppies are then often unreadable on a true 360K drive). I found that out the hard way. It's also true for 1.4M -> 720K writes.

Indeed the MS-DOS kernel seems to do "some magic". Looks like SetDeviceParameters IOCTL eventually triggeres a SETDASD, which in turn calls INT13,17h.

Sounds like FD-FORMAT is doing much more than it should, and if doing less does not work then it should rather be reported as a kernel issue?

[boeckmann]

Sounds like FD-FORMAT is doing much more than it should, and if doing less does not work then it should rather be reported as a kernel issue?

Not remotely sure what was the reason they implemented it like it is. Perhaps a lack of FreeDOS kernel capabilities, perhaps something different, perhaps both.

My guess is that all this is unneccessary when a disk conforming to the drives "native" format is formatted.

[boeckmann]

My proposal would be to implement a minimal floppy format utility restricting to DOS function calls, perhaps without the capabilities to format foreign geometry disks (does anyone ever use this), only the bare minimum. Could then be extended to hard disks (and eventually FAT32).

[mateuszviste]

My proposal would be to implement a minimal floppy format utility restricting to DOS function calls, perhaps without the capabilities to format foreign geometry disks (does anyone ever use this), only the bare minimum. Could then be extended to hard disks (and eventually FAT32).

This is, I think, what we effectively have already coming from MS-DOS 4.0?

perhaps without the capabilities to format foreign geometry disks (does anyone ever use this)

I think such feature should not exist in the first place, as it's very misleading and can only lead to user frustrations. Such formatted diskettes only work in the newer-capacity drive they were formatted in, not in the native lower-capacity drive. So totally useless.

[boeckmann]

This is, I think, what we effectively have already coming from MS-DOS 4.0?

Yes, in assembly. Thought more of a C conversion, because implementing the missing parts would be easier. But if one wants to work on the assembly version, that also would be awesome :)

[mateuszviste]

Ah, I was somewhat afraid you'd want to go for an asm version. :) Having a minimalist FORMAT in C would be very good indeed. Much easier to understand than the MS FORMAT (which requires some deciphering skillz) and much lighter/simpler than the FD alternative.