Floppy drive motor remains on after tests

[screwtop]

I noticed that running devtest on trackdisk.device devices leaves the floppy drive motor running following the test. This happens on two A1200s I have, on the geometry and benchmark tests (but not the open/close test). Running DiskChange is one way to turn the motor off afterwards.

(I also have a question about TD_GETGEOMETRY, which doesn't seem to work nicely with the classic Compact Flash card on an IDE adapter via scsi.device. I've seen this affect devtest and CheckDisk at least. My SanDisk CF cards are reported by HDToolbox and friends as an optical drive, and I wonder if this (or the removable bit) might be part of the problem.)

Thanks!

[cdhooper]

Thank you for reporting this. I completely forgot about trackdisk.device requiring a TD_MOTOR to turn off the drive after a read or write. I'll fix this for the next release of devtest.

Regarding TD_GETGEOMETRY, I'm surprised that it fails on CF over IDE. As far as I know, the Commodore scsi.device fully implements TD_GETGEOMETRY using whatever native methods are necessary to get the drive geometry. I don't know how this is done with IDE. With SCSI, an INQUIRY will return the number of sectors on disk. The SCSI mode pages can also be requested to get cylinders/heads/sectors, and if the mode pages can't be acquired, the cylinders/heads/sectors can be computed (made up) based on the number of disk sectors. One thing about the Commodore scsi.device is that it queries drives only at startup. So if your CF is not installed at that time, then I don't think the Commodore driver will see a drive there. It might be different if the drive reports that it's removable. I don't know what the Commodore IDE driver does in that case.

Try using the -c option to send individual commands to the drive to see if you can figure out what is failing. Examples (SCSI):
12.ZOS322:> devtest scsi.device 0 -c geometry
TD_GETGEOMETRY Success 2097152 x 512 C=130 H=255 S=63 Type=0
12.ZOS322:> devtest scsi.device 0 -c inquiry
SCSICMD Inquiry Success V='ZULUSCSI' P='HARDDRIVE' R='2.0' DT=0x0 Linked Sync
12.ZOS322:> devtest scsi.device 0 -c tur
SCSICMD TUR Success Ready

[screwtop]

Thank you - I was also mindful that using devtest on floppy devices was probably not the intended use case! I should also mention that devtest reports errors when running the benchmark test on a floppy, specifically "Read Fail -4 IOERR_BADLENGTH at <address>", where <address> is 0x80000, 0x100000, 0x180000, 0x200000 for 512 kiB transfers, and 0xc0000, 0xe0000 for 128 kiB transfers (no errors for the 32 kiB transfers). I'm not surprised that it has problems with such a small device and such proportionately large transfers, but maybe it highlights a minor bug whereby it tries to read beyond the end of the disk.

I ran the commands you suggested on the CF device:

devtest -c inquiry scsi.device 0
	SCSICMD Inquiry	Success	V='SanDisk' P='SDCFX3-1024' R='HDX' DT=0x7 Removable Wide

devtest -c tur scsi.device 0
	SCSICMD TUR	Success	Ready

devtest -c geometry scsi.device 0
	TD_GETGEOMETRY	Fail -1 IOERR_OPENFAIL

I had also noticed that HDToolbox reports "Unit is not a disk (type 7)!" for this CF card (I presume this is the same 7 value as in the Inquiry DT field).

And sorry that I've now lumped two or three issues into one - would you like me to create a separate one for the floppy IOERR_BADLENGTH errors? (I should clarify, I don't think the lack of TD_GETGEOMETRY for the CF-IDE setup is actually a problem for devtest, as it's able to determine the drive capacity through other methods.)

[screwtop]

Oh, I just noticed that in the devtest -g output for a floppy, it reports only 1706 sectors for the Read-to capacity versus 1760 for TD_GETGEOMETRY. That might be the root cause of the benchmark test overruns.