Managing CPC files on other systems: split problems to handle one at a time ?

[cpcitor]

I do a bit of cross-development. Testing code requires to handle it in formats that allow transfer to emulators (for test) and real CPC (the real(TM) thing).

After encountering bugs on iDSK, I'm considering to use the version of cpcXfs host by Pulkomandy on Source Checkout - cpcsdk - Collection of tools for helping cross-development for .

As a last resort I might write bug-free tools, but they would be different.

Desiderata

From a bunch of files on any build platform with metadata for AMSDOS header, create a valid floppy or disk image.
From a valid disk image or data from floppy, extract files and metadata stored in AMSDOS headers.

I'm only interested in programs that would work on any CPC and are easy to transfer, so that means no non-portable hack (well, using two more tracks maybe but that should be it).
This usage pattern does not need to handle special hackish disk formats.

How to think to write bug-free tools.

I'm faithful to methods that allow to create programs that are bug-free, with a source code clear to read and maintain.
Also the Unix philosophy says "do simple tools that do just one thing and do it well". That translated in the modern world in dedicated command-line programs and libraries (scriptable !), then optional graphical front-ends for some one-time needs on some platforms.

Separation of concerns simplifies when applied wisely.

Separating problems allows to write simpler programs. Yet I'm wondering if even separating the AMSDOS filesystem issues from the DSK file format issues would make sense.

Separating AMSDOS filesystem logic from DSK file format logic ?

Typically, the user (or user scripts or toolchain) would create a directory with a bunch of files native to the build machine (e.g. foo.bin), and companion files (e.g. foo.bin.amsdosheader, a simple text file that would tell in the form of one "key=value" per line what values to put in the amsdos header).

e.g.

Code Select Expand

mode=binary
loadaddress=&1000
runaddress=&1080


A first program "dir2amsdos" would read that directory and generate a valid AMSDOS filesystem that would be exactly 180kbytes in size (the content of the sectors, no metadata at all). It may even output the data on standard output, not even to a file.

A second program "amsdos2dsk" would encapsulate that AMSDOS filesystem into a valid DSK image. Again it could get data via standard input and output via standard output (besides plain files).

Writing to a real floppy could be handled by yet another program e.g. dsk2floppy, but that's already done by third parties, isn't it ?

Symetric tools would be written.

floppy2dsk functionality is already written by third parties, isn't it ?
dsk2amsdos extracts from a DSK the sector data, throwing away the metadata and complaning if it's not standard
amsdos2dir from that data write all files in a directory with amsdos headers turned into readable text files.

Benefits

Now it becomes very easy to populate a directory by any means and get a DSK in one step.
Now it becomes very easy to see what's the content of existing images and files, provided they are standard.

The CP/M reserved tracks might be considered a special file "cpmreservedtracks.bin" in the first directory read by dir2amsdos or written by amsdos2dir.

amddos2dir would have no sector number to detect system/data/IBM/vendor formats  so it would have to probe but it should be okay.

Limitations

Obviously this would not work with special layouts and sector numbers.
That would not fit all uses of iDSK, like extracting files from strange layouts.


But it would probably make the programs simpler and bug-free.

What do you think ?