Req : "Audio Sculpture" (STX,...) even not running...

[Maartau]

I should get pastI out on the STE and image up my (1.4 IIRC ) originals of audio sculpture. It would be interesting to know what was changed in v 1.5. Also I think DHS has only up to 1.4. So a genuine 1. 5 is an exciting find!

@MiggyMog : Yes, interested by the 1.4 .

If you can dump your disks, many thanks .

[ijor]

You can certainly write a track with the exact same number of bitcells, and it doesn't matter where the index pulse is. You don't really need that much fiddling for flux. The only thing you really have to determine is the drive speed of the target drive. It's not a "luck" thing.

The luck, sort to speak, in there is because the target drive speed is never constant. You can measure a specific revolution or an average. That doesn't mean at all that would be the speed when you are going to write. The less stable the more retries you might need to achieve the match.

And again, writing the exact same number of transitions (bitcells) might not be enough. At least not in every case.

[JimDrew]

For a standard FDC like the WD1772, 8277A, etc., where it's not really possible to measure the time between bitcells (it's difficult enough to measure the time for each sector like with Rob's protection), you could get away with bitcells varying in length. The key is to make sure that from write splice to write splice (no matter how many there are) the number of bitcells remains the same. That will require you to adjust the bitcell length for each bitcell (or over a number of bitcells) to be able to account for the target drive's speed vs. the speed at which the original flux was written at. It's really not that big of a deal. Drive speeds are probably more consistent than you realize, at least with the dozen or so different 3.5" drives I have tested. The biggest variance I see is in old 5.25" drives that use a belt drive.

Keep in mind that bitcells change in length on a read. So, any protection would have to be able to account for drive speed variances on a read. This is why the only thing that matters is the total number of bitcells on a track. It's the ONLY thing that you can actually check, and that really requires doing so at the flux level. This protection appears to be just counting the number of bytes between the write splices. During production (without a verify) I am sure that this changes from disk to disk and that's why there is a key created for each disk.

[npomarede]

Hi
this is the theory, but it seems others users were not able to create a correct copy despite using the splice mode on track 3 as you suggested.
Were you able to get a working copy by writing back the SCP file posted above ?

Nicolas

[ijor]

For a standard FDC like the WD1772, 8277A, etc., where it's not really possible measure the time between bitcells (it's difficult enough to measure the time for each sector like with Rob's protection), you could get away with bitcells varying in length.

That is correct. The DMA in the ST makes things even more difficult.

This protection appears to be just counting the number of bytes between the write splices.

Not at all. The protection reads the exact full, circular (which means including the data that crosses the write splice), content of the track as it is interpreted by the PLL. It then computes some kind of checksum. This depends on exactly how the end of the recording overlaps the start of the revolution.

So what matters, besides the exact number of flux transitions, is the distance between the last transition written and the first one. Or more precisely, the distance between the last transition recorded and the next one in circular order (that was recorded at the beginning of the revolution). Because the bitcell as read by the PLL depends on this distance. You need a precision in the order of a single microsecond accumulated in the whole revolution to match this special bitcell at the write splice.

Drive speeds are probably more consistent than you realize, at least with the dozen or so different 3.5" drives I have tested. The biggest variance I see is in old 5.25" drives that use a belt drive.

May be, I didn't perform tons of statistics. But checking the speed variation on this very same image, it seems to be quite significant, much more than a microsecond.

this is the theory, but it seems others users were not able to create a correct copy despite using the splice mode on track 3 as you suggested.

He needs to implement that verify and retry writing mode to produce a better match. That special mode, as I understand, is still not implemented.

Edit: It remains to be seen if it would work with that mode. IMHO it depends on the drive, and in this specific case if the protection check has some tolerance (it seem it has). But without this special mode, it has no chances.

[JimDrew]

Not at all. The protection reads the exact full, circular (which means including the data that crosses the write splice), content of the track as it is interpreted by the PLL.

Exactly - the bytes between write splices. This is a protection used on a couple of Amiga disks too. The write splice relative to the index position is only important for standard FDCs though (to add another level of complexity).

If you take 2 revolutions of original data and you write one full revolution, and then write the next revolution up to the write splice, you can generate a write splice over top the exact position within +/- one sample period, which is +/- 25ns. The WD1722 can only give you one MFM word (converted to hex) of resolution, which is a minimum of 4us per bitcell, with multiple bitcells required to decode a MFM word.

Does anyone have the actual 68K code that checks this track?

[ijor]

Exactly - the bytes between write splices.

Not exactly the bytes between write splices. The key is the few bytes around the write splice.

The write splice relative to the index position is only important for standard FDCs though (to add another level of complexity).

Not in this specific case, but this sometimes can be a big problem. The dumps don't tell us the original index position, but only the position in the drive that was used to make the dump. And the relative index position in some drives can be quite different.

If you take 2 revolutions of original data and you write one full revolution, and then write the next revolution up to the write splice, you can generate a write splice over top the exact position within +/- one sample period, which is +/- 25ns. The WD1722 can only give you one MFM word (converted to hex) of resolution, which is a minimum of 4us per bitcell, with multiple bitcells required to decode a MFM word.

That doesn't make much sense to me. But I won't argue anymore about this. Implement the verify mode first an we'll see how much precision you can get.

Does anyone have the actual 68K code that checks this track?

I can tell you what it does:

- Read sector 10 (that crosses the index and the write splice).
- Compute a checksum of the whole 1024 bytes of this sector.

- Perform a read track.
- Locate the first sync mark in the buffer (it is a few bytes after the index).
- Compute a checksum on all the bytes from that sync mark up to a few bytes before of the end of track.

[Steven Seagal]

Anyway, and regardless the terminology. Yes, if an interrupt reaches the CPU by the end of the instructions it would be delayed even if SR was not changed.

Hi, would you have an idea of what this delay is in cycles? Something like 2?

[JimDrew]

Exactly - the bytes between write splices.

Not exactly the bytes between write splices. The key is the few bytes around the write splice.

No... exactly. Write splice to write splice of course includes 100% of all bytes.

Not in this specific case, but this sometimes can be a big problem. The dumps don't tell us the original index position, but only the position in the drive that was used to make the dump. And the relative index position in some drives can be quite different.

This is true, however, a copy protection would have to take this into account, so it doesn't matter.

I can tell you what it does:

- Read sector 10 (that crosses the index and the write splice).
- Compute a checksum of the whole 1024 bytes of this sector.

- Perform a read track.
- Locate the first sync mark in the buffer (it is a few bytes after the index).
- Compute a checksum on all the bytes from that sync mark up to a few bytes before of the end of track.

Ok, so it's just counting the number of bytes on the track from write splice to write splice and using the data contents as a checksum. I will try to get a ST setup this weekend. I should be able to just write the image and if it doesn't work, go re-write track 3 with the editor/analyzer and adjust the number of bitcells manually to be correct.

[ijor]

Anyway, and regardless the terminology. Yes, if an interrupt reaches the CPU by the end of the instructions it would be delayed even if SR was not changed.

Hi, would you have an idea of what this delay is in cycles? Something like 2?

I would need to check the exact number. But it is much more than just two cycles, and it is not fixed, it depends on the microcode of the specific instruction.

First the CPU must synchronize the IPL signals because by the specs they are async. Then it performs the comparison with the SR mask. Then it has to make the decision if to trigger an exception or not.

In our case the timing is not that critical because the CPU doesn't have direct control of interrupts. The only way that the CPU can provoke a change of the IPL signals is by way of the MFP. But the MFP has its own delays. The end result is that the interrupt timing depends on the combination of the MFP (and GLUE) delays plus the CPU ones.

[ijor]

Not in this specific case, but this sometimes can be a big problem. The dumps don't tell us the original index position, but only the position in the drive that was used to make the dump. And the relative index position in some drives can be quite different.

This is true, however, a copy protection would have to take this into account, so it doesn't matter.

May be the protection should take this into account, but in some cases they don't. And it still (usually) doesn't break the protection because the index alignment is fairly consistent across original ST drives. The problem here is that for dumping people usually don't use an original ST drive. They mostly use PC HD drives. And some of them (I've seen this on some Sony drives) have the index alignment displaced significantly.

Actually Nicolas here wrote back the image, and when it read back on the ST, the index position was shifted so much that the protection would break (not in track 3, but in the other protected tracks). When you write back, the problem might become even worse if the source and the target drives happen to have the index position displaced in opposite directions.

Ok, so it's just counting the number of bytes on the track from write splice to write splice and using the data contents as a checksum.

It isn't counting anything, where you see it does? Not directly at least. It is just computing a checksum. But the checksum does depend on the exact number of bitcells (not just bytes). Furthermore, it depends on the MFM type of the bitcells. If the number of bitcells is different, or if any bitcell is of the different type that changes the MFM sync, then the checksum would change.

[Marcer]

funny facts. in the tracker try: "GNUER" then press space. or type "SYNC" then space. also "GURKA" then space.

[Steven Seagal]

About IPL check delay, there's this not so hard to find figure 5-11 in the M68K User Manual:

iack_figure.jpg

Look at the little arrows on the top, indicating that IPL is sampled sometime during the last bus cycle of the instruction.
Incredibly, I never really paid attention to it.
Now does that mean that if the instruction ends without a bus access, the check happens before?
And what about STOP?

[ijor]

About IPL check delay, there's this not so hard to find figure 5-11 in the M68K User Manual:
...
Incredibly, I never really paid attention to it.

I'm afraid that timing diagram is completely wrong about the delay.

[MiggyMog]

So it turns out my originals are actually version 1.2! I was obviously confusing them with the cracked version of 1.4 I have. I will image them up anyway when I get some free time.

P.S. just seen the 1.5 cracktro, nice work!

[troed]

So it turns out my originals are actually version 1.2! I was obviously confusing them with the cracked version of 1.4 I have. I will image them up anyway when I get some free time.

P.S. just seen the 1.5 cracktro, nice work!

That's absolutely awesome - I wasn't even sure there ever was a v1.2 released since no one has seen one Yes please!

(and thanks )

/Troed

[Maartau]

So it turns out my originals are actually version 1.2! I was obviously confusing them with the cracked version of 1.4 I have. I will image them up anyway when I get some free time.

P.S. just seen the 1.5 cracktro, nice work!

That's absolutely awesome - I wasn't even sure there ever was a v1.2 released since no one has seen one Yes please!

(and thanks )

/Troed

+1 [smilie=greencolorz4_pdt_01.gif]

Yes, a dump of this version is really welcome too .

[Steven Seagal]

I'm afraid that timing diagram is completely wrong about the delay.

Then no worry that I missed it so long.

[JimDrew]

Not in this specific case, but this sometimes can be a big problem. The dumps don't tell us the original index position, but only the position in the drive that was used to make the dump. And the relative index position in some drives can be quite different.

This is true, however, a copy protection would have to take this into account, so it doesn't matter.

May be the protection should take this into account, but in some cases they don't. And it still (usually) doesn't break the protection because the index alignment is fairly consistent across original ST drives. The problem here is that for dumping people usually don't use an original ST drive. They mostly use PC HD drives. And some of them (I've seen this on some Sony drives) have the index alignment displaced significantly.

The protection would always have to take in account varying drive speed if it was counting bitcells - no exceptions. However, counting actual bitcells is not possible on the Atari ST or anything else that uses a canned FDC. The WD1772 converts flux to MFM and then decodes that into hex. The write splice can be seen doing this using the READ_TRACK command, and the WD1772 handles any floating bits caused by the write splice. If this were not the case, the data would change on every read of the track.

Actually Nicolas here wrote back the image, and when it read back on the ST, the index position was shifted so much that the protection would break (not in track 3, but in the other protected tracks).

He didn't use SCP. He used Kryoflux. SCP won't shift the data as part of writing it back.

[ijor]

May be the protection should take this into account, but in some cases they don't. And it still (usually) doesn't break the protection because the index alignment is fairly consistent across original ST drives. The problem here is that for dumping people usually don't use an original ST drive. They mostly use PC HD drives. And some of them (I've seen this on some Sony drives) have the index alignment displaced significantly.

The protection would always have to take in account varying drive speed if it was counting bitcells - no exceptions. However, counting actual bitcells is not possible on the Atari ST or anything else that uses a canned FDC. The WD1772 converts flux to MFM and then decodes that into hex. The write splice can be seen doing this using the READ_TRACK command, and the WD1772 handles any floating bits caused by the write splice. If this were not the case, the data would change on every read of the track.

Man, there is no relation between what you write and what you quote. In that paragraph of mine you quoted me, I wasn't talking about counting bitcells, neither I was talking about variations on the drive speed. I was talking about how each drive has a different relation between the index pulse and the data .

Anyway, assuming you are replying me to a different paragraph than the one you quoted me:

This protection doesn't count anything directly, not even bytes. But indirectly, yes, it depends on the exact number of bitcells. If the number of flux transitions is different than the original, then the checksum when reading sector 10 that crosses the index and the write splice would be different. If you don't understand how this protection depends on the exact number of bitcells to match the original disk, then it seems you don't understand how this protection works.

Actually Nicolas here wrote back the image, and when it read back on the ST, the index position was shifted so much that the protection would break (not in track 3, but in the other protected tracks).

He didn't use SCP. He used Kryoflux. SCP won't shift the data as part of writing it back.

The Kryoflux doesn't shift any data neither. It would have been exactly the same if he was using a SCP. The shift was produced by different index pulse alignments of the source and the target drives. The image was created on one drive (Brume's), it was written on a different one (Nicolas PC drive), and the copy was finally read on a third one (Nicolas ST drive). As I was saying, each drive has a different alignment between the index pulse and the data stream.

[JimDrew]

The protection relies on how the WD1772 actually decodes the write splice as part of the track read. It's the reason why the protection needs the key written separate after whatever created the protection reads the track. The WD1772 does different things. If the write splice created weakbits, you could have several flux transitions that occurred before the WD1772 would actually latch the data and passed it along. You could also have no weakbit and a bitcell or two fewer and still have the same WD1772 data generated. Like I said before, reproducing the exact same number of bitcells is certainly possible and that is what SuperCard Pro always attempts to do. You can use the editor/analyzer to try for yourself. You can experiment with changing bitcell lengths to generate weakbits or strongbits and see how it affects the number of bitcells at a flux level, and then see how that decodes on the WD1772.

[troed]

So I think this discussion is fascinating, really, but I think it would be extremely helpful if we just had someone who could _test_ the theory that it is indeed possible to write back ... ?

That would seem to be the missing piece of information.

(And no, when I cracked it I didn't care at all about track 3 - I'm sure it plays a role in generating one of the two 32 bit keys that decrypts track _2_ - but that's where I started out since that, after a while, gives me the actual program binaries, which check a protection on track _1_ IIRC .. there are multiple layers at work here, and multiple protections on different tracks)

[ijor]

Like I said before, reproducing the exact same number of bitcells is certainly possible and that is what SuperCard Pro always attempts to do.

So we are back to the main issue. If it's possible and reliable to reproduce exactly the same flux transition pattern, even at the write splice, which depends a lot on the drive speed stability. We'll know better when (and if) you'll implement the verify and retry logic at the software.

So I think this discussion is fascinating, really, but I think it would be extremely helpful if we just had someone who could _test_ the theory that it is indeed possible to write back ... ?

To test that in practice we need software that would implement the mentioned "verify and retry" mode. Otherwise it doesn't have much chances.

For all those that might not understand the concept of this mode/logic. Normally you don't reproduce the exact number of transitions (or bits, or bitcells or even bytes). The main reason is the difference between the rotation speed of the source and the target drive. It is not very difficult to measure the target drive speed and to adjust the widths of the transition pulses accordingly. But the drive speed is not perfectly constant. It changes slightly in every revolution. You measure one specific revolution, or perform an average in the best case. But when you go to actually write the track the speed probably won't be exactly the same.

The end result is that usually, the number of transitions won't be exactly identical to the source. For most cases it doesn't matter. The protection check doesn't expect a perfect precision. It doesn't because some variations were also present when the disks were originally duplicated. If you check the track length in multiple copies of the same original release, you will see quite some significant variations. A protection check verifying, say, a so called long track will accept a range. It doesn't expect an exact number of bytes (let alone bits or transitions).

But this case is very different. Each copy has an unique key and the protection check is then much stricter. You need much more precision. So the idea of that verify logic is as following. After writing the track, the software reads the track again and check if the number of transitions is correct or not. If it isn't, try to adjust the width and retry writing the track once again ...

To actually be able to write back the track and pass the protection you depend on two things. One is the stability of the target drive speed. If it is very unstable to mention extreme cases, as it would be with most belt driven drives, it would be very difficult. You might need to retry too many times. The other one is if, and how much, the protection check has some tolerance.

It seem it has some tolerance in this specific case. It doesn't require the transition pattern to be 100% exact. This is probably because otherwise it might be a bit risky. The write splice magnetization is not clean. It might be diffuse and noisy. Then the exact read back behavior might depend on the end user's drive. I don't know for sure how much tolerance this program allows and in which way.

Note that other cases are less tolerant. I understand that some PC games with this protection use the checksum directly as a decryption key. This would require an exact match.

[JimDrew]

I will have to unpack my ST (all of my non-CBM machines are still packed due to my move). SCP already looks at the target drive and adjusts the bitcells so they are the same length (in time) for the rotational speed of the target drive. This was necessary because sometimes people dump disks with a 360 RPM drive and then want to write them back on a 300 RPM drive. I typically see +/- 1 bitcell variance when read/writing on the same drive.

[Brume]

I will have to unpack my ST (all of my non-CBM machines are still packed due to my move).

That's a pure sacrilege, Jim