So I reverse engineered a primitive filesystem...

[zl2wrw]

A friend had an old CRT display chart plotter on their boat, which stored all its waypoints (the good fishing spots!) on a 720kB 3.5" floppy disc. As tends to happen with electronics in a marine environment, the chart plotter died, so it was replaced with a new one. Even though there is PC software to read the waypoint files, the disc from the plotter could not be read with a PC and of course there was no backup copy of the waypoints

I ended up magnetic flux imaging the disc with picosonic's bbc-fdc github project (turn a Raspberry pi into a flux imager).
This revealed that the floppy was 80 tracks, 9 sectors per track, double sided and formatted with common ISO-MFM sectors (just like a common MSDOS FAT12 720kb floppy disc). However, the filesystem is a bit different from and seems quite primitive compared to FAT12, which probably has quite a bit to do with why the disc can't be read with a PC - I searched around the 'net trying to figure out what the filesystem is (I though that it might have been CP/M but this does not appear to be the case). So, I managed to reverse engineer enough of the file system to piece the files back together...

Attached is a screenshot of the first sector of the disc, it contains the directory listing for the disk.
The first sector starts with the descriptor "CDOSDATADISK" followed by (hex) 9D 05 01 00 (Google was no help).
Each file entry is 16 bytes long and the first file entry appears to start at 0x0010 (next file is at 0x0020, 0x0030 and so on...)
0x0012 (or file_entry+0x02) is the first sector of the file contents (counting from first physical sector on disc is sector 0, so 0x03 starts at the fourth physical sector)
0x001c (file_entry+0x0c) is the number of sectors that the file occupies (counting from 1 ie 0x03 means 3x sectors occupied)
8-character file name is stored from 0x0014 to 0x001b (file_entry+0x04 to file_entry+0x0b)
there does not appear to be provision for a file name extension or for fragmented files.
I have not figured out what the value in the byte at 0x0010 (file_entry+0x00) is for.
Also, there does not appear to be any record of file length, other than the number of sectors used for each file.

The second sector of the disc is zero-filled. I'm guessing that this is a continuation of the directory in the first sector.

The third sector of the disc looks like it contains a "bit field" of which sectors are occupied. It starts with (hex) "FF FF FF FF 07 00 00..." and the rest of the sector is zero-filled - this is 35 "1" bits, which matches the sectors that have been allocated on this disc. I'd say that this is a primitive FAT - it only marks sectors as occupied, without the linked-list cluster chaining and bad sector marking functionality of FAT12.

Subsequent sectors contain the contents of the files, which won't be repeated here.
The good news is that there wasn't much data on this disc, I succeeded in recovering all the files, and my friend is very very happy


If you've seen this filesystem before, I am very curious and I'd really like to know what it is?

[Ed.Kloonk]

Stabbing in the dark...

https://en.wikipedia.org/wiki/Multiuser_DOS#CCI-CDOS

I wondered if CDOS is the header and DATADISK is the volume label.

 

[amyk]

http://www.diamondspirit.net/adunk/software/USERIMG_BIN.html

[zl2wrw]

http://www.diamondspirit.net/adunk/software/USERIMG_BIN.html

Yep - that looks like it!
It explains the extra numbers in the directory entry that I couldn't figure out, and the slight differences between disc layouts can probably be attributed to different revisions of the software / different implementations.

Thanks

[guenthert]

[..]
I ended up magnetic flux imaging the disc with picosonic's bbc-fdc github project (turn a Raspberry pi into a flux imager).

     Uh, why no link?  It's https://github.com/picosonic/bbc-fdc