CopyLock protection has a portion of one sector with a different bit-rate than the nominal one. A different bit-rate means that it will take a different amount of time to read.
leonard wrote:Hey Ijor I'm very interested by low level technical details about it.
In that case, did the ST floppy engine slow down when reading that "slow sector" ?
Do you mean the data are written with another floppy rotational speed ?
Zippy wrote:I always thought they just had very accurate control of drive RPM speed and varied it during writing the protection, but of course as you say it's a lot easier and more reliable to vary the bit rate of writing the data, with a constant RPM of the drive.
Total Eclipse wrote:One game I recall having odd protection was Golden Axe - I recall that one actually caused Acopy to bomb out part way through the copy - anyone care to guess how it managed that???
leonard wrote:Other question, which might be more interesting (to me ) : You said if it stay in a range, a drive can write data at higher bitrate, and data is still redeable on a classic ST. What's the size of the range ? Do you see what I mean ? I think: imagine an advanced controller writing at 1.5 speed. If the disk still is readable by ATARI FDC, then I can do working atari disk with more data ?? maybe we can fit 13,14 or 15 sectors per track ?
What's your opinion about that ?
Total Eclipse wrote:Ah, this explains why I was able to copy Xenon2 using a Blitz Turbo.
One game I recall having odd protection was Golden Axe - I recall that one actually caused Acopy to bomb out part way through the copy - anyone care to guess how it managed that???
leonard wrote:How does Pasti image-maker work for rob nothen disk ?Did pasti image include disk data + timing info on each sector ?
You said if it stay in a range, a drive can write data at higher bitrate, and data is still redeable on a classic ST. What's the size of the range ?
maybe we can fit 13,14 or 15 sectors per track ?
ggn wrote:BTW: this reminds me of the old tape controller I used to have on my Atari 800XL. Its bitrate was 600 baud (!), and by using a special program I could re-write the images at up to 850 baud without errors
ijor wrote:Oh the Atari 8-bit tape system! I could write pages about it
It is similar in some sense, but it is quite different in some aspects. One important difference is that the "receiver" clock can be changed in the 8-bit. But you can't (normally) change the FDC clock in the ST. Also the whole "protocol" and "encoding" is different. The 8-bit uses a simple serial async with start and stop bits, then the tolerance for variations is much better.
ggn wrote:Well, since you know somthing about the subject... The program that I had read the source file and could write it at speeds up to 1200 baud, but I never had any luck higher from 850 baud. I always thought that this was a hardware limitation. Am I right?
ijor wrote:There are both hardware and software limitations. I am a bit rusty with the topic, didn’t mess with tape code for some centuries.
Then there are software issues. The tape mechanical speed is not very constant or stable. So the operating system attempts to adapt the receiver clock to the incoming one. For this purpose each block of data has a header with two $55 bytes (an alternating 1 and 0 pattern). Because the pattern is known, the software can measure the time and set the receiver serial clock accordingly.
This procedure has the nice effect (likely not by design) that you can increase the recorded bit-rate (as you did), and you can read it back successfully without any need of modifying the read portion of the software.
The problem is how this procedure is performed. It is based on a table that translates the measured time (of the $55 pattern) to the value that should be poked on the receiver. The table is not linear, and is optimized and bounded for the nominal bit-rate.
Zippy wrote:Here's some more goodies found on my HD image, this program will help you create working Rob Northen Keydisk originals from non-working copies, if you already have 1 working keydisk.
Zippy wrote:I've included the COPY_ROB.PRG as well as the source code file and the 2 included binary files so you can change/assemble your own version if required.
Zippy wrote:In theory this should work with PASTI but i haven't tested it, so you may need a proper ST (with at least 1 MEG RAM) for it to work 100%.
Users browsing this forum: No registered users and 3 guests