SuperCard Pro Flux Image format (.scp)
#21
The flux data starts either from the index pulse or some random location, depending on the FLAG bit 0. If bit 0 is set, then the read starts from the index mark. If it is clear, then the read was from any random spot on the disk.

Spooling in two tracks, like with the analyzer is how you can duplicate tracks that do not actually start at the index mark, and yet still retain a skew reference to the index (when reading using the index). When reading from the backside of a disk (without an index reference), you lose the index reference capability.

If you read two revolutions in and look at the data starting from the 2nd revolution onwards, you can locate the gap area (or actual write splice via the FIND INVALID option) and move the cursor to that location and click on the SET FLUX END button. That marks the end of the flux data. Now, if you click the WRITE TRACK button, the 1st entire revolution and the part of the 2nd revolution (up to where you selected the flux end to be) will be written back. The write starts with the index pulse.
Reply
#22
Note that I just made a couple of more changes and documented some in post #19.

I made some things a bit more clear based on questions/discussions in this thread.
Reply
#23
I'm referring mostly to Amiga/ST disks here, since C64 protections can't read index hole positions due to lack of a sensor.

You can only retain a reference to the index when spooling in 2 tracks using the analyzer if you choose the "index sensor->reads->required" option. Otherwise, it just comes in random and you can't tell where the hole is since its position wasn't recorded during the read. In many cases, the track alignment to the physical index hole is not required and the method you describe should work. But in some protections, it is. So I'm not sure why there would ever be a need to start a read at a random position (on a 3.5" disk) when you can start at the index. This way, you know data relation to index always, and you don't have to update the scp specification at all.

BTW, I've never had that "find invalid" button do anything for me. I click it an nothing happens. Doesn't matter if I'm in MFM or Flux view mode.
Reply
#24
You will start reading at a random position when there is no index pulse available - like when reading a disk that has been flipped over. Unless it has a second index hole you can't use the index pulse to start the read, so it has to be "ignored". When this occurs, the track is read using a virtual index pulse so that exactly one revolution is read. You would NEVER use this option for 3.5" disks.

The FIND INVALID will locate a write splice if one exists. There is preliminary code for the Amiga/ST, but complete code for the C64 GCR stuff.

Apparently I can not ADD!! I just discovered why DrCoolZic was confused over the number of tracks. 0x10->0x2A4 is 165 entries, which is not an even multiple of 2. So, I got rid of the reserved long word at 0x2A4 (glad that was there!) and now there are 166 entries. So, for Amiga/ST disks that is tracks 0-82 (83 tracks), bottom and top heads. I changed the info in the specs file to reflect this change and I am changing the software as well.
Reply
#25
Thanks for updating the documentation

But if I understand you will update again so we get 2 more tracks Angel
Reply
#26
So the disk imager will also honour the "index sensor->reads->required" option when removing the check from "blind mode"?

I tried a number of images and disks, and did find a few that would show an invalid (flux transition times that were too short I suppose: $0081 and $006a) on a track here or there. Not sure if this is a bug, but when it marks the invalid flux transition and you switch the view to MFM, it doesn't show the corresponding MFM section where that invalid is, it jumps to whatever was last selected in the MFM window it seems. So I couldn't be sure, but it did appear that these invalid transitions appeared in the gap area.
Reply
#27
(01-04-2014, 03:21 PM)DrCoolZic Wrote: Thanks for updating the documentation

But if I understand you will update again so we get 2 more tracks Angel

The documentation is fully updated now. Tracks 0-82 (bottom and top) are the tracks allowed. This is a total of 166 entries spanning between 0x0010 and 0x2A8.
Reply
#28
(01-04-2014, 03:27 PM)LordCrass Wrote: So the disk imager will also honour the "index sensor->reads->required" option when removing the check from "blind mode"?

Yes, in all modes.


(01-04-2014, 03:27 PM)LordCrass Wrote: I tried a number of images and disks, and did find a few that would show an invalid (flux transition times that were too short I suppose: $0081 and $006a) on a track here or there. Not sure if this is a bug, but when it marks the invalid flux transition and you switch the view to MFM, it doesn't show the corresponding MFM section where that invalid is, it jumps to whatever was last selected in the MFM window it seems. So I couldn't be sure, but it did appear that these invalid transitions appeared in the gap area.

That's not a bug. That's the actual flux time. It's quite common to have flux times that are short, but more common to have really long times. In all cases, these are either weakbits or write splices.

I need to look into the analyzer again. I thought I fixed that issue jumping back and forth between flux and MFM.
Reply
#29
So, DrCoolZic, are you thinking of adding support for scp images to your flux transition analyzer? If so, I'm looking forward to that! I also appreciate your info-coach web site with the very informative details on the Atari FDC handling.

I read that your analyzer has support for PLL simulation for processing the bits. This is great for analyzing how the host systems will see the data as it would have been processed by their controllers. For straight conversion of flux to standard MFM/FM/others (no deliberate encoding/timing violations, just normal disks), do you find that this level of processing is required? Or is a simple range binning algorithm usually sufficient? ie. if flux timing is between 3.0us and 5.0us, consider it as an MFM "1", between 5.01us and 7.0us consider it a "01", etc..

Just wondering how difficult it is to get into conversion of flux timings to various other formats. Damaged disks that have timings that blur into other ranges obviously won't work with a simple algorithm, but from looking at the timings on my own disks (even old ones i've written to numerous times), it seems like the bands are very well defined for the most part.
Reply
#30
He already did. If you join the forum on www.atari-forum.com you can see the results. It proves that the SCP hardware is substantially better at imaging disks too. The image quality is much more accurate due to the higher resolution and not having the read data rounded and shifted signal edges that the Kryoflux board has.

Yes, you have the right idea. The bands are well defined, even when bits have shifted. If you use a window comparator like I use in my flux conversion routines for GCR and MFM, you can make data that is normally unreadable, now readable. My comparator window is set to +/-15% of the band. That is pretty narrow still, so I could go wider and that is one of the things I plan on implementing in the data recovery function. The disk controllers typically have a <10% comparator window. You don't need to do the PLL simulation because you have the raw flux data available to you and we don't care about clock and data bits, we simply rotate as necessary to syncronize the data when write splices occur. Unlike the Amiga where full tracks are written, the ST (just like the C64 and 1581) looks for the sector header and writes the sector data, so it generates a write splice. The WD1772 used in the ST parses the flux data as it comes in looking for the sync words to appear (448944894489, decoded as A1/A1/A1) and syncs the data to that, which fixes the issue with all of the write splices.

Here is a link to the comparison of SCP vs. KF.

http://www.atari-forum.com/viewtopic.php...25#p243037
Reply




Users browsing this thread: 1 Guest(s)