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?
npomarede wrote: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.