CPMDISK again

[stefano]

While trying (once again unsuccessfully) to port a northstar emulator on Windows, I bumped into a couple of tools for the Microbee.
They are were named "alien" because they were able to exchange files working on several disk formats, one of the two even addressed the MSDOS/Apricot, NorthStar etc.
What impressed me was the cp/m related one, it supported a big number of disk formats and worked without modifying the machine's disk configuration.
I extracted the configuration table and I'm decoding it.

https://github.com/z88dk/techdocs/blob/ ... _alien.txt

The fields I was able to identify should be enough to complete what it is easy to spot with a disk tool like IMDU, but obviously you must have a disk image on file to analyse.
Hope I'll spot something else useful, like the skew tables and the sector sizes.

It confirmed the format parameters I got already for the Knight 2000 (aussie byte) and alienc.com picks the z88dk created file correctly running on the Microbee emulator. Still it's not good enough for MAME being able to load it correctly. There seems to be a small difference between the two disk sides on the original disk images, which I couldn't totally identify and recreate.
By the way I the new disk format is now available.

[stefano]

The Don Maslin archive includes the files for the GNAT System 10 computers.
I used them, partially unsuccessfully to test this new method of merging the results gathered from the IMDU convert log and the ones listed in my file (data obtained from ALIENC.COM).
It's not enough to build a valid disk image we can provide off the shelf, but it helps in extracting files from the disk dumps.

# Gnat System 10, IMDU RAW extraction (original format: 10 sectors, 2 sides)
# The 80 tracks version is a direct extension of the 40 track)
diskdef gnat
seclen 512
heads 1
tracks 80
sectrk 20
blocksize 2048
maxdir 128
os 2.2
boottrk 1
skewtab 0,1,6,7,12,13,18,19,4,5,10,11,16,17,2,3,8,9,14,15
end

The GNAT had a 9512 APU math coprocessor, and this disk includes a couple of diagnostic programs, t9512.com and tapu.com.

[stefano]

I'm pulling in a new option, side2_sector_numbering, useful to deal with those disk formats requiring a progressive sector numbering between the two disk sides. The Kaypro 4/10 double side disk format is a perfect test case (https://forum.vcfed.org/index.php?threa ... ost-696390).

Experimenting with appmake on new cpmdisk formats also helped me in spotting a limit on the D88 format, it had a fixed sector numbering offset (+1).

[dom]

I've been wondering if we should add the capability of reading the diskdefs file from cpmtools. There should mostly be a one-to-one mapping between > the parameters in that file and our structure.

cpmtools is many times used to read or edit diskette dumps rather than creating them, most of the definitions miss relevant details needed in a diskette dump to make a valid image file.
There are several versions of cpmtools around, loosely compatible each other which brings in further confusion (e.g. the version distributed in the "MicroBEE" website is very handy for the Windows users because it directly support many containers, including IMD, but IIRC misses some configuration trick).
In example, I don't think it has a parameter taking care of the sector numbering like the one I just introduced, it is just reading/writing the sector from/to the expected position. Nor it is dealing with the stepping mode or the transfer rate speed.

The "alienc" tool includes all the required information, it was able to format and fully edit alien diskette formats, but I decoded it only partially, enough to be a good alternative to the DPB.COM tool plus some extra detail.



I usually gather the word/byte addressing mode from the diskette dump, it's easy but I'm sure there are better ways to identify the directory type.. Looking online I think cpmtools is using the same standard CP/M logic to determine it: "The operating system determines whether to use 8 or 16-bit allocation entries by looking at the number of blocks on the disk. If it's less than 256 then it uses 8-bit allocation blocks. If it's more than 256 then it uses 16-bit allocation"

I'm not totally trusting this rule, but I admit I can't remember exceptions I met while dealing with disk images. Perhaps we could make appmake smarter and guess some of those parameters which are not specified.

EDIT2:
The Einstein format is a good example of an exception: "By telling cpmtools there are 103 tracks on the disk it will calculate there are 257 blocks and use 16-bit allocation block numbers. This works fine for us reading data off a disk as there can't possibly be blocks pointing that high up onto the (non-existent) parts of the disk."


EDIT:
There are even more subtile cases, like the Aussie Byte Knight2000 format where the files I'm generating are not "perfect" and the current versions of MAME can't read it properly. The emulator loads it and the DIRectory is properly shown, but CP/M hangs while loading a program. It is not the byte/word block addressing mode, I suspect that the two disk sides have a different stepping or similar.
The MicroBee's ALIENC.COM gets the file properly and once copied the program runs as expected, I can't say whether the real hardware would hang.

[stefano]

With the new "side2_sector_numbering" option I got a valid configuration for the GNAT disk format. At the moment it is a totally lost/forgotten system, but it passes the check with ALIENC.COM on an emulated microbee

[stefano]

We now have also a 40 tracks floppy mode for the microbee.
It required different space for the boot records and a different starting position in the sector skew sequence which is odd (the skew factor is always 3). Moreover both the 40 and 80 tracks images need to keep the sectors shuffled over a sequential sector numbering!

[stefano]

Yet another weird format, the 'Amust'.
Having the boot tracks formatted differently was more common on the 8" floppy drives, but when it happened on different media formats everybody had its personal way to go.
There's a good probability that keeping 5 big sectors on the first track (both the sides) would work for data disks, but to be 100% sure it should be tested on the real hardware or on a working emulator. The cpmtools in such cases will require 2 different definitions to skip the boot tracks, if a disk container is used it will be straightforward, but a raw dump will need an offset on the first bytes.



0/0 250 kbps DD 16x256
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
D D D D D D D D D D D D D D D D
0/1 D D D D D D D D D D D DE5 DE5 DE5 DE5 DE5
1/0 250 kbps DD 5x1024
1 2 3 4 5
D D D DE5 D
1/1 DE5 DE5 DE5 DE5 DE5
2/0 D D D D D
2/1 D D D D D
3/0 D D D D D
3/1 D D D D D
4/0 D D D D D
4/1 D D D D D
5/0 D D D D D
5/1 D D D D D
(...)

[stefano]

Those CP/M disks are even more different one each other than expected !

One of the biggest obstacle to support some rare format is the sector numbering.

Here
https://forums.debian.net/viewtopic.php?t=112244
--are mentioned 5 different methods supported by 22disk.

Another less tricky but totally uncovered case is the earlier Sharp MZ models, the diskdumps boot on the emulators but the data is recorded totally with inverted bits, and currently the common tools are hardly able to manage those disk images.
I'm close to a valid output, for those ones, inverting the output data on appmake and setting the parameters like the ones on ALIENC, I can launch DIR and see the filename listed on the MZ80B (which reads also the MZ80A disks), but the program does not run yet.
I know, there's still a lot to do before finding the right sector order, also because the sector number themselves were recorded with inverted bits!

mz80.png