Real and Imaginary Disk Editor
Real and Imaginary Disk Editor
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
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
-
- Posts: 687
- Joined: 08 Nov 2013, 21:48
Re: Real and Imaginary Disk Editor
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
David
Re: Real and Imaginary Disk Editor
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![Smile :-)](./images/smilies/icon_e_smile.gif)
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
![Smile :-)](./images/smilies/icon_e_smile.gif)
Re: Real and Imaginary Disk Editor
Interesting how you've managed to reverse to communication between KF and PC. ![Smile :)](./images/smilies/icon_e_smile.gif)
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: Real and Imaginary Disk Editor
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.
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.
Re: Real and Imaginary Disk Editor
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.
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.
Re: Real and Imaginary Disk Editor
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.
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.
Re: Real and Imaginary Disk Editor
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).
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).
Re: Real and Imaginary Disk Editor
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.
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.