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

[Steven Seagal]

Brume original is OK to me, but the protection send Steem to hell or valhalla lol !D

Steven (and npomaredes) need to find the bug(s) creeping inside the emulators and that make Audio Sculpture HALT the emulation

Do you mean you could write it back on a disk and it runs on real hardware?
And what about the first image posted in this thread?
I'm a bit surprised if both emulators have the same bug.

[dlfrsilver]

the problem is not writing it back on disk (i can do that), but checking why the protection crash steem and Hatari.

[troed]

Nah, the first thing I would like to see done is for someone to actually boot it on real hw, see that it's indeed Audio Sculpture and which version

[Brume]

Give me two days and I'll can check with my original copies of the tool.

[dlfrsilver]

brume i will check that tonight on my main 1040 STF.

[npomarede]

Hi
I wrote the RAW file posted by Brume using my KF board and tested it on my STF : same crash, loader stops at the same point as under Hatari (hard to tell if it's exactly the same point, but it doesn't seem to read more tracks)

This doesn't necessary means this image is not the one from Audio Sculpture, maybe the CTR/RAW dump itself is faulty for some reasons, or maybe I made an error when writing it back to a floppy (I used "dtc -fdiskA/track00.0.raw -w").
Or maybe the protection expects a specific TOS or will fail on some older ones ?

Hard to conclude with just my test, let's see what drfsilver gets on his STF and if Brume can find the original floppy and test it on his ST.

Regarding the protection, the loader does a read track on track 1 and track 2 ; on track 2 it looks for byte "CD" in the header of the track then read the next 2 bytes (B4F7) then 2 others bytes 5 bytes after. Nothing really fancy on a first look, should be possible to image with STX too.

Nicolas

[Brume]

I'm just coming to run the original disks (not the copy) on my Atari STE, and... They work fine.
Please note it's v1.3.

Here are both captures made on the real machine:

Audio Scuplture 01.png

Audio Scuplture 02.png

So I've dumped again both original disks : they still don't work with emulators.

Here are the new dumps. This time it contains SCP format, too:

https://mega.nz/#F!aUFAhQpD!pqQIwUnCFPNu2H-rLeJoSw

Let me know how I can help (using Pasti on the STE, maybe?)

[troed]

Thanks for testing! Too bad about not being a "v1.5" though.

AFAIK the only cracks available for AS are v1.0 in color and mono, and v1.4 in color (and that crack isn't perfect, has issues with disk access/refresh).

A v1.3 in mono would be a nice release for a still active cracking group, I guess. Also, there are no original images of AS available at all ...

[npomarede]

Thanks a lot for testing this and confirming it works on real STE.
As the image I wrote from the RAW files didn't work on my STF, maybe the RAW file can't be written back in that specific protection case ? (IIRC some games were reported some times ago with this problem, but could be written with SCP). Or maybe I did sthg wrong when using my KF board

Regarding the protection, the loader will do 2 read tracks :

- on track 1, it looks for '7F' in the track header and expect to find it before the 1st 'A1'. The 20 bytes at the start of consecutive read tracks will be different, but they will sync after the 7F. The protection then read the 4 next bytes, ie 92 07 91 90.

Code: Select all

00000140 41f9 0006 0000           LEA.L $00060000,A0           
                                                               
00000146 0c18 007f                CMP.B #$7f,(A0)+ [24]        
0000014A 6718                     BEQ.B #$18 == $00000164 (F)  
0000014C 43f9 0000 007a           LEA.L $0000007a,A1           
00000152 21c9 0024                MOVE.L A1,$0024 [0000007a]   
00000156 0c10 00a1                CMP.B #$a1,(A0) [24]         
0000015A 6702                     BEQ.B #$02 == $0000015e (F)  
0000015C 60e8                     BT .B #$e8 == $00000146 (T)  
                                                               
00000164 7e00                     MOVE.L #$00,D7               
00000166 1e18                     MOVE.B (A0)+ [92],D7         
00000168 e18f                     LSL.L #$08,D7                
0000016A 1e18                     MOVE.B (A0)+ [07],D7         
0000016C e18f                     LSL.L #$08,D7                
0000016E 1e18                     MOVE.B (A0)+ [91],D7         
00000170 e18f                     LSL.L #$08,D7                
00000172 1e18                     MOVE.B (A0)+ [90],D7         
00000174 21c7 02da                MOVE.L D7,$02da [04545225]   

Track is read at $60000 :

Code: Select all

00060000: 00 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24   .$$$$$$$$$$$$$$$
00060010: 24 30 f0 c2 7f 92 07 91 90 90 ff ff ff ff ff ff   $0ðÂ............
00060020: ff ff c2 a1 a1 fe 01 00 01 02 bc db 4e 4e 4e 4e   ..¡¡þ....¼ÛNNNN

- on track 2, it looks for F7, starting at $78000. Here also the 30 bytes at the start will change after each read track, but content will be stable after CD. So, we read 00, then DE AD FA CE.

Code: Select all

$00060d76 : 1018                               move.b    (a0)+,d0
$00060d78 : b03c 00a1                          cmp.b     #$a1,d0
$00060d7c : 671e                               beq.s     $60d9c
$00060d7e : 0c00 00f7                          cmpi.b    #$f7,d0
$00060d82 : 66f2                               bne.s     $60d76
$00060d84 : 4a10                               tst.b     (a0)
$00060d86 : 66ee                               bne.s     $60d76
$00060d88 : 5248                               addq.w    #1,a0
$00060d8a : 1c18                               move.b    (a0)+,d6
$00060d8c : e14e                               lsl.w     #8,d6
$00060d8e : 1c18                               move.b    (a0)+,d6
$00060d90 : 4846                               swap      d6
$00060d92 : 1c18                               move.b    (a0)+,d6
$00060d94 : e14e                               lsl.w     #8,d6
$00060d96 : 1c18                               move.b    (a0)+,d6

Track content at $78000

Code: Select all

00078000: ff fe 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e   .þNNNNNNNNNNNNNN
00078010: 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 14 0b cd b4   NNNNNNNNNNNN..Í´
00078020: f7 00 de ad fa ce 00 00 00 00 00 00 00 00 14 a1   ÷.Þ­úÎ.........¡

In the case of Hatari, loader will crash just after this part. The crash is "normal" (a real ST would crash too), but maybe that's because the code is not the correct one due to some unexpected results from the 2 read track command, I need to look at this later.

Maybe the SCP file will give better results under Steem ? Just to be sure it's not a limitation to one image format.

Nicolas

[Steven Seagal]

Let me know how I can help (using Pasti on the STE, maybe?)

Thx.
One more useful step would be to write the images back on floppies and check if it still works?

[npomarede]

Thanks a lot for testing this and confirming it works on real STE.
As the image I wrote from the RAW files didn't work on my STF, maybe the RAW file can't be written back in that specific protection case ? (IIRC some games were reported some times ago with this problem, but could be written with SCP). Or maybe I did sthg wrong when using my KF board

I read track 01 and track 02 directly on my STF (from the floppy I wrote using the RAW files and my KF board) and for some reasons the first 25 bytes of each track were not written (if I compare with a read track under emulation using the CTR file). This means protection will fail on my STF when checking track 01 as part of the data are not present anymore.
Does anyone have more experience when writing back RAW or CTR files to disk, maybe I need some extra parameters when running "dtc" ?

[kodak80]

I have tried writing Brume's SCP dump back to floppy but it does not work in either my STE or STFM. I have tried the various options in the SCP program when writing back but I have had no success with getting a disk 1 that boots.

On boot it accesses the disk twice and then no further disk activity and my screen turns itself off as it is not detecting any video output.

I hope this helps. If the dumps are good then maybe Jim Drew should have a look at the SCP dump for further testing?

[npomarede]

Hi kodak80, this looks like what I get on my STF when writing back the RAW files, the written track is too short by a few bytes at the start and the protection will fail (the protection goes to mono video mode during its tests, that's why you don't see any video output). Check on track 1 is likely to fail as the required bytes are really close to the track's start.

Maybe some of the bytes in the track header are too close from the index mark and by the time the index signal is detected to start writing, some bytes are lost corresponding to this delay ?

If so, one solution would be to add ~25 extra "useless" bytes at the start of the stream, so those bytes would not be written, but at least the useful bytes would be written, but I don't think that's possible to do this with KF or SCP ?

[ijor]

Seems there are all sort of issues. These "amateurish" protections are always the most complicated for emulation. I can't perform a full analysis at this time, so just some comments ...

It sounds like there are both emulation issues and write back problems as well. Not necessarily strictly related one with the other.

Besides the protection in tracks 1 and 2, there is further copy protection in track 3. Although, under emulation at least, the program crashes before reading anything on track 3.

The first Pasti image posted here was taken from a different version.

Steven, there is long standing bug that makes this difficult to debug. You are probably aware about it. Seems that a boiler breakpoint in some critical positions (bus error, trace, etc) affects emulation and alters the behavior.

Btw Steven, did you (or anybody else) try the SCP or raw images with a HxC or Gotek disk emulator?

I read track 01 and track 02 directly on my STF (from the floppy I wrote using the RAW files and my KF board) and for some reasons the first 25 bytes of each track were not written ...

The index position is not the same on every drive. 25 bytes sounds a bit too much. But you can confirm if this is the problem by dumping your non working copy with your same Kryoflux setup. You would be reading in the same drive that you wrote it.

If you can, try writing back with an ST drive, just remember to twist the cable if you do!

Btw, the Kryoflux images have the index position displaced in relation to the SCP one. The SCP image seems better in this sense, with more bytes before the first sync. So writing back the SCP image has less chance to cut off the protection on the initial part of track 1.

kodak80, can you please make an image of the non working copy you wrote back? It would be useful for comparison with the original dump.

Maybe some of the bytes in the track header are too close from the index mark and by the time the index signal is detected to start writing, some bytes are lost corresponding to this delay ?

No, this delay should be tiny because it is internal to the board.

[Steven Seagal]

I have tried writing Brume's SCP dump back to floppy but it does not work in either my STE or STFM. I have tried the various options in the SCP program when writing back but I have had no success with getting a disk 1 that boots.

Thx for your help. That's quite a mysterious case.

Steven, there is long standing bug that makes this difficult to debug. You are probably aware about it. Seems that a boiler breakpoint in some critical positions (bus error, trace, etc) affects emulation and alters the behavior.

No, I'm not aware. Could you give a PC in the case under review (v1.3) as an example?
Notice I made some changes in the latest dev build (last Sunday), affecting STOP.
I also changed something in MFP emulation for this case but it isn't uploaded yet, meanwhile switching off option 'C2' will make the crashes less random.

Btw Steven, did you (or anybody else) try the SCP or raw images with a HxC or Gotek disk emulator?

Just did HxC conversion to HFE and it crashed too on my STE + HxC.
The converted HFE image doesn't load properly in Steem (get Assert failed: TRACKBYTES>=0 && TRACKBYTES<6500).

[dlfrsilver]

a word from Frédéric Bautista (one of the 3 authors of this copy protection) :

Hello, Oh my god it's not from yesterday...

IPL, yes i remember, for "Initial Program Lock", a joke made with "Initial program Load" a name that Pascal Truong had found...

What is actually giving you some troubles ? The disk protection ?

I remember this gave them troubles, but i remember that he (Pascal Truong) solved it by removing the disk test part... (the protection is tested, so bad souvenirs i guess)

I suppose that's the problem, otherwise, there was 3 parts, the one made by Illegal, the one done by pascal and mine, (it was a very simple synchro trace).

I did an enhanced version (of my part) that i put on some softwares, and one particular called "Lotopsy", But all this is so old...

[dlfrsilver]

he has written this to me :

"Ok, i don't remember well Pascal's soft protection, it was more or less a sort of Rob Northern, with a lot of trace decoding if i remember well.

For the disk protection it's almost impossible to reproduce in serial... I have not even ben able to copy it with the Option Board Card for PC which was using the "Transcopy" micro-processor at this time. This board could reproduce the signal as well as express copiers or cyclone on amiga...

In fact the principle is very simple, it's based on the disk drives rotation speed variation on a whole round, it's in fact an extreme pain in the ass to replicate, maybe completely impossible.

Due to this variation you never write twice the same track. You only need to have a track finishing by the beginning of a sector, which when read, will be composed by the end of track plus the beginning of it...

So basically, by combining a "read track" and a read sector command on the concerned sector, we read the full circular integrality of the track.

And this thing, is almost impossible to reproduce identically...

The only way to copy this protection is to make a program that is modifying dynamically the awaited value depending on what is observed on the newly written track with the copy.

This was what i was doing by hand to create a protected disk...

It's possible to integrate a manual copy tool which is modifying the test dynamically depending on the result given by the track reading.

But copy the protected track in itself, specialised laboratories would be able to copy it today, however, there is no simple way to do it...

[ijor]

The converted HFE image doesn't load properly in Steem (get Assert failed: TRACKBYTES>=0 && TRACKBYTES<6500).

Is that an assert you coded? Why? It is very possible that some of the unformatted tracks in this disk have more than 6500 bytes (if I understand correctly the meaning of the assertion).

[ijor]

Due to this variation you never write twice the same track. You only need to have a track finishing by the beginning of a sector, which when read, will be composed by the end of track plus the beginning of it ... So basically, by combining a "read track" and a read sector command on the concerned sector, we read the full circular integrality of the track.

And this thing, is almost impossible to reproduce identically... The only way to copy this protection is to make a program that is modifying dynamically the awaited value depending on what is observed on the newly written track with the copy. This was what i was doing by hand to create a protected disk...

Interesting. I knew this protection was used on the PC, but I wasn't aware about any ST title with that protection. As he is saying, the idea is to be able to read the write splice with a sector that spawns under the index. And due to the rotational speed imprecision, you can't reproduce the exact behavior of the write splice, even a professional industrial duplicator can't. So actually this protection is never copied in the strict sense, it is just created, each time in a unique and unrepeatable way

This protection seems to be present in track 3. But emulation fails before any attempt to access that track. So again as I said before, it seems there are multiple issues. There are emulation issues that are besides the protection. And anyway, emulation does can reproduce this protection.

This however, it is probably the reason that all attempts to write back fail.

The reason why it fails with the HxC emulator is probably because it is not trivial to deduce the exact write splice behavior from a flux level dump. In this case, a Pasti dump might help.

So please Brume, make a Pasti dump of the disk.

[Steven Seagal]

Here is sector 3-10 of v1.3, CTR:

Code: Select all

#001 (0-03-10) to 07A9DA: 53 4F 46 54 20 50 52 4F 54 45 43 54 49 4F 4E 20 
#002 (0-03-10) to 07A9EA: 43 4F 44 45 44 42 59 3A 20 4D 72 20 54 52 55 4F 
#003 (0-03-10) to 07A9FA: 4E 47 20 4E 47 4F 43 20 50 61 73 63 61 6C 20 54 
#004 (0-03-10) to 07AA0A: 45 4C 3A 20 34 33 20 33 36 20 35 35 20 39 31 20 
#005 (0-03-10) to 07AA1A: 20 20 20 20 20 44 49 53 4B 20 50 52 4F 54 45 43 
#006 (0-03-10) to 07AA2A: 54 49 4F 4E 20 43 4F 44 45 44 20 42 59 20 4D 72 
#007 (0-03-10) to 07AA3A: 20 42 41 55 54 49 53 54 41 20 46 72 65 64 65 72 
#008 (0-03-10) to 07AA4A: 69 63 20 54 45 4C 3A 20 39 32 20 36 36 20 36 33 
#009 (0-03-10) to 07AA5A: 20 31 36 20 69 66 20 79 6F 75 20 61 72 65 20 69 
#010 (0-03-10) to 07AA6A: 6E 74 65 72 65 73 74 20 62 79 20 6F 75 72 20 70 
#011 (0-03-10) to 07AA7A: 72 6F 74 65 63 74 20 73 6F 2E 2E 2E 00 28 29 C2 
#012 (0-03-10) to 07AA8A: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#013 (0-03-10) to 07AA9A: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#014 (0-03-10) to 07AAAA: C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 
#015 (0-03-10) to 07AABA: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#016 (0-03-10) to 07AACA: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#017 (0-03-10) to 07AADA: C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 
#018 (0-03-10) to 07AAEA: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#019 (0-03-10) to 07AAFA: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#020 (0-03-10) to 07AB0A: C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 
#021 (0-03-10) to 07AB1A: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#022 (0-03-10) to 07AB2A: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#023 (0-03-10) to 07AB3A: C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 
#024 (0-03-10) to 07AB4A: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#025 (0-03-10) to 07AB5A: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#026 (0-03-10) to 07AB6A: C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 
#027 (0-03-10) to 07AB7A: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#028 (0-03-10) to 07AB8A: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#029 (0-03-10) to 07AB9A: C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 
#030 (0-03-10) to 07ABAA: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#031 (0-03-10) to 07ABBA: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#032 (0-03-10) to 07ABCA: C2 28 29 C2 28 A1 C2 28 29 14 28 C2 28 28 29 C2 
#033 (0-03-10) to 07ABDA: 4C DA F7 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 
#034 (0-03-10) to 07ABEA: 4E 4E 4E 4E 4E 4E A1 A1 A1 FE 50 00 04 03 6E 1F 
#035 (0-03-10) to 07ABFA: 4E 4E 4E 4E A1 A1 A1 FE 50 00 15 03 EC C5 F7 A1 
#036 (0-03-10) to 07AC0A: A1 A1 A1 FE EF 38 A1 03 1E 2C 00 00 00 00 00 00 
#037 (0-03-10) to 07AC1A: 00 00 00 00 00 00 A1 A1 A1 FB F0 F0 F0 F0 F0 F0 
#038 (0-03-10) to 07AC2A: F0 41 4C 54 41 49 52 20 20 20 20 20 20 20 20 20 
max rev 5 real 3 next 4
CAPS Lock A:S0T3 flags 704 sectors 0 bits 12583 overlap -1 startbit 0 timebuf 9ab69d0
#039 (0-03-10) to 07AC3A: 20 20 20 20 20 20 20 20 20 20 F0 F0 F0 F0 00 00 
#040 (0-03-10) to 07AC4A: 00 07 AA 4A 82 65 0D 0D 0A 4B 73 4B A3 4B 0B 61 
#041 (0-03-10) to 07AC5A: 02 83 93 7B 3B 93 0B 69 03 63 7B 0B 21 02 DB B1 
#042 (0-03-10) to 07AC6A: 91 71 82 E9 01 02 A3 69 01 89 C9 C1 C9 61 89 C9 
#043 (0-03-10) to 07AC7A: C9 81 02 A3 43 AB 73 23 2B 92 9B 7B 33 A1 02 23 
#044 (0-03-10) to 07AC8A: 2B B3 2B 63 7B 83 6B 2B 73 A6 16 16 17 F2 80 00 
#045 (0-03-10) to 07AC9A: 08 13 1B 67 AD 0D 0F F2 80 00 58 1A 05 F7 BD 0A 
#046 (0-03-10) to 07ACAA: 0B A3 0B 93 49 6A 9A A1 02 4A 82 61 02 A3 93 0B 
#047 (0-03-10) to 07ACBA: 1B 59 01 00 00 05 0D 0D 0F DF 2F 2F 2F 2F 2F 2F 
#048 (0-03-10) to 07ACCA: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#049 (0-03-10) to 07ACDA: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#050 (0-03-10) to 07ACEA: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#051 (0-03-10) to 07ACFA: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#052 (0-03-10) to 07AD0A: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#053 (0-03-10) to 07AD1A: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#054 (0-03-10) to 07AD2A: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#055 (0-03-10) to 07AD3A: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#056 (0-03-10) to 07AD4A: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#057 (0-03-10) to 07AD5A: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#058 (0-03-10) to 07AD6A: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#059 (0-03-10) to 07AD7A: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#060 (0-03-10) to 07AD8A: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#061 (0-03-10) to 07AD9A: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#062 (0-03-10) to 07ADAA: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#063 (0-03-10) to 07ADBA: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
#064 (0-03-10) to 07ADCA: 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
142520876 FDC(3) IRQ CR 80 STR 88 ( MO CRC ) TR 80 (CYL 3) SR 10 DR 47

The same, SCP:

Code: Select all

119985620 FDC(4) CR $80 A:0 STR 80 TR 80 CYL 3 SR 10 DR 249 dma $7A9DA #3 PC $78B42
SCP LoadTrack side 0 track 3 TRK 6 rev 1/5  INDEX TIME 7989873 (199.746826 ms) TRACK LENGTH 38083 bits 38083 last bit unit 7989827 DATA OFFSET 64  checksum 9B003300
FE found at 700
At 706:ID T80 S0 N2 L2 CRCEA7
FE found at 721
At 727:ID T80 S0 N12 L3 CRCD929
FE found at 1315
At 1321:ID T80 S0 N3 L2 CRCD936
FE found at 1332
At 1338:ID T80 S0 N13 L3 CRCEA18
FE found at 1938
At 1944:ID T80 S0 N4 L2 CRC40A1
FE found at 1951
At 1957:ID T80 S0 N14 L3 CRCBF4B
FE found at 2554
At 2560:ID T80 S0 N5 L2 CRC7390
FE found at 2568
At 2574:ID T80 S0 N15 L3 CRC8C7A
FE found at 3169
At 3175:ID T80 S0 N6 L2 CRC26C3
FE found at 3183
At 3189:ID T80 S0 N16 L3 CRC9F37
FE found at 3784
At 3790:ID T80 S0 N7 L2 CRC15F2
FE found at 3798
At 3804:ID T80 S0 N17 L3 CRCAC6
FE found at 4399
At 4405:ID T80 S0 N8 L2 CRC5CC
FE found at 4413
At 4419:ID T80 S0 N18 L3 CRCF955
FE found at 5014
At 5020:ID T80 S0 N9 L2 CRC36FD
FE found at 5028
At 5034:ID T80 S0 N19 L3 CRCCA64
FE found at 5629
At 5635:ID T80 S0 N10 L3 CRC738F
A1 found at byte 5672, reset CRC
AM found at byte 161 (5673 in), reset CRC
TR80 SR10 FB found at byte 5674 (39 after ID)
#001 (0-03-10) to 07A9DA: 53 4F 46 54 20 50 52 4F 54 45 43 54 49 4F 4E 20 
#002 (0-03-10) to 07A9EA: 43 4F 44 45 44 42 59 3A 20 4D 72 20 54 52 55 4F 
#003 (0-03-10) to 07A9FA: 4E 47 20 4E 47 4F 43 20 50 61 73 63 61 6C 20 54 
#004 (0-03-10) to 07AA0A: 45 4C 3A 20 34 33 20 33 36 20 35 35 20 39 31 20 
#005 (0-03-10) to 07AA1A: 20 20 20 20 20 44 49 53 4B 20 50 52 4F 54 45 43 
#006 (0-03-10) to 07AA2A: 54 49 4F 4E 20 43 4F 44 45 44 20 42 59 20 4D 72 
#007 (0-03-10) to 07AA3A: 20 42 41 55 54 49 53 54 41 20 46 72 65 64 65 72 
#008 (0-03-10) to 07AA4A: 69 63 20 54 45 4C 3A 20 39 32 20 36 36 20 36 33 
#009 (0-03-10) to 07AA5A: 20 31 36 20 69 66 20 79 6F 75 20 61 72 65 20 69 
#010 (0-03-10) to 07AA6A: 6E 74 65 72 65 73 74 20 62 79 20 6F 75 72 20 70 
#011 (0-03-10) to 07AA7A: 72 6F 74 65 63 74 20 73 6F 2E 2E 2E 00 28 29 C2 
#012 (0-03-10) to 07AA8A: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#013 (0-03-10) to 07AA9A: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#014 (0-03-10) to 07AAAA: C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 
#015 (0-03-10) to 07AABA: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#016 (0-03-10) to 07AACA: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#017 (0-03-10) to 07AADA: C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 
#018 (0-03-10) to 07AAEA: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#019 (0-03-10) to 07AAFA: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#020 (0-03-10) to 07AB0A: C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 
#021 (0-03-10) to 07AB1A: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#022 (0-03-10) to 07AB2A: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#023 (0-03-10) to 07AB3A: C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 
#024 (0-03-10) to 07AB4A: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#025 (0-03-10) to 07AB5A: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#026 (0-03-10) to 07AB6A: C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 
#027 (0-03-10) to 07AB7A: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#028 (0-03-10) to 07AB8A: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#029 (0-03-10) to 07AB9A: C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 
#030 (0-03-10) to 07ABAA: 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 
#031 (0-03-10) to 07ABBA: 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 C2 28 29 
#032 (0-03-10) to 07ABCA: C2 28 29 C2 28 A1 C2 28 29 14 28 C2 28 28 29 C2 
#033 (0-03-10) to 07ABDA: 4C DA F7 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 
#034 (0-03-10) to 07ABEA: 4E 4E 4E 4E 4E 4E A1 A1 A1 FE 50 00 04 03 6E 1F 
#035 (0-03-10) to 07ABFA: 4E 4E 4E 4E A1 A1 A1 FE 50 00 15 03 EC C5 F7 A1 
#036 (0-03-10) to 07AC0A: A1 A1 A1 FE EF 38 A1 03 1E 2C 00 00 00 00 00 00 
#037 (0-03-10) to 07AC1A: 00 00 00 00 00 00 A1 A1 A1 FB F0 F0 F0 F0 F0 F0 
#038 (0-03-10) to 07AC2A: F0 41 4C 54 41 49 52 20 20 20 20 20 20 20 20 20 

SCP triggers IP side 0 track 3 rev 1/5
A: IP #4 (WD_TYPEII_READ_DATA) (triggered) CR 80 TR 80 SR 10 DR 32 STR 83 ACT 121555244
SCP LoadTrack side 0 track 3 TRK 6 rev 2/5  INDEX TIME 7990846 (199.771149 ms) TRACK LENGTH 38082 bits 38082 last bit unit 7990858 DATA OFFSET 76230  checksum 9B003300
#039 (0-03-10) to 07AC3A: 20 20 20 20 20 20 20 20 20 20 F0 F0 F0 F0 00 00 
#040 (0-03-10) to 07AC4A: 00 10 01 20 79 10 A0 A0 A1 20 08 20 18 20 E0 1C 
#041 (0-03-10) to 07AC5A: F8 78 48 00 80 48 E0 04 F8 18 00 E0 9C F8 00 0C 
#042 (0-03-10) to 07AC6A: 4C 0C 78 04 FC F8 18 04 FC 64 24 3C 24 1C 64 24 
#043 (0-03-10) to 07AC7A: 24 7C F8 18 38 00 08 98 80 48 40 00 88 1C F9 98 
#044 (0-03-10) to 07AC8A: 80 08 80 18 00 78 00 80 08 11 41 41 40 08 7F FF 
#045 (0-03-10) to 07AC9A: E7 C8 C0 10 00 A0 A0 08 7F FF 07 C1 F0 00 00 A1 
#046 (0-03-10) to 07ACAA: E0 18 E0 48 24 00 40 1C F9 20 79 1C F8 18 48 E0 
#047 (0-03-10) to 07ACBA: C0 04 FC FF FF F0 A0 A0 A0 00 80 80 80 80 80 80 
#048 (0-03-10) to 07ACCA: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#049 (0-03-10) to 07ACDA: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#050 (0-03-10) to 07ACEA: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#051 (0-03-10) to 07ACFA: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#052 (0-03-10) to 07AD0A: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#053 (0-03-10) to 07AD1A: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#054 (0-03-10) to 07AD2A: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#055 (0-03-10) to 07AD3A: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#056 (0-03-10) to 07AD4A: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#057 (0-03-10) to 07AD5A: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#058 (0-03-10) to 07AD6A: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#059 (0-03-10) to 07AD7A: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#060 (0-03-10) to 07AD8A: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#061 (0-03-10) to 07AD9A: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#062 (0-03-10) to 07ADAA: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#063 (0-03-10) to 07ADBA: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
#064 (0-03-10) to 07ADCA: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 
CRC error - computed: F834 - read: 8080
Read sector A:0-80-10 CRC error
121658492 FDC(4) IRQ CR 80 STR 88 ( MO CRC ) TR 80 (CYL 3) SR 10 DR 128

You can see they're the same through IP then not anymore, even though they're dumps of the same disk.
Both give CRC error.
At least, according to Steem traces (and cheating to pass track 2).
Then it hangs anyway.

[Steven Seagal]

The converted HFE image doesn't load properly in Steem (get Assert failed: TRACKBYTES>=0 && TRACKBYTES<6500).

Is that an assert you coded? Why? It is very possible that some of the unformatted tracks in this disk have more than 6500 bytes (if I understand correctly the meaning of the assertion).

Yes, it's when there are ASSERT( ); lines in Steem. Just checked: 7525 bytes (track 0).
Steem sees no data on those disks, it goes to desktop then "drive A: is not responding".
Quite odd. Could be a separate issue, maybe I did something wrong. On the HxC it does load some tracks.

[dlfrsilver]

Interesting. I knew this protection was used on the PC, but I wasn't aware about any ST title with that protection. As he is saying, the idea is to be able to read the write splice with a sector that spawns under the index. And due to the rotational speed imprecision, you can't reproduce the exact behavior of the write splice, even a professional industrial duplicator can't. So actually this protection is never copied in the strict sense, it is just created, each time in a unique and unrepeatable way

This is for the moment exactly the principle. The only way to get beyond this problem is to prepare again with the tools we have a new master, that will be replicated with the boards like KF or SCP.

This protection seems to be present in track 3. But emulation fails before any attempt to access that track. So again as I said before, it seems there are multiple issues. There are emulation issues that are besides the protection. And anyway, emulation does can reproduce this protection.

Protection is in track 3. protection fails on me on track 6 sector 10.

This however, it is probably the reason that all attempts to write back fail.

The only way is to devised how things must be, and make a new master.

The reason why it fails with the HxC emulator is probably because it is not trivial to deduce the exact write splice behavior from a flux level dump. In this case, a Pasti dump might help.

So please Brume, make a Pasti dump of the disk.

Brume did already. The funny fact is that the Amiga version of Audio Sculpture doesn't use any protection When the ST version use a nasty one

[ijor]

Here is sector 3-10 of v1.3, CTR: ...
The same, SCP: ...
You can see they're the same through IP then not anymore, even though they're dumps of the same disk.

Not sure what is your point. There are several reasons why it could be different. I would actually be surprised if they would be the same.

[ijor]

The only way to get beyond this problem is to prepare again with the tools we have a new master, that will be replicated with the boards like KF or SCP ... The only way is to devised how things must be, and make a new master.

A new master??? Do you mean copy protected with a "normal" protection? To do that you first need to crack the software, then re apply a different protection. Why would you want to do such a thing? If you already have a crack you trust, then just use the plain unprotected crack that could be written without specialized hardware. Writing back copy protected software makes sense for the original, unaltered version.

So please Brume, make a Pasti dump of the disk.

Brume did already.

There is a Pasti dump in this thread that was taken from a different version. I don't see any Pasti dump from Brume's disk. And note that for this purpose it should be done directly on the ST, not converted from other formats.

[Brume]

So please Brume, make a Pasti dump of the disk.

No problem ijor, it's done. You can find it at the same place as the previous dumps:
https://mega.nz/#F!aUFAhQpD!pqQIwUnCFPNu2H-rLeJoSw