Question on GUI:You have a very nice track analyzer GUI. What is nice is that in track or disk view the status windows display the content of the sector. However on Windows 8 I do not succeed in "freezing" the display on a specific sector so I can use the scroll bar to look at content. I have tried to right click without success. In track mode if I go out of the sector quickly sometimes it still display the sector, but in disk mode no chance to freeze on what you want to look at.

DrCoolZic wrote:- on v2.0.30.0 built by me today it takes 7 minutes and 6 second on Core i7 @3.4GHz ??? Is this normal?

(it actual use only one core of the i7 )

This may happen on with some images with lots of semi unformatted parts : the software is looking for some track coherency from the stream between all revolutions.The problem here is the unused side 1.

Image3.png

Most parts of this side are unformatted, but not all...

Some analysis speed improvement are planned but anyway just convert/export the image to the AFI format and you will save disk space and time

DrCoolZic wrote:Question on GUI:You have a very nice track analyzer GUI. What is nice is that in track or disk view the status windows display the content of the sector. However on Windows 8 I do not succeed in "freezing" the display on a specific sector so I can use the scroll bar to look at content. I have tried to right click without success. In track mode if I go out of the sector quickly sometimes it still display the sector, but in disk mode no chance to freeze on what you want to look at.

yes i know. here again there still some room of improvement here for the next version.

You do not have the required permissions to view the files attached to this post.

A quick question I have noticed that Aufit display the layout using the "inverse" rotation for the disk.

timeoflore-layout.PNG

I believe a floppy disk is rotating counterclockwise? Therefore the flux transitions are layout clockwiseIN this case Aufit seems to be right ?what do you think?

Another question: seems like you use the color red to indicate unformated?or is it "out of range" transitions?I can see on side one some red "dots". They seems to be located in the "write splice" area. With Aufit I can see by zooming that there a are only few transitions out of band. Does that correspond to these reds dots.

The subject of unformated areas and fuzzy bits area is not easy ... Perso I am using Shannon entropy function to detect unformated. It has the advantage to be fast but does not work all time?For fuzzy bit it is easy inside a sector but for a track it is more tricky as they could be located anywhere. However to be useful they must be located after at least one sync mark.If I remember correctly one of our discussion for all these you divide the track in blocks and try to match them from one rev to the next. Problem is that these blocks must be shifted from one rev to the next for many reason.So are you using some sort of sliding of blocks until they match? Again if blocks are align with sync mark it is easy otherwise you will find fuzzy bits in the "sector splice area" (where WG is turned on/off for writing sector). This only happen if the disk has been written on an Atari as this does not exist on mastering machine.So another question is HxC capable of finding if an image is from an original made on a mastering machine or from a copy on an Atari?The CTA program from SPS people is suppose to be able to detect if you have an original or a copy? I have thought about that for quite some times and the only idea that come to my mind is that it must be by detecting the presence of "sector write splice" but probably I should ask them

You do not have the required permissions to view the files attached to this post.

DrCoolZic wrote:Another question: seems like you use the color red to indicate unformated?or is it "out of range" transitions?I can see on side one some red "dots". They seems to be located in the "write splice" area. With Aufit I can see by zooming that there a are only few transitions out of band. Does that correspond to these reds dots.

Yes exactly. This can be out of band or fuzzy bits/unformated bits.

DrCoolZic wrote:The subject of unformated areas and fuzzy bits area is not easy ... Perso I am using Shannon entropy function to detect unformated. It has the advantage to be fast but does not work all time?For fuzzy bit it is easy inside a sector but for a track it is more tricky as they could be located anywhere. However to be useful they must be located after at least one sync mark.If I remember correctly one of our discussion for all these you divide the track in blocks and try to match them from one rev to the next. Problem is that these blocks must be shifted from one rev to the next for many reason.So are you using some sort of sliding of blocks until they match?

Exactly and this is done for each revolution.

DrCoolZic wrote:Again if blocks are align with sync mark it is easy otherwise you will find fuzzy bits in the "sector splice area" (where WG is turned on/off for writing sector). This only happen if the disk has been written on an Atari as this does not exist on mastering machine.

I don't make any assumption about the track format at this stage of the analysis. So the block sliding and the fuzzy bits detection is done only on a bunch of pulses. There is no sector or sync mark meaning here. The sectors detection & decoding are done at the very last part of the analysis.

DrCoolZic wrote:So another question is HxC capable of finding if an image is from an original made on a mastering machine or from a copy on an Atari?The CTA program from SPS people is suppose to be able to detect if you have an original or a copy? I have thought about that for quite some times and the only idea that come to my mind is that it must be by detecting the presence of "sector write splice" but probably I should ask them

Good question. Is there a 100% reliable method to detect a copy ?Yes write splices may be an good indication, but i got some interesting cases with disks coming from Japan (for PC88). Master disks and protections was make with normal machines, and then all the original disks have the write splices.So this not a 100% reliable indication for me.You can also look for a bitrate disconnuity between sector header and sector data, but again they may be also present on the master disk.

One good method is maybe to have a look directly at the physical/magnetic/analog level of the track to check the write splices are true (done by a normal machine - in this is case the disk is a copy)or a copy (done by a Trace machine - in this is case the disk is original). The track alignement may be insteresting too.a Magview may help for this kind of work.Or an HD floppy disk drive modified to capture the analog signals from the heads (digital part removed) with an microstepping motor to "see" what is going on between the tracks.BTW working directly on the analog signal make the fuzzy bits analysis easier to detect and understand. And no need anymore to make multiple revolutions to detect them .

Thanks for all these technical information.I am making a major rewrite of Aufit. Including a big change in data structure to be able to read IPF/CTR files and others....So it is time to take extra requirements ....

For the rotation you seems to be right I have found this www.moria.de/~michael/floppy/floppy.ps and others that indicates that the FD is rotating clockwise.This is strange as hard disk are rotating counter clockwise

Software that displays an image should show what one would see if they were to look at the actual object. Thus, the disk should be shown from the side that the read/write had contacts the media. The software should also show the direction the media is moving. Note that the top of a spinning disk spins counter to the bottom as viewed from an external frame of reference. Other pictorial representations should be unambiguous to avoid confusion.

Hippy Dave wrote:Software that displays an image should show what one would see if they were to look at the actual object. Thus, the disk should be shown from the side that the read/write had contacts the media. The software should also show the direction the media is moving. Note that the top of a spinning disk spins counter to the bottom as viewed from an external frame of reference. Other pictorial representations should be unambiguous to avoid confusion.

This is exactly what the HxC Floppy software shows you. And the arrows on the pictures indicate the disk rotation (which is the real one).About the top/bottom counter rotation : yes, but this must be an option since you may miss some copy protection if you only do a top/bottom counter/mirror representation .

Request Would be nice in HxCFloppyEmulator batch mode to be able to filter input on a specific type. Seems like currently the program converts all files that it understand in the source directory. Would be nice to have a filter with options: ALL (for all types like now) or for a specific type e.g. SCP so we only convert files of this type in the source directory. (Je ne fais que demander!)

Reason is that as most people I have a image source tree that already contains a lot of different type and I just want to batch convert one type to another type.

Hum strange behavior?In batch conversion I specify a source directory that contains 3 directories (for three games) each of them contains directories with actual disk images (several on a multi disk game).Seems like HxCFloppyEmulator only reads the first directory and stops?

DrCoolZic wrote:Hum strange behavior?In batch conversion I specify a source directory that contains 3 directories (for three games) each of them contains directories with actual disk images (several on a multi disk game).Seems like HxCFloppyEmulator only reads the first directory and stops?