Disk drive status code test

[phaeron]

Presenting my latest experiment, a test program to check what FDC status codes are returned by an Atari-compatible drive when attempting to read various kinds of bad sectors. It's a test disk containing one of every kind of stable abnormal sector and a test program that reads each sector to retrieve the FDC status code. The reason for this test is to improve ATX image cross-compatibility and compatiblity against software that looks for specific FDC error codes, especially codes that are specific to disk drive models.

 

I'd be very interested in hearing what other people see on their hardware, but fair warning: it's not easy to create the physical test disk for this, as you can't write it with a stock 810/1050. I've attached it in ATX and SCP form. The ATX image will work for emulators, but a8rawconv 0.92 cannot write it correctly due to some bugs in address CRC error handling in the encoder. For that reason I've also included a pre-encoded SuperCard Pro (SCP) image, which is index-aligned for easier writing. It might be possible to copy it with one of the modded drives, but that would presume you already had a physical disk to copy from.

 

Below are expected results for a 1050 and XF551. They're from an emulator, but I've checked them against the real drives; I'm just too lazy to get out my camera.

 

 

A few interesting results I've already seen:

• The XF551 doesn't report missing sector errors, apparently due to a quirk in the 1772 FDC and the way the XF551 reads status. The command fails but the FDC status is $FF (no error).
• Some disk protection references report that the DRQ bit (bit 2) can be negated when a lost data condition is reported on a 1050, but all tests that I've run have always shown DRQ and Lost Data activated together.
• Several disk drive types don't seem to report long sector errors at all, including the Indus GT and Percom. This is because their sector read loops simply read the entire physical sector instead of the expected sector size. This is potentially interesting as it may offer a way to get custom code onto drives that don't natively support it via buffer overflow with a 1K sector.

 

disktest.zip

[_The Doctor__]

I wonder if a bitwriter drive could make the test disks as well?

[ijor]

Great stuff, as usual ...

 

Some disk protection references report that the DRQ bit (bit 2) can be negated when a lost data condition is reported on a 1050, but all tests that I've run have always shown DRQ and Lost Data activated together.

If I follow the 1050 ROM correctly, DRQ indeed should always be set on long sectors. IIRC it is quite different on the 810.

 

I wonder if a bitwriter drive could make the test disks as well?

Of course it can. Most drive enhancements, including the Happpy and The Chip, can create these type of sectors. The problem is the software to write back from an image, and not copying a source disk.

[ebiguy]

Below are expected results for a 1050 and XF551. They're from an emulator, but I've checked them against the real drives; I'm just too lazy to get out my camera.

 

3 questions:

 

1) Do you have the stock 810 output ?

 

2) I wish I could try but I have a Kryoflux, not a SuperCard Pro. Do you think you could make the .raw files ?

 

3) What kind of DAM did you use when writing the track ($F8...$FB) ?

Edited July 31, 2018 by ebiguy

[phaeron]

1) Do you have the stock 810 output ?

No, I don't have an 810 to test on. The long sector results should be different due to the differences in firmware and the deleted sector tests different due to the FDCs.

 

2) I wish I could try but I have a Kryoflux, not a SuperCard Pro. Do you think you could make the .raw files ?

I don't have a Kryoflux and can't create the .raw files, but I might be able to get a friend to image the disk with his.

 

3) What kind of DAM did you use when writing the track ($F8...$FB) ?

 

$FB for normal sectors and $F8 for deleted. The ATX file format only includes the LSB as the FDC used by the 1050 does, so the other two user defined marks can't be stored in that image type. I think the 810 might be the only drive type that can detect the user defined marks.

 

[ebiguy]

No, I don't have an 810 to test on. The long sector results should be different due to the differences in firmware and the deleted sector tests different due to the FDCs.

 

I don't have a Kryoflux and can't create the .raw files, but I might be able to get a friend to image the disk with his.

 

 

$FB for normal sectors and $F8 for deleted. The ATX file format only includes the LSB as the FDC used by the 1050 does, so the other two user defined marks can't be stored in that image type. I think the 810 might be the only drive type that can detect the user defined marks.

 

 

Thank you for your answers.

I don't want to bother you creating the .raw files. This was just in case you have also a Kryoflux. Anyway, thank you for trying.

I have 2 810 drives. One with the Chip 810 and one with the Happy Rev 5. So I could send you the result if I was able to create the disk.

 

I tried to create the disk from the ATX. This explains my question about the DAM because, as you said, the exact kind of record type is missing in the ATX.

Same kind of question: how did you create your long sectors. Did you write a sector header with 1 as the sector length (for 256 bytes) ?

 

Maybe I missed something in the ATX file format but is there a way to get the sector size. If I write a header with 1 as the setor length and I write a full 256 byte sector with the right CRC, how does it end up in the ATX file ?

[ebiguy]

 

Thank you for your answers.

I don't want to bother you creating the .raw files. This was just in case you have also a Kryoflux. Anyway, thank you for trying.

I have 2 810 drives. One with the Chip 810 and one with the Happy Rev 5. So I could send you the result if I was able to create the disk.

 

I tried to create the disk from the ATX. This explains my question about the DAM because, as you said, the exact kind of record type is missing in the ATX.

Same kind of question: how did you create your long sectors. Did you write a sector header with 1 as the sector length (for 256 bytes) ?

 

Maybe I missed something in the ATX file format but is there a way to get the sector size. If I write a header with 1 as the setor length and I write a full 256 byte sector with the right CRC, how does it end up in the ATX file ?

I guess I have to deal with the sector position to know that there is enough space between sectors for a 256 byte sector

[phaeron]

I tried to create the disk from the ATX. This explains my question about the DAM because, as you said, the exact kind of record type is missing in the ATX.

Same kind of question: how did you create your long sectors. Did you write a sector header with 1 as the sector length (for 256 bytes) ?

 

Yes, or more precisely the two low bits set to %01. The upper 6 bits are ignored.

 

The a8rawconv flux encoder uses different strategies for long sectors depending on whether there is also a CRC error. If the CRC is correct, a full 256 byte sector is written. If the CRC is bad, the encoder cuts off the sector at 128 bytes to save track space since the rest of the long sector isn't visible to the computer (at least with a standard drive). In this case I deleted sectors on the track in the Python script that creates the ATX image to make sure there was room even without doing this.

 

I've recently discovered from the opened VAPI source that ATX does actually support encoding the true sector size, via another chunk type in the track. Its use is somewhat dubious since it still doesn't seem to allow more than 128 bytes of data to be encoded, so it only helps with accurate timing. You can't get at that data with a standard 810/1050, though.

 

Maybe I missed something in the ATX file format but is there a way to get the sector size. If I write a header with 1 as the setor length and I write a full 256 byte sector with the right CRC, how does it end up in the ATX file ?

 

It is by default inferred from the Lost Data FDC status (bit 2). The first 128 bytes are stored as usual, the rest needs to be filled in if you're doing full drive emulation. It seems that track chunks of type 0x11 can provide the actual sector size value, similar to the 0x10 chunk for weak data start. You're probably not going to find anything supporting this yet besides the original VAPI DLL

 

I don't remember how the DRQ bit (bit 1) is supposed to be set in the ATX image, as it seems to be overridden in the VAPI DLL. I also override it in Altirra as part of converting the FDC status to 810 or 1050 behavior. Have to check some VAPI images to see what's in the wild.

[ijor]

I've recently discovered from the opened VAPI source that ATX does actually support encoding the true sector size, via another chunk type in the track. Its use is somewhat dubious since it still doesn't seem to allow more than 128 bytes of data to be encoded, so it only helps with accurate timing. You can't get at that data with a standard 810/1050, though.

Yes, that was precisely the idea. To provide accurate timing when reading the sector. It isn't really very important, in first place because the 1050 firmware will retry because of the DATA LOST error, which becomes now the dominant time. And in second place because long sectors on an 810 are completely different anyway. So probably no title really depends on this.

 

I don't remember how the DRQ bit (bit 1) is supposed to be set in the ATX image, as it seems to be overridden in the VAPI DLL. I also override it in Altirra as part of converting the FDC status to 810 or 1050 behavior. Have to check some VAPI images to see what's in the wild.

I would need to double check, but I believe you will find both kinds, with and without the DRQ bit set on the image. Was partially my fault because only later I realized the difference in this regard between the 810 and the 1050 (I never had an 810).