I want to review the difficult to handle case of having an NFA located over the index.
It might be interesting for Jeff to modify the way HxC currently works to better handle this case when reading information from raw stream file.
It might be also interesting for Jim if he finally decides to fix the SCP format and SCP sampling behavior in order to provides correct information in this case.
Description of NFA over index
It is possible to have the No Flux Area located over the Index pulse.
This is a hard to handle case for programs that reads the flux transitions produced by devices like Kryoflux and SuperCard Pro. These devices sample the index pulse and data pulse produced by floppy drives.
It is good to know that, for obvious reasons, in (almost) all cases the index pulse and the data pulse are not synchronized. In order to correctly interpret the information sampled, it is therefore necessary to know the position of the index pulses relative to the data pulse.
In “normal” cases (i.e. for data pulse in range 4 to 8 µs) it is acceptable to ignore the position of the index relative to the current flux transition, but in case where a no flux area is located over the index it is mandatory to get and interpret correctly this information.
Here is a typical case of an NFA over index. As we can see we have a huge area without flux transition located just above the index. In the figure we show three important values: one is the “NFA flux value” (typically around 4 to 5 ms.), the pre-Index time value, and the post-Index time value (only 2 of these three values are required as the third can be easily computed from the other two). For a practical example I use the Turrican game. On my version track 8 has a NFA of about 4.3 ms located on top of the index. The pre-index value is about 3 ms and therefore the post-index is about 1.3 ms.
Here is the correct display of this track by Aufit using Kryoflux raw stream file The Kryoflux raw stream format provides the NFA value as well as the pre-index timing (see my documentation KryoFlux Stream File Documentation at http://info-coach.fr/atari/documents/_m ... otocol.pdf).
The only way to be able to provide this kind information is to start to sample flux before the index as the Kryoflux device does.
It is the responsibility of the program reading the raw stream to use correctly this information. For example the HxC program currently seems to ignore the pre-index value As you can see the complete NFA is passed as the first flux in the revolution, but as the pre-index value is ignored the complete NFA is positioned at the beginning of the track resulting in an incorrect display and incorrect position values in Pasti file.
Unfortunately the SCP format does not provide any information about the positioning of the index pulse relative to data pulse. I have requested this feature to Jim several times on Atari-Forum as well as on the SCP forum without success. The situation is bad because it is doubled by several problems:
- The sampling of transitions on the SCP device starts at the index pulse. If this behavior is not changed it will never be possible to detect the position of the index in the transition happening before the index.
- The results is the No Flux Area is just not transmitted on the first revolution (one more reason to sample several revolutions). On the second revolution the NFA is passed as the first transition.
- Normally it is expected that the sum of the length of all the transitions in one revolution is equal to the revolution time given as the time between two indexes. But this does not work in SCP format because the sum does not include the post-index part of the NFA and therefore the value in that case is much smaller than the expected value. This is to compare to the exact value transmitted by KF raw stream as explained page 14 of KryoFlux Stream File Documentation.
Of course the HxC software cannot do better as you can see here: Here we can see that the first revolution does not indicates any NFA (as not stored in the SCP file) and the second revolution has the complete NFA in the first position.
Fortunately for the end user it seems that in all the games using the NFA protection that I have tested the relative position of the NFA is not relevant. Therefore even though the information displayed and saved in the Pasti STX file is incorrect the test of the protection seems to work in all my test cases.