12-20-2013, 03:00 AM
It is a bit more complex than that and it will not work with a copier unless it is handled specifically. Let me try to explain what I believe is happening. (Note that I am not 100% sure because I do not have access to a good Scope/Logic analyzer …)
What is happening is that very fast transitions (unfortunately I do not know at what frequency) are recorded on the disk. This is possible because the write channel of the Floppy drive has no limitation (at least at that frequency). But when this transitions are read by the floppy drive read channel, by design (and even on modern drive) the signal is “integrated” (part for ACG, and I guess part for LF filtering) so what is happening when reading this burst of fast transitions is that you get *nothing* out of the read channel… So obviously if you try to blindly copy the transitions it won’t work. What has been done on some competitors products is that NFA are detected and when written back the area with no flux is converted to an area with very high flux rate. This protection is in fact used on many Atari games.
So this is already one case where blind copy won’t work.
In general blind bit copy works fine with a lot of games like DM CSB or Games using Rob Northern protection(s) on bit with variation (long/short sector or track). But many Atari games uses protections that I refer as Data over index and ID over index. As the name indicates an ID field or a DATA field is located just *over* the index and … On a normal track there is an area where the write head is turned on/off that I call the “track write splice” area. When you write a normal track the FDC wait for the index pulse and start to write the track until the next index pulse where it turn off the writing. Due to motor speed variation (and others…) the exact emplacement where the write gate is turned off is not precise at the bit flux level and this is the “track write splice” (there is also a “sector write splice” but this is another story). So if you have an ID segment or a DATA segment over the index and blindly copy from index to index you will always get glitches in the index area and the data won’t be correct. On professional duplication machine you could specify the location of the “beginning” of the track and writing would continue until the same point is reached again. Below you will see an extreme case where on some track only few sync bytes are located on the end of the track. In that case obviously blind copy won’t work either.
This is the only two obvious cases that come immediately to my mind and that would defeat a blind copy but they may be others. Usually pre-comp is not a problem as DPLL can handle this fairly well.
Now the good news is that once you have analyzed the protection it should be easy to reproduce it with your hardware.
Here is the Disk Layout for “Computer Hits Volume 2”. The ID field is in yellow and is followed by an intra-gap in light green followed by data in blue, followed by inter-gap in green. As you can see in that case the ID is just in front of the index and in some cases just above (track 70+) the index.
For example track 77 is 199822 µs long (not compensated) and if you look at the “read track buffer” (artificially prolonged) you can see the ID (line with byte 6272 starting at 199787 µs) that indeed span over the index.
What is happening is that very fast transitions (unfortunately I do not know at what frequency) are recorded on the disk. This is possible because the write channel of the Floppy drive has no limitation (at least at that frequency). But when this transitions are read by the floppy drive read channel, by design (and even on modern drive) the signal is “integrated” (part for ACG, and I guess part for LF filtering) so what is happening when reading this burst of fast transitions is that you get *nothing* out of the read channel… So obviously if you try to blindly copy the transitions it won’t work. What has been done on some competitors products is that NFA are detected and when written back the area with no flux is converted to an area with very high flux rate. This protection is in fact used on many Atari games.
So this is already one case where blind copy won’t work.
In general blind bit copy works fine with a lot of games like DM CSB or Games using Rob Northern protection(s) on bit with variation (long/short sector or track). But many Atari games uses protections that I refer as Data over index and ID over index. As the name indicates an ID field or a DATA field is located just *over* the index and … On a normal track there is an area where the write head is turned on/off that I call the “track write splice” area. When you write a normal track the FDC wait for the index pulse and start to write the track until the next index pulse where it turn off the writing. Due to motor speed variation (and others…) the exact emplacement where the write gate is turned off is not precise at the bit flux level and this is the “track write splice” (there is also a “sector write splice” but this is another story). So if you have an ID segment or a DATA segment over the index and blindly copy from index to index you will always get glitches in the index area and the data won’t be correct. On professional duplication machine you could specify the location of the “beginning” of the track and writing would continue until the same point is reached again. Below you will see an extreme case where on some track only few sync bytes are located on the end of the track. In that case obviously blind copy won’t work either.
This is the only two obvious cases that come immediately to my mind and that would defeat a blind copy but they may be others. Usually pre-comp is not a problem as DPLL can handle this fairly well.
Now the good news is that once you have analyzed the protection it should be easy to reproduce it with your hardware.
Here is the Disk Layout for “Computer Hits Volume 2”. The ID field is in yellow and is followed by an intra-gap in light green followed by data in blue, followed by inter-gap in green. As you can see in that case the ID is just in front of the index and in some cases just above (track 70+) the index.
For example track 77 is 199822 µs long (not compensated) and if you look at the “read track buffer” (artificially prolonged) you can see the ID (line with byte 6272 starting at 199787 µs) that indeed span over the index.