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.