KryoFlux Support Forums

Suppose I am writing an emulator that loads floppy disk images containing several revolutions. The emulated program rewrites only one sector of that track. What is the proper way of emulating this? I could think of only two alternatives: Write to all revolutions at once, which will be odd when the sector starts at slightly different positions from revolution to revolution, or consolidate all revolutions into a single circular buffer with bits that change specifically marked. This question does not arise on the Amiga because as I understand, the Amiga always rewrites an entire track, but it would arise with a µPD765 floppy controller that writes sectors at once.

I don't believe there is any current "proper way" of emulating writing to a disk, especially if you are using Kryoflux stream files. A kryoflux stream is conceptually different from a real floppy disk track. A real track is an infinite loop, yet the results of multiple passes may not always be identical. A Kryoflux stream file is just a recording of multiple passes.

Just off the top of my head, an emulated format probably should contain only a single revolution, treated as an infinite loop, but for some copy protections (weakbits, for example) it would need extra data to describe how reading might vary per revolution.

Converting non index-aligned tracks in to a single revolution would also be a headache. But once converted, software could look at it as a seamless loop, so indexing would not be important unless one wanted to write the image to a real disk.

For non copy protected stuff, a single-revolution kryoflux stream file might work as a storage format. But for instances where multiple read passes must differ, that would probably not work.

Trying to write to multiple revolutions would be problematic in that revolutions might get "out of sync". For example, if only revolution #3 had a bad sector the write would fail in potentially unpredictable ways.

I think also some of the kryoflux folks would object to the idea of writing to a kryoflux stream file, as they are really intended for preservation purposes. It is already enough of a headache finding regular 1.44mb ".img" files of 1991 software that contain 2014 last access dates, hidden trash/desktop files, thumbnail files, and so on because someone mounted the image on their "modern" computer.

It sounds like you want to add save support to an emulator that runs IPF and/or CTR and/or stream files

As you say it's not an issue on Amiga - in WinUAE (Toni might correct me on this), there is a "diff" file, and whenever track data needs to be accessed the diff is checked first. If it's valid for a track the data stored there replaces the data from the IPF (or CTR...) etc files.
Notice, that while all IPF/CTR/stream may (and often does) contain variable density data, or data with higher/lower bitcell density than normal this is not an issue when rewriting the track data, simply because the emulated machine is not capable of writing such data at all without hardware modifications (that was the reason to use these densities in the first place).
The problem is slightly more complex when a program only partially writes a track though...

What you may consider to implement is how Atari ST emulators deal with saving to IPF/CTR.
I think the idea is very similar, just replacing the data works at the sector level.
At least Nicolas (Hatari author) is on this forum, but both Hatari and Steem are open-source, so you can find out what they specifically do.
Again, what is worth keeping in mind is that the FDC can only write sectors using the standard cell density (without extra hardware added, like afair the Discovery cartridge), which simplifies the problem.

In both cases it is an issue if the track is partially written; on the Amiga it happens when not an entire track is overwritten (which is not common), on a generic FM/MFM controller that's almost always the case (except for write track command).
You can switch between the bitstream (or the lower-level flux reversal) representation vs decoded sector data depending on which sector is "dirty", or keep the original track data as a single revolution only as soon as it gets written to.
That is possible with IPF as the whole track is guaranteed to be good (otherwise the IPF wouldn't exist), so you would not need multiple-revolutions to ensure that at least one those contains correct sector data.
It is not trivial to do this for CTR or stream though; finding matching data on multiple revolutions is a very complex problem due to variation in the data and way too many other factors - so not worth it for saving data in an emulator.

An additional complexity arises if the cell density is not standard on the track/sector overwritten. Depeding on the cell width used on the original recording, the newly written data may overwrite more than one sector, additional gap, or actually occupy less space than a sector with the original density on the same track.
In either case the new sector data gets fully written, but what remains of the data following (or inside) the existing sector can be very different.
I do not think that any emulator deals with this edge case though, because if they do, that means that they support overwriting copy-protected data on an original disk - but I am sure Toni or Nicolas would correct me if the current emulators actually do support this edge case as well

As SomeGuy pointed out though - we do NOT support modifyig IPF/CTR/stream files directly.
Other than being it very complex and error prone, it would completely defeat the purpose of preservation: you don't want to see 100s of different versions (disk images) of the same application without being able to tell which one is correct - so you'd have to try each one of them...
What you have instead is 1 file for preservation/archival purposes, and modifications (e.g. originating from emulators) represented as diff files.
This way your original data remains intact, you can even create mechanism where you can very easily "undo" saves etc without ever touching the original image files - you simply delete the diff file. Or you can create multiple undo levels etc - the possibilities are endless, and very easy to implement since you'd only ever deal with the diff file(s), e.g. like in a very simple source-control solution.

IFW wrote:It sounds like you want to add save support to an emulator that runs IPF and/or CTR and/or stream files

No. I will rephrase the question then:

Assume a PC track with weak bits. The CAPS library will return multiple-revolution data to the caller, with the weak bits having different content between revolutions. The emulated program writes one sector to this track --- maybe to a part containing the weak bits, but maybe to a normal part, for example if the copy-protected weak bit sector is sector 9 while the config file is in sector 4. How should the emulator apply that one written sector to the multiple-revolution data given to it by the CAPS library? The question is valid even if the emulator only saves "diff files", because the question then becomes what should go into the diff file.

IFW wrote:Again, what is worth keeping in mind is that the FDC can only write sectors using the standard cell density (without extra hardware added, like afair the Discovery cartridge), which simplifies the problem.

Cop's Copylock II writes variable-density tracks using a standard µPD765 floppy controller and drive. It does so by turning off the drive motor for a small period of time at specific intervals while writing. (I do not intend to emulate writing such disks. I do already emulate the keydisk check for such disks.)

IFW wrote:that means that they support overwriting copy-protected data on an original disk - but I am sure Toni or Nicolas would correct me if the current emulators actually do support this edge case as well

Laser-hole protections overwrite copy-protected data on an original disk. My DOSBox-TC successfully emulates laser-hole protections, using a single consolidated revolution, by checking whether any bit being overwritten is a weak bit, and refusing to do it if that is the case.

You can ask the library to return a single revolution for weak bit data.
I'd create the diff file for that single revolution.