VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

What happens on a 82077AA FDC when you execute a read sector ID, read data or write data command on an unformatted track? I'd assume ST0's reporting an error condition, with either or both drive not ready and unit check bits set?
What about ST1 and ST2? UniPCemu currently sets NDAT and NID in ST1 and NDAM in ST2.

If https://github.com/kerheol/dingux-cap32/blob/master/fdc.c is to be believed, it should set NID in ST1 only when it's an unformatted track, and NDAT when it's formatted but the sector ID wasn't found or unreadable?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 3, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've just changed the formatted tracks to report ND, while unformatted tracks report NID instead(also applies to wrong rate and motor off).

Verified same behaviour on MS-DOS. Also same behaviour on Windows NT 3.1. And also the very same behaviour on Windows 95.

I've noticed that both MS-DOS and Windows 95 seem to misdetect that a track isn't formatted. Windows NT 3.1 seems to detect that properly.

Also, I've noticed that both Windows 95 and Windows NT seem to not properly change the disk when it's changed while the disk motor is still spinning? Is that normal behaviour? Windows 95 even seems to request, using a BSOD-style input, for the previous disk? Windows NT displays the previous disk's volume label, then the new disk's content in that case?

All those errors reporting actually set both ST0's Unit Check(bit 4) and Not Ready(bit 3). Anyone knows what the correct ST0 value for such errors is for those two bits? Or are those two always cleared when ST1 bit 0 or 3 is set with the case of not found sectors(ND), not found index of the track(NID)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 2 of 3, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. The first effect I notice when removing the ST0 Unit Check and Not Ready bits is that MS-DOS format.com can actually format the IMD disks without requiring the unconditional format /u parameter now, which is a nice improvement. Executing dir on the disk still results in a "General failure reading drive" error message, though, so at least the message doesn't change.

Edit: Windows NT performing "dir" on the unformatted floppy disk says it's "not formatted properly". Format.com reports it's filesystem is "RAW". Formatting succeeds and the disk is usable.
Edit: The same error message as MS-DOS 6.22 gives is given by Windows 95 when the disk isn't formatted. Perhaps it has something to do with being based on MS-DOS 7 and 6.22 respectively that's being run?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 3 of 3, by superfury

User metadata
Rank l33t++
Rank
l33t++

So now, the only problem that's left is the response by MS-DOS 6.22 and Windows 95 when a IMD floppy disk is inserted, but isn't formatted. The format.com program handles it without issues now, but the dir command gives the "General failure reading drive" message? Why doesn't it give a more descriptive message like Windows NT does?

Edit: After reading https://www.pcmag.com/encyclopedia/term/gener … reading-drive-x , perhaps it's supposed to do that when the disk isn't formatted? So the FDC is fully functional now?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io