Aus meiner zuletzt gemachten Recherche hier ein Zitat aus dem FluxEngine Forum. Angemerkt sei noch, auch hier geht es hauptsächlich darum ein Image zu erzeugen und nicht um das Zurückschreiben desselben, was wir wollen. Es geht hier auch um die Technik, wie die Flux-Aufzeichner arbeiten.
Für den Catweasel wird klar was mit der Unterstützung von hartsektorierten Disketten ab dem MK4 gemeint war.
In einem weiteren Thread, ich hoffe ich finde den auch noch wieder, wurde noch bemängelt, das der Catweasel vom Hersteller zu stiefmütterlich supported wurde, weshalb nur wenige fähige Programmierer Software für ihn geschrieben haben, aber immerhin alles open source.
Der Kryoflux ist aktuell, aber nicht open source und es hängt an seinen Entwicklern, uns die gewünschten Funktionen zu implementieren.
Haben wir ein Abbild der ersten, scheinbar richtig gelesenen, Spur? Und zum Vergleich ein Re-Read von der erstellten Kopie? Wo sind mögliche
Unterschiede entstanden, und können wir die Samplingrate verändern, um zu viel Datenmüll zu verhindern?
In #retrocomputing #fluxengine news:
A little while back someone sent my a Kryoflux image of my first hard sectored floppy disk, one which uses multiple index holes to identify where sectors are. These was for an AES Data Superplus / Lanier No Problem word processor. It was actually pretty easy to decode even without the index holes, as sectors could be identified by a magic number in the data stream. http://cowlark.com/fluxengine/disk-aeslanier.html
However, since then I’ve received another one. This one’s for a Zilog MCZ 1/20, a very early Z80 development minicomputer from 1976. http://www.retrotechnology.com/restore/zilog.html
This one’s interesting. 32 sectors, 128 bytes per sector (plus four bytes of metadata used to form a doubly-linked list with other sectors in a file), and very hard sectored. There’s no identifiable record separator. Instead, the controller waits for an index pulse, synchronises its clock against the bitstream, and then waits for the first data bit. This is the high bit of the sector number in the sector header, so once it’s seen that it knows where the byte boundaries are.
The trouble is that this same sequence may be embedded inside perfectly valid data. I can’t reliably find it from looking at the data stream alone.
What I probably need to do is to take into account the index information as well. Currently FluxEngine doesn’t do this, for simplicity — the only data it captures is the intervals between pulses (I attach a picture of the source code of the FPGA firmware which does it: yes, really). The index signal is a completely independent timing stream.
The Kryoflux handles this by having multiple parallel timing streams. The Catweasel does (well, did) it by recording the state of the index signal on every pulse. From the firmware perspective, the latter’s preferable, although I’m not sure I have enough space in my coprocessor datapath thingy to actually do it; I can only have two more states in my FSM. (I could always add another FSM and chain them. I’m using 3, and my device has space for 24.) But when writing pulse streams, things get more complicated, as things are now no longer symmetrical: reading doesn’t produce data which I can write.
From the decode perspective… ugh. Right now the decode pipeline is: Guess clock → Decode to raw bits → Segment into records → Parse each record and produce a bag of sectors → Assemble the sectors in the right order. Taking index information into account means my raw bitstream needs to be annotated somehow. It’s not a std::vector<bool> any more…
I sense another major refactor coming along.
Ein anderer Autor macht folgende Anmerkungen zum Schreiben hartsektorierter Disketten auf per Flux Basis:
"
Actually, I'm mucking with a catweasel card right now.
I took Tim Mann's code as a starting point and I'm going from there. I
don't have any use for his decoding routines nor of making virtual disk
images since my needs are different. However, I can't imagine how many
hours of work he saved me by having routines that locate the card in PCI
space. Also, his "trackhist" program provided some very useful
subroutines. With the help of Tim's code, it took me less time to
modify/write the code to decode the disk format than it did to rig up
the 34-pin to 50-pin ribbon cable adapter.
Anyway, I can provide an example disk format where the catweasel, as it
stands, can't write the disk image, at least not without some dodgey
trial & error (try to write a track, read it back and if it is mucked
up, try and adjust the write timing for the next attempt. Even then,
there is a lot of luck involved).
Hard sectored disks are a problem for the catweasel to write. There is
a function to write from index mark to index mark, except the catweasel
assumes there is just a single index mark per revolution. Thus, you can
write one sector, but you can't even reliably tell it which sector you
want -- it just starts at the next index hole that appears. Perhaps
under DOS you can disable interrupts and figure out via polling when
sector N is about to appear and use index-to-index write mode. Even
this doesn't suffice for the disk format used by the Processor Tech
Helios system. It ignored every other sector mark so that effectively
there were 16 256B sectors instead of 32 128B sectors. Further, blocks
of data could be larger than 256B -- they simply spanned more than one
sector. Thus, this mode is useless for that scheme.
You can do a write where you specify "wait for an index hole, then write
this sequence of transitions". The problem is that due to speed
variations you can't say that index 5 is going to come exactly (166 2/3
ms / 32) after index 4. That is where you could try to write the whole
track, then read everything back to see if you succeeded and if not,
adjust the clock pulses wider or shorter to make things line up. Oh
yeah, in this mode I think it doesn't wait for an index hole, it just
goes whenever you tell it to, so good luck trying to get the data to
line up with the index marks at all.
As it turns out, now that I have the catweasel set up and running, there
are three disk formats that I would personally find useful to be able to
decode -- 8" Helios, 8" Wang 2200, and 5.25" Northstar. Guess what --
all three are hard sectored formats. Luckily, I'm really only looking
to use it to archive virtual disk images, not to create new disks."
