List of difficult to copy disks

[DrCoolZic]

Full rez:
http://hxc2001.com/disks_analysis/vrac/ ... 89_scp.png

Very interesting. What is the meaning of the two different green colors for sectors?
I have looked at the high resolution picture and it seems you are not detecting the "strange ID" located at end of track 1.
Here is a very high res portion of the image with this ID field

p47-hr-layout.PNG

This is a very special case. Normally the WD1772 only detect ID with exactly 3 sync marks. But 7 sync marks is a special case: after the first 3 sync marks the FDC expect an IAM but receive another sync mark so it immediately return to the sync search sequence and the next 3 sync marks followed by an IAM are corretly interpreted by the WD1772 as the start of an IAM
Here is the content of the buffer

p47-7sync-id-1-buf.PNG

But even more amazing this ID is placed on top of a "fuzzy area" (just after the $FF)

P47-track1-fuzzy-id.png

so if you read again (e.g. revolution 2) you get different content

p47-7sync-id-2-buf.PNG

Does not seems to be used as a protection for the game (obviously STX does not support this) but certainly not a coincidence!

[JimDrew]

Your confusion lies in the percentage of "what". My 47% window is of the separation between the common flux "zones". For Atari ST disk this is 2us, because the zones are 4us/6us/8us and that is 2us apart. Your assumption about how the WD1772 PLL works is not quite correct. The window used varies depending on what function it's performing, so the window changes between 12% and 15% tolerance of the bitcell times, not 10% as you elude to in your documentation. This is one of the main reasons why the WD1772 does some odd things with certain bitcell patterns between sync and header decodings (as your learned about earlier).

[DrCoolZic]

Jeff here is an experimental view of P47
I have generated an ultra high resolution image that you can download from here https://mega.co.nz/#!pwhQiDJb!lTG9CRKN7 ... Wj1oOGgIAI about 19 MBytes
Below is an extract

p47-out-of-band.PNG

as you can see the "out-of-band" bits are drawn with heavy white line.
so we can see on the "orange sector" (the "Atari sector" with intra-sector bit width variation) the offending bits.
and on the first "data track" the offending bits as well
interesting

Did you had time to look at viewtopic.php?f=95&t=21669#p263573
What do you think

[DrCoolZic]

Your confusion lies in the percentage of "what". My 47% window is of the separation between the common flux "zones". For Atari ST disk this is 2us, because the zones are 4us/6us/8us and that is 2us apart. Your assumption about how the WD1772 PLL works is not quite correct. The window used varies depending on what function it performing, so the window changes between 12% and 15% tolerance of the bitcell times, not 10% as you elude to in your documentation. This is one of the main reasons why the WD1772 does some odd things with certain bitcell patterns between sync and header decodings (as your learned about earlier).

Amazing a floppy disc controller with a two speeds DPLL
You should take a patent!

[DrCoolZic]

About the 7 Sync marks sequence
I have seen it on several games (not always coupled with fuzzy bits). Again does not seems to be used as a protection but interesting.

[JimDrew]

Your confusion lies in the percentage of "what". My 47% window is of the separation between the common flux "zones". For Atari ST disk this is 2us, because the zones are 4us/6us/8us and that is 2us apart. Your assumption about how the WD1772 PLL works is not quite correct. The window used varies depending on what function it performing, so the window changes between 12% and 15% tolerance of the bitcell times, not 10% as you elude to in your documentation. This is one of the main reasons why the WD1772 does some odd things with certain bitcell patterns between sync and header decodings (as your learned about earlier).

Amazing a floppy disc controller with a two speeds DPLL
You should take a patent!

Perhaps they should have, but that is really how the WD1772 FDC works internally. I don't think it is by accident either. I think this change was made from the WD1771 to help sync detection.

[Brume]

Hello Brume,
Here is what I think...

Hey DrCoolZic,
Thanks for your help and the explanation about the CRC. I've read it carefully and I understand better the issue. I just hope I didn't arouse an old debate
Thank you also for the tip about Aufit. I didn't know you integrated such a great feature, it's really helpfull. I've played with the rev button, but only the revolution #5 gives me good results (rev 1, 2 , 3 and 4 displayed sector #6 as "bad CRC" + "Fuz"). Aufit generated a working copy of the game, like the .STX you posted here. This feature is really cool and I'm pretty sure it will help me in the future.

Now, about my KF dumps: no, I never used the guided format option. Do I really have to do?
Let me know. Of course I won't redo all the dumps I've done until now (impossible task!), but I can use this option for the next dumps if it's really essential.

[IFW]

Having a guide format ensures that if the track data being read contains errors the track gets redumped automatically - so you can save a lot of hassle and time actually using a guide format.

[DrCoolZic]

Yes guided format is nice on non protected disks as it just retries when error are found. The only drawback is that on protected disk the imaging time is increase a lot as for each track with errors.
I was using this mode originally but now I prefer to dump in non guided mode and check with Aufit.
By the way new version is progressing well and is much more faster as it heavily uses multi-threading and therefore checking a disk is fast ...
But I am still stuck on some problems ...

Yes the capability of choosing the rev for writing stx is nice but not perfect. All correctly read track have to be on the same rev. I had some disk where I had one track good on one rev and another one good on another rev and in that case it wont work. This is why I hope in future to provide a mechanism to pick the correct rev automatically (of course if possible)

[Jeff_HxC2001]

About the 7 Sync marks sequence
I have seen it on several games (not always coupled with fuzzy bits). Again does not seems to be used as a protection but interesting.

I think that this is used to sync the FDC. This may be usefull for the read track command.

For the moment i prefer to not display such details on the disk view. The track view is a better place to display.

Anyway these sync bytes can be found here :

Image7.png

Image4.png

[Jeff_HxC2001]

BTW i have done some mass stream images analysis :

http://hxc2001.com/disks_analysis/disks_0003/

Note : The actual version doesn't yet decode GCR C64 disks and the DPLL have some difficulties with Apple GCR images, but i am working on this

Some PC88/PC98/X680000 images :
http://hxc2001.com/disks_analysis/disks_0002/

[DrCoolZic]

this is effectively massive

[JimDrew]

Please tell me that was done using some sort of auto-load and analyze function based on the disk type ID in my .scp structure!

[mc6809e]

Here are more details.
Gunship and P47 both use what I call intra-sector bit width variation.
http://info-coach.fr/atari/software/Gam ... sea_compil will be soon updated with more technical details

Interesting magnetic ghost effect on the Gunship P47
Look at the unformatted side 1 :

Image2.png

The ghosting is very interesting.

Possibly the same sort of thing happens on every disk to some degree.

A fresh write to one side appears to weaken what is on the other side.

I wonder: is there any way to take advantage of this is recover old marginal data that might be otherwise corrupt?

[DrCoolZic]

I doubt?
It is already amazing to see this but signal is far from being usable.

[Jeff_HxC2001]

Please tell me that was done using some sort of auto-load and analyze function based on the disk type ID in my .scp structure!

Sure ! I just used the batch converter function of the HxC software + Irfanview. I just let the machine do the job.

[Jeff_HxC2001]

Here are more details.
Gunship and P47 both use what I call intra-sector bit width variation.
http://info-coach.fr/atari/software/Gam ... sea_compil will be soon updated with more technical details

Interesting magnetic ghost effect on the Gunship P47
Look at the unformatted side 1 :

Image2.png

The ghosting is very interesting.

Possibly the same sort of thing happens on every disk to some degree.

A fresh write to one side appears to weaken what is on the other side.

I wonder: is there any way to take advantage of this is recover old marginal data that might be otherwise corrupt?

Yes i see some others disks with this effect. To be able to see this , the side 1 must be unformatted.
i don't think that you recover something from this side, but sometime the software detect some valid Address/data mark..

[mc6809e]

Yes i see some others disks with this effect. To be able to see this , the side 1 must be unformatted.
i don't think that you recover something from this side, but sometime the software detect some valid Address/data mark..

I was thinking more along the lines of finding some way to cancel out the "noise" that penetrates from one side to the other.

If one side can be read, but the other side has trouble, then maybe there's some way to subtract away the signal that has penetrated through the disk and so allow bad data to become readable.

[IFW]

Yes i see some others disks with this effect. To be able to see this , the side 1 must be unformatted.
i don't think that you recover something from this side, but sometime the software detect some valid Address/data mark..

I was thinking more along the lines of finding some way to cancel out the "noise" that penetrates from one side to the other.

If one side can be read, but the other side has trouble, then maybe there's some way to subtract away the signal that has penetrated through the disk and so allow bad data to become readable.

Highly unlikely in the digital domain that you get from the drive - the signal is too weak and the filtering eliminates most of what might be otherwise readable by a more sophisticated signal processing possible today.
Plus you only get 0 or 1 - which is the result of the analog signal being filtered/amplified, nothing else.
Subtracting the waves etc. would require the analog signal.

[JimDrew]

It's also unpredictable in nature (not to mention backwards, due to the disk spinning the opposite direction). You don't get enough a signature to even get the same data on consecutive reads. It would be possible if you built new drive electronics where you had access to the analog signal and could use some high level FFT coding on that signal. So, it's not something that we will see using the current preservation techniques.

[JimDrew]

Why did this thread get moved out of my SuperCard Pro area? I created this thread to discuss difficult to copy programs for testing with SCP.

[Brume]

Why did this thread get moved out of my SuperCard Pro area? I created this thread to discuss difficult to copy programs for testing with SCP.

I moved it because it has been deflected from its original topic. This thread contains a lot of discussion not related to SCP.
But of course nothing is fixed. If you think it's better to keep this thread in the SCP forum, I'll remove it. Let me know, Jim.

[JimDrew]

Well, my intention was to keep this thread for information on difficult to copy programs, and how SCP is to be setup to duplicate them. SCP has an analyzer/editor portion to its software and many of the posts pertain to information about how the protection is seen through the SCP software.

[DrCoolZic]

I got Theme Park Mystery and Dragonflight in today. Both copy and image perfectly.

So, at this point "Crown Of Creation 3D" remains as the only program that is suppose to be difficult to copy that I have not yet seen. Does anyone have this program?

Hi Jim can you do me a favor. Create some SCP from dragonflight.
There is a version on your FTP site but the generated FD do not work.
So what I would need is the following
1) a good sampling of disk a / b-c / c if possible with multiple revolutions - 5 would be perfect

2) start the game and select create a backup
- you will be asked to format a disk at the end a number will be provided - please note this number
- now copy disk b to this newly formatted disk (follow instruction)

I never succeeded to go that far is always indicates that the disk is corrupted ??? So seems like my copy did not succeed
- it might also ask you to make a backup of disk c?

3) So now you should have one or two new "backup disks" created
Please create scp images of these backup disks if possible with multiple revolutions - 5 would be perfect

and publish or send
thanks in advance

[JimDrew]

First of all, that is not my FTP site. Secondly, I don't have an original Dragonflight but the Dragonflight images do generate working disks. What happens when you try to boot the copy?