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_analogtest [2022/03/02 15:02] – [What do all these graphs mean?] Added a bit more explanation. flanapp:using_analogtest [2022/03/02 20:21] (current) – ianoid
Line 42: Line 42:
 ==== Test settings ==== ==== Test settings ====
  
-There are only 2 setting for the analog test. The first is to choose the **Density**. This allows you to specify the density used for the test Low (DD) of High (HD). Be sure to use the proper media type with each setting or you will not get accurate results. For PC drives that support low and high density operation, many used different sets of filters for each density. The screen shots below show the same drive set to different densities with low on the left, and high on the right. The gold line clearly shows that the characteristics of the drive are quite different for each density.+There are only 2 settings for the analog test. The first setting is the **Density**. This allows you to specify Low (DD) or High (HD) density. Be sure to use the proper media type with each setting or you will not get accurate results. For PC drives that support low and high density operation, many used different sets of filters for each density. The screen shots below show the same drive set to different densities with low on the left, and high on the right. The gold line clearly shows that the characteristics of the drive are quite different for each density.
  
 {{:app:analog_pc525_dd.png?nolink&512 }}{{ :app:analog_pc525_hd.png?nolink&512 }} {{:app:analog_pc525_dd.png?nolink&512 }}{{ :app:analog_pc525_hd.png?nolink&512 }}
  
  
-The other setting is **View**. This allows you to perform the tests slightly differently. There is a **Heads** mode that put the head in the center of the disk and performs analysis on each head (in a 2 headed drive). The bottom drive head (head 0) will be shown on the bottom half of the graph, and the top head (head 1) will be shown on the top half. The other option is **Outer and Inner Tracks** which will perform the test with the head at each end of the media. The physical spacing of fluxes differs on the outer vs inner tracks, and so this lets you see how different the drive deals with each end.+The second setting is **View**. This allows you to perform the tests slightly differently. The **Heads** option puts the head in the center of the disk and performs analysis on each head (in a 2 headed drive). The bottom drive head (head 0) will be shown on the bottom half of the graph, and the top head (head 1) will be shown on the top half. The **Outer and Inner Tracks** will perform the test with the head at each end of the media. The physical spacing of fluxes differs on the outer vs inner tracks, and so this lets you see how different the drive deals with each end.
  
 ---- ----
 ==== If the Noise test is a worst-case scenario, why do we care about it? ==== ==== If the Noise test is a worst-case scenario, why do we care about it? ====
  
-For the most part when reading normally structured disks, you won't care about the noise level at all. Where it comes into play tends to be with various forms of copy protection that use no-flux areas on the disk (spiral track protections and such). These kinds of areas are not that uncommon for Apple II games. The below image shows three disk renderings of the same disk rendered in drives with low, medium, and high levels of noise.+For the most part when reading normally structured unprotected disks, you won't care about the noise level at all. Where it comes into play tends to be with various forms of copy protection that use no-flux areas on the disk (spiral track protections and such). These kinds of areas are common for Apple II games. The below image shows three disk renderings of the same disk rendered in drives with low, medium, and high levels of noise.
  
 {{ :app:analog_lr_noise.png?direct&768 |}} {{ :app:analog_lr_noise.png?direct&768 |}}
Line 70: Line 70:
 The primary analog test uses a test track that is comprised of a whole bunch of smaller tests. A test has a header, gap, payload, and settle field. The header contains information about the specific test (like the gap size). Following that is the gap (no flux area) whose duration ranges from 1µs to 48µs in 250ns increments. Then there is a payload which is a special bit sequence that is used to be able to detect bit slip, desynchronization, and other conditions. And then the settle which is a bit pattern that lets the analog amplifier/gain control/whatever cool down before the next test. The primary analog test uses a test track that is comprised of a whole bunch of smaller tests. A test has a header, gap, payload, and settle field. The header contains information about the specific test (like the gap size). Following that is the gap (no flux area) whose duration ranges from 1µs to 48µs in 250ns increments. Then there is a payload which is a special bit sequence that is used to be able to detect bit slip, desynchronization, and other conditions. And then the settle which is a bit pattern that lets the analog amplifier/gain control/whatever cool down before the next test.
  
-What it is checking for is the integrity of the gap and payload. If the gap is clean (no bits injected) and the payload is as well, then that is a success and it adds to the gray lines in the Stability graph. In the case of a failure, the payload is checked for integrity and if the payload is intact, then we check the gap. If the gap has a spurious transition (injected bit), then the time offset from the last flux transition of the header to the first spurious transition is recorded onto the First Injection Timing graph at the bottom. +To create the test track, the track is wiped (WRREQ on to engage head erase coil and writing no data), then the tests are generated and written. 
 + 
 +The test track is then read 50-ish times. What the test is checking for is the integrity of the gap and payload. If the gap is clean (no bits injected) and the payload is as well, then that is a success and it adds to the gray lines in the Stability graph. In the case of a failure, the payload is checked for integrity and if the payload is intact, then we check the gap. If the gap has a spurious transition (injected bit), then the time offset from the last flux transition of the header to the first spurious transition is recorded onto the First Injection Timing graph at the bottom.