Preservation - that's the name of the game

A forum about Atari protected floppy disks analysis, preservation, emulation, tools

Moderators: DrCoolZic, Brume

svkelley
Atarian
Atarian
Posts: 2
Joined: Tue Jan 20, 2009 3:27 am

Re:

Postby svkelley » Sun Jan 25, 2009 6:34 pm

muguk wrote:
belboz wrote:Can a Pasti image of a non copy-protected disk be written back to disk with a normal ST/STE?

Or do you have to have a Discovery Cart or Cat Weasel?


Oooh .. tricky one there. I guess, if it's unprotected and more importantly Ijor releases a write-back tool for people to play with then it should be possible to do this. All depends on what extra information is stored in the STX files and as to how the tool interprets that information.

You'll definitely need the h/ware though for when you start doing the protected stuff.


Why would an Atari ST hardware owner use Pasti for backup if he or she cannot recover the STX content? So is Paisti some sort of one way ticket to emulation and there is no way to write back to disck with a normal ST/STE?

Sean

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

Re: Preservation - that's the name of the game

Postby DrCoolZic » Tue Jan 27, 2009 12:28 pm

This last message has retriggered the thread so I read it again completely.

First on the question:
Why would an Atari ST hardware owner use Pasti for backup if he or she cannot recover the STX content? So is Paisti some sort of one way ticket to emulation and there is no way to write back to disck with a normal ST/STE?
Yes currently Pasti is one way but it is feasible to create a program that would use the pasti file to write Floppys using special HW.

Here are some remarks questions...

On the subject of preservation as defined by Ijor: I find this technically challenging and interesting and therefore I do not really care whether it is necessary or not, good or bad, efficient or inefficient ... so keep working on it!

Publication of Pasti format: Ijor has promised to publish it long long time ago ... so we have to be patient as this is a must. Meanwhile, with the help of someone I do not want to mention here, I have looked at the information stored in pasti files (could not wait) and I now know about most of the information stored in the file. I did that because I wanted to compare the information stored in the pasti file to the information extracted by my "protection analysis program". On this subject, one place where I have made lots of work is on measuring as accurately as possible the timing of reading blocks of character (used for example in short/long sectors) and I have found results which are somewhat different from Pasti. I still need to investigate on this subject and the intent is to compare the results from pasti and my program with the extremely accurate results from the Discovery Cartridge. Unfortunately I had to stop all developments two months ago for lack of time… I hope more on this later.

There was a suggestion on using Pasti as a “protection detector”. This is exactly what the program I wrote is doing (it checks for above 20 protections). I already talked a bit about this program in other threads, and the status is as follow: I just completed a new version of the program that now has a nice GUI. The program has been tested on about 70 games but is still alpha. If there is interest (and if I find some time) I intended to publish the program in the coding section of the forum…

Now here is the question for Ijor if he is still around: You talk about the capability to find out if a diskette has been modified or not by a user: I would be interested to know technically how you think you can detect this. It turn out that I have been thinking/experimenting on this subject for some times. Here are some ideas and I would be interested to hear comments.
1) Reformatting a track: I believe that in this case the only way to find out is to check if there is a difference of timing between the track rewritten and the average timing of the other tracks. This would be caused by the fact that the FD drives have different rotation speed. If this happen it is feasible to detect reformatted track by measuring the track timing using standard FDC on the Atari. However if the drives speeds are too close it would not work.
2) Rewriting of one or several sectors: This one a little bit trickier. First what has been said above would also apply to the sector timing. In that case if we have one sector timing slightly different due to RPM variation it would be possible to detect it by measuring the sector timing using the standard FDC. But I believe that there is a more definitive way of knowing if a track has been rewritten and here is the explanation. When formatting, the complete track is written at once and of course there is“continuity” for the bits written one after another. On the other hand when a sector is rewritten the following happen (simplified): the FDC detect the “address block” of the sector and, if it is the correct sector to write, it then switch from read to write and starts to write in the gap following this address and finishes by writing the “new data block” and the following gaps. The switching from read to write is triggered at the “block” level and cannot be done at the “bit” level and therefore the “new bits” are generally shifted compared to the original bits. This can be detected with special HW like the discovery cartridge. We just need to check for an abnormal transition (in term of timing) in the GAP preceding the data sector rewritten as well as in the gap following it.

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

Re: Preservation - that's the name of the game

Postby ijor » Thu Feb 05, 2009 5:09 am

DrCoolZic wrote:This last message has retriggered the thread so I read it again completely...


Hi Jean,

Contact me by PM if you want to discuss the topics you raised here.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Preservation - that's the name of the game

Postby Dio » Thu Feb 12, 2009 10:54 pm

At least in theory, the optimum archival format is to store the MFM track images, the bitrate (which might vary), any error regions on the track, and in a few rare cases, possibly unwritable regions. Those without error regions could be written back to disk pretty easily. The emulator can then emulate the WDC1772 properly rather than relying on high-level techniques using the cooked data read by an actual 1772 (which is what STX is - it's a very detailed method, but it's still HLE).

Not that it's been tried yet to my knowledge, of course, and these things are never definitively 'the best' until they've been tried. (Perhaps some Amiga emulators use formats such as this, as their FDC was much closer to the MFM metal).


Social Media

     

Return to “Floppy Disk Preservation”

Who is online

Users browsing this forum: No registered users and 1 guest