Real and Imaginary Disk Editor

[tomascz]

Hi all Kryofluxers,

I've been developing this app since 2015, and in Spring of this year, I've added a read and write support for KryoFlux (without DTC) - functions well, but with many magical constants scattered in the resulting code, please take it as a very experimental solution for the moment being.

https://github.com/tomas-nestorovic/RIDE

[brightcaster]

That looks very interesting! Is there any chance to get a binary? As a linux user I don't have access to visual studio. But I would like to run it on wine...

David

[tomascz]

Hi David,
there are already binaries to the right in the Code tab (must scroll a bit). Formerly it was nicely visible on the top (like Code or Issues tabs) but GitHub has decided otherwise.
Just in case: https://github.com/tomas-nestorovic/RIDE/releases
I'm not certain if you will be able to communicate with KryoFlux or internal PC floppy drive via Wine, but everything else is confirmed to function more or less well

[ZrX]

Interesting how you've managed to reverse to communication between KF and PC.

[tomascz]

A little wonder for myself - the whole thread on a this (and English machine translation). There are, however, still plenty of magical constants in the resulting code that would be nice to have decode - but it somehow functions, where "somehow" means an occasional timeout but the data successfully written anyway.

Thanks to an awful crash in case of a mousewheel used in hexa-editor, I've yesterday issued a quick patch version 1.6.1.1.

[IFW]

There are no magic constants in the write stream, except for the first 4 bytes of the header - but the purpose of that is to prevent overwriting of someone precious disk accidentally or via bad programming.
The rest of the data is completely dynamic and every aspect of it depends on the data to be written. The whole process is optimized for having minimal data size where the flux reversals are dense, and more data passed while flux reversals are not so dense.
Preparing the data correctly is a convoluted process that involves a complex code optimizer - the code being here the command buffer the firmware understands.
Since the firmware can toggle the write gate at will with nanosecond correctness, naturally it can easily wipe an entire track or write partially formatted tracks etc.
In other words, while repeating a "known good" sequence may work for a specific track it can be totally wrong or barely working for another... and as you have experienced it will lead timeouts or worse.

[IFW]

When you do get a timeout the data written is incorrect - at least one bitcell will have an incorrect size, as the stream was not optimized correctly for the execution timeslot the firmware/hardware had for processing the data.
Whether that incorrect bitcell or cells matter for the specific data you are writing or not, depends on pure luck, but technically speaking the data written is not exactly the data that was sent.

[tomascz]

Thanks for the clarification!

Naively asking - is there any chance that you could fix or somehow improve my KFW1 implementation? (KryoFluxDevice.cpp/TrackToKfw1 method). Pre-compensation has already been applied to the input track (represented by CTrackReader tr method parameter).

[IFW]

Not really at the moment - not because I don't want to, but I am working a lot on upcoming software releases.
However I was thinking about having a library with full KryoFlux board control eventually - but there is no ETA, given it depends on having other software ready first with much higher priority.