Questions about new Graph capability in DTC

[DrCoolZic]

Yes, I had to, as some conversions generated stream files that crashed DTC at random points in the analyser pipeline... or worse, DTC did not crash but the results were incorrect/random.

From the 2.72 release notes:
- prevent using a stream file with broken index signal data (generated by
some third party tools)
- ensure that broken index data does not cause invalid calculations and
NaNs for the cell conversion and thus later crashes at random stages of the
analyser pipeline

...and here is the original bug report:
https://forum.kryoflux.com/viewtopic.php?f=3&t=1398

Thanks for the information but it does not really help.

I expect that the format stay as described in the documentation and therefore the only possible problem I see is what I describe in my document http://info-coach.fr/atari/documents/_m ... otocol.pdf page 10 and page 13

• Index Time: This is the time taken for one complete revolution of the disk. It is equal to the number of index clock cycles since the last index occurred. It can also be calculated by summing all the flux reversal values that we recorded since the previous index, adding the Sample Counter value at which the index was detected (see Sample Counter field in Index Block) and subtracting the Sample Counter value of the previous index.

Can you confirm that the new version of DTC check consistency between the Index Time and the flux reversal values between two index. Ironically my original KF Stream reader was checking this consistency but I had to remove the check because some files either produced by KF board or provided by you were not totally consistent.

This brings another question that I asked you long time ago: assuming this is the problem, what accuracy DTC expects between the two values? Are you performing the test using integer values or floating point values?

If indeed this is the problem, it is going to be challenging to convert the SCP files to perfect KFS files because SCP is a bit messy in this area. In most of the cases the time between index matches the sum of the flux transitions. But unfortunately, as the format do not provide the position of the flux in regard to the index, there can be a huge difference in case of NFA. Aufit makes some magic computations to guess the missing values based on timing provided by multiple revolutions.

Can you confirm that this is the problem so I can update my documentation, and the C# reference reader/writer I provide in open source (I should probably also provide a C/C++ version).

[IFW]

One problem was indices with 0 time before and after the signal which is not possible. There might have been something else too, but fix that and we'll see if it still fails.

[IFW]

...which is the consequence of having timer=0 in the index OOB and pointing to a non-existent or empty cell or something like that.

[DrCoolZic]

Many thanks problem solved in Index OOB the sample counter was equal to 0 as you mentioned.
Seems odd that you check for null value here as 0 in timer means transition perfectly aligned with index. Agree that the probability is low but not impossible?

[IFW]

Actually, that case is handled by the stream decoder and there are dumps like that. However, the meaning of 0 is not what you expect - you'll see why from the decoder source.
The problem is what happens at the very last index if that's a 0 value and sampling has stopped - as normally it does at that point.
We then have an index signal with an invalid cell associated and no position... or worse if the stream is flipped (e.g. c64) then you have bad index data propagating to all other index signals in various ways... (in DTC pipeline)

[DrCoolZic]

While talking about index…

As you may know SCP does not provide index to flux position which is bad especially in case of NFA. I have found a way to approximate the position but this is not perfect and Jim does not want to change the behavior.

NFA over index is discussed here http://www.atari-forum.com/viewtopic.php?f=104&t=27364

Therefore, I have a question concerning KF index position: The firmware samples several transitions before the index and therefore in case of an NFA you are correctly providing the correct size of the first transition as well as its position even if it starts before the index. However, if an NFA starts long before the index there is a non-null probability that if the “start sampling command” is issued randomly it arrives in middle of this transition. So my question is do you always checks that the start of the transition before the index is correctly sampled? This could be done by always waiting one revolution or by waiting one revolution only if you find out that the first transition was not sampled.

I am asking the question because the reader check to see if the index is pointing to a non null transition. After years of imaging FD I never had such a case so I am sure you are doing what is needed but I am curious to know how.

[IFW]

The hardware sampling starts way before the samples are actually taken. For a "real" disk this should be more than enough, but I could create one where the signal would be incomplete.
Regardless, the stream index decoder handles this - luckily simple to do mostly because the complex things happen afterwards though... see:
// edge case; the very first cell has an index signal