Page 1 of 1

Test of HxCFloppyEmulator program

Posted: Mon Nov 17, 2014 1:44 pm
by DrCoolZic
Here I would like to give feedback and questions about usage of HxCFloppyEmulator program

Test with Time of lore 5 rev sony viewtopic.php?f=102&t=26976&hilit=time+of+lore&start=100#p261722
- on official release 2.0.26.0 program crash
- on v2.0.30.0 built by me today it takes 7 minutes and 6 second on Core i7 @3.4GHz ??? Is this normal?

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.

Re: Test of HxCFloppyEmulator program

Posted: Mon Nov 17, 2014 2:45 pm
by DrCoolZic
Does HxCFloppyEmulator loads KF .ctr files ?
does not seems to work?
any plan?

Re: Test of HxCFloppyEmulator program

Posted: Mon Nov 17, 2014 2:47 pm
by DrCoolZic
Same question for IPF files?
does not seems to work?

Re: Test of HxCFloppyEmulator program

Posted: Mon Nov 17, 2014 4:24 pm
by AdamK
I think, HxC forum is a better place for this questions.

Re: Test of HxCFloppyEmulator program

Posted: Tue Nov 18, 2014 7:32 am
by Jeff_HxC2001
DrCoolZic wrote:Does HxCFloppyEmulator loads KF .ctr files ?
does not seems to work?
any plan?


DrCoolZic wrote:Same question for IPF files?
does not seems to work?


Yes it does but you have to copy the caps library into the HxC software folder. I can't put it into the HxC software package for license issues reasons since years.

Re: Test of HxCFloppyEmulator program

Posted: Tue Nov 18, 2014 8:19 am
by Jeff_HxC2001
DrCoolZic wrote:Here I would like to give feedback and questions about usage of HxCFloppyEmulator program

Test with Time of lore 5 rev sony viewtopic.php?f=102&t=26976&hilit=time+of+lore&start=100#p261722
- on official release 2.0.26.0 program crash


Yes i know and the issue is corrected on the SVN server.

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 :wink: )

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. :D

Re: Test of HxCFloppyEmulator program

Posted: Tue Nov 18, 2014 1:23 pm
by DrCoolZic
Good IPF and CTR works great with IPFLIB 5.1
Thanks

Pretty nice

Re: Test of HxCFloppyEmulator program

Posted: Wed Nov 19, 2014 7:02 am
by Jeff_HxC2001
"Full HD" export version :

timeoflore_rev5_sony_acdc_scp_afi.png


:D

Re: Test of HxCFloppyEmulator program

Posted: Wed Nov 19, 2014 3:32 pm
by DrCoolZic
How do you do a full HD export?

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 clockwise
IN 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 :)

Re: Test of HxCFloppyEmulator program

Posted: Wed Nov 19, 2014 10:43 pm
by JimDrew
That's a neat display, Jeff!
As for the direction - when the disk is rotating counter-clockwise, are those tracks skewed forwards or backwards when stepping fom track 0 to track 79?

Re: Test of HxCFloppyEmulator program

Posted: Sun Nov 23, 2014 8:51 am
by Jeff_HxC2001
DrCoolZic wrote:How do you do a full HD export?

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

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



I use a top view of the floppy disk, and at this position the floppy is not rotating counterclockwise. This is a clockwise wise rotation.

To illustrate this, here is the disk rotating :

http://www.youtube.com/watch?v=2__DIiNsWvk

Re: Test of HxCFloppyEmulator program

Posted: Sun Nov 23, 2014 10:49 am
by Jeff_HxC2001
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 ;).

Re: Test of HxCFloppyEmulator program

Posted: Sun Nov 23, 2014 11:01 am
by Jeff_HxC2001
DrCoolZic wrote:How do you do a full HD export?


Just export the loaded image to the BMP format :

The latest version :
http://hxc2001.com/download/floppy_driv ... 2_beta.zip

Re: Test of HxCFloppyEmulator program

Posted: Sun Nov 23, 2014 11:04 am
by Jeff_HxC2001
JimDrew wrote:That's a neat display, Jeff!
As for the direction - when the disk is rotating counter-clockwise, are those tracks skewed forwards or backwards when stepping fom track 0 to track 79?


this is not a counter clockwise rotation but a clockwise disk rotation :

More than words :
http://www.youtube.com/watch?v=2__DIiNsWvk

Re: Test of HxCFloppyEmulator program

Posted: Sun Nov 23, 2014 2:59 pm
by DrCoolZic
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

Re: Test of HxCFloppyEmulator program

Posted: Sun Nov 23, 2014 7:08 pm
by Hippy Dave
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.

Re: Test of HxCFloppyEmulator program

Posted: Sun Nov 23, 2014 10:38 pm
by Jeff_HxC2001
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 :wink:.

Re: Test of HxCFloppyEmulator program

Posted: Thu Aug 13, 2015 7:42 am
by DrCoolZic
Request :roll:
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.

Re: Test of HxCFloppyEmulator program

Posted: Thu Aug 13, 2015 7:50 am
by DrCoolZic
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?

Re: Test of HxCFloppyEmulator program

Posted: Thu Aug 13, 2015 7:52 am
by DrCoolZic
Converting from SCP to KF RAW
reads for a loooong time and says writing then stops in middle of operation (on the letter t!)?

Re: Test of HxCFloppyEmulator program

Posted: Thu Aug 13, 2015 8:13 am
by DrCoolZic
Closing and reopening batch converter window does not reset status.
So seems impossible to restart without leaving program

Re: Test of HxCFloppyEmulator program

Posted: Thu Aug 13, 2015 8:19 am
by DrCoolZic
When converting to KF raw file would it be possible to create a directory for each file converted?
Currently all files converted end up in one directory and Kryoflux GUI cannot handle this situation :(

Re: Test of HxCFloppyEmulator program

Posted: Thu Aug 13, 2015 8:25 am
by DrCoolZic
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?

Forget this one it seems related to the bug described below that blocks the program ....
Test case http://arcade.ym2149.com/files/scpro/un ... ist_SCP.7z
second disk

Re: Test of HxCFloppyEmulator program

Posted: Thu Aug 13, 2015 8:28 am
by DrCoolZic
Actually the bug of blocking the program in middle of writing seems to happen on several test cases.
Just fails also on amc_d1_epson340_rev5.scp