Reading FM formats don't work

All questions about how to use KryoFlux go here.
User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Reading FM formats don't work

Post by IFW »

No problem.
One thing that might catch you out: you have to specify the format parameters before the format specificatio (-i) command, anything specified after -i belongs to the next format requested.

edit: this is only true for format local commands of course. -i always resets all format local parameters to their default value.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Reading FM formats don't work

Post by IFW »

If you could submit the stream files for entire disks (two should be enough) written in DiskSpare it could get added eventually.

firefly
Posts: 14
Joined: Sun Nov 07, 2010 2:32 am

Re: Reading FM formats don't work

Post by firefly »

I think the point of putting the parameters you need to specify before the selected -i command needs to be made more clearer in the PDF instructions perhaps with a little diagram as I think this will catch many people out.

When I repeated the command but this time putting my options before the selected -i command they worked as expected.

Sector dumps can be very vanilla (plain) as emulators will assume the format written a certain way, I was wondering if a new sector containment format could be designed or a descriptive xml file could be provided with more details of the format i.e tracks 0 sectors, sectors size, gap, bad block etc.

I have an Atari ST utils disk which has an initial 9 sector track and all the rest are 10 sectors.

Ideally emulators could support the draft or ipf format but there will be many that will not.

I have uploaded a big rar file into /firefly/2010-11-14/ which contains full dumps of 2 diskspare disk plus some other original disks. You can preserve these if they are of interest.

User avatar
mr.vince
Posts: 2130
Joined: Tue Oct 05, 2010 5:48 pm

Re: Reading FM formats don't work

Post by mr.vince »

firefly wrote: I have an Atari ST utils disk which has an initial 9 sector track and all the rest are 10 sectors.
Hm, guess this won't work. Sector dumps usually have a fixed sector size (or a pre-programmed "sequence"; like D64)...

As for the manual... It think we've spent a complete page on image local and global parameters.

firefly
Posts: 14
Joined: Sun Nov 07, 2010 2:32 am

Re: Reading FM formats don't work

Post by firefly »

mr.vince wrote: As for the manual... It think we've spent a complete page on image local and global parameters.
Yes I noticed but its not very clear.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Reading FM formats don't work

Post by IFW »

Good news then, thanks for both the report that it's working now, and the DiskSpare dumps :)

For a later revision of DTC I might consider a more logical order for the parameters (ie start with -i and valid until next -i or end of line), but there are plenty of things more important and DTC was always considered to be a tool that is likely to be used together with a front-end application, and a front-end works always according to specifications anyway.

There was a very convincing reason why the parameters have to be set the way it is done now though... just can't remember what it was... been a while :)

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Reading FM formats don't work

Post by IFW »

As for the Atari Disk with 9 sector then 10 sector; this would work as long as the program does not explicitly check that track 0 is really just 9 sectors and the rest is 10.

The whole disk will be dumped as if it was 10 sectors all the way.

When creating a sector dump the host software first dumps the entire disk, then checks the decoded data for each track to find the smallest possible set of track count, side count and sector count that would contain all the valid sectors of the data disk without data loss.
The selected parameters will be constrained though by either the format constrains (e.g. minimum 80 tracks expected; both sides must be present, etc) or manual setting of parameters set through the dump command.

Sector dump formats are also set to automatically detect additional tracks as well, ie by default they scan the whole disk, hence you don't have to know whether they use the standard number of tracks or more; again if the extra tracks don't contain data they won't be added; if they do, all of them will be correctly added according to the format specification and within the dumping constraints.

You can override all parts of this automatic behaviour using the -s, -e, -g, -z, -n parameters - the resulting sector dump file will still have the correct disk offsets for tracks considering the parameters, e.g. starting the disk dumping from track 10 will fill the preceeding tracks with the default filler value associated with the format.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Reading FM formats don't work

Post by IFW »

As for creating a flexible sector dump format - that is a "real" format containing disk geometry etc. that would be a very good and indeed useful thing due to the obvious problems with no geometry data at all in these dumps.
The only problem is, that it is just as likely to be added to tools, emulators etc as any other format... but we can try.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Reading FM formats don't work

Post by IFW »

The next beta supports sector dumps from DiskSpare disks - it will be available soon.

r09
Posts: 28
Joined: Sun Nov 14, 2010 1:34 pm

Re: Reading FM formats don't work

Post by r09 »

IFW wrote:As for creating a flexible sector dump format - that is a "real" format containing disk geometry etc. that would be a very good and indeed useful thing due to the obvious problems with no geometry data at all in these dumps.
The only problem is, that it is just as likely to be added to tools, emulators etc as any other format... but we can try.
Correct me if I'm wrong, but I think the Extended DSK format (used in most Amstrad CPC and Spectrum +3 emulators) does exactly that, and it's open and well documented. With it you could at least have a flexible sector dump format which is already a de facto standard for some systems, and that isn't a bad thing at all. ;)

Post Reply