Speedlock was also available in disc version.
One version called "[[8k Speedlock]]" relied on the fact that the CPC's hardware (specifically, the [[765 FDC|µPD765]] disk controller) could read 8 Kbyte sectors even though it was typically only possible to store more than 6,250 bytes on 300 rpm double density diskettes. Attempting to write an 8 Kbyte sector would cause the system to over-write its header block, because it requires to slow down the write speed (what the duplicator is doing. when examined with a flux tool like AUFIT, you can see that speedlock tracks are 'density variation' type. the density is higher due to the slower write speed used).
It was written here that "the format was either "devised or done " on an Atari ST or an IBM PC compatible machine (since the CPC share with them the same FDC controler). The main difference being that an , but not written on them since the Atari ST or and IBM PC are unable to perform writetrack, they can only do sector write more data per track than a CPC." This contains several inaccuracies. The Speedlock team in fact wrote the diskettes using diskette interfaces custom-modified for this purpose. Also, an Atari ST also has 6,250 bytes/track although used a WD1772 disk controller, while the PC has over time been based on a variety of formats (e.g. HD was 360 rpm 15 sectors etc.) and controllers (e.g. NEC µPD765 or Intel 8272A or 82072A.
"The main difference being that an ST or PC can write more data per track than a CPC." "That's incorrect, since those industrial duplicator formats were not made on standard machine equipment, you can also squash up to 6700 bytes on a CPC track. For that, you will need to do exactly the same thing as on PC and ST, slowdown the write speed in order to write more on each track. With a standard 300RPM speed, that's impossible. A speed lowered to a range of 260-280RPM is needed. that's why trying to copy a speedlock track fails on a CPC. A CPC can't do write track, only sector write. Speedlock tracks were duplicated on trace machine or Philips Unix duplicator in Writetrack, not sector write." "This contains several inaccuracies. The Speedlock team in fact wrote the diskettes using diskette interfaces custom-modified for this purpose. Also, an Atari ST also has 6,250 bytes/track although used a WD1772 disk controller, while the PC has over time been based on a variety of formats (e.g. HD was 360 rpm 15 sectors etc.) and controllers (e.g. NEC µPD765 or Intel 8272A or 82072A." "The Speedlock team was using an IBM PC equipped with a drive linked to an FDC able to write disks in writetrack or they used directly a Trace machine (duplicator) to make the master disk. "Another statement written here was: "In itself, a 'Speedlock track' exists in 2 versions, used at the discretion of the duplicator, one use a CRC, and the other not." This is inaccurate, in the sense that it was never at the discretion of the duplicator. There were at least two separate versions, one of which may have involved a CRA issue." "the writing above is incorrect. I maintain what i said, i have encoded in IPF (interchangeable Preservation Format) all the commercial games/softwares using the speedlock $1800 track system on the Amstrad CPC There are 3 variants : -the Speedlock $1800 with CRC 16 bits, -the Speedlock $1800 with no EDC The third one has only been used on one compilation, and i can't currently encode it in IPF, because it has a subtility that has yet to be found. And nothing else. The CRC16 and no EDC options were decided by the operator when building the master before writing it to disk.The Speedlock $1800 with CRC 16 bits is made as follow : 1.Track is $1800 bytes long, 2.Checksum 16 bits calculated as polynomial on 2 bytes ; The speedlock $1800 with no CRC (no EDC - Error Data Checksum):1.the checksum is always the same2.the '4e' byte pattern on each track is the same. The publishers who released games with this version used a duplicator different from Trace Machine duplicators, and they did the duplication blindly, without checking (exactly what happens on spanish games, and some french,english,and german ones). Last point, calling the speedlock tracks as speedlock 6K or 8K is incorrect. When i process a game dumped as flux for Amstrad CPC in original, my tool recognize the speedlock tracks. Those were "writetrack" written, NOT as a big 6K sector. Therefore, if someone copy a game with speedlock tracks, my tool will then not recognize the tracks anymore, because they will have been changed from "writetrack" mode to "writesector" mode, loosing informations in the process.
A 'Speedlock track' consists of only 512 bytes declared for the sector while all the remaining data is spanned in a huge GAP section. When copied on a CPC, the FDC only stores the 512 first bytes as declared in the CHRN, and discards the remaining contained in the gap section. Those tracks have an EDC (Error Data Checksum) because only 512 bytes are used to calculate the data checksum as well as an illegal data field size. Several other protection mechanisms existed on such tracks, including special codes written by the Trace 1006 duplication equipment commonly in use at the time: these codes could not be written by standard Amstrad disc drives.