fluxengine
fluxengine copied to clipboard
davidgiven
Disks from Q1 computer
Hello! If you are interested in supporting a very strange floppy format you might look at some research into it I did Q1 decode github repo.
I managed to decode track with the kludge code I wrote but since the format is not using the index pulse I have not been able to decode the full track as the catweasel only stores one revolution worth of samples starting from index.
It is basically MFM encoded but the format has variable sector size so that each track have their own sector size. A file consists of a number of tracks. Text files / source files usually have 80 character records / sectors while binaries have 255 bytes records. Track 0 always have 40 bytes records and contain the directory of the disk. One record per directory entry. Disks are single sided.
That looks interestingly cursed. Also, very inefficient --- you need a largish gap between records to give space for the drive to turn the write and erase heads on and off, so the more records you have the more wasted space there is.
For technical reasons FluxEngine requires all the sectors on each track to have the same size, but I think this is the case here, right? If you can get me a complete flux file I can take a look. It'd also be cool to add filesystem support for it.
Nice that you also got intrigued by the strange format!
Very inefficient yes. From my understanding the format is somewhat similar to what IBM used on the disks for their S/360 / S/370 line of mainframes. A file consisted of a number of tracks with a certain record size which was reflected directly in the hardware.
All sectors are the same on each track. Just varying between different tracks.
There are Catweasel dumps in the repo I linked to under the directory "Q1 disks". The kludge-code provided in the repo reads those files and are able to decode it.
Hello --- I finally had a chance to look at this. Unfortunately the dumps you've got aren't the .cwf files that I know of. Where did you get them?
The dumps are debug output from Catweasel, using the CW2DMK DOS program. The files contains a byte per transition. The high bit is the index marker. The seven lower bits are the count between two transitions. The code q1decode.c is able to decode them.
It looks like CW2DMK is third-party software which uses a different flux format to the original Catweasel software. Which is nice. I was hoping not to have to write a decoder...
Incidentally, I'd rather like to implement native Catweasel support in FluxEngine, so that you can use it on Catweasel devices directly. Except, I don't have one! It looks like there's a library in CW2DMK which should do all the hard parts. Would you be at all interested in testing this?
I have the DMK files reading and have progressed some way towards reading the disks --- I have some data. I see what you mean about these weird. I'm not actually sure that FluxEngine's architecture can support them as the sector sizes can vary from disk to disk. Hoiw would you even encode disk images? You might have to go directly from the low-level encoding to files. I'll have to think about this.
The disks, however, seem to be riddled with bad sectors. I'm getting very few clean decodes. The log in the README produced by your tool seems much better. Which disk was that made with?
We have a Q1 machine in datamuseum.dk and I have reverse engineered this format now.
I have documented what I have found out here:
https://github.com/Datamuseum-DK/FloppyTools/blob/main/q1_microlite.py
(Feel free to poach my decoders from that project into FluxEngine, I only use python because it's faster to prototype and to recover really stubborn sectors by hand that way)
I have also tried running my decoder against @MattisLind's images, but because the streams have only a single media rotation, a lot of sectors are missing.
