AUFIT Program

[Maartau]

New release of Aufit v1.2 August 12, 2015

Jean : will you release a stand alone version for this release, or maybe in the next versions ?

[DrCoolZic]

goto http://info-coach.fr/atari/software/pc- ... p#download
and click Aufit portable link it contains => Aufit + BatchAufit + dll + doc

[Maartau]

[DrCoolZic]

PS I have tested reading DM with HxC floppy emulator and the content of sector 7 seems to be correctly decoded. However the .stx file generated is incorrect (seems like HxC does not handle fuzzy bytes in STX?).

Y a qu'a demander

Here is the latest version with the STX fuzzy bytes export support :

http://hxc2001.com/download/floppy_driv ... t_beta.zip

The STX created from the Dungeon Master SCP dump work perfectly with Steem.

Excellent I just tested and works perfectly.

However I have few questions:

• The number of fuzzy bytes detected by HxCFloppyEmulator 2.1.1.0 on DM/CSB is around 176. This seems a very high number. Aufit 1.1 was detecting fuzzy bytes by just comparing two revolutions and the number was around 30-40. Gothmog pointed out that Pasti imager was usually generating around 70-90 fuzzy bytes in the mask. So new version 1.2 of Aufit now combines all fuzzy bytes by comparing one revolution with ALL other revolutions and indeed the number is now around 70-90.
  Can you explain why you find such a high number of fuzzy bytes? This is not really a problem just a question.
• The .stx file generated by HxCFloppyEmulator does not contains track data and this results in a .stx file with a small size of about 415KB. In the case of DM/CSB this is correct and actually perfect.
  The question is the following: knowing when to generate track data (used by read track) is extremely difficult in some cases. For that reason the latest versions of Pasti imager ALWAYS generates track data (to be on the safe side). Only the Ijor personal version of the Pasti imager (using the Discovery Cartridge hardware) had the capability to generate .stx without track data. In released Aufit the track data are also always generated. Gothmog just tested Aufit v1.3 with the capability to manually indicate not to generate track data. Should be able to do that automatically on a track basis when "master analysis" will be implemented in Aufit.
  In HxCFloppyEmulator when/how do you decide not to generate track data?
• related question: stx format support an optimization of not writing sector data when already present in the track data. Aufit support this capability which is a pain to implement but allows to generate smaller file. Does HxCFloppyEmulator support it? Again not a problem just a question

By the way HxCFloppyEmulator DPLL seems to be be doing quite a good job, apparently better than Aufit in one marginal test case

[DrCoolZic]

Well actually it seems that HxCFloppyEmulator never(?) write track data???

I just tested on dragonflight that hides data into gap. HxCFloppyEmulator does not generates track data and when trying to use the generated stx file you get a Pasti Warning "read track attempted without track info" and if you ignore program loop forever

So I would suggest that you default to always write track data

[Jeff_HxC2001]

• The number of fuzzy bytes detected by HxCFloppyEmulator 2.1.1.0 on DM/CSB is around 176. This seems a very high number. Aufit 1.1 was detecting fuzzy bytes by just comparing two revolutions and the number was around 30-40. Gothmog pointed out that Pasti imager was usually generating around 70-90 fuzzy bytes in the mask. So new version 1.2 of Aufit now combines all fuzzy bytes by comparing one revolution with ALL other revolutions and indeed the number is now around 70-90.
  Can you explain why you find such a high number of fuzzy bytes? This is not really a problem just a question.

I don't know why there are such differences. What i know is that i got the exactly the same fuzzy byte mask of a DM STX generated with the Pasti imager in 2007.

[*]The .stx file generated by HxCFloppyEmulator does not contains track data and this results in a .stx file with a small size of about 415KB. In the case of DM/CSB this is correct and actually perfect.
The question is the following: knowing when to generate track data (used by read track) is extremely difficult in some cases. For that reason the latest versions of Pasti imager ALWAYS generates track data (to be on the safe side). Only the Ijor personal version of the Pasti imager (using the Discovery Cartridge hardware) had the capability to generate .stx without track data. In released Aufit the track data are also always generated. Gothmog just tested Aufit v1.3 with the capability to manually indicate not to generate track data. Should be able to do that automatically on a track basis when "master analysis" will be implemented in Aufit.
In HxCFloppyEmulator when/how do you decide not to generate track data?

[*]related question: stx format support an optimization of not writing sector data when already present in the track data. Aufit support this capability which is a pain to implement but allows to generate smaller file. Does HxCFloppyEmulator support it? Again not a problem just a question[/list]

The STX track write is not done yet. I will add this soon.

By the way HxCFloppyEmulator DPLL seems to be be doing quite a good job, apparently better than Aufit in one marginal test case

I have no choice, the DPLL / decoding stages must be as good as possible.

[DrCoolZic]

New release v1.3 of Aufit and BatchAufit -- October 21, 2015

Main features are: KF RAW / CTR writer, Database improvement, new options, bugs fix

Detail:
• Major change in the Database -- Typical size of database after Read/Process image is now down to 650 MB instead of 900 MB
• While reading/processing file the button matrix is now disabled to avoid problems
• Fix added tool tips to reflect changes
• In flux transition graph when flux limit is checked, a flux transition bigger than 10000 µs is displayed as big black dots at the border of graph. This indicates the presence of flux transitions beyond the graph limit.
• Color usage in transition chart has changed:
Normal mode: normal=blue, red=violation, green=border
Unformatted in black
Odd/even mode: blue/red
• Added Odd/Even checkbox for flux transition chart
• Added Average checkbox for Clock chart
• Hack in DPLL to correctly read DM fuzzy bits
• Added call to DTC.EXE (if present in Aufit executable directory) to automatically write .ctr file from generated KF Raw files.
• Added KF stream Raw file writer
• Short/long sectors are now 4% above/below normal instead of 3%
• Fixed Alternate Realty bug (JMD & DF checking + limit OBB line + stx)
• Added checkbox that allow to not generate Track Data in stx file
• Fixed bug of ISS sometimes incorrectly detected.

If you have installed with setup just click the update button this should download and install new version.
Otherwise for portable version visit http://info-coach.fr/atari/software/pc- ... p#download

If you want to convert scp file to RAW/CTR files you need to place the dtc.exe file in the Aufit directory (otherwise ctr will not be produced). Sorry but I do not think I am allowed to distrubute dtc software so go to Kryoflux site to get latest.
Read the documentation

[Maartau]

Hi,

Thanks for the good work : any standalone version planned for the v1.3 + batch ?

[DrCoolZic]

As indicated it is here

Otherwise for portable version visit http://info-coach.fr/atari/software/pc- ... p#download

[Maartau]

Hi,

Thanks for the good work : any standalone version planned for the v1.3 + batch ?

As indicated it is here
Otherwise for portable version visit http://info-coach.fr/atari/software/pc- ... p#download

Latest available portable version is 1.2 for the moment .

[Avanze]

Just change the download link.

http://info-coach.fr/atari/software/pc- ... it-1.3.rar

[DrCoolZic]

oops
Fixed
Thanks

[Maartau]

Perfect, thanks for all .

[kodak80]

Thanks DrCoolZic. A really useful tool and it is getting even better.

[Mikerochip]

Hi!

This is a super tool, thanks!
I've noticed, if I launch it from the command line, I can drag and drop images on to the program to launch them, but, if I launch the exe by hand, I can.
Sometimes dropping an image on it causes it to crash, too.
(Just FYI, I don't use it this way, I just noticed this. I launch it from a tiny front end, using GreaseWeazle)

And the reason for my post:

The STX/ST/KF disk image type drop down is at the other side of the screen from the write button.
Can it be moved closer, or, maybe give us different write buttons for each type?
And maybe default in a file name? (Maybe, name of the .scp file plus .st or .stx, etc? Only for those file types. It defaults to a folder, if you pick the KF export type)

At the moment, every time I want to change to ST/STX, I have to go all the way over to the left, drop down, pick stx, all the way to the right, click write, back to the left again, pick st, back to the right again, click write.
And since the drop down is pretty small, I sometimes miss it with the mouse and have to click a second time.

All in all, not a big problem at all! Just some small things.

I know there is BatchAufit, but, I need to open each image, check for bad sectors etc. before I write them, so, it's not useful in this instance.

[TheNameOfTheGame]

Thanks for the link above. I downloaded 1.3 but it is crashing on Windows 7. Does this program have any requirement like .NET or something that maybe I am missing?

[Mr Nours]

Hello,

Is there anyone who manages to run Aufit under Linux using Wine?

No luck here...

olivier@ordiman:~/atari_floppy$ wine Aufit.exe
002d:err:ole:CoGetContextToken apartment not initialised
0031:err:module:import_dll Library MSVCR100_CLR0400.dll (which is needed by L"C:\\windows\\Microsoft.NET\\Framework64\\v4.0.30319\\WPF\\WPFFontCache_v0400.exe") not found
0031:err:module:LdrInitializeThunk Importing dlls for L"C:\\windows\\Microsoft.NET\\Framework64\\v4.0.30319\\WPF\\WPFFontCache_v0400.exe" failed, status c0000135
0014:err:service:process_send_command service protocol error - failed to write pipe!

[DaveTC]

I've run it under wine. I can't remember exactly what I did to get it running but I used "winetricks dotnet45" to install the required .Net framework. I can't remember what else I had to use winetricks to install but I got it all working eventually over a remote X session.

[sarnau]

Is there a chance that you might open-source AUFit at some point? I'd love to add more file formats and maybe even port it to macOS.

[DrCoolZic]

Yes I have been thinking about that. I wanted to do some cleanup before but to be honest I have not looked at the code for years
My current version has several new features I was working on but never finished. The idea was to produce a perfect image from the Kryoflux or SCP image - something similar to what SPS people are doing to produce IPF files ...
So yes I should make it open source but you will have to wait because currently I do not have spare time.

[Brume]

The idea was to produce a perfect image from the Kryoflux or SCP image - something similar to what SPS people are doing to produce IPF files ...

Hi DrCoolZic,

Interesting. Does it mean you worked on a new format of file? Was it supported by emulators only or did you plan to make it a "rewritable on disk" format, too?

[DrCoolZic]

No new format you just need to correct the approximate information to a perfect information then write it.
Lets take the simple example of a track containing a Rob Northen protection. For this track we know that sector 6 uses a bit width variation of 5%. So if we recognize such a track we can correct the actual timing to a "perfect timing".
From the HW point of view there is not so many "protections" so it should be possible to reconstruct a perfect image for the recognized protections. This is what is used in CTA program from SPS to rebuild master disk from approximate image.
Once you a have a perfect master you can rewrite in in any format that support protections for example STX.
This would be particularly useful if you want to rewrite on a floppy as currently error accumulates ...
Sorry may be not clear but I did not look at Atari stuffs for long time ...

[ijor]

Hi Jean,

Are you aware that some time ago we found a new type of protection? Actually a completely different category than any other protection:

viewtopic.php?p=330131#p330131

[DrCoolZic]

Hi Ijor,

Yes I was aware of this protection but not doing any work on Atari for long time, I have forgotten lot of things
Glad to hear from you. It seems you still very active on Atari

Cheers