
Req : "Audio Sculpture" (STX,...) even not running...
Moderators: Mug UK, Zorro 2, Moderator Team
Re: Req : "Audio Sculpture" (STX,...) even not running...
LOL! Sorry, remember I am not an "Atari guy". I spent most of my life (from 1977 til now) working on Commodore stuff. I never made products for the Atari line, but I sold a lot of Supercard Ami's to Atari ST user groups that used an Amiga 500 to back up their Atari ST disks. 

I am the flux ninja
- Steven Seagal
- Fuji Shaped Bastard
- Posts: 2018
- Joined: Sun Dec 04, 2005 9:12 am
- Location: Undisclosed
- Contact:
Re: Req : "Audio Sculpture" (STX,...) even not running...
Tests seem to confirm that "diag 16" is indeed necessary to avoid random HALT (v 1.5).ijor wrote:Regarding the Pasti images, you might need to use the undocumented diag Code 16 in the Pasti Config Option pane. I'll provide later a correct 1.3 Pasti image that doesn't need this option. For 1.5 it is more difficult since we don't have a flux level dump of that version.
Also this program is one of the most sensitive to some MFP timings in emulation. So this could be MFP emulation imprecision.
EDIT: Well no, the apparent MFP issue was hiding another real STOP issue.
About how to write back the disk, one definite way is to replicate what the dudes did: read track 3, compute the key and write it wherever it should be. So, the "master" approach in this case. This can be automated.
Last edited by Steven Seagal on Fri Nov 10, 2017 8:05 pm, edited 1 time in total.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
Steem SSE: http://sourceforge.net/projects/steemsse
Re: Req : "Audio Sculpture" (STX,...) even not running...
I hope the attached are working ok. I didn't have time to test. I had a heck of a time getting my cosmosex to cooperate. Here goes:-
You do not have the required permissions to view the files attached to this post.
('< o o o o |''| STM,2xSTFM,2xSTE+HD,C-Lab Falcon MK2+HD,Satandisk,Ultrasatandisk,Ethernat.
Re: Req : "Audio Sculpture" (STX,...) even not running...
Boots up nicely in latest Hatari dev build hereMiggyMog wrote:I hope the attached are working ok. I didn't have time to test. I had a heck of a time getting my cosmosex to cooperate. Here goes:-

Thanks!
/Troed
Re: Req : "Audio Sculpture" (STX,...) even not running...
Disk B seems badly preserved though, when loading module 'no_sense.mod' from the side2 directory, I get a disk error.troed wrote:Boots up nicely in latest Hatari dev build hereMiggyMog wrote:I hope the attached are working ok. I didn't have time to test. I had a heck of a time getting my cosmosex to cooperate. Here goes:-(TOS 1.62, will bomb out with TOS 2.06)
But it seems AS 1.2 disk B is the same as AS 1.3 disk B, so that's not such a big problem.
Re: Req : "Audio Sculpture" (STX,...) even not running...
That's good disk A was ok. I can re- image disk B at some point. But as you say not much value
('< o o o o |''| STM,2xSTFM,2xSTE+HD,C-Lab Falcon MK2+HD,Satandisk,Ultrasatandisk,Ethernat.
Re: Req : "Audio Sculpture" (STX,...) even not running...
Thanks MiggyMog [smilie=greencolorz4_pdt_01.gif] ...troed wrote:Boots up nicely in latest Hatari dev build hereMiggyMog wrote:I hope the attached are working ok. I didn't have time to test. I had a heck of a time getting my cosmosex to cooperate. Here goes:-(TOS 1.62, will bomb out with TOS 2.06)
Thanks!
/Troed
...thanks Troed

Thanks to : Steven, Nicolas & Jim too










- dlfrsilver
- Atari God
- Posts: 1517
- Joined: Mon Jan 31, 2005 1:41 am
Re: Req : "Audio Sculpture" (STX,...) even not running...
and thanks to me for contacting frederic bautista, who told us how the protection is working 

Now SPS France representative since the 19th of June 2014. Proud to be an SPS member !
Re: Req : "Audio Sculpture" (STX,...) even not running...
Dam, how can you forget Amiga-man, Maartau? 

Re: Req : "Audio Sculpture" (STX,...) even not running...
Talking ofd Amiga. I seen the amiga version was for sale on eBay.
('< o o o o |''| STM,2xSTFM,2xSTE+HD,C-Lab Falcon MK2+HD,Satandisk,Ultrasatandisk,Ethernat.
Re: Req : "Audio Sculpture" (STX,...) even not running...
dlfrsilver wrote:and thanks to me for contacting frederic bautista, who told us how the protection is working
Hell yeah, my bad & apologizes : also thanks to dlfrsilverBrume wrote:Dam, how can you forget Amiga-man, Maartau?



-> "we" can seek for an 1.4 original version too

Re: Req : "Audio Sculpture" (STX,...) even not running...
I compared the original dump made by Brume and a copy of that dump written back to disk with the SCP (in a different drive):JimDrew wrote: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.
Code: Select all
...... Original .......... Copy ............. Diff in # of transitions
===============================================================
Track 0: samples: 46654. samples: 46665 11
Track 1: samples: 38500. samples: 38518 18
Track 2: samples: 38637. samples: 38664 27
Track 3: samples: 38082. samples: 38114 32
Track 4: samples: 38448. samples: 38474 26
Re: Req : "Audio Sculpture" (STX,...) even not running...
Hmm... I don't see this much variance with any setup I have here. How are you determining the number of samples?
I am the flux ninja
Re: Req : "Audio Sculpture" (STX,...) even not running...
Simply, from the track header of the SCP images.JimDrew wrote:Hmm... I don't see this much variance with any setup I have here. How are you determining the number of samples?
Re: Req : "Audio Sculpture" (STX,...) even not running...
Holy sh*t
!
I also forget to thanks you Ijor
...
...
I've got one question : who was responsible to produce/make the "duplication" ?
- Thundersoft dev ? -> Frédéric, Pascal, ...
- Expose Software ?
- Sync ?


I also forget to thanks you Ijor

...
I've got one question : who was responsible to produce/make the "duplication" ?
- Thundersoft dev ? -> Frédéric, Pascal, ...
- Expose Software ?
- Sync ?

- dlfrsilver
- Atari God
- Posts: 1517
- Joined: Mon Jan 31, 2005 1:41 am
Re: Req : "Audio Sculpture" (STX,...) even not running...
Frédéric Bautista.
Now SPS France representative since the 19th of June 2014. Proud to be an SPS member !
Re: Req : "Audio Sculpture" (STX,...) even not running...
Hi troed, doesnt runs in Falcon coz AS doesn't run on it or because your crack doesnt work in Falcon?
Just curiosity,
thx
Just curiosity,
thx
・Falcon ct60e・Atari MegaSTE ・Atari STe ・MIST ・MISTer・
Re: Req : "Audio Sculpture" (STX,...) even not running...
AS was written in 1990/1991. Falcon came out in 1992/1993Estrayk wrote:Hi troed, doesnt runs in Falcon coz AS doesn't run on it or because your crack doesnt work in Falcon?
Just curiosity,

/Troed
- Steven Seagal
- Fuji Shaped Bastard
- Posts: 2018
- Joined: Sun Dec 04, 2005 9:12 am
- Location: Undisclosed
- Contact:
Re: Req : "Audio Sculpture" (STX,...) even not running...
Maybe the STOP is handled differently?
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse
Steem SSE: http://sourceforge.net/projects/steemsse
Re: Req : "Audio Sculpture" (STX,...) even not running...
Yes, stop on 68020/68030 behaves "correcty", no test of S bit in the new SR (it was checked by Toni Willen on Amiga).Steven Seagal wrote:Maybe the STOP is handled differently?
But even so, I think the cracked version made by Troed doesn't work on Falcon (the TOS is not supported I think)
Re: Req : "Audio Sculpture" (STX,...) even not running...
I don't believe AS uses TOS at all, I would expect the reason to be purely hardware differences. The uncracked version does patch TOS as part of its protection and that's the reason why it's not working on TOS 2.06 (came out later).npomarede wrote:Yes, stop on 68020/68030 behaves "correcty", no test of S bit in the new SR (it was checked by Toni Willen on Amiga).Steven Seagal wrote:Maybe the STOP is handled differently?
But even so, I think the cracked version made by Troed doesn't work on Falcon (the TOS is not supported I think)
- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2261
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Req : "Audio Sculpture" (STX,...) even not running...
Being away for some times, I just discovered this old but very interesting thread!
I briefly looked at the image under Aufit and found lots of interesting info / problems that I need to eventually address.
But most of my problems are related to write splice detection ...
So if Ijor is still looking at this thread I have a question for him (actually anybody is welcome to answer): Can you explain simply what is the best way to detect the write splice. I am currently using a very complex process that checks both rupture in bit length and a state machine that checks rupture in bytes value etc. It works in most cases but it is complex and not reliable and therefore not satisfying.
Can this be done without interpreting the byte content, just a the flux level? And is there cases where it can't be detected reliably because the flux length of the write splice is equal or close to normal bit length?
I have attached a document that describes in more detail what is used in Aufit
I briefly looked at the image under Aufit and found lots of interesting info / problems that I need to eventually address.
But most of my problems are related to write splice detection ...
So if Ijor is still looking at this thread I have a question for him (actually anybody is welcome to answer): Can you explain simply what is the best way to detect the write splice. I am currently using a very complex process that checks both rupture in bit length and a state machine that checks rupture in bytes value etc. It works in most cases but it is complex and not reliable and therefore not satisfying.
Can this be done without interpreting the byte content, just a the flux level? And is there cases where it can't be detected reliably because the flux length of the write splice is equal or close to normal bit length?
I have attached a document that describes in more detail what is used in Aufit
You do not have the required permissions to view the files attached to this post.
Visit *** http://info-coach.fr/atari ***
Re: Req : "Audio Sculpture" (STX,...) even not running...
Hi Jean,
Yes, ideally you should combine both a low and a high level analysis. Sometimes the track is very "clean" at both levels, except at the splice point. In those cases it is relatively straightforward. Sometimes depending on how the track was recorded, the flux transitions might be very irregular. Sometimes there are multiple write splices. Sometimes there isn't exactly a write splice point, but recording was ended some time before the index (or the start). In those cases, the start and the end of the recording don't overlap. This is not so uncommon because duplicators usually ended the recording at a fixed data length, and if the drive was rotating slightly slower, the recorded length wouldn't cover a full revolution.
Yes, if you are "unlucky", the transitions at the write splice could be (just by chance) the same, or almost the same as a regular transition. And this obviously, is more likely when the track transitions are not so regular and normalized in the first place. IMHO, at the end of the day, the best you can do is to combine analysis at multiple levels and make a more or less educated guess.
Note that the protection here doesn't attempt to detect the write splice. It just reads and compares the data that is supposed to be at the write splice. I also am not sure you can really detect this protection by a disk analysis alone. Probably in the best case you can determine that there is a sector that spawns the index and what it seems to be the write splice. You can of course guess/infer the possible/probable purpose of a such a sector.
I don't think there is a foolproof reliable way to detect a write splice. At least not without having access to the full analog magnetic recording (not just the transitions).DrCoolZic wrote:But most of my problems are related to write splice detection ...
So if Ijor is still looking at this thread I have a question for him (actually anybody is welcome to answer): Can you explain simply what is the best way to detect the write splice. I am currently using a very complex process that checks both rupture in bit length and a state machine that checks rupture in bytes value etc. It works in most cases but it is complex and not reliable and therefore not satisfying.
Can this be done without interpreting the byte content, just a the flux level? And is there cases where it can't be detected reliably because the flux length of the write splice is equal or close to normal bit length?
Yes, ideally you should combine both a low and a high level analysis. Sometimes the track is very "clean" at both levels, except at the splice point. In those cases it is relatively straightforward. Sometimes depending on how the track was recorded, the flux transitions might be very irregular. Sometimes there are multiple write splices. Sometimes there isn't exactly a write splice point, but recording was ended some time before the index (or the start). In those cases, the start and the end of the recording don't overlap. This is not so uncommon because duplicators usually ended the recording at a fixed data length, and if the drive was rotating slightly slower, the recorded length wouldn't cover a full revolution.
Yes, if you are "unlucky", the transitions at the write splice could be (just by chance) the same, or almost the same as a regular transition. And this obviously, is more likely when the track transitions are not so regular and normalized in the first place. IMHO, at the end of the day, the best you can do is to combine analysis at multiple levels and make a more or less educated guess.
Note that the protection here doesn't attempt to detect the write splice. It just reads and compares the data that is supposed to be at the write splice. I also am not sure you can really detect this protection by a disk analysis alone. Probably in the best case you can determine that there is a sector that spawns the index and what it seems to be the write splice. You can of course guess/infer the possible/probable purpose of a such a sector.
Fx Cast: Atari St cycle accurate fpga core
- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2261
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Req : "Audio Sculpture" (STX,...) even not running...
Thanks Ijor. It looks like at least I am moving in the right direction…
I did not consider the possibility of multiple write splice (what I refer as ‘track write splice’) as the result of using duplicators with fix (and probably slightly shorter) track length.
As described in my document I am also trying to differentiate “sector write splice” from “track write splice”. To be able to make the distinction between the two requires high-level analysis. The reason for detecting sector write splice is to be able to detect if a FD has been modified (tampered). The splice detection as described is only available in my ‘in progress’ version 1.4 of Aufit. In this version, I am attempting to regenerate a “perfect master image” from known templates and splice detection is a requirement. The goal is to be able to write perfect image in IPF or STX format.
For the protections present on track three, I need to improve Aufit, because this track used a very smart mechanism that I have never seen before: Each sector contains two ID_field in front of the Data_field! We have exactly 30 bytes (post_id_gap=7 + id_field = 6 + post_id_gap=17) from the end of the first ID_field to the data_field. This is less than the maximum 43 bytes in DD allowed by the WD1772 to correctly read a sector. I have not yet tried to read this tracks under emulation with the WD1772, but in theory you should be able to read the same sector with two different id (sector 2 and sector 12, sector 3 and Sector 13, etc.). To be more precise the first ID declare a record length of 512 and should read without CRC error, while the second ID declare a length of 1024 and should reads with a CRC error (because it is a truncated sector) but the first 512 bytes should be the same. About the last sector that contains the write splice: We also have two ID_fields: the first one describes a sector 10, and is followed by another ID_field that contains many invalid values and has a bad CRC. As sector 10 is declared to be 1024 bytes long it ‘extent over the index’ (where we have the write splice)… I have to further analyze this protection, but as the write splice is detected by Aufit INSIDE the content of the sector it should possible to use this information to detect this specific protection mechanism.
As far as I understand this protection was produced ‘by hand’ (not on a duplicator) and probably on an Atari? On the Atari, a track is written from IP to IP. As the last sector is declare with a length of 1024 the end of the sector is well behind the IP and consequently it is truncated by the WD1772 at the IP. As mentioned this position where is is truncated is dependent of the motor speed and should be different each time… Remember that if a write track is stopped by the IP, a read sector is not (can go beyond IP).
By the way there was no feedback from Jim being able to write back a working FD?
Therefore I assume nobody was able to produce a working FD from SCP (or from KF) for this protection?
This discussion about writing flux reminds me when I first discovered the Discovery Cartridge in the 80’s: At that time I could not understand why it was not possible to copy all existing FD just using a perfect ‘track flux copy’!
Question to ‘dlfrsilver’: Did you tried to analyze the program under CTA (I will give a try, but I first need to reinstall the dongle protection)? I think you were supposed to get information from people at SPS? Any news from them?
I did not consider the possibility of multiple write splice (what I refer as ‘track write splice’) as the result of using duplicators with fix (and probably slightly shorter) track length.
As described in my document I am also trying to differentiate “sector write splice” from “track write splice”. To be able to make the distinction between the two requires high-level analysis. The reason for detecting sector write splice is to be able to detect if a FD has been modified (tampered). The splice detection as described is only available in my ‘in progress’ version 1.4 of Aufit. In this version, I am attempting to regenerate a “perfect master image” from known templates and splice detection is a requirement. The goal is to be able to write perfect image in IPF or STX format.
For the protections present on track three, I need to improve Aufit, because this track used a very smart mechanism that I have never seen before: Each sector contains two ID_field in front of the Data_field! We have exactly 30 bytes (post_id_gap=7 + id_field = 6 + post_id_gap=17) from the end of the first ID_field to the data_field. This is less than the maximum 43 bytes in DD allowed by the WD1772 to correctly read a sector. I have not yet tried to read this tracks under emulation with the WD1772, but in theory you should be able to read the same sector with two different id (sector 2 and sector 12, sector 3 and Sector 13, etc.). To be more precise the first ID declare a record length of 512 and should read without CRC error, while the second ID declare a length of 1024 and should reads with a CRC error (because it is a truncated sector) but the first 512 bytes should be the same. About the last sector that contains the write splice: We also have two ID_fields: the first one describes a sector 10, and is followed by another ID_field that contains many invalid values and has a bad CRC. As sector 10 is declared to be 1024 bytes long it ‘extent over the index’ (where we have the write splice)… I have to further analyze this protection, but as the write splice is detected by Aufit INSIDE the content of the sector it should possible to use this information to detect this specific protection mechanism.
As far as I understand this protection was produced ‘by hand’ (not on a duplicator) and probably on an Atari? On the Atari, a track is written from IP to IP. As the last sector is declare with a length of 1024 the end of the sector is well behind the IP and consequently it is truncated by the WD1772 at the IP. As mentioned this position where is is truncated is dependent of the motor speed and should be different each time… Remember that if a write track is stopped by the IP, a read sector is not (can go beyond IP).
By the way there was no feedback from Jim being able to write back a working FD?
Therefore I assume nobody was able to produce a working FD from SCP (or from KF) for this protection?
This discussion about writing flux reminds me when I first discovered the Discovery Cartridge in the 80’s: At that time I could not understand why it was not possible to copy all existing FD just using a perfect ‘track flux copy’!
Question to ‘dlfrsilver’: Did you tried to analyze the program under CTA (I will give a try, but I first need to reinstall the dongle protection)? I think you were supposed to get information from people at SPS? Any news from them?
You do not have the required permissions to view the files attached to this post.
Visit *** http://info-coach.fr/atari ***
- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2261
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Req : "Audio Sculpture" (STX,...) even not running...
@dlfrsilver : I have setup my system to use CTA and guess what it does not seems to like this image!
It complains on almost all tracks! Actually if the FD has been written on an Atari this could make sense. CTA using some magic finds that the tracks have been tempered, which make sense, as probably each track is first formatted (write track) then content is written using write sector (this should generate sector write splice). Therefore, it is a pain if you try to analyze the complete FD. So what I did is to is to only analyze track 3.0. I am first getting this error: SG error unresolved group (I never could get the meaning of this error from SPS?). Then, when analyzed CTA incorrectly detect (with probability of 50%) the track has a speelock track. By setting the Sync to DOS it correctly detects 10 sync marks (I guess data sync mark) but the content does not make too much sense. I have tried to select manually MFM format but it is rejected. Can you have a look at the ctr image with CTA? Can you ask Istvan some help?
For info in Aufit I detect: last data_field is at about 179.85ms with length about 32.6ms -> places the end at 212.4 well beyond splice at 0 (=200)
It complains on almost all tracks! Actually if the FD has been written on an Atari this could make sense. CTA using some magic finds that the tracks have been tempered, which make sense, as probably each track is first formatted (write track) then content is written using write sector (this should generate sector write splice). Therefore, it is a pain if you try to analyze the complete FD. So what I did is to is to only analyze track 3.0. I am first getting this error: SG error unresolved group (I never could get the meaning of this error from SPS?). Then, when analyzed CTA incorrectly detect (with probability of 50%) the track has a speelock track. By setting the Sync to DOS it correctly detects 10 sync marks (I guess data sync mark) but the content does not make too much sense. I have tried to select manually MFM format but it is rejected. Can you have a look at the ctr image with CTA? Can you ask Istvan some help?
For info in Aufit I detect: last data_field is at about 179.85ms with length about 32.6ms -> places the end at 212.4 well beyond splice at 0 (=200)
You do not have the required permissions to view the files attached to this post.
Visit *** http://info-coach.fr/atari ***