List of difficult to copy disks

[JimDrew]

I would like to collect a list of disks that people think are the most difficult to copy. I have very little experience with the Atari ST and what is hard to copy and what is not. The only title so far I have from this forum area is Crown Of Creation 3D.

I have copied/imaged everything I have successfully, but its not a lot of titles:

Dungeon Master, Chaos Strikes Back, Chaos Strikes Back - Utility Disk, Skyfox, Tower Toppler, Techno Cop, Devon Aire, Winter Games, California Games, Crimson Crown, Dive Bomber, Rambo III, Notator, CuBase, and a few other midi based apps.

I have a dozen more programs coming from the U.K and Canada.

If you know of something that is difficult to copy, please post it here. I will try to find it and verify that it copies correctly. Thanks!

[Brume]

Depending of what you mean with 'copy disks'.

There are tons of original ST disks we can't copy with Acopy (was the best tool for protected disks). Best way is to test with original games such as Maupiti Island, Space Ace, etc. Since they have their own format, Acopy can't deal with them. Hackers included their own copy-program at the start of each release they made. Also Dragonflight is famous to have one of the best protection ever made on Atari.

But there's also disks we can't copy with Pasti. In that case, one title comes to my mind: Au nom de l'hermine [French game by Coktel Vision]. Strangely, Acopy can copy it on another disk, but STX won't work.

[JimDrew]

Yes, by "copy disks" I mean make an identical working back up copy of a copy protected disk.

I know the Discovery Cartridge could copy a lot of stuff.. was there anything that it could not copy?

I will look for Dragonflight. Thank you!

[DrCoolZic]

Depending of what you mean with 'copy disks'.

There are tons of original ST disks we can't copy with Acopy (was the best tool for protected disks). Best way is to test with original games such as Maupiti Island, Space Ace, etc. Since they have their own format, Acopy can't deal with them. Hackers included their own copy-program at the start of each release they made. Also Dragonflight is famous to have one of the best protection ever made on Atari.

But there's also disks we can't copy with Pasti. In that case, one title comes to my mind: Au nom de l'hermine [French game by Coktel Vision]. Strangely, Acopy can copy it on another disk, but STX won't work.

Do you own the games mentioned above?
I would be interested to get KF stream image of all the tough to copy games, especially the game than cant be converted to Pasti.
I am surprise that games can't be converted to Pasti! Need to know if this is a problem with the program or with the format.

It might be interesting to see if it would be possible to convert KF stream files to scp file in order to create floppies on SuperCard Pro from KF raw file.
I am currently integrating spc format in my prototype and once "decoded" the kryoflux information is almost identical to scp information (not a surprise). The only information missing is the position of the index inside a flux transition. Usually it is not a problem on normal transitions of less that 8µs but for what I call" No Output Flux Transition" area (like used in Turrican) the position of the index inside a flux that can be several ms long becomes crucial. I have already discussed the subject with Jim and he will experiment when he receives the game.

I hope I will receive my SuperCard Pro soon so I can also directly experiment with my disks.
Obviously the nice thing with SCP is that you can immediately used the information you dump
And potentially we will even be able to create FD with SuperCard Pro using raw file from Kryoflux

Jim if you are interested I have source code to decode the complex stream raw file (I made it public domain) into structures equivalent to your file and I should be able to convert to scp easily (if you can provide index position )

[JimDrew]

I am not sure what you mean by "the index position". The flux data starts at the beginning of the index, and the end of the flux data is the start of the index again. Each of the 5 entries (one per revolution) contains the index to index duration, number of bit cells captured during that duration, and the offset from the TDH (track data header) to the flux data. In multi-rev dumps, the data is continuous and the table entries will give you the information for each revolution as it occurred.

Keep in mind that the SCP bit cells are 25ns, not 41.6666ns like KryoFlux. It's critical to use 16 bits to represent the flux transitions because weakbits can last thousands of microseconds.

Going from stream to .scp images would be reducing the quality of the image because of the difference in capture resolution. My goal was to replace the stream files with a higher resolution version in a format that was open and easy to use for emulators.

[DrCoolZic]

I am not sure what you mean by "the index position". The flux data starts at the beginning of the index, and the end of the flux data is the start of the index again. Each of the 5 entries (one per revolution) contains the index to index duration, number of bit cells captured during that duration, and the offset from the TDH (track data header) to the flux data. In multi-rev dumps, the data is continuous and the table entries will give you the information for each revolution as it occurred.

Why would flux transition be aligned with index? In reality the index is often used as a trigger for starting to write data and therefore the first flux is happening sometime after the index. Below is a view of data transition in respect with index transition.

Index-timing.jpg

It shows that the two signals are not synchronized. In normal case knowing the position is not critical because the transitions are less than 8-10 µs apart so it is not a big deal.

However with the No Output Flux protection the transitions can be several MILISECONDS apart and the index can be somewhere in the middle. In that case not knowing the index position means an “error” of several ms in the representation. For decoding / writing etc. it is not too bad as the data are “circular” and you might not care …

Below is a representation of what is happening in track 8 of Turrican. There is a No Output Flux area starting at roughly 199.7 ms in the track and that extent for 4299.17 µs. This means that it ends in the second revolution (here 204.2 equivalent to 4.2µs in the next revolution).

turrican-8-NFA-over-index.JPG

Keep in mind that the SCP bit cells are 25ns, not 41.6666ns like KryoFlux. It's critical to use 16 bits to represent the flux transitions because weakbits can last thousands of microseconds.

see reply here viewtopic.php?f=102&t=25848&p=242761#p242761

Going from stream to .scp images would be reducing the quality of the image because of the difference in capture resolution. My goal was to replace the stream files with a higher resolution version in a format that was open and easy to use for emulators.

Of course this is true. So if we were in "preservation business" like some other people we know it would be bad. But if we can succeed in creating a working copy (not a perfect copy) from a raw stream file this would be nice

[Brume]

Do you own the games mentioned above?

I have the original version of Maupiti Island (French version + German version: the format is the same on both releases). I have maybe Space Ace somewhere, too.
I don't have the original version of Au Nom De l'Hermine. I'd love to get the original version. I only have a copied disk made with Acopy. Game is still protected.
Will post them on the FTP asap.

[JimDrew]

Why would flux transition be aligned with index?

Because that is how disks were duplicated on TRACE and other types of machines. A duplication machine waited for the index pulse to appear and then wrote 1 or 2 full revolutions of data, depending on the speed of the drive. Most machines were 600 RPMs.

You keep looking at things from an "Atari" point of view, where you were stuck in a box because of the WD1772 controller. You need to look at the data at a flux level, ignoring syncs, sectors, etc. You never should be trying to decode the data at all for duplicating at a flux level, much like the TRACE and other machines didn't. You just find the index pulse, spool the data until you find the index again and that is the total data contained on the track. You write the data back out the same way. The only exception is if the track was not produced (deliberately or otherwise) without referencing the index pulse. In which case, spooling 2 revolutions (starting at the index, so you have a track skew reference) will guarantee that you have 100% of the data, including the write splice(s). Now, go through the data for the 2nd revolution and locate the splice. The total write length will be the length of the 1st revolution + the length of the data up to where you found the write splice. For the write, you would wait for the index and then write back the total calculated length. That's it. Locating the write splice is the only magic needed for flux copying. So, in your case with Turrican - if the protection checks the data that appears directly before/during/after the index pulse, it's no problem. You would read 2 revolutions, go through the 2nd revolution and locate the first write splice and write back the 1st revolution + the data up where you found the write splice.

[Stefan jL]

Now i don't know if this is difficult for devices like SCP and KF but the "pocket power" release of Bad Company can only be imaged using certain ST's or even just to play the game it only works on some ST's, i'm talking about PASTI images now.

[AtariZoll]

I did not hear so far about SuperCard Pro - maybe just because it is new
But it seems that it will be something more useful than Kryoflux - without need to send raw images to team and similar.

As games Space Ace and Maupiti Island are mentioned here, I can say that first uses pretty tight format of 6x1K sectors (with variable IDs) , what is of course not possible to write with regular HW. Whole serial of ReadySoft Space Ace and Dragon's Lair ST versions use same format. First couple tracks are with 11 x 512byte sectors, variable IDs.
Maupiti Island is one of many using track read, what is special case with WDC 1772. Some I saw recently with track read: Golden Axe, Hot Rod .
That could be interesting for emulation support too.

Considering Pasti: it is admitted by author (Jorge Zwick) that it can not image everythig, and here you may find some threads about few problematic releases.

Unfortunately, I don't have anything what is difficult to copy.

[Jake/Depression]

This read in forum pasti-side.
Power Drift - retail Activision release is harder to made.
Disc 2 cannot pastified. (3 discs version.) 2 disc version is easy and pasti is made already.

[DrCoolZic]

I have received from Brume Maupiti Island and I have analyzed it
This is quite interesting. My program display the information like this

maupiti-track-1.JPG

As this protection is not specifically handled it is seen as a huge gap after an ID
So it is interesting to see the result of the read track command

maupiti-1-top-buffer.JPG

We can see a sort of ID following the 3 A1 sync (for more info see description from Sarnau http://www.sarnau.info/atari:protection_maupiti_island )
So the Disk Layout looks like this

maupiti-disk-layout.JPG

Not mentioned by Sarnau the track 79 is interesting it is composed of 0xFF (could also be decoded as 0x00) and at the very end of the track we find two A1 sync folowed by 0x0x00.
Not sure this is part of the protection but it is interesting.

maupiti-79-bottom-buffer.JPG

Should be very easy for SuperCard Pro to copy this kind of track.

[JimDrew]

I hope someone will dump this with SCP. I have to work backwards in my mind and encode the data as MFM. This reminds me of most Amiga custom tracks (just one sector per track) and a wiped upper track.

[DrCoolZic]

Just looked at another interesting disk: Ghost Buster.
Apparently it uses the same protection as Turrican: an area without flux transitions (NFA) http://www.sarnau.info/atari:protection_turrican
below is the disk layout:

ghost-buster-disk-layout.JPG

As you can see track 0 and 4 have an area of about 5ms without flux transition just before the index mark
track 1-3 have the same NFA but the ID are placed close to the end of the track and the NFA just at the beginning

The picture below is a "wrapped" view of the track in the transition window the red line are the sync and the black line is the index. As you can see in the data graph the ID in yellow are placed just before the end of the track and the transitions stops also just before the end of the track. Therefore the NFA is located just above the index...

ghost-buster-track-1-wrapping.JPG

[Brume]

I hope someone will dump this with SCP. I have to work backwards in my mind and encode the data as MFM. This reminds me of most Amiga custom tracks (just one sector per track) and a wiped upper track.

I'll order very soon the SCP, so I'll dump my collection of disks with it. By the way, the price is only $99.95 instead of $149.95. Is it available for a few days only?

[JimDrew]

The price won't change until the floppy drive emulator is available, which will be a few months away still.

[alexh]

Dragonflight disk A?

Lethal Xcess & Monster Business (These are dual format copy protected disks which when copied must work on both Amiga and AtariST)

[DrCoolZic]

My new "Disk Data View" is interesting to see the No Flux Area - it is displayed in Yellow
As you can see on track 1 this is not really a NFA but a partially unformatted area (dotted yellow)
Yellow => MFM = 0 ==> Clock and data = 0

ghost-buster-disk-data.JPG

[Dal]

that utility of yours looks awesome.

[DrCoolZic]

Thanks DAL
I hope to be able to publish a prototype soon. It is a bit challenging because I am a C++ programmer and somewhat ignorant with GUI.
Therefore for this new project I am learning WPF and C# plus basic GUI, charting, .... and this is a lot ... plus WPF has a steep learning curve.
Currently the program has already most of the basic functionalities but the GUI needs a lot of work
The goal is
- to read input from most formats from flux level (KF raw, SCP raw, Discovery Cartridge Raw), bitpack level (IPF), protected level (STX, STT) to unprotected level (ST, MSA, DIM)
- From there it is possible to analyze the data to check protections
- to write output STX and ST for sure but maybe more like IPF or maybe raw

In summary this will be an FD analyzer / image Format converter.
The name is AUFIT (Atari universal FD Image Tool)

[JimDrew]

I might add the "disk" the SCP's analyzer tool. I have already added preliminary support for decoding MFM data, which is very interesting as there is quite a lot of difference between flux data and decoded sector data. There is extra flux that is ignored when framing the syncs, headers, etc. I will not be supporting IPF format, as that makes no sense with flux available. Instead, I will look at helping implement flux level support to numerous emulations.

[DrCoolZic]

I already have code to use IPF file ths is why I am considering read support. But IPF lack support for some Atari protections like Dungeon Master + plus it uses a totally different way of storing information that make it difficult to handle. Writing is a nightmare for reasons too long to explain here

[Hippy Dave]

My goal was to replace the stream files with a higher resolution version in a format that was open and easy to use for emulators.

Hi,
I'm watching this with interest because I would help where useful with the
Hatari ST emulator.

[DrCoolZic]

This post is mainly for Brume that provided me with some stream files to analyze:

Both « Au nom de l’Hermine » and « Sherman M4 » use the same protection that I have seen on some other games.
Track 79 contains 70 sectors! Numbered 0,5,10,….60, 65, 1, 6, 11,…,61,66,….69

sherman-m4-flux.JPG

Each sector starts with a normal ID segment followed by an inter-gap that seems to contain special characters, followed by the Data segment. The data segment contains
54, 41, 4E, 4B (TANK), 20, 20, 20, 20, F1, F2, … , FF, followed by pre-id gap 12x00

sherman-M4-track-buffer.JPG

All the sectors seems to contain exactly the same 24 first bytes.
in summary: 3xSync - ID Field ( = FE + track + Side + Sector + Length + CRC) - GAP of 35 bytes - Data Field ( = FB + 24 bytes)

sherman-m4-sector-buffer.JPG

All sectors read with CRC error. Some reads with Fuzzy bytes but if you look at the zoom on an area where it happen it seems that the reading might not “be clean” (don’t know if this is by design).

sherman-m4-flux-zoom.JPG

Fuzzy + CRC error = orange
CRC only error = Red

I have also looked at “au nom de l'hermine” and it also has fuzzy bytes. But in that case it seems to be caused by “write splice” because the program was copied using Acopy. I am amazed that Acopy was able to copy this I will have to think how it can be done…

You are mentioning the fact that Pasti can’t image “au nom de l'hermine” but can image « Sherman M4 »? This is strange as apparently they use the same protections. I have used my STX file dumper program to look at the content and for this track it stores the 70 sectors. Anyone knows why Pasti cant image au nom de l'hermine?

As far as using the ST image written by DTC for this disk the problem is that even if written correctly (if this mean something for this kind of track) I believe that none of the emulators would be able to read this kind of ST file. I have talked with Jeff (HxC) and Nicolas (Hatari) and looked at Steem source and they all use some heuristic to recognize the FD format from the ST file but they will have hard time with this one…

[DrCoolZic]

I am not an expert in FD magnetization but it seems to me that your FD has some "degradation" problem

There are many tracks that reads with Fuzzy bytes but probably not on purpose
Here is for example the track 74. You can see in the first sector that the flux "spreads" in an unusual way around 10 ms inside the first sector. Notice also that this result in a probably unwanted shift of the DPLL clock.

sherman-m4-flux-problem.JPG

By looking at the fuzzy mask (generated by reading 5 times the same sector and doing an XOR operation) we can see that the reading starts correctly but the second half of the sector contains errors

sherman-m4-fuzzy-sector.JPG