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

All about the serious stuff.

Moderators: Mug UK, Zorro 2, Moderator Team

User avatar
Maartau
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2588
Joined: Thu Dec 15, 2005 2:15 am
Location: France

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

Postby Maartau » Thu Nov 02, 2017 12:52 pm

MiggyMog wrote: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 :D .

If you can dump your disks, many thanks 8) .

:cheers: :cheers: :cheers:
Member of :
- aTaRi LeGeNd ,
- eLiTe ! ,
- NoExTrA .

Don't hesitate to visit http://www.atarimania.com/ & http://www.atarilegend.com/ :D

-> Slowed due to serious health troubles <-

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

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

Postby ijor » Thu Nov 02, 2017 3:55 pm

JimDrew wrote: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
Atari Super Hero
Atari Super Hero
Posts: 586
Joined: Mon Nov 04, 2013 5:23 pm

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

Postby JimDrew » Thu Nov 02, 2017 7:34 pm

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.
Last edited by JimDrew on Fri Nov 03, 2017 3:25 am, edited 1 time in total.
I am the flux ninja

User avatar
npomarede
Atari God
Atari God
Posts: 1160
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

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

Postby npomarede » Thu Nov 02, 2017 8:19 pm

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
Hardware Guru
Hardware Guru
Posts: 3095
Joined: Sat May 29, 2004 7:52 pm
Contact:

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

Postby ijor » Thu Nov 02, 2017 9:22 pm

JimDrew wrote: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.

npomarede wrote: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
Atari Super Hero
Atari Super Hero
Posts: 586
Joined: Mon Nov 04, 2013 5:23 pm

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

Postby JimDrew » Fri Nov 03, 2017 3:56 am

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?
I am the flux ninja

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

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

Postby ijor » Fri Nov 03, 2017 1:21 pm

JimDrew wrote: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.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1950
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

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

Postby Steven Seagal » Fri Nov 03, 2017 9:30 pm

ijor wrote: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
Atari Super Hero
Atari Super Hero
Posts: 586
Joined: Mon Nov 04, 2013 5:23 pm

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

Postby JimDrew » Fri Nov 03, 2017 11:25 pm

ijor wrote:
JimDrew wrote: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.

ijor wrote: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.
I am the flux ninja

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

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

Postby ijor » Sat Nov 04, 2017 1:16 am

Steven Seagal wrote:
ijor wrote: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
Hardware Guru
Hardware Guru
Posts: 3095
Joined: Sat May 29, 2004 7:52 pm
Contact:

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

Postby ijor » Sat Nov 04, 2017 1:31 am

JimDrew wrote:
ijor wrote: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.

User avatar
Marcer
Atarilegend
Atarilegend
Posts: 4123
Joined: Wed Mar 10, 2004 6:21 pm
Location: sweden
Contact:

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

Postby Marcer » Sat Nov 04, 2017 9:09 am

funny facts. in the tracker try: "GNUER" then press space. or type "SYNC" then space. also "GURKA" then space. :)
- Atari ST/FM/E - Mega sTe - Portfolio - Falcon 030 FX 3 in 1 -- Atari 7800/Lynx/Jaguar -
- FTP... Ask for info
- Atari Legend (Games all-a-round)
- Paradize (Chip Music)
- Elite (Atari Softs)
- The Legion (Demos)
- Alive Maggie Team
_/|\_YM-RockerZ_/|\_

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1950
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

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

Postby Steven Seagal » Sat Nov 04, 2017 10:15 am

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? :mrgreen:
You do not have the required permissions to view the files attached to this post.

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

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

Postby ijor » Sat Nov 04, 2017 12:19 pm

Steven Seagal wrote: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.

User avatar
MiggyMog
Atari Super Hero
Atari Super Hero
Posts: 801
Joined: Sun Oct 30, 2005 4:43 pm
Location: Scotland

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

Postby MiggyMog » Sat Nov 04, 2017 2:20 pm

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!
('< o o o o |''| STM,2xSTFM,2xSTE+HD,C-Lab Falcon MK2+HD,Satandisk,Ultrasatandisk,Ethernat.

User avatar
troed
Atari God
Atari God
Posts: 1197
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

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

Postby troed » Sat Nov 04, 2017 2:35 pm

MiggyMog wrote: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 :D Yes please!

(and thanks :))

/Troed

User avatar
Maartau
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2588
Joined: Thu Dec 15, 2005 2:15 am
Location: France

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

Postby Maartau » Sat Nov 04, 2017 3:26 pm

troed wrote:
MiggyMog wrote: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 :D Yes please!

(and thanks :))

/Troed


+1 :cheers: [smilie=greencolorz4_pdt_01.gif]

Yes, a dump of this version is really welcome too :D .
Member of :
- aTaRi LeGeNd ,
- eLiTe ! ,
- NoExTrA .

Don't hesitate to visit http://www.atarimania.com/ & http://www.atarilegend.com/ :D

-> Slowed due to serious health troubles <-

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1950
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

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

Postby Steven Seagal » Sat Nov 04, 2017 8:23 pm

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


Then no worry that I missed it so long. :)

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

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

Postby JimDrew » Sun Nov 05, 2017 3:41 pm

ijor wrote:
JimDrew wrote:
ijor wrote: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.
I am the flux ninja

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

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

Postby ijor » Sun Nov 05, 2017 8:29 pm

JimDrew wrote:
ijor wrote: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
Atari Super Hero
Atari Super Hero
Posts: 586
Joined: Mon Nov 04, 2013 5:23 pm

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

Postby JimDrew » Mon Nov 06, 2017 8:41 pm

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.
I am the flux ninja

User avatar
troed
Atari God
Atari God
Posts: 1197
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

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

Postby troed » Mon Nov 06, 2017 9:29 pm

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
Hardware Guru
Hardware Guru
Posts: 3095
Joined: Sat May 29, 2004 7:52 pm
Contact:

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

Postby ijor » Tue Nov 07, 2017 1:07 pm

JimDrew wrote: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.

troed wrote: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
Atari Super Hero
Atari Super Hero
Posts: 586
Joined: Mon Nov 04, 2013 5:23 pm

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

Postby JimDrew » Tue Nov 07, 2017 4:07 pm

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.
I am the flux ninja

User avatar
Brume
Red eyes
Red eyes
Posts: 4094
Joined: Mon Apr 22, 2002 10:16 am
Location: France
Contact:

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

Postby Brume » Tue Nov 07, 2017 4:27 pm

JimDrew wrote: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 :lol:


Social Media

     

Return to “Applications”

Who is online

Users browsing this forum: No registered users and 4 guests