Floppy Disk Copy protection

A forum about Atari protected floppy disks analysis, preservation, emulation, tools

Moderators: DrCoolZic, Brume

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 638
Joined: Mon Nov 04, 2013 5:23 pm

Re: Floppy Disk Copy protection

Postby JimDrew » Thu Oct 01, 2015 2:14 pm

That is true. Which is why I thought the SPS' mentality of only "their" version of the program is the only one that is correct is complete rubbish.
I am the flux ninja

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Floppy Disk Copy protection

Postby DrCoolZic » Tue Oct 06, 2015 9:27 am

Ijor as usual you raise some very interesting questions about fuzzy bits.

I am currently working in Aufit for adding the capability to retrieve “mastering information” from the flux transitions (similar to what CTA from SPS is doing). Basically the idea is that as long as the quality of the floppy disk is good enough to retrieve the mastering information, we should be able to regenerate a perfect image. This would allow Aufit to write perfect image for simulation using STX format, or to generate a perfect floppy using IPF or SCP format. Of course fuzzy bits is an important part of this process (I will use the term fuzzy bits for bit transitions that decode sometimes as 0 and sometimes as 1).

First I have identified several type of fuzzy bits that are either created intentionally (usually tested for protection) or unintentional (usually not tested). Here is a list of all the type of fuzzy bits that I am aware of:
• Random fuzzy bits
• Dungeon master fuzzy bits
• DrT fuzzy bits
• Unplanned fuzzy bits
• Others?

For each of these types of fuzzy bits I am trying to understand:
- How are they created on a master machine?
- How are they read by the Atari FDC?
- How can they be emulated?
- How can they be copied?

Random fuzzy bits:
This type of fuzzy bits is the result of unformatted areas on a track and is widely used for protection. Creating unformatted areas on a track is not possible with the Atari FDC and therefore the usage of special hardware is required (i.e. Kryoflux) as explained here http://forum.kryoflux.com/viewtopic.php ... t=20#p6586 .

When reading from an unformatted area, the floppy drive returns random flux transitions that are decoded as fuzzy bits (the durations and therefore the positions of the flux transitions differ from one revolution to the next). For more details please look at http://forum.kryoflux.com/viewtopic.php?f=3&t=749#p6551 ).

Detecting that a cluster of fuzzy bits belongs to the “random” type is not obvious. Several techniques have been used by programs that have direct access to flux transitions information. For example the HxC software uses some sort of correlation analysis between revolutions (see http://forum.kryoflux.com/viewtopic.php ... 9&start=10 ) that provides very accurate detection, Aufit uses Shannon entropy functions (less accurate but faster), and I do not know the technique used by CTA. For a program that only have access to decoded data like the Pasti imager, it is even more complex to detect this kind of information.

A perfect emulation of fuzzy bits resulting from unformatted area is not really possible. This is due to the fact that the durations of the flux transitions should follow a pseudo-random repartition that vary with floppy disks and floppy drives vendors. If you look here http://forum.kryoflux.com/viewtopic.php ... t=20#p6590 you can see that the probability reach a peak around 2.75 µs then decrease regularly.

But in practice it does not really matter as the protection only tests that subsequent reads of the bits in the unformatted area returns different results. For example the program checks that the content of a sector with an unformatted area in the data segment differ for each read.

Performing a perfect copy requires to detect the presence and position of the unformatted area and to recreate it on the backup disk. For example with the Kryoflux hardware it is possible to specify a weak sector in the IPF mastering file and that will result in an unformatted area. I do not know if it is possible to specify an unformatted area with SCP.

However, as mentioned for emulation, it is perfectly acceptable to directly copy the flux transitions from the source to the destination floppy as this is done for example with SCP. This will result in pseudo random transitions that are good enough to pass the game protection check. But making copy of copy should be avoided.

This type of protection is primarily used on sectors. In that case we talk of a fuzzy sector protection.

For example the track 79.0 of Atari Arcade Classic FD contains an unformatted area in sector 9 (6th sector). The unformatted area starts only after few bytes inside the sector’s data segment and extend few bytes after the end of this segment. This ensure that the data sector is correctly read and that all the bytes until the end of the segments return random values. You can see at the end of the track that we have another unformatted area. Actually it is very common to find unformatted areas at the end of all the tracks of a FD. This is due to the fact that sometimes only “meaningful” track content is written on the mastering machine (probably to speed up the creation of the floppy) and non-meaningful area at the end of the track is not written and therefore left unformatted.
random-fuzzy-bits.PNG


Radom fuzzy bits can also be used outside of a sector. In that case we talk of a fuzzy track protection (note that fuzzy track protection is not supported by Pasti format).
For example in Vroom track 78.0: we have a very small unformatted area (about 120 µs) located at position 179.7 ms shortly after three $A1 sync mark.
vroom.PNG


Another example is found in Power Drift track 01.0: we have a small unformatted area (about 250 µs) located at position 4.7 ms shortly after four $A1 sync mark.
power-drift.PNG


Dungeon Master fuzzy bits
The fuzzy bits used in Dungeon Master have been already described in many places and therefore I just present a short description of the protection here. To create this kind of fuzzy bit on a mastering machine a specific flux transition located between two adjacent flux transitions is slowly moved.
dm-fzb.PNG

dm-fuzzy-sector.PNG

We can see that the sliding transitions follow a triangular pattern.

When this kind of fuzzy bits is read, we have at some unpredictable point (when the transition crosses the 5 µs boundary) a decoded bit that changes from 0 to 1. The position where the bit flip from 0 to 1 vary between revolution due to flux drift (ISV and MSV).
The sector is filled of $68 bytes but due to the sliding transition some of these bytes get transformed to $E8 (upper bit changing from 0 to 1) when reading.
Therefore for emulation we use a byte mask array that looks like this:

Code: Select all

Sector 7 Fuzzy Bytes Mask array
3817 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3833 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3849 80 00 80 80 00 00 00 80 00 00 00 00 00 00 00 00
3865 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80

All the bytes in the mask array are $00 (no variation) except in some places they become $80 (random generation of 0 or 1). The program checks that subsequent reads of this sector returns different values and that only bytes $68 or $E8 are found.

Copying DM fuzzy bits is easy because the exact positions of the transitions is not critical as long as the “sliding transitions” crosses the 5µs border. Therefore copying DM fuzzy bits works perfectly with SCP, but unfortunately there is currently no support in Kryoflux.

DrT fuzzy bits
Most programs (except early ones) created by DrT uses fuzzy bits that are a sort of combination of DM fuzzy bits and unformatted area.

They first start with an area with sliding transitions that follow a pattern different from DM (probably not to violate the patent) that I refer to as a fishbone pattern. We have sliding transitions in the 4 to 5 µs range that are compensated (not to disturb the DPLL) with sliding transitions in the 3 to 4 µs range. This area (about 5 ms) is followed by an unformatted area.
drt-fuzzy-sector.PNG


When reading the first part, at some unpredictable point (due to ISV and MSV), some of the transitions crosses the 5 µs border resulting in bits read as 0 or 1. The sector is filled with $00 bytes but due to the sliding transition some of these bytes get transformed to $01 (lower bit changing from 0 to 1). Reading the second part of the sector return random fuzzy bits.

Therefore for emulation we use a byte mask array that looks like this:

Code: Select all

Sector 10 Fuzzy Bytes Mask array
5650 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 01
5666 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 01
5682 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 01
5698 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 01
5714 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01

All the bytes in the mask array are $00 (no variation) except in some places they become $01 (random generation of 0 or 1).

Copying DrT fuzzy bits first part is easy because the exact positions of the transitions is not critical as long as the “sliding transitions” crosses the 5µs border. Copying the second part (unformatted area) has already been explained. Therefore copying DrT fuzzy bits works perfectly with SCP, but unfortunately there is currently no support in Kryoflux.

Unplanned fuzzy bits
Unplanned fuzzy bits do not happen on purpose and therefore are not tested. In general they are the result of long flux transitions like in the case of No Flux Areas. This kind of flux transitions violates the MFM rules causing the desynchronization of the FDC DPLL and this results in unplanned fuzzy bits due to small flux drift (ISV & MSV).

Here an example of an NFA with unplanned fuzzy bits
turrican-nfa.PNG


Unplanned fuzzy bits also appears with tracks that contains several tens of overlapping sectors like in Au Nom de l’Hermine (70 sectors)
andlh.PNG


Other type of fuzzy bits
I am not aware of other kind of fuzzy bits, but I am open to learning.

Question about Kryoflux capabilities
  • For “random fuzzy bits” I know that the weak sector definition exist in IPF format. Are fuzzy bits on a track (outside of sectors) supported? In that case how.
  • Is it correct to say that Dungeon Master and DrT type of fuzzy bits are not supported?
  • Is there any other type of fuzzy bits supported by KF?
  • When specifying unformatted track in IPF format does that results in keeping the write data line negated for the duration of the track?

Questions about SCP capabilities
  • Currently, as far as I understand, SCP copy random fuzzy bits directly from source to destination. Is there a way to indicate in SCP format that an area is unformatted? In other word having SCP that keep the Write Data line negated for the duration of the unformatted area.
  • Is this possible for an entire track (equivalent to completely unformatted, factory new track).
You do not have the required permissions to view the files attached to this post.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Floppy Disk Copy protection

Postby DrCoolZic » Tue Oct 06, 2015 9:31 am

Same information in pdf
You do not have the required permissions to view the files attached to this post.

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 638
Joined: Mon Nov 04, 2013 5:23 pm

Re: Floppy Disk Copy protection

Postby JimDrew » Tue Oct 06, 2015 5:45 pm

DrCoolZic wrote:Questions about SCP capabilities
  • Currently, as far as I understand, SCP copy random fuzzy bits directly from source to destination. Is there a way to indicate in SCP format that an area is unformatted? In other word having SCP that keep the Write Data line negated for the duration of the unformatted area.
  • Is this possible for an entire track (equivalent to completely unformatted, factory new track).


You can ALWAYS duplicate weakbits exactly as the original, and you only need one revolution to do it. However, you have to know how weakbits actually work and adjust the flux data so that what is written becomes what was read. That took a lot of work experimenting with different types of drives to get it right.

So, yes, it is possible to hold the /WRData line high (or low) during the write phase of the revolution while /WREn is low... but it's not necessary, and that will certainly not reproduce the weakbits exactly.

I do NOT consider ANYTHING "unformatted". This is flux data, not any type of decoded data. So, there is actually no "format" at all, just a series of magnetic transitions that need to be reproduced exactly, which certainly can be done.

It's easy to see that the "fuzzy bits" protection with DM generates a particular pattern, one that can be easily re-produced with very little adjustment to the bitcell data. This is no different than standard 4us/6us/8us bitcells for flux copiers. Everything in between is automatically copied... in fact, everything is copied. It's only when you start exceeding certain thresholds with valid adjacent bitcells that you need to adjust the surrounding bitcells times in order to write back the data properly so that it reads identical to the original. This is not to be confused with write pre-comp.. that is a completely different method of correction.
I am the flux ninja

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Floppy Disk Copy protection

Postby DrCoolZic » Wed Oct 07, 2015 9:38 am

I understand that it works perfectly without unformatted areas today and that it would be difficult for you to detect unformatted areas.

However storing unformatted tracks (i.e. for single sided FD) is a lot of transitions for nothing. So it would be nice to be able to add in the SCP format a way to specify unformatted track and/or unformatted areas (hold the /WRData line high (or low) during the write phase of the revolution while /WREn is low). So that a program like HxC or Aufit could use this feature to have a smaller SCP and more accurate way of recreating unformatted tracks.

Just consider if this is feasible without too much work.
- For tracks this would require to hold the wrdata low from index pulse to next (plus few µs to be sure to overlap)
- For areas it would be more difficult. But it is already possible to specify areas for what you call strong bits (aka NFA) so something similar should be possible?

It would be nice because this is already possible with KF but unfortunately IPF is lacking several capabilities as explained in the fuzzy bits post.
This would allow to fully master what we write in SCP and this would be a true killer capability :)

subsidiary question about NFA
When we detect an area without transition we know that this is due to a NFA (aka strong bit): this is created by having transitions with a relatively high frequency ...
There is no "direct" indication of NFA in SCP format other than having a looooooong transition (e.g. several milliseconds). What is the "threshold" that causes your software to detect and write "strong bits" (HF transitions)? -- what frequency are you using?

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 638
Joined: Mon Nov 04, 2013 5:23 pm

Re: Floppy Disk Copy protection

Postby JimDrew » Wed Oct 07, 2015 11:23 pm

DrCoolZic wrote:I understand that it works perfectly without unformatted areas today and that it would be difficult for you to detect unformatted areas.


There is nothing to "detect". SuperCard Pro records the flux transitions as they occur, and during the write phase reproduces those transitions using a method that results in the data being identical to the original data that was read.


However storing unformatted tracks (i.e. for single sided FD) is a lot of transitions for nothing. So it would be nice to be able to add in the SCP format a way to specify unformatted track and/or unformatted areas (hold the /WRData line high (or low) during the write phase of the revolution while /WREn is low). So that a program like HxC or Aufit could use this feature to have a smaller SCP and more accurate way of recreating unformatted tracks.


Sorry, I refuse to do this. SuperCard Pro's sole purpose to reproduce a disk exactly as the original. Doing what you describe would go against the intent of the product by providing a sub-par representation of the disk, and would be the most inaccurate way to try to duplicate a track. If you want a smaller file for storage, use the 7-zip compressor. I am also adding the option to duplicate either side (or both), so that will reduce that extra space. You will be able to strip one side or the other as well with existing images. Keep in mind though, that single sided disks often have data on the other side (associated with the duplication system), so for me, duplicating everything is the true act of preservation.


DrCoolZic wrote:subsidiary question about NFA
When we detect an area without transition we know that this is due to a NFA (aka strong bit): this is created by having transitions with a relatively high frequency ...
There is no "direct" indication of NFA in SCP format other than having a looooooong transition (e.g. several milliseconds). What is the "threshold" that causes your software to detect and write "strong bits" (HF transitions)? -- what frequency are you using?


That also took quite some time to figure out, using several different types of drives and a logic analyzer to reverse engineer the flux converter logic. I will say that it's not a simple process and the flux duration presented in the .scp format is converted during the write phase to the proper groups of flux transitions (and frequencies), based on the several factors including track and drive speed. The entire process is something that I will not divulge.
I am the flux ninja

Maartau
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2593
Joined: Thu Dec 15, 2005 2:15 am

Re: Floppy Disk Copy protection

Postby Maartau » Thu Oct 08, 2015 4:56 am

Just some quick words : thanks to all for the infos you bring, I was aware there was lotsa "details" about Floppies, but far to know there was so much 8) .

I really appreciate your job, cheers for the sharing with the community :D .

My apologizes for this small post like a polluting, I just wanted let you know there are readers interested :cheers: .

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Floppy Disk Copy protection

Postby DrCoolZic » Thu Oct 08, 2015 2:27 pm

JimDrew wrote: Sorry, I refuse to do this. SuperCard Pro's sole purpose to reproduce a disk exactly as the original. Doing what you describe would go against the intent of the product by providing a sub-par representation of the disk, and would be the most inaccurate way to try to duplicate a track.

Never mind. The purpose was to reproduce the disk exactly as the original, with an unformatted areas, rather than as read by the FD controller. But as I said copying flux, even if not what was originally written, is good enough to pass protection tests so I will have to live with this. If I use KF I get the unformatted areas but not the DM fuzzy bits, if I use SCP I get the DM fuzzy bits but not the unformatted areas. I guess that's life :)

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 638
Joined: Mon Nov 04, 2013 5:23 pm

Re: Floppy Disk Copy protection

Postby JimDrew » Thu Oct 08, 2015 3:02 pm

With SCP you get EXACTLY what the disk has for information. Again, there is no such thing as an "unformatted area" at a flux level. The flux transitions captured by SCP are all valid whether from a brand new unused disk or a disk written to by a drive. You can easily determine from the flux data where weakbits are (you can see that in Aufit), so I am not sure what the issue is.
I am the flux ninja

ijor
Hardware Guru
Hardware Guru
Posts: 3147
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Floppy Disk Copy protection

Postby ijor » Sun Oct 11, 2015 3:12 pm

DrCoolZic wrote:This type of fuzzy bits is the result of unformatted areas on a track and is widely used for protection. Creating unformatted areas on a track is not possible with the Atari FDC and therefore the usage of special hardware is required (i.e. Kryoflux) ...


I don't think the KF or any other flux level hardware can create truly unformatted areas on a standard drive. The technical term for this level of unformatting is called degaussing, and it requires special hardware, precisely called a degausser. A standard drive can't really degauss for several reasons. But yes, you can create a very similar effect that will likely be enough for any protection.

As I said, I used to be able to distinguish just by looking at the hex dump of the flux pattern, and as along as the area was long enough, if it was really degaussed or if it was created by other methods already mentioned.

Detecting that a cluster of fuzzy bits belongs to the “random” type is not obvious.
...
A perfect emulation of fuzzy bits resulting from unformatted area is not really possible. This is due to the fact that the durations of the flux transitions should follow a pseudo-random repartition that vary with floppy disks and floppy drives vendors.


It is interesting to detect and analyze exactly how the weak bits were originally mastered on each case. But for emulation, and even for write back purposes is not that important. Well, yeah, on most platforms you have limited hardware random capabilities, and no pseudo random algorithm is perfect. Who cares?

However, as mentioned for emulation, it is perfectly acceptable to directly copy the flux transitions from the source to the destination floppy as this is done for example with SCP.


When I mentioned that you could copy weak bits by copying flux transitions verbatim, I was thinking more in write back than under emulation. Emulation is a bit different case. Write back creates an additional level of randomization and production of noise. This is because the write process, as the read one, also has mechanical and magnetic variations, and because the drive (and the disk) hardware has all sort of limitations on term of what transitions it can actually write.

This is good news and bad news, jaja. For random weak bits (random flux transitions) is good. For DM type weak bits (non random transitions), is bad. Multiple generations copies are, of course, more critical, but even the first generation has some risk if you write back like an analog copier.

Emulation is, in this regard, actually the opposite case if you think about it.

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 638
Joined: Mon Nov 04, 2013 5:23 pm

Re: Floppy Disk Copy protection

Postby JimDrew » Sun Oct 11, 2015 5:54 pm

ijor wrote:
DrCoolZic wrote:This type of fuzzy bits is the result of unformatted areas on a track and is widely used for protection. Creating unformatted areas on a track is not possible with the Atari FDC and therefore the usage of special hardware is required (i.e. Kryoflux) ...


I don't think the KF or any other flux level hardware can create truly unformatted areas on a standard drive. The technical term for this level of unformatting is called degaussing, and it requires special hardware, precisely called a degausser. A standard drive can't really degauss for several reasons. But yes, you can create a very similar effect that will likely be enough for any protection.


SCP can create exactly what the drive sees. So, regardless of why the RDData line is providing the data that it is, SCP can reproduce that same data exactly. If you deliberately erase a disk with a bulk eraser magnetic, it is a very recognizable pattern when reading it. SCP duplicates the same pattern exactly during a write. My point is that flux data can contain bitcells having a time of 1.00001us-200ms, and those bitcells are re-produced perfectly. They are just a flux duration, and if you know what is required to make consecutive bitcell times correct, then you can duplicate everything so it appears exactly as the original.

For emulation you don't need to do anything more than spool the bitcells times to the data separator. No randomizing is required. Look at the source code for handing .scp images in WinUAE.
I am the flux ninja

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Floppy Disk Copy protection

Postby DrCoolZic » Thu Oct 15, 2015 2:19 pm

Ijor,

I believe most of the confusion comes a gain from approximation in the terminology used. In particular what is the meaning of unformatted areas?

Let go back to floppy disk manufacturing process (http://www.madehow.com/Volume-1/Floppy-Disk.html) :
The recording media (Mylar) is coated with an extremely fine layer of iron oxide (for example, the layer thickness is 35 microinches for 3 1/2-inch high density disks). During manufacturing the Magnetic Domains (small regions in the magnetic media which may be magnetized independently of adjacent regions) are randomly oriented (ignoring the earth magnetic field) resulting in areas with null magnetization (summation of randomly oriented vectors). I will call virgin (or never-written) the state of the floppy disk after manufacturing.

When a virgin area (for example a track) pass under the drive head there is nothing to read and therefore the read channel picks up magnetic noises (partially due to the ACG pushed to its maximum) and the end result is the reading of random transitions.

As we know in order to be usable a soft sectored floppy disk needs to be formatted by writing adequate information on the media. Going from this formatted state back to the virgin state would require to degauss (https://en.wikipedia.org/wiki/Degaussin ... rage_media ) the media. As you mention this operation is not possible on a standard floppy drive as it requires special hardware (see for example http://www.protondata.com/product/proton-1090 ).

But even though it is not possible to degauss a track it is possible to erase that track. Doing so is just a matter of asserting the WG low and keeping the Write Data high. The write head generates a constant magnetic field which orients all the magnetics domains on the surface of the disk in the same direction. I will call erased the state of this area.

When an erased magnetic domains area pass under the drive read head there is no flux reversal (change in polarity while moving from one domain to the next) to read and therefore the read channel picks up magnetic noises and the end result is the reading of random transitions.

So we can see that both virgin and erased areas results in random transitions read. This is what I refer to as un-formatted areas: areas not formatted because virgin or erased.

Most probably, as you mentioned, the randomness of the flux transitions resulting from these two kinds of areas must be slightly different and recognizable.

Now let’s talk about what is done on a mastering machine.
Assuming that we use virgin (never written / never formatted) floppy disks, an unformatted area is probably obtained by not writing in this area. For example on a single sided diskette we simply do not write anything on the second side.
So if we want to have for example a sector with random fuzzy bits we just need to leave this sector untouched rather than writing random transitions.

Now let’s talk about what can done on a copy machine.
On a copy machine we certainly cannot assume that we are using virgin media (they were almost never sold like this). As a copy machine does not have the capability to restore a virgin area, for reason explained above, it has two options to reproduce unformatted areas:
  • The first option is to approximate the virgin area by erasing the data in this area
  • The second option is to approximate the virgin area by writing random flux transitions in this area.
As explained it is easy for any copier machine to produce erased areas but it is not always possible to access this capability.

On the SPS machine there is no way to specify in the SPS file that we want to create an erase area. Again this is not a problem as an eased area is read as random transitions that can be easily reproduced by the Supercard Pro.

Kryoflux takes a totally different approach. The IPF file does not contains any timing information and therefore it is not possible to directly specify random transitions. In fact the IPF file directly relates to CTA mastering language and it is just a matter of specifying that a track as unformatted, or that a sector uses a RN protection to write random transitions (I am not sure if random transitions are just recorded as random transitions or erased areas on KF? Only Istvan would be able to answer).

References:
http://info-coach.fr/atari/hardware/_fd-hard/AN-917.pdf
http://info-coach.fr/atari/hardware/_fd ... MAGREC.pdf
http://info-coach.fr/atari/hardware/_fd ... -disks.txt
http://info-coach.fr/atari/hardware/_fd ... 1de00a.pdf

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 638
Joined: Mon Nov 04, 2013 5:23 pm

Re: Floppy Disk Copy protection

Postby JimDrew » Fri Oct 16, 2015 4:07 pm

DrCoolZic wrote:As a copy machine does not have the capability to restore a virgin area


This is where you are mistaken!

You most certainly can duplicate what you call a 'virgin area' to be exactly as an original.

You can make an image of a brand new disk that has never been used in a drive, and write that image to another disk. When you read that copy back, it will in fact look the same as the original 'virgin' disk.

Like I said - if you can read it, you can write it exactly. During the write phase, there is a LOT of changing of the flux data to get this to occur though. You just can't directly write what was read. You have to be able to create the super short as well as super long pulses to make a read just like the original, and that means duplicating the same issues that cause the AGC to increase into it's feedback region. A bi-product of doing this is that strongbits (NFA) is also duplicated by default.
I am the flux ninja


Social Media

     

Return to “Floppy Disk Preservation”

Who is online

Users browsing this forum: No registered users and 1 guest