Disks from Q1 computer about fluxengine HOT 7 OPEN

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.

from fluxengine.

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.

from fluxengine.

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?

from fluxengine.

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.

from fluxengine.

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?

from fluxengine.

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?

from fluxengine.

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.

from fluxengine.