Databyte disks on Atari 810

[ijor]

Force Interrupt is one of the most important and criminally undocumented commands in the 177X/277X FDC series.

Indeed. And even Atari itself was burnt by its quirks. There is a bug in Atari ST TOS 1.0 that sometimes might miss a CRC error and it relates precisely to this. The ST has the same FDC as the XF-551.

 

Do you know what kind of timing is involved in Force Interrupt completing?

 

It is not constant. That's why in this case the busy set is sometimes set, but sometimes is not. In first place the FDC might not process the interrupt immediately. Some internal operations cannot be interrupted and then it is deferred. Then it takes a couple of "internal cycles" to clear the busy flag, and then a couple more to assert INTRQ.

 

But the FDC is not directly synchronized to the external clock. When reading from the disk, the FDC is synchronized to the PLL, one cycle per data bit. So a cycle would be 8us at nominal bit rate. But, of course, it would be variable depending on the actual timing of the incoming bitstream.

 

 

BTW, Altirra does support debugging drive coprocessors. The ~s command is used to switch processor contexts (~1s, ~2s, etc).

 

Oh. Great. Why you didn't tell me before ! LOL. I seemed to remember you mentioned something about it, but I missed the ~ command on the debugger help. As a lame excuse for me, your debugger help documentation is not the best part of Altirra

 

Does this mean it's time to extend ATX to store the full long sector?

Probably yes. But note again that in this specific case it is not strictly needed because the 129th byte can be inferred from the shorter distance to the next sector and its content. I note this just as a temporary workaround. I do agree that it is a good idea to extend the format to allow storing the full long sector data.

 

Edited September 14, 2018 by ijor

[ijor]

Hats off for ijor. To be honest, I was the arm manipulating the 810 and he was the brain !

 

Thanks, but obviously there was a brainstorming work here. Not only you were involved, DjayBee's work on the software side of the protection was also instrumental, and Phaeron as well indirectly because the analysis would have been much more difficult without Altirra (even when I made it more difficult than needed, because I didn't realized that Altirra can debug the drive's CPU)

[phaeron]

Probably yes. But note again that in this specific case it is not strictly needed because the 129th byte can be inferred from the shorter distance to the next sector and its content. I note this just as a temporary workaround. I do agree that it is a good idea to extend the format to allow storing the full long sector data.

 

It can be inferred, but there are a lot of ways it can go wrong, particularly due to invisible clock bits. Writing code to reconstitute the next sector header and searching for it with bit alignment in the previous sector sounds un-fun.

 

I'd be interested in thoughts on how to extend the format. An option would be to add bits to the extended sector header chunk (0x11). One bit might be enough to indicate that the full physical sector is stored in the image. If done right, this would also be usable for double density and for storing full size boot sectors (Indus CP/M).

[ijor]

I'd be interested in thoughts on how to extend the format. An option would be to add bits to the extended sector header chunk (0x11). One bit might be enough to indicate that the full physical sector is stored in the image. If done right, this would also be usable for double density and for storing full size boot sectors (Indus CP/M).

 

That might be one option, but there is some risk of breaking backwards compatibility. Another option could be just to use a new chunk and store the full sector data there.

 

I think that for double density we should better use a global flag at the track level indicating the default sector size for the track. And then full boot sectors should be included by default. With DD images we don't need to care about backwards compatibility, so it makes more sense IMHO to make it more straightforward without using chunks. Chunks might still be used for non default sector sizes in MFM, if we ever need to use them.

[phaeron]

 

That might be one option, but there is some risk of breaking backwards compatibility. Another option could be just to use a new chunk and store the full sector data there.

 

I think that for double density we should better use a global flag at the track level indicating the default sector size for the track. And then full boot sectors should be included by default. With DD images we don't need to care about backwards compatibility, so it makes more sense IMHO to make it more straightforward without using chunks. Chunks might still be used for non default sector sizes in MFM, if we ever need to use them.

 

My thinking is that as long as parsers are using the sector data offset and can ignore unknown chunks at the end of the track, they should be able to handle gaps in the sector data and the extended sector header chunk that's already defined. Existing parsers would then only use the first 128 bytes that they know about and new parsers would recognize the additional data from the sector size and extension bit in the extended sector header. The VAPI DLL masks off all but bits 0-1 when it looks for the physical sector size, so it should ignore bit 2.

 

Being able to change the default sector size wouldn't be a bad idea, but just having the ability to store larger sectors without the lost data bit alone would give us that ability without much additional parser complexity. At least the way I'm currently parsing the chunk, it'd just be another switch entry in the chunk parser to update the physical sector size entry in the sector metadata.