View Single Post
Old 06 March 2014, 18:17   #32
Cheesy crust

mr.vince's Avatar
Join Date: Nov 2008
Location: Hawk's Creek
Age: 42
Posts: 1,374
Originally Posted by JimDrew View Post
"Customers" did not supply scripts. These were created by the duplication houses as part of their service. I had hundreds of thousands of disks produced on these machines. I also sold protection schemes to some companies that had to be duplicated on these machines, so I worked with a couple of duplication houses to be able to create the proper scripts to do that.
Great - so we agree! Scripts had to be made. There was no blind copying; Trace was against flux level copying - as this could not be verified. Let's ask Rob Northen for advice:

Interview conducted by Codetapper:

Trace would supply format files to read-in standard formatted disks, but if the format was non-standard, as in a protected disk then the duplicator would have to write a format file of their own to read-in the floppy. I always supplied the format files for Copylock protected disks. This made the duplicators job a lot easier. Format files could be supplied in object form (uneditable) or source (editable).
Before Rob could create his own key disks, he'd send scripts to Trace and get key disks in return. The computers he used were unable to create the protections he used, so he could not supply master disks otherwise.

Flux level copying is a gamble. You never know if the data is valid, you can not verify.

Originally Posted by demolition View Post
These scripts you're talking about, could they be automatically generated for all master disks or did it involve some manual work? If the last is true, then that sounds like IPF generation where you not just copy blindly, but try to describe the format on a higher level to be able to verify it properly.
Exactly. We can/will deliver a set of standard scripts, e.g. for Rob Northen's Copylock, and several others. These can then be used as the basis for new scripts, which can be created by users. We intend to set up a repository, so people can search and exchange scripts.

Scripts will generate results and let you know if the raw data present matches a format. And you will be able to transform the data, e.g. for MFM disks created on a PC. The PC only writes sectors, whereas the Amiga writes tracks. This means disks created on a PC have a write splice for every sector. Many Japanese games were duped this way. So to create an archival master, that can be verified against other disks of the same game, such bogus data needs to be removed. A transformation script would remove these mini splices and create a master track.

We can already do much of the above with the IPFs we do. Because the Analyser knows the formats it encodes, we can compare the data _within_ the format, thus ignoring e.g. weak bits and other rubbish in a write splice, which is never the same for two copies.

Originally Posted by demolition View Post
Isn't flux level disk copying similar to creating .TAP files from C64 tapes? Here you also look at zero-crossings in the source signal and create timing codes from them. If you rip the same tape in two different tape decks (or the same for that matter), the output will not be 100% identical, although they might both load just fine. Then there's tools like TapClean which can clean it up and in many cases make two rips be identical, but this requires knowledge of the loader being used. It will not be possible to clean it up completely if you're blind.
Yes, I'd say this compares very well. May I use your wording for a FAQ?

Originally Posted by demolition View Post
Unless there's an inherent hardware quantization in the timing of flux transitions (is it being latched with a clock in the floppy drive?), then it should be considered as an analog signal.
Yes, the disk itself is analogue. The signal goes through an amplifier and some noise cancelling and will then be converted to pulses by the drive's electronics. These pulses are then sent via the flat ribbon cable to the floppy drive controller. The signal is low active, so the drive pulls down the data line from +5V to 0V for a defined period of time. The information is in the timing, the signal strength does not matter. The trigger itself depends on the analogue readout, so varies slightly from revolution to revolution. This gets even worse due to drive wobble, friction and other fancy stuff. That's why no readout happens at exactly 300rpm. It's 299.59, or 300.61, or 301.02. The PLL ( in the floppy drive controller must take care of this...
mr.vince is offline  
Page generated in 0.04002 seconds with 10 queries