meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
app:using_flux [2024/01/29 13:41] – pdevineapp:using_flux [2024/02/23 13:54] (current) – pdevine
Line 12: Line 12:
  
 2. Insert the disk into the drive, and click Image Disk button as shown below. 2. Insert the disk into the drive, and click Image Disk button as shown below.
-{{ :app:image_disk_button.png?500 |}}+{{ :app:image_disk_button.png?800 |}}
  
 3. The flux imager will start to record the disk. Depending on the type of drive and disk you're imaging, you might see a slightly different representation of the progress.  3. The flux imager will start to record the disk. Depending on the type of drive and disk you're imaging, you might see a slightly different representation of the progress. 
Line 21: Line 21:
  
 Finally, as another progress indicator, colored boxes may start to encircle the outside of the image. These are both progress bars and recording health indicators. When the colored bars make a complete circle the first pass of the recording has been made. 3.5" disks will show these outer progress colors while 5.25" disks will not have these indicators present. Finally, as another progress indicator, colored boxes may start to encircle the outside of the image. These are both progress bars and recording health indicators. When the colored bars make a complete circle the first pass of the recording has been made. 3.5" disks will show these outer progress colors while 5.25" disks will not have these indicators present.
-{{ :app:flux_imager_start.png?500 |}}+{{ :app:flux_imager_start.png?800 |}}
  
-  * Green indicates the track has been recorded with data that has sector structures, no bad sectors, and low noise. +  * **Green** (healthy) indicates the track has been recorded with data that has sector structures, no bad sectors, and low noise. 
-  * Yellow means that it does see sector structures, but it is also seeing a bunch of noise and/or bad sectors. +  * **Yellow** (poor) means that it does see sector structures, but it is also seeing a bunch of noise and/or bad sectors. 
-  * Red means that it can't find any sector structures.  +  * **Red** (bad) means that it can't find any sector structures.  
-  * Blue indicates XXX.+  * **Blue** (really bad) indicates it doesn't recognize the encoding format (FM, MFM, GCR) of the track at all.
  
-The flux image makes an initial first pass reading of the disk. This initial pass helps the Flux Imager get its bearing as to what's on the disk. While making the first pass the flux image counts the current track in the middle of the screen, and it also counts the elapsed time to read the disk on the left-hand side. The current track count is represented as a hexadecimal number. The below image shows the first pass as it's nearing completion. +The flux image makes an initial first pass reading of the disk. This initial pass helps the Flux Imager get its bearing as to what's on the disk. While making the first pass the flux image counts the current track in the middle of the screen (shown as 3C in the image below, or 60 in decimal) and displays the elapsed time to read the disk on the left-hand side. The current track count is represented as a hexadecimal number. The below image shows the first pass as it's nearing completion. 
-{{ :app:flux_1st_pass_late.png?500 |}}+{{ :app:flux_1st_pass_late.png?800 |}}
  
 Some disks have complex medleys of various formats, where publishers might have put MFM data in one set of tracks and GCR data in another. After moving across the whole surface of the disk from the outside in towards the center, the imager then reverses the process and takes a second pass through the disk gong from the inside track outward.  Some disks have complex medleys of various formats, where publishers might have put MFM data in one set of tracks and GCR data in another. After moving across the whole surface of the disk from the outside in towards the center, the imager then reverses the process and takes a second pass through the disk gong from the inside track outward. 
Line 36: Line 36:
  
 As this format is designed to capture potentially intentional errors used by copy-protection mechanisms, AppleSauce will attempt to record accurate representations of blank, damaged, or corrupted data. This can be challenging as some corrupt information has occurred due to physical damage, dirt or mold on the disk, or simply the impact of time. While other data was intentionally corrupted during the disk creation process as part of a copy protection scheme. Multiple passes of each track gives the Applesauce a better sense of how to interpret this messy reality. While doing the second pass the track count decrements from the highest track to the lowest track, meaning it counts backwards. The elapsed time continues to count the total time the imaging process is taking. Below shows an image of the second pass halfway completed, note the aqua circle is traveling in the opposite direction towards the outside of the disk. As this format is designed to capture potentially intentional errors used by copy-protection mechanisms, AppleSauce will attempt to record accurate representations of blank, damaged, or corrupted data. This can be challenging as some corrupt information has occurred due to physical damage, dirt or mold on the disk, or simply the impact of time. While other data was intentionally corrupted during the disk creation process as part of a copy protection scheme. Multiple passes of each track gives the Applesauce a better sense of how to interpret this messy reality. While doing the second pass the track count decrements from the highest track to the lowest track, meaning it counts backwards. The elapsed time continues to count the total time the imaging process is taking. Below shows an image of the second pass halfway completed, note the aqua circle is traveling in the opposite direction towards the outside of the disk.
-{{ :app:flux_second_pass_early.png?500 |}}+{{ :app:flux_second_pass_early.png?800 |}}
  
 4. While the disk is being imaged, you can fill out the Product Metadata on the right-hand side of the screen. Often this can be obtained from the disk label, while sometimes you need to allow the imaging process to be completed to know what's actually on the disk. For archival purposes try to be as complete as possible. Remember individuals in the future may get a copy of the .a2r and might need a serial number, unlock key, or other information that's on the disk label or jacket. More information is always better.  4. While the disk is being imaged, you can fill out the Product Metadata on the right-hand side of the screen. Often this can be obtained from the disk label, while sometimes you need to allow the imaging process to be completed to know what's actually on the disk. For archival purposes try to be as complete as possible. Remember individuals in the future may get a copy of the .a2r and might need a serial number, unlock key, or other information that's on the disk label or jacket. More information is always better. 
-{{ :app:meta_data_completed.png?500 |}}+{{ :app:meta_data_completed.png?800 |}}
  
  
 5. When the disk has completed being read, click the Save & Analyze button in the lower right-hand corner of the screen. 5. When the disk has completed being read, click the Save & Analyze button in the lower right-hand corner of the screen.
-{{ :app:meta_data_completed.png?500 |}}+{{ :app:meta_data_completed.png?800 |}}
  
 6. The disk will open in the disk analyzer. 6. The disk will open in the disk analyzer.
-{{ :app:disk_analyzer.png?600 |}}+{{ :app:disk_analyzer.png?800 |}}
  
 ---- ----
Line 62: Line 62:
 Here are some example flux recordings so you can see how the visualization differs between various floppy data formats. In addition, note that the metadata fields change depending on what is selected in the Platform pulldown. This is to help you identify dependencies frequently encountered on each computing platform. Here are some example flux recordings so you can see how the visualization differs between various floppy data formats. In addition, note that the metadata fields change depending on what is selected in the Platform pulldown. This is to help you identify dependencies frequently encountered on each computing platform.
  
-  * Below is an example of a poor quality 800K Mac HFS disk. There are two points in time represented. The first image shows the output of the display as the first pass is being completed. In the left-hand, Side A visualization, note the red and yellow indicators around the 8 o'clock position. Then in the second image, note how many of the indicators in that spot have turned yellow or green.+  * Below is an example of a poor quality 800K Mac HFS disk. There are two points in time represented. The first image shows the output of the display as the first pass is being completed, at 1:10 elapsed. In the left-hand, Side A visualization, note the red and yellow indicators around the 8 o'clock position. Then in the second image, at 4:00 elapsed, note how many of the indicators in the 8 o'clock spot have improved to yellow or green after Applesauce has made several attempts to recover the data. Since this disk is not copy protected, attempting to recover the data using the Fast Imager would probably prove fruitful. The Fast Imager would allow for more attempts at re-reading the difficult sections of the disk. Also, the Fast Imager would allow attempts to recover the damaged sections with several different drives, where some drives might do better on certain sectors than other drives. Finally, a disk like this should be inspected under magnification to look for dirt or mold. A solid cleaning and/or a drop of cyclomethicone might render this disk fully readable.
 {{ :app:bad_disk_inital_pass.png?800 |}} {{ :app:bad_disk_inital_pass.png?800 |}}
 {{ :app:bad_disk_final.png?800 |}} {{ :app:bad_disk_final.png?800 |}}
Line 69: Line 69:
 {{ :app:1440k_dshd_mac_disk_second_pass.png?800 |}} {{ :app:1440k_dshd_mac_disk_second_pass.png?800 |}}
  
-  * Below is an example of a 5.25" DSDD 360K MFM IBM Disk. Notice the fading that appears at the 1 o'clock and 7 o'clock positions in the image, this is likely due to either dirt on the disk or the magnetic signal starting to break down. Also notice the gray area appears to have banding or gaps. This is due to a double-density disk being imaged on a high-density drive.+  * Below is an example of a 5.25" DSDD 360K MFM IBM Disk. Notice the fading that appears at the 11 o'clock and 7 o'clock positions in the image, this is likely due to either dirt on the disk, problems with the binder, or the magnetic signal starting to break down. Also notice the gray area appears to have banding or stripes. This is due to a double-density disk being imaged on a high-density drive. Half of the tracks will not have data due to the high density drive expecting the data to be more tightly packed, and finding nothing between the double-density track gaps.
 {{ :app:mfm_ibm_disk.png?800 |}} {{ :app:mfm_ibm_disk.png?800 |}}
  
   * Below is an example of a 5.25" SSQD 620K Victor 9000 GCR Disk. Note the right-hand circle is black because this is a single-sided disk with no data on Side B. The Flux Imager tried to read several of the outer tracks on Side B, and when it saw a pattern of no data on the 2nd side it determined it was a single sided disk.   * Below is an example of a 5.25" SSQD 620K Victor 9000 GCR Disk. Note the right-hand circle is black because this is a single-sided disk with no data on Side B. The Flux Imager tried to read several of the outer tracks on Side B, and when it saw a pattern of no data on the 2nd side it determined it was a single sided disk.
 {{ :app:ssdd_victor_disk_second_pass.png?800 |}} {{ :app:ssdd_victor_disk_second_pass.png?800 |}}
 +
 +  * Below is an example of a 5.25" Flippy DSQD 1.2M Victor 9000 GCR Disk. Note the Flux Imager saw data on both sides of the disk so the autodetect treated it as a double-sided disk. But this is a flippy—meaning the disk was treated as if each side was a single-sided disk. In the vintage hardware the second side was written and read by inserting the disk upside down, hence the name flippy. Only drives that didn't utilize an index sensor could read and write flippy disks. Because of this, when read right-side up by the Applesauce the disk data will be read backwards and the track will be slightly misaligned for the Side B as the upper and lower recording heads are not in the same position relative to the disk. So after imaging the data on the second side will not be valid when read this way. 
 +{{ :app:victor_flippy_complete.png?800 |}}