I'm currently trying to fix the floppy disk controller used by the AT BIOS. Currently, it's emulating a 82072A floppy disk controller.

I see it emitting various commands before giving the error:
1. Sense interrupt, resulting bytes C0h 00h.
2. Sense interrupt, resulting bytes D1h, 00h.
3. Recalibrate, ST0 becoming 0x70(No floppy disk inserted). Disk changed bit is cleared, ST1 becomes 0x00.

No floppy disk is inserted into the drive.

Anyone can see what might be going wrong here?
My documentation I'm using: http://www.isdaman.com/alsos/hardware/fdc/floppy.htm (also http://bochs.sourceforge.net/cgi-bin/lxr/sour … iodev/floppy.cc )
My floppy disk emulation: https://bitbucket.org/superfury/unipcemu/src/ … ppy.c?at=master

Why is the BIOS throwing an error after the recalibrate command (which fails because of there being no floppy disk inserted)? It's a 601-Floppy disk error.

Recalibrate only returns track 0 not found if there is no drive connected. The command succeeds even if there is no disk.

I don't mean no drive is connected. Just that no disk is inserted in the drive(existing drive without disk inserted).
This is the current result(based on Bochs code):

1case RECALIBRATE: //Calibrate drive
2			//Execute interrupt!
3			FLOPPY.commandstep = 0; //Reset controller command status!
4			FLOPPY.currentcylinder[FLOPPY.DOR.DriveNumber] = 0; //Goto cylinder #0!
5			FLOPPY.ST0.data = 0x20|FLOPPY.DOR.DriveNumber; //Completed command!
6			if (!has_drive(FLOPPY.DOR.DriveNumber ? FLOPPY1 : FLOPPY0)) //Drive present?
7			{
8				FLOPPY.ST0.data |= 0x50; //Completed command! 0x40: Abnormal termination, 0x10: Unit Check, cannot find track 0 after 79 pulses.
9			}
10			updateFloppyWriteProtected(0); //Try to read with(out) protection!
11			clearDiskChanged(); //Clear the disk changed flag for the new command!
12			FLOPPY_raiseIRQ(); //We're finished!
13			break;

Is that correct?

That error is only returned if there is no drive. The code comment even says it.

Not exactly. has_drive returns 1 when a storage medium(disk image file) is present and mounted in the specified slot. Otherwise 0.

In this case it returns 0, since I don't have a floppy disk image mounted in the emulator Settings. Compare it to Dosbox state of imgmount used successfully vs after "mount -u" image(or never mounted) states.

Maybe a more correct name would be something like "is_mounted". The drives (FLOPPY0, FLOPPY1, HDD0, HDD1, CDROM0, CDROM1) themselves are always valid entries. They just can have two states(mounted with backend or not mounted(and thus no backend)). has_drive simply returns the mounted/not mounted state(1=mounted to backend, 0=not mounted to any backend). Compare it to having a floppy drive with or without a disk inserted.

Btw, results are instantaneous(not timed according to accurate timing) atm. The only thing that's currently timed is the DMA transfer itself(which is timed by the DMA controller at 10 14.31818MHz cycles per byte).

Oh, that's your code, I thought that was from bochs. If you look at bochs it doesn't return track 0 not found if the drive is missing or the motor is off (which was a mistake in my comment above as drives won't seek if not spinning).

So if there's no floppy disk inserted into the drive, it will give a success code(my if clause not used case), the only difference between an existing and non-existing floppy disk being inserted or not being the TRK0 bit? So it will be 1 when a disk is present, but 0 when no disk is inserted?

So the code would need to become(based on below documentation):

1 case RECALIBRATE: //Calibrate drive
2         //Execute interrupt!
3         FLOPPY.commandstep = 0; //Reset controller command status!
4         FLOPPY.currentcylinder[FLOPPY.DOR.DriveNumber] = 0; //Goto cylinder #0!
5         FLOPPY.ST0.data = 0x20|FLOPPY.DOR.DriveNumber; //Completed command!
6         if (!has_drive(FLOPPY.DOR.DriveNumber ? FLOPPY1 : FLOPPY0)) //Drive present?
7         {
8            FLOPPY.ST0.data |= 0x10; //Completed command! 0x10: Unit Check, cannot find track 0 after 79 pulses.
9         }
10         updateFloppyWriteProtected(0); //Try to read with(out) protection!
11         clearDiskChanged(); //Clear the disk changed flag for the new command!
12         FLOPPY_raiseIRQ(); //We're finished!
13         break;

From my documentation:

When the controller sees this command, it sets the DIR signal to 0, and passes the drive up to 79 step pulses. After each of these pulses, the controller checks the TRK0 signal. If it is active (htat is, the head is on track 0), the controller sets the SE bit in Status Register 0, and aborts the command. If TRK0 is not active after 79 step pulses, the controller sets bits SE and EC in Status Register 0, and terminates the command.

Thus it needs to set SE to 1, and set EC to 1(floppy inserted) or 0(floppy not inserted)?

Edit: This is my current version:

1		case RECALIBRATE: //Calibrate drive
2			//Execute interrupt!
3			FLOPPY.commandstep = 0; //Reset controller command status!
4			FLOPPY.currentcylinder[FLOPPY.commandbuffer[1]] = 0; //Goto cylinder #0!
5			FLOPPY.ST0.data = 0x20|FLOPPY.commandbuffer[1]; //Completed command!
6			if (!is_mounted(FLOPPY.commandbuffer[1] ? FLOPPY1 : FLOPPY0)) //Media inserted?
7			{
8				FLOPPY.ST0.data |= 0x10; //Completed command! 0x10: Unit Check, cannot find track 0 after 79 pulses.
9			}
10			updateFloppyWriteProtected(0,FLOPPY.commandbuffer[1]); //Try to read with(out) protection!
11			clearDiskChanged(); //Clear the disk changed flag for the new command!
12			FLOPPY_raiseIRQ(); //We're finished!
13			break;

Even after those latest improvements, it still errors out immediately after the RECALIBRATE command for some reason. It doesn't even get to interpreting the ST0 value. It simply reports the 601 error immediately after issuing the recalibrate command? The command resets the controller back to state 0, which is the state used for issuing new commands:

1//Execution after command and data phrases!
2byte oldMSR = 0; //Old MSR!
3
4OPTINLINE void updateFloppyMSR() //Update the floppy MSR!
5{
6	switch (FLOPPY.commandstep) //What command step?
7	{
8	case 0: //Command?
9		FLOPPY.sectorstransferred = 0; //There's nothing transferred yet!
10		FLOPPY.MSR.CommandBusy = 0; //Not busy: we're waiting for a command!
11		FLOPPY.MSR.RQM = !FLOPPY.floppy_resetted; //Ready for data transfer when not being reset!
12		FLOPPY.MSR.HaveDataForCPU = 0; //We don't have data for the CPU!
13		break;
14	case 1: //Parameters?
15		FLOPPY.MSR.CommandBusy = 1; //Default: busy!
16		FLOPPY.MSR.RQM = 1; //Ready for data transfer!
17		FLOPPY.MSR.HaveDataForCPU = 0; //We don't have data for the CPU!
18		break;
19	case 2: //Data?
20		FLOPPY.MSR.CommandBusy = 1; //Default: busy!
21		//Check DMA, RQM and Busy flag!
22		switch (FLOPPY.commandbuffer[0]) //What command are we processing?
23		{
24		case WRITE_DATA: //Write sector?
25		case WRITE_DELETED_DATA: //Write deleted sector?
26		case FORMAT_TRACK: //Format sector?
27		case READ_DATA: //Read sector?
28		case READ_DELETED_DATA: //Read deleted sector?
29			FLOPPY.MSR.RQM = FLOPPY.MSR.NonDMA = !FLOPPY_useDMA(); //Use no DMA? Then transfer data and set NonDMA! Else, clear non DMA and don't transfer!
30			break;
31		default: //Unknown command?
32			FLOPPY.MSR.RQM = FLOPPY.MSR.NonDMA = 1; //Use no DMA by default, for safety!
33			break; //Don't process!
34		}
35
36		//Check data direction!
37		switch (FLOPPY.commandbuffer[0]) //Process input/output to/from controller!
38		{
39		case WRITE_DATA: //Write sector?
40		case WRITE_DELETED_DATA: //Write deleted sector?
41		case FORMAT_TRACK: //Format sector?
42			FLOPPY.MSR.HaveDataForCPU = 0; //We request data from the CPU!
43			break;
44		case READ_DATA: //Read sector?
45		case READ_DELETED_DATA: //Read deleted sector?
46			FLOPPY.MSR.HaveDataForCPU = 1; //We have data for the CPU!
47			break;
48		default: //Unknown direction?
49			FLOPPY.MSR.HaveDataForCPU = 0; //Nothing, say output by default!
50			break;
51		}
52		break;
53	case 3: //Result?
54		FLOPPY.MSR.CommandBusy = 1; //Default: busy!
55		FLOPPY.MSR.RQM = 1; //Data transfer!
56		FLOPPY.MSR.HaveDataForCPU = 1; //We have data for the CPU!
57		break;
58	case 0xFF: //Error?
59		FLOPPY.MSR.CommandBusy = 1; //Default: busy!
60		FLOPPY.MSR.RQM = 1; //Data transfer!

61		FLOPPY.MSR.HaveDataForCPU = 1; //We have data for the CPU!
62		break;
63	default: //Unknown status?
64		break; //Unknown?
65	}
66	if (FLOPPY.MSR.data != oldMSR) //MSR changed?
67	{
68		oldMSR = FLOPPY.MSR.data; //Update old!
69		FLOPPY_LOGD("FLOPPY: MSR changed: %02x", FLOPPY.MSR.data) //The updated MSR!
70	}
71}

Can you see why it seems to error out immediately?
https://bitbucket.org/superfury/unipcemu/src/ … ppy.c?at=master

crazyc wrote:

Oh, that's your code, I thought that was from bochs. If you look at bochs it only returns track 0 not found if the drive is missing or the motor is off (which was a mistake in my comment above as drives won't seek if not spinning).

Made a error which reversed what I meant.

So if there's no floppy disk inserted into the drive, it will give a success code(my if clause not used case), the only difference between an existing and non-existing floppy disk being inserted or not being the TRK0 bit? So it will be 1 when a disk is present, but 0 when no disk is inserted?

There is no difference between an disk inserted or not with a seek/recal. The controller has no way of telling if a disk is inserted or not.

Then what DO seek/recal commands return? Are they always reporting success on both seek and recalibrate even without enough tracks(seek) or no floppy disk inserted?

This is what my seek command currently does when executed:

1		case SEEK: //Seek/park head
2			FLOPPY.commandstep = 0; //Reset controller command status!
3			updateFloppyWriteProtected(0,FLOPPY.DOR.DriveNumber); //Try to read with(out) protection!
4			if ((FLOPPY.DOR.DriveNumber >= 2) || (FLOPPY.DOR.DriveNumber!=(FLOPPY.commandbuffer[1]&3))) //Invalid drive specified?
5			{
6				FLOPPY.ST0.data = (FLOPPY.ST0.data & 0x32) | 0x14 | FLOPPY.DOR.DriveNumber; //Error: drive not ready!
7				FLOPPY.commandstep = 0; //Reset command!
8				clearDiskChanged(); //Clear the disk changed flag for the new command!
9				return; //Abort!
10			}
11			if (!is_mounted(FLOPPY.DOR.DriveNumber ? FLOPPY1 : FLOPPY0)) //Floppy not inserted?
12			{
13				FLOPPY.ST0.data = (FLOPPY.ST0.data & 0x30) | 0x18 | FLOPPY.DOR.DriveNumber; //Error: drive not ready!
14				FLOPPY.commandstep = 0; //Reset command!
15				clearDiskChanged(); //Clear the disk changed flag for the new command!
16				return; //Abort!
17			}
18			if (FLOPPY.commandbuffer[2] < floppy_tracks(disksize(FLOPPY.DOR.DriveNumber ? FLOPPY1 : FLOPPY0))) //Valid track?
19			{
20				FLOPPY.currentcylinder[FLOPPY.DOR.DriveNumber] = FLOPPY.commandbuffer[2]; //Set the current cylinder!
21				FLOPPY.ST0.data = (FLOPPY.ST0.data & 0x30) | 0x20 | FLOPPY.DOR.DriveNumber; //Valid command!
22				FLOPPY_raiseIRQ(); //Finished executing phase!
23				clearDiskChanged(); //Clear the disk changed flag for the new command!
24				return; //Give an error!
25			}
26
27			//Invalid track?
28			FLOPPY.ST2.data |= 0x4; //Invalid seek!
29			FLOPPY.commandstep = (byte)(FLOPPY.commandposition = 0); //Reset command!
30			break;

Edit: It seems that after sending the recalibrate(1 command byte, 1 parameter) it simply doesn't touch the floppy disk controller anymore(ports 1FXh)? Nothing is sent or received to the FDC between sending that one parameter byte and throwing the 601 error?

PC FDCs never report drive not ready the as the ready line is forced set. Why are you setting bit 2 of ST2? That's scan failed not seek.

I've changed the setting of ST2 to 0x00 instead during seek to an invalid track.

My latest source code:
https://bitbucket.org/superfury/unipcemu/src/ … ppy.c?at=master

- Recalibrate always returns success, no matter what the floppy disk number of tracks and no matter if a disk or no disk is inserted.
- Track0 now updates the whole ST3 register in all used cases.
- Not Ready is never set, not even during error conditions(in ST0).
- Seeking to an invalid track updates ST0 the same way as a successfull seek, but doesn't set bit 5(Seek Ended). Bits 4&5 are kept, all other bits are cleared and bits 0-1 are set to the drive number.

Edit: After the last recalibrate instruction, the MSR contains 0x90. When the recalibrate command is sent (which triggers an IRQ6), the MSR (port 3F4) isn't ready anymore until the 601 error is displayed?

Only the Sense Interrupt command lowers the IRQ(enables further IRQs to be received). Interrupts after another interrupt without Sense Interrupt having been received don't trigger new IRQs(IRQ goes from high to high instead of low to high, thus triggering no new interrupt handler). Is that correct?

superfury wrote:

I've changed the setting of ST2 to 0x00 instead during seek to an invalid track. […]
Show full quote

I've changed the setting of ST2 to 0x00 instead during seek to an invalid track.

My latest source code:
https://bitbucket.org/superfury/unipcemu/src/ … ppy.c?at=master

- Recalibrate always returns success, no matter what the floppy disk number of tracks and no matter if a disk or no disk is inserted.

The 765 will actually only seek 77 tracks and report error if track 0 isn't reached so 80 tracks drives may not hit track 0 with one recalibrate but this likely isn't something you have to worry about.

superfury wrote:

- Track0 now updates the whole ST3 register in all used cases.
- Not Ready is never set, not even during error conditions(in ST0).

Correct.

superfury wrote:

- Seeking to an invalid track updates ST0 the same way as a successfull seek, but doesn't set bit 5(Seek Ended). Bits 4&5 are kept, all other bits are cleared and bits 0-1 are set to the drive number.

I think Seek ended is always set after a seek or recal command but I'm not certain.

superfury wrote:

Edit: After the last recalibrate instruction, the MSR contains 0x90. When the recalibrate command is sent (which triggers an IRQ6), the MSR (port 3F4) isn't ready anymore until the 601 error is displayed?

Only the Sense Interrupt command lowers the IRQ(enables further IRQs to be received). Interrupts after another interrupt without Sense Interrupt having been received don't trigger new IRQs(IRQ goes from high to high instead of low to high, thus triggering no new interrupt handler). Is that correct?

The Generic XT BIOS requires a seek command to also clear a seek irq (in reality any command has to clear a seek irq, the only machine I know of that requires this though is the x68000).

So essentially all interrupts raising by the FDC operate by lowering and raising the IRQ line each time an execution phase ends? So not only raised(or kept raised) when an execution phase ends and only lower when an Sense Interrupt is received?

The irq line is lowered when a byte is written to the command port. I've personally tested this with a real 765.

I've modified the FDC to save the current IR line status for Sense Interrupt and lower the IR line after saving it, before handling the written data itself. Sense Interrupt now uses that stored last IR status(before lowering) to determine invalid calls(which lock up the controller until reset).

Raising still works the same way(triggering an interrupt through raising the IR line when transitioning from low to high(PIC), but not from high to high(normally not the case, since new commands, and thus interrupts, send a command byte through the data port).

Unfortunately my documentation on the NEC µPD765 doesn't explain that behaviour:(
http://www.isdaman.com/alsos/hardware/fdc/floppy.htm

Sure, it isn't documented anywhere but I ran headfirst into it and had to poke at the chip myself to find out what was happening.

It now issues one(or two) recalibrates, then executes a seek. which fails on the mounted check (the lines within the is_mounted if-clause gets executed), then throws a 601 error again.

Edit: Changing it a bit, based on Bochs' floppy.cc:
- Sense interrupt (reset 1/2)
- Sense interrupt (reset 2/2)
- Recalibrate(A)
- Sense interrupt
- Recalibrate(B)
- Sense interrupt
- Seek (A)
- Sense interrupt
- Seek (B)
- Sense interrupt
- Sense drive status
- 601 diskette error reported.

Edit: After closer inspection of the ST1, ST2 and ST3 registers, it seems that their bit values in thier respective structs were backwards. So they started with the highest bits(bit 7) and ended with the lowest bits(bit 0). They need to be reversed for their proper results:S

It seems it's not happy with the drive status after recalibrating and seeking on both floppy drives?

It returns 0x39 in ST3 with both floppy drives.

Latest source code: https://bitbucket.org/superfury/unipcemu/src/ … ppy.c?at=master

superfury wrote:

Unfortunately my documentation on the NEC µPD765 doesn't explain that behaviour:(
http://www.isdaman.com/alsos/hardware/fdc/floppy.htm

That's where you got the seek failed thing from, huh. You need to look at the datasheet for controller registers instead, http://www.classiccmp.org/dunfield/r/765.pdf.

superfury wrote:

Edit: After closer inspection of the ST1, ST2 and ST3 registers, it seems that their bit values in thier respective structs were backwards. So they started with the highest bits(bit 7) and ended with the lowest bits(bit 0). They need to be reversed for their proper results:S

Note that bit field orders are not defined by C standard so it is implementation specific - it may be different on a different compiler and/or platform and it won't work if it is different. IIRC, microsoft compiler and gcc compiler have different bit field orders by default.

If code depend on first bit field entry within a byte being 0x80 or 0x01 by value, I don't know what would be the best way to handle it in a cross platform way. I'm sure other projects have hints how to handle it, like one solution is not to use bitfields 😀