Moderators: Mug UK, ijor, Moderator Team
DrCoolZic wrote:For reading, the process is reversed: the head is passed over the magnetic fields and a current of one direction or another is induced in the windings, depending on the polarity of the magnetic field.
Remarks on so called “analog copier”: ... This implies that doing copies through an analog copier do not degrade the strength of the signal (as it would do with a VCR) yet multiple copies (and sometimes even single copy) may fail but for totally different reasons (mainly due to rotation speed and/or synchronization of the two drives).
But weak bits can also be created on a media with no physical defects [followings are suggestions]:
- ??? By formatting only a portion of a track???
- ??? By writing information totally out of synch???
- ??? By ???
If you format a complete track on a “virgin” media and that during portion of a specific sector you “disable” the formatting this should result in weak transitions (in fact no transition) on the media?
We therefore need a more generic mechanism that can explain for example how a Discovery Cartridge performs a copy of a weak sector on an already formatted diskette…
I can only think of one way to create weak bits on preformatted diskette: By writing “uncorrelated” bits on the media. In other words by writing sequences of data which are not related (synchronized) with the pre-existing data on the media. This should result in random combination of new and existing bits and therefore result in random weak transition on the media?!?
ijor wrote:DrCoolZic wrote:
For reading, the process is reversed: the head is passed over the magnetic fields and a current of one direction or another is induced in the windings, depending on the polarity of the magnetic field.
Not exactly. The head doesn’t read the magnetic field polarity, it only detects changes. As in most electromagnetic applications, it is the variation of the magnetic field that produces the current. So you cannot know the absolute polarity, but only when there is a change in the polarity.
This is not the main problem of analog copier. This affects only the capability of them to copy some time of protections. But the drawbacks of analog copiers are much more far reaching. Search for analog copier in this forum. Some time ago I elaborated extensively in the issue
Sorry, I don’t really understand what you mean in this paragraph.
The two readings both start the same (here the first three bytes):
= DATA 515 bytes l=16454.47us @121.368ms *BAD CRC=7300
0ed4 4.00 fb 07 50 .|.|.|.|.|...|.| ..|.|.|.|..|.|.| ...|...|..|.|.|.
But after a while first reading:
0efe 4.00 07 07 07 ..|.|...|..|.|.| ..|.|...|..|.|.| ..|.|...|..|.|.|
And second reading:
0f2e 4.00 d0 d0 d1 .|.|...|..|.|.|. .|.|...|..|.|.|. .|.|...|..|.|..|
As you can see the flux is exactly the same but shifted by one position
DrCoolZic wrote:(analog+copier)But this was not my point. I just wanted to reinforce the fact that data signals coming in and going out of a floppy drive are digital signals and therefore there is no signal degradation during copy like it would happen with analog recorder (e.g. a VCR).
The problem is how do we create a weak analog transition ...
This where I do not understand how the DC would copy weak bits due to weak transitions ...
But the more I think about it the more I am convince that weak bits used for protection (not to be confused with weak bits due to defects) are probably based on timings rather than on weak transitions ?!?
There is no such thing as “weak transitions”, at least not that they were intentionally and professionally created. I never seen or heard any protection that is based on weak transitions. That would be too complicated to create and too unreliable.
Flakey bits: These are particular bit cells on a disk that indicate neither a 0 or a 1 clearly. They are indeterminate because they have neutral magnetic polarity. You can think of them as unformatted, and when read, they just return “noise”, i.e. random data...
Beginning of sector is ok (.=not transition |=transition scale 2µsec):
= DATA 515 bytes 16542.31us @ 0.000ms clk=4.01 *BAD CRC=314e
0000 4.00 fb 01 ff .|.|.|.|.|...|.| ..|.|.|.|.|.|..| .|.|.|.|.|.|.|.|
0003 4.00 ff ff ff .|.|.|.|.|.|.|.| .|.|.|.|.|.|.|.| .|.|.|.|.|.|.|.|
But after a while:
00a5 4.00 83 84 34 ||..|.|......||| .|..|......||... |.|..|.|..|||.|.
00a8 4.00 70 72 e2 |..|.|.|....|... |.||.|.|..|..||. .|.|.|..|.|..|..
00ab 4.00 4c 45 07 ...||.|..|.|.... |.||.......|...| ....|......|.|.|
00ae 4.00 24 d0 10 ..|.||.....|..|. ||.|...|....|... .......|..|...|.
00b1 4.00 8f c2 7f .||.|....|.|.|.| .|.|..|.|.|..||. ..||.|.|.|.|.|||
But this doesn’t matter. In first place the protections usually aren’t too strict about detecting weak bits.
DrCoolZic wrote:But you also mention that not all weak bits are like that … So question is how other weak bits are…?
As I mention in my original post I can think of long period without transition (this obviously violate the MFM encoding) that would desynchronized the PLL and trigger random read values. ???
With this DrT diskette the pattern looks totally random and alternate between pulses less than 4µs apart (short timing violation sometimes down to 2µs) and up to ~20µs (long timing violation) apart!
I did not pay attention to that but I bet it should result in fuzzy/weak bits (i.e. random values)? Would that be another form of weak bits?
Actually I am not at all interested in protection mechanism per se and how to crack or full them. I am actually interested in diskette's preservation and therfore in ways to make perfect duplication with the DC.
Preservation and perfect duplication are two different things. For the purpose of preservation you only need an image. The fact that you are unable to write back the image exactly as the original, or even not at all, doesn't affect preservation.
Take for example protections based on physical alteration to the media (such as laser burnt holes). You can preserve them with an image, but you can't write them back (not without a laser equipment).
DrCoolZic wrote:Yes it is true that it is better to be able to run a preserved image of a game on an emulator than nothing! But for me nothing replace running a game on an real old Atari with it’s mouse that have a very very special touch, the clunky and noisy disk drive, the small screen, …
I do not want to open a debate here but for me preservation is to be able to keep something as close as possible with the original.
games like Turrican that uses a strong erasure of area of disk…?
Is there a flag in the STX file that indicate weak sector so that when emulator reads this sector some "randomness" is returned? If this is the case do you record where this "randomness" starts?
As a matter of fact I have found that usually the beginning of weak sectors seems to always start correctly up to a point where the weak bits start.
Would it possible to get a description of the PASTI image format. I remember that you said in a post that you intended to make it public at some point in the future.
ijor wrote:Please bear with me a little more. I am introducing some significant modifications for the next version.
ijor wrote: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…
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.
Zippy wrote: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… 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.
ijor wrote:In a “normal" ST system the FDC writes at a bit-rate of 250 Kbps (one bit every 4 microseconds)… 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 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…
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 difficult 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.
I don't know the exact range for data bit-rate variation, but it is quite small for reading without errors. Something in the order of 4-5% offs 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).
Rob Northen wrote:From memory, I think the 'slow' sector had to take at least 15% longer to read than the other sectors or it failed the protection test...
ijor wrote: Seems that his memory is not too good. It is just ~3% slower, not 15%.
DrCoolZic wrote:First one short comment on the ~3%: I do not know the value used by RNC but the 15% number that Rob gives is the same value that can be found in CopyLockDecoder's Guide. Are they both wrong or did the CopyLockDecoder guys took this number from Rob?
Questions for (1): How do you measure the time to read a sector?
Actually this is a pretty smart protection as, if the bit-rate variation is kept within PLL data capture range, software would read the sector correctly and sector time would look normal!
Questions for (3): First question is how do we detect such sector? Actually do we try to do anything with this sector or is it there just to make any software copy attempt fail?
Also having this kind of bit-rate variation cannot be copied by software copiers. Any title that use this protection ?
And now for the last protection mechanism I want to cover: the data "under index hole" (which is not a hole with 3-1/2 diskette)...
but I do not know what king of error is returned (not documented in FDC) ... Do you know of any games that uses this protection???
ijor wrote:Questions for (1): How do you measure the time to read a sector?
There are several ways to do it. You can easily check how protections do it by using Steem's debugger.
There are some protections with variable bit-rate where the average is normal. But I never seen anyone that needs the data to be 100% correct all over the sector. That wouldn't be reliable.
ijor wrote:Questions for (3): First question is how do we detect such sector? Actually do we try to do anything with this sector or is it there just to make any software copy attempt fail?
Sorry, I don't understand this question.
ijor wrote:And now for the last protection mechanism I want to cover: the data "under index hole" (which is not a hole with 3-1/2 diskette)...
but I do not know what king of error is returned (not documented in FDC) ... Do you know of any games that uses this protection???
It doesn't give any error (why it should?). It is usually detected by the protection software by using the read track command. Several earlier US releases use this protection (F-15 I, Silent Service).
Found another protection mechanism:
Sector with Wrong Track Number in ID field
Added to the document as #21
ppera wrote:Looking to my small collection, I have more games without floppy copy protection, but with 'manual protection'. Preserving them should mean - image with some imaging program
Is someone worked on it?
ppera wrote:I'm 100% sure that my 'manual protected' floppies have not copy protection.
ppera wrote:There is in fact 2 level of 'standard floppy' for Atari ST serie. First is 9 sector/track, and it is what ROM format routine produces.
Second level is very flexible. ... that means that floppies with 1 to 22 sector/track are usable. It is checked, not theory.
One thing more: developers at Atari or DR made strange solution by floppy format - they choosed FAT size of 5 sectors, instead 3
ijor wrote:Btw, Pera, regarding the different FAT size, you might now know better than anybody else. Which kind of incompatiblity it actually represents?
Users browsing this forum: CommonCrawl [Bot] and 1 guest