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

All about the serious stuff.

Moderators: Mug UK, Zorro 2, Moderator Team

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

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

Postby JimDrew » Tue Nov 07, 2017 7:46 pm

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

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

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

Postby Steven Seagal » Wed Nov 08, 2017 10:35 am

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.


Tests seem to confirm that "diag 16" is indeed necessary to avoid random HALT (v 1.5).
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

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

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

Postby MiggyMog » Thu Nov 09, 2017 12:08 am

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.

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

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

Postby troed » Thu Nov 09, 2017 1:23 pm

MiggyMog 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:-


Boots up nicely in latest Hatari dev build here :) (TOS 1.62, will bomb out with TOS 2.06)

Thanks!

/Troed

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

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

Postby npomarede » Thu Nov 09, 2017 2:48 pm

troed wrote:
MiggyMog 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:-


Boots up nicely in latest Hatari dev build here :) (TOS 1.62, will bomb out with TOS 2.06)

Disk B seems badly preserved though, when loading module 'no_sense.mod' from the side2 directory, I get a disk error.
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.

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

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

Postby MiggyMog » Thu Nov 09, 2017 5:20 pm

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.

Maartau
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2630
Joined: Thu Dec 15, 2005 2:15 am

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

Postby Maartau » Thu Nov 09, 2017 8:16 pm

troed wrote:
MiggyMog 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:-


Boots up nicely in latest Hatari dev build here :) (TOS 1.62, will bomb out with TOS 2.06)

Thanks!

/Troed

Thanks MiggyMog [smilie=greencolorz4_pdt_01.gif] ...

...thanks Troed :thumbs: .

Thanks to : Steven, Nicolas & Jim too :cheers: :cheers: :cheers: .

:oops: ...also thanks to Brume & Dsp56001 :D :D :D.

8) 8) 8)

User avatar
dlfrsilver
Atari God
Atari God
Posts: 1483
Joined: Mon Jan 31, 2005 1:41 am
Contact:

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

Postby dlfrsilver » Fri Nov 10, 2017 3:24 pm

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 !

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

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

Postby Brume » Fri Nov 10, 2017 3:30 pm

Dam, how can you forget Amiga-man, Maartau? ;)

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

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

Postby MiggyMog » Fri Nov 10, 2017 7:23 pm

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.

Maartau
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2630
Joined: Thu Dec 15, 2005 2:15 am

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

Postby Maartau » Fri Nov 10, 2017 7:44 pm

dlfrsilver wrote:and thanks to me for contacting frederic bautista, who told us how the protection is working :)


Brume wrote:Dam, how can you forget Amiga-man, Maartau? ;)


Hell yeah, my bad & apologizes : also thanks to dlfrsilver :angel: :angel: :angel: .

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

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

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

Postby ijor » Fri Nov 10, 2017 9:34 pm

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.


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):

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


The difference is more in the order of two or three full bytes. Not bad and probably close enough for almost any disk, except this one. For this protection it's way too much and has no chance.

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

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

Postby JimDrew » Fri Nov 10, 2017 10:44 pm

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

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

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

Postby ijor » Fri Nov 10, 2017 11:28 pm

JimDrew wrote:Hmm... I don't see this much variance with any setup I have here. How are you determining the number of samples?


Simply, from the track header of the SCP images.

Maartau
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2630
Joined: Thu Dec 15, 2005 2:15 am

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

Postby Maartau » Sat Nov 11, 2017 12:49 am

Holy sh*t :oops: !

I also forget to thanks you Ijor :oops: ...

...

I've got one question : who was responsible to produce/make the "duplication" ?

- Thundersoft dev ? -> Frédéric, Pascal, ...
- Expose Software ?
- Sync ?

:shrug:

User avatar
dlfrsilver
Atari God
Atari God
Posts: 1483
Joined: Mon Jan 31, 2005 1:41 am
Contact:

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

Postby dlfrsilver » Sat Nov 11, 2017 8:52 pm

Frédéric Bautista.
Now SPS France representative since the 19th of June 2014. Proud to be an SPS member !

User avatar
Estrayk
Captain Atari
Captain Atari
Posts: 261
Joined: Mon Nov 23, 2015 2:52 pm
Location: Spain

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

Postby Estrayk » Thu Nov 23, 2017 10:24 pm

Hi troed, doesnt runs in Falcon coz AS doesn't run on it or because your crack doesnt work in Falcon?
Just curiosity,

thx
・Falcon ct60e・Atari MegaSTE ・Atari STe ・MIST ・MISTer・

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

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

Postby troed » Fri Nov 24, 2017 7:18 am

Estrayk wrote:Hi troed, doesnt runs in Falcon coz AS doesn't run on it or because your crack doesnt work in Falcon?
Just curiosity,


AS was written in 1990/1991. Falcon came out in 1992/1993 :) Even though AS handles TT nicely I would expect there to be many Falcon specific things that break it.

/Troed

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

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

Postby Steven Seagal » Sat Nov 25, 2017 8:39 am

Maybe the STOP is handled differently?
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

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

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

Postby npomarede » Sat Nov 25, 2017 10:12 am

Steven Seagal wrote:Maybe the STOP is handled differently?

Yes, stop on 68020/68030 behaves "correcty", no test of S bit in the new SR (it was checked by Toni Willen on Amiga).
But even so, I think the cracked version made by Troed doesn't work on Falcon (the TOS is not supported I think)

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

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

Postby troed » Sat Nov 25, 2017 10:17 am

npomarede wrote:
Steven Seagal wrote:Maybe the STOP is handled differently?

Yes, stop on 68020/68030 behaves "correcty", no test of S bit in the new SR (it was checked by Toni Willen on Amiga).
But even so, I think the cracked version made by Troed doesn't work on Falcon (the TOS is not supported I think)


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).

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2258
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

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

Postby DrCoolZic » Wed Jan 22, 2020 3:35 pm

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
Write Splices Information v1.0.pdf
You do not have the required permissions to view the files attached to this post.

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

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

Postby ijor » Thu Jan 23, 2020 1:53 am

Hi Jean,

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?


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).

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

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2258
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

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

Postby DrCoolZic » Thu Jan 23, 2020 1:50 pm

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.
as.PNG

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.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2258
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

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

Postby DrCoolZic » Thu Jan 23, 2020 4:03 pm

@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).
AS-sg-err.PNG

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.
as-data-content.PNG

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.


Social Media

     

Return to “Applications”

Who is online

Users browsing this forum: No registered users and 5 guests