Looking for Rob Northen originals images

[hakkuh]

Hiya !

I'm Looking for Rob Northen originals images to understand what it exactly does. If anyone have some or can tell me where. Thanks.

[ijor]

There are some Pasti images of CopyLock protected disks (like Xenon 2, Populous, etc) floating around, including in the binaries newsgroup.

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.

The code reads the "protected" sector measuring the time it takes, does the same with a "normal" sector; and then compares the time. If the difference is at leas the expected one, the code assumes the disk is original.

In all disks I've seen the "protected" sector is #6 on track 0. The protected sector also has a key that it is used to decrypt the software. The idea is that you can't use the protection on one disk to decrypt a different game.

Some disks have a few additional disk checks. And there is an earlier CopyLock protection that is much simpler and can be copied with a software copier.

There are several variants of the code. Most of them include a PACKER. A code for stopping debugging and hacking. The packer executes encrypted code by tracing each instruction, decrypting the next and reencrypting the previous one. That's why when the protection is run it runs very slow.

Most of the time the protections runs only once as a wrapper to the main code. Others it's embedded in the main code and can be run several times during run-time.

The Packer was also used by other disk protections. Probably they licensed the Packer separately from the on-disk copy protection.

[hakkuh]

Huum... I've found the RNC packer & see the whole pack to protect games. But as there some variants, could you tell me where I can dl some img? Thanx.

[hakkuh]

The Trace protect u dial about is the Trace Vector Decoder (I learnt the TVD basics from an amiga one, clever code!).

[ijor]

Google is your friend. Search for "pasti atari xenon2".

[hakkuh]

Kewl. Gonna look at this. Thanx.

[leonard]

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.

Hey Ijor I'm very interested by low level technical details about it. I was too young at rob-norten protections and I don't know anything about asm coding at that period.
Now I want to know how does it works ? Do you mean the data are written with another floppy rotational speed ? In that case, did the ST floppy engine slow down when reading that "slow sector" ?
Could you give more info on how the FDC know it must "slow down" or "speed up" to read the #6 sector ?

Thanks in advance

[Mug UK]

Not sure how much use the official Rob Northen code would be to you Leoard, but it's on my site for reading.

Ijor is the king of FDC on here, so if it's a more technical answer you're after, I'll leave you in his hands.

[Zippy]

The ST floppy drive reads the track at the same speed as normal, but the data either comes into the floppy controller slower or quicker than normal depending on whether the drive motor was speeded up or slowed down during writing.

I experimented with disc protection a bit, just with a "long track" by slowing down the drive (which was basically how the "proto-scan" ST/AMIGA protection system worked). There was a util which displayed the floppy RPM in realtime and you could adjust the motor speed up/down about 5-7% and it still worked OK.

If you speeded up the drive then the disc would rotate quicker meaning the time for a single rotation was reduced... the FDC would write data at the normal rate so the track would be shorter (less bytes) than normal.

Conversely, if you slowed the drive speed down then you could write more data during a single rotation.

When reading the track back in at normal speed the bytes of the "long track" would be shorter and coming in quicker than normal, with a "short" track the bytes would be longer and coming into the FDC slower.

The rob northen protection varied the drive speed (during writing of the keydisk) only on 1 sector, and then compared how long it took to read that sector back in in relation to how long it took to read one of the normal sectors from the same track.

[ijor]

Hi Leonard,

Hey Ijor I'm very interested by low level technical details about it.

In a “normal” ST system the FDC writes at a bit-rate of 250 Kbps (one bit every 4 microseconds).

The bit-rate (so to speak) on the magnetic surface depends also on the rotational speed of the drive. Technically there is no such thing as bit-rate in the disk, but there is density instead. The mechanical motion of the disk has the effect of translating distance (density) to time (bit-rate) and vice versa.

So the final bit-rate produced when reading, depends both on the written bit-rate and the relation between the rotational speeds of both drives (the drive used when writing and the current drive used when reading).

Normally both drives would rotate in theory at the same speed (300 RPM) and then the read bit-rate would be “exactly” the same as the written one. Obviously that in practice, there are always small differences, and even the speed of any drive is not exactly constant. But the difference normally is very small and you “read” what you “write”.

But this doesn’t need to be the always the case. The drive used when writing might rotate at a very different speed. Actually, almost all ST (and modern) original disks were written with a drive rotating much faster.

For speeding duplication, duplicators typically use “faster” drives at a minimum of x2 (600 RPM), x3 (900 RPM) or even x4 (1200 RPM). The written bit-rate must be altered proportionally to compensate for the faster rotational speed. If using an x2 speed drive, the duplicator’s controller uses a bit-rate twice as fast (500 Kbps).

So it is important to understand that alterations on the “destination drive speed” and on the original bit-rate written by the controller, are equivalent. A drive rotating twice as fast, or a controller writing twice as fast, has exactly the same effect. And if both are altered in the same proportion, the effect is nullified.

In that case, did the ST floppy engine slow down when reading that "slow sector" ?

No. Within certain limits, the reading FDC will adapt itself to the bit-rate coming from the disk drive. This is thanks to an FDC component called “PLL” (Phase-Lock Loop). The full explanation is a bit complex. Probably there are good on-line descriptions about how a PLL work (PLL is not restricted to drives). Just google PLL.

The important point for our purpose is that the FDC will deliver data to the computer at the rate sent by the drive. So if the disk was written at a faster bit-rate, the FDC will take less time to read a sector.

Do you mean the data are written with another floppy rotational speed ?

Not exactly. Changing the drive speed was sometimes used as an “amateur” way of creating or copying some protections. But it is too unreliable and too cumbersome for professional use. And it is probably even unfeasible to change the speed of the drive accurately enough in the middle of a track.

Instead of altering the drive speed, the controller bit-rate when writing was altered. Obiously, electronics are faster and more reliable than mechanics. A standard FDC uses a constant bit-rate (assuming a constant density, clock and modulation). But advanced controllers allow for changing the bit-rate “on the fly”. That’s how a duplicator’s controller created the protection. And that’s how a Catweasel or a Discovery Cartridge can copy CopyLock disks using a standard speed drive.

[Zippy]

Ijor - very interesting, I learned something there! 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.

[ijor]

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.

Well, some older (8-bit) commercial disks were indeed protected modifying the drive speed. And some Atari 8-bit hardware copiers had a switch that allowed to change the speed. Cheapers models had a manual switch, others was eletronically controlled by the software/firmware.

But this was for producing long/slow tracks, and only when advanced controllers were not available or not affordable. This can't be done fast and accurately enough in the middle of a track, as the CopyLock protection requires. Even modern hard disks and CD-DVD readers take a significant spin-up time.

It is interesting to note that measuring the sector time in the ST is not so easy. This is because the DMA chip seats in the middle between the CPU and the FDC (you can disable DMA if you want, but it won't help). Not so difficultl for CopyLock, but harder for other one:

There is another ST protection, more advanced than CopyLock if you want, that has a variable bit-rate in the very same sector. The sector is divided in sections and each section has a different bit-rate. The average is the normal/nominal one!

Actually CopyLock has a variable bit-rate in the protected sector as well. But the protection doesn't check this. It just checks if the average rate is slower enough than other sector.

[Total Eclipse]

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]

Ijor, thanks a lot for that long and complete explain ! Your explains are always interesting.

You're really a floppy knight !

[insanity]

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???

If a program bombs out it is generally because it didn't expect or
doesn't handle a certain scenerio... Golden Axe may have been the
cause forcing it to do something stupid but defensive coding, such
as boundary checks, should prevent this!

I suppose, as with all things, protection evolved and the programmers
of ACopy may have thought the certain scenerio was either unlikely
or impossible...

Golden Axe's protection couldn't have been that good!

[leonard]

Hi Ijor, me again

Just after writing my previous message, I wonder a question

How does Pasti image-maker work for rob nothen disk ? I mean, if you read an original track, you get all data, but you can't know if a sector was written at higger speed or not ? Did pasti image include disk data + timing info on each sector ?

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 ?

[ggn]

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 ?

I think that in the "normal" speed we can fit 9 sectors per track and the maximum allowed is 11 for Double Density disks. 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!

Well, of course Ijor can verify my speculation more accurately.

[ijor]

Ah, this explains why I was able to copy Xenon2 using a Blitz Turbo.

The actual reason you were able to copy Xenon2 with the Blitz it's because it uses an older variation of CopyLock. The on-disk protection is the same, but the protection check was enhanced in later versions.

Analog copiers as the Blitz have no troubles in reproducing the variable bit-rate. But they have a hard time aligning the tracks, something that is checked by most newer CopyLock variations.

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???

Sorry, haven't seen an image of Golden Axe, so I don't know which kind of protection it has. But as "insanity" explained, if the copier crashes it's because a bug of the copier. This doesn't have much relation with the protection being more or less advanced. A more advanced protection can make the copier failing in making a working copy, but not in making the copier itself to crash.

[ijor]

How does Pasti image-maker work for rob nothen disk ?Did pasti image include disk data + timing info on each sector ?

Yes.

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 ?

I don't know the exact range, but it is quite small for reading without errors. Something in the order of 4-5% off the nominal rate. It’s not symmetric. It seems the FDC is more tolerant for slower than faster bitrates.

You can extend the range (probably to around 10%) if you don't mind getting some errors (could be useful for a protection).

The exact numbers will be different for a different FDC (it mostly depends on the PLL). For example, the FDC on a PC usually has a better tolerance.

Note that there is a limit imposed by the drive and the media as well. Even when using, say a Discovery Cartridge for reading and writing, you can't increase the bit-rate too much.

maybe we can fit 13,14 or 15 sectors per track ?

Sorry, no chance.

There are some ways to get more data per track, but not more sectors. Actually the best way to do this is to use less sectors. Each sector has an overhead (sector header, syncs, and the gap bytes between header and sector and between two sectors). So one sector of 1024 bytes takes less space of the overall track than two 512 bytes sector.

Many games use this "trick" to fit more data. You can easily fit 5 1024 bytes sectors, plus a normal 512 bytes one. And this is much more reliable than using 11 sectors per track.

Combining this with a slight increase in the bit-rate, plus some gap tricks, and you can reach 6 1024 bytes sectors per track.

Btw, Leonard, please check your email.

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

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]

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.

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?

(sorry, getting a little off-topic here, but whatahell, it's still Atari machines )

George

[ijor]

(Re: Atari 8-bit tape bit-rate)

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?

There are both hardware and software limitations. I am a bit rusty with the topic, didn’t mess with tape code for some centuries. So I don’t remember the exact numbers, but it’s more or less like this:

The data on the magnetic media is written using FSK. One audio frequency is recorded for each 1 bit, and a different frequency for each 0 bit (Atari called this two-tone mode). When reading, audio filters in the tape unit translate each frequency to 1s and 0s.

If the bit-rate is too high, the bit cell is too small and then there would be too few periods of the audio frequency. Then the audio filters would react too late or they won’t be able to distinguish the two frequencies at all.

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]

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.

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.

If you have a working keydisk and a non-working copy off an original this program will write the copy back over the working keydisk and change the "magic number" to the correct value, thus creating a working original. 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%.

There are full instructions on the help screens in the program.

[ggn]

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.

I am too very rusty on this, because I was never so hot on the subject (I was too little to understand stuff back then ), but I remember that the data were being loaded into a 128-byte buffer and then issued for decoding. I guess that if the decoding wasn't complete when the new steam waltzed in the buffer, the procedure would fail (and tears from my eyes would start flowing )

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.

Cool

[bit5]

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.

... and in addition -from the master himself- a tool to verify the written keydisk and print out the magic key number. Of course it is encrypted but it doesn't contain tons of garbage code like in the protected programs. Just search for $4afc as usually

[ijor]

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%.

You mean to modify a Pasti image under emulation?

It will work only temporarily. Pasti allows writes to a copy protected image. But currently the changes are lost on eject, they are not saved to the image file. Also not every type of write is supported, not even temporarily.

Hopefully this will be enhanced and expanded in future releases.