Ian Collier wrote: > http://andercheran.aiind.upv.es/~amstrad/File_Formats/
Ah, thanks! > Now I've seen it I'm not so sure... It's pretty close but I'm not sure it's quite there either... The Amstrad controller seems to have 2 status registers for each data read command, but the SAM only has one for the actual data read. The SAM also has a status value returned as part of the READ_ADDRESS command, and I'm not sure that it's equivalent to the other Amstrad status value. The SAM READ_ADDRESS command can be used without ever having to use a READ_SECTORX command so the status value needs to be kept separate. In fact, it's possible to have a sector with a CRC error in the ID field header, which is distinct from a CRC error in the data block, so it's something that needs to be preserved. The extended Amstrad format also copes with copy protected software specifying 8K sectors, which is a clever hack since a track is only about 6K long. I'm not sure the SAM motor can be switched off on demand to be able to manage to create it (anyone tried?), but it'd be another consideration for the format needed. The extended format is also a lot more compact and gets rid of a lot of the unnecessary baggage that's in the original format for legacy support. So, if the 2 Amstrad status values are equivalent to the SAM's READ_ADDRESS and READ_SECTORX values we should be able to use the same format. If the 8K sector hack is possible on the SAM we need the extended format to be able to cover that possibility too (if it _is_ possible and SimCoupe can't handle it then someone's bound to use it!). Si
