CP/M filesystem fails for disks with non standard track order

[boamaod]

I want to browse my DSDD "outout" disks from JUKU E5104 and it seems there is no configuration option to support either that or "outback" (in Libdsk parlance). Currently I make it work by recalculating the track positions at vfs.cc just before obtaining them:

if (sides>1)
{
    track *=2;
    if(side==0)
    {
        if (track>=tracks) { side++; track-=tracks; }
    }
    else
    {
        if (track<tracks) { side--; track++; }
        else { track-=tracks-1; }
    }
}

If one would like to convert it to a configuration option, there might be a better way to do it though. Is it a feature worth adding and how to fit it in? Number of 800kB DSDD "outout" disks for testing can be found here.

[davidgiven]

There are some image layout options in lib/layout.proto, but not this one (currently you can specify CHS and HCS).

To confirm I'm thinking about the same thing you are: does this affect the position of tracks on the disk, or just the order of the blocks in .dsk files?

[boamaod]

I tried CHS/HCS, but did not fully understand how they relate to my case. They didn't appear to directly help me with my "outout" floppies in any combination.

About the ontological question, the tracks are on JUKU and some other disks in that order and need to remain so for the system and the emulators, but in order to make sense of the filesystem, they have to be processed in the correct order by third party tools. Alternating tracks between sides as the default way of reading a floppy disk normally makes tracks appear in natural order also on disk image and this image can be directly read as the basis for CP/M filesystem. For "outout" and "outback" you have to either read the tracks in different order, convert the disk or reorder the tracks of a disk image on the fly to meaningfully process them.

My code above only intended to modify how logical blocks are presented to CP/M filesystem, not the tracks on disk. It seemed that tracks were presented in correct order if I just looped through them in case of CHS (and not HCS), but getCpmBlock at cpmfs.cc seemed to mix up the sectors of the block with tracks from wrong side of the disk. I tried to modify the behaviour of CHS/HCS part of the getTrackOrdering in layout.cc, but this didn't seem to help and so I ended up just changing getLogicalSector.

[davidgiven]

libdsk's outout is HCS order (outermost ordering by head, innermost by sector). But there isn't a setting for libdsk's outback.

The way the mapping works is that LayoutProto defines how to convert between disk order and filesystem order. There is also a setting filesystem_sector_order ImageReaderProto/ImageWriterProto which is supposed to set whether .img files are written in disk order (the default) or in filesystem order. However, it's a bit broken:

• the tracks image files are always written in filesystem order.
• the sectors within each track are only written in filesystem order if filesystem_sector_order is set.

This could all use a bit of an overhaul, TBH.

I think for your case, there needs to be a new track layout enumeration for outback disks. But there also needs to be a setting to make the tracks in image files be written in disk order, which is I think how your images are laid out, and why it's not really working.

[davidgiven]

Okay, I think I've overhauled everything and added support for the mode you need. If you fetch this branch: https://github.com/davidgiven/fluxengine/tree/layout ...then you should be able to set layout.filesystem_track_order=HCS_RH1 and layout.image_track_order=HCS and it might do what you want.

Do you have a config for the Juku E5104? It's be good to add one.

[davidgiven]

Also, if you happen to have the real hardware and a flux reader of some kind, I'd love to have a flux image of a real disk. It'll need to be something which doesn't have any data on it which requires a license (for distribution reasons). That will let me add it to my test suite.

[boamaod]

Added my version of Juku E5104 floppy formats which seem to work fine with the new filesystem_track_order=HCS option. You are welcome to edit the descriptions/links as you see fit. I will ask around about a flux image of a real disk without copyrighted content... Do we consider CP/M 2.2 itself to be in the public domain or can it contain only explicitly CC zeroed content or my own personal creations?

[davidgiven]

Thanks for the PR --- I've merged it into my branch. I will note that you say:

The disks have
a sector skew factor 2 and tracks start from outside of the
diskette for both sides...

That's actually the normal way tracks are laid out, both physically and logically, so I'd like to double check that's what you meant?

Also, which platform uses the outback logic order?

[boamaod]

Thanks, there is something missing indeed. Maybe so:

The disks have a sector skew factor 2 and tracks are written on one side of the floppy until it is full and then continued on the other side, starting from the outside of the disk again. This differs from the most common alternating sides method and somewhat complicates reading CP/M filesystem content with common tools.

I have no experience with outback method, but there is a reference to 144FEAT CP/M disks here. Grepping libdsk configs circulating on the Web should also give some results.