KryoFlux v3.50 Linux release package

DTC 3.50 is a major rewrite of the host software, porting the existing codebase to C++17 and beyond.
The work on DTC started in late 2008/early 2009 - 2 years before C++11 was even ratified - and consequently a significant portion of the original backend code of DTC was written in C++03 (C++98) during the first few years of development.
Against all odds, C++ releases changed to a 3 yearly cadence, arguably for the better in terms of language and Standard Library features, but to take advantage of all of those required a step-by-step update of the source code with very careful management of code compatibility, data compatibility and avoiding regressions.
Using the (practically brand new) C++17 language enabled us to do things that would have been hard (if not borderline impossible) to manage in the codebase previously, and made it possible to use recent toolchains, SDKs and Standard Library releases with all the latest security and stability improvements.
While in general we don't like release notes that claim "security and stability" improvements, the reality is, in this case updating our backend code to Modern C++ has had tangible benefits - including those security and stability improvements as well. We even have found problems along the way (mostly edge cases though), that wouldn't have been noticed or fixed otherwise.
The transition of the entire backend code is not complete yet; however, we have reached a stage where we felt releasing the current version can finally bring benefits to all of our users as well. 
We have quite a few new features planned that are based on the new backend code - and some of these are already available in this release!

DTC 3.50 is supplied for X86_64 and ARM64/AARCH64 platforms and any subsequent maintenance release will follow this tradition.

DTC 3.50 is not the only codebase that has been updated to C++17; the SPS Decoder Library has been ported to C++17 too.
You should use the library (capsimg.dll) supplied with this release if you are using any functionality related to CT Raw or IPF file formats. The library version has been updated to 5.2.0.1 to reflect the changes.
As usual, please ensure that you use the correct version of the library - 32 or 64 bit according to the version of DTC you are using as the host software.
The source code of the new library will be available soon, via the download section of the KryoFlux website.

Finally, we have spent a lot of time revising the existing manual, adding more details and context to existing feautures and explaining new ones.

NEW:
- New backend code with speed, security and stability improvements

- Improved Revolution Analyser; matching flux reversal data across multiple revolution data sampled in a stream file

- New Path Solver generating "best possible" data from all the flux reversal samples present in the stream files, at the flux level.
The Path Solver is using the consistency data generated by the Revolution Analyser. 
Paths represent the solution(s) from the path solver telling us whether or how it is possible to construct a single contiguous stream with all consistent flux reversals across multiple samples taken, effectively generating a single track sampled without any defects that are common reading magnetic media, especially old magnetic media.
The Path Solver currently sees weak bits as blocked paths (since they are always inconsistent) and reports them as having no solution. This behaviour is by design, but we have some enhancements planned for more selective reporting of such data.

- The graph default plot domain is based on automatic or user selected RPM now

- Improved heat maps in the graphs

- Improved consistency bars in graphs that are easier to read

- Path map generation. Path maps are built from the data generated by the Path Solver; they represent the solution(s) from the path solver telling us whether or how it is possible to construct a single contiguous stream with all correct flux reversals. 
Since path maps are derived from consistency data, they show both consistency bars as well as the path(s) resolved superimposed over the consistency bar.
DTC checks the image consistency for us when a path map is being generated.
If there is no error reported during the generation of a path map, the current track image is as good as it gets; it is possible to create a "best" track without any discontinuity or inconsistency from all the available track samples.
If there is an error it may be due to the track containing weak bits (e.g. fully or partially unformatted) or because there is no way to get a consistent reading from the currently sampled track. In the latter case, the disk should be cleaned and re-imaged. In the case of unformatted or partially unformatted tracks or weakbit based protections, no action is necessary.
Having a full path resolved in a track image does not necessarily mean that the data is good; but it is checked for us that the sampled data is consistent enough. As an example, a physical damage on the disk surface may generate consistently bad flux reversals. Generally speaking, having track data with a path fully resolved can be considered a good quality track sample and more convenient than manually checking the consistency bars.
Having poor quality, inconsistent samples read from old magnetic media is very common.
The path effectively represents the quality of the samples, not the quality of the data - the quality of the data content can only be verified once the data is decoded, but having good quality samples for that is essential.
Since the path solver can take some time to run depending on the number of inconsistencies found in the samples, it is only used when a path map graph is requested.

- Initial EDOS (Electronic Distribution Of Software) support. 
EDOS used to be a hardware and software-based system where commercial software was being duplicated in the store on demand. It was especially popular in the UK, but it seems EDOS machines were in circulation at other markets as well.
EDOS used original mastering data (or data generated from masters/commercially duplicated media) so it is an important aspect of software preservation.

So far we only have 2 early CD images, but there were new collections available once every few months (quarterly?) during the lifetime of the EDOS system, so if you happen to have more CDs (or CD images) available, please do get in touch.

- DTC is capable of recovering any encryption key used in the file headers of the distribution CDs. These CDs contain image and catalogue/database files for each disk or tape available for duplication in the specific CD release.
Due to the limited material currently available it is not yet known whether the encryption key was ever changed - DTC however is capable of finding it automatically as long as the CD contents are fully available.

- DTC can decrypt the EDOS image file headers using the previously recovered key and save them as TXT or CSV files

- It is possible to tap and capture the stream data generated for writing by DTC. 
It is planned to have different tap points in the future for further analysis.



KryoFlux v3.00 release package

DTC 3.00 together with KryoFlux firmware 3.00 introduce fully automatic support for hard-sectored disks.
This is not a trivial change and required an almost complete rewrite of the track reading/streaming firmware code, as well as many changes in DTC.
Both x86 and x64 builds of DTC 3.00 are available, however as usual the x64 specific build is the recommended one.
'Fast' firmware releases are no longer supported starting with the new 3.00 release of the firmware.
Starting with DTC 3.00, a KryoFlux board running firmware 3.00 or later is required; the new firmware is included in the release package and is used automatically if available at the installation location.

For more in-depth details about using hard-sectored disks, please read the manual.

NEW:
- GUI updated for Java 10

- DTC 3.00 requires features only available in firmware 3.00 or later; DTC will stop with an error if the firmware file downloaded to the KryoFlux board is an older, incompatible release.

- Full automatic hard-sectored disk support - it is even possible to mix & match hard-sectored and normal tracks in a single disk image if needed.

- Any disk operation is guaranteed to use the user-defined or preset number of disk revolutions, regardless of whether the disk is soft or hard-sectored. This is fully automatic, the user does not have to know or specify the disk type currently being used.

- Hard-sectored disks are automatically detected and hard sector information is shown for any read operation. Write operations are not allowed to hard-sectored disks, since they'd only damage the existing data.

- Added extra drive spin up process for both read and write, so if there is no disk in drive or the disk is stuck the read or write process stops before starting the selected function.

- Added timeout to drive spin up - it is no longer allowed to start reading or writing, but insert a disk later.

- hs: <hard_sector_count> added to read level output, if the track is hard-sectored

- Any streams generated by 3.00+ firmware is marked to support hard-sectored streaming; has hs=1 in the info area of the stream. Since the old firmware is known to get out-of-sync when streaming a hard-sectored disk, even if someone seemingly managed to image a hard-sectored disk with such firmware, no hard-sector oriented functionality will be enabled for the stream - it's more than likely to contain incorrect data. Generally speaking though, it was next to impossible to dump a hard-sectored disk before with the old firmware, so this is just a safety measure.

- The stream file now contains the number of hard sectors detected to simplify later processing, hc=<sector count>
If the sector count is 0 it's a normal, soft-sectored disk; any other value is the number of hard-sectors. If this value is not present, it simply means soft-sectored disk imaged with a pre-3.00 DTC; it can't be a hard-sectored disk since imaging that was not possible.

- DTC uses separate processing of the track/revolution index signal and the hard-sector generated index signals in the analyser pipeline.

- RPM calibration has been completely rewritten and now it can auto-detect soft-sectored/normal and hard-sectored disks and it should even work when disks gets replaced with a different type while it's running, e.g. changing to any kind of soft-sectored or hard-sectored disk should be fine while RPM calibration is running.

- If a hard-sectored disk is being used during RPM calibration (dtc -c3) the RPM output contains the number of hard sectors present on the disk. For a normal, soft-sectored disk the output is identical to previous DTC releases. The hard sector count is always updated, so a disk swap changes the hard-sector count displayed according to the type of the freshly inserted disk.

- The fimware now allows up to 16383 index revolutions to be sampled, since a disk with 32 hard-sectors would use 33*360 = 11880 index events in a minute.

- The firmware has significantly improved error recovery during streaming.

- The firmware fixes the buffer overrun problems that occured when very high number of revolutions were sampled, e.g. 1000. A few hard-sectored disks have been tested with 1000 (10K+ index signals) revolutions sampled after the fix: no buffering errors at all.

- All known buffering errors, hangs and disconnects during streaming have been fixed. Although these were very rare edge cases, they don't happen anymore. If you still see any buffering error, it's always because the PC/USB port can't keep up with the streaming now.

- DTC now saves partial streams to disk even if there is a communication error; this provides better diagnostics and error messages if trying to use the stream file later. In order to make this safe to use, incomplete streams always generate errors now if they are accessed by any command/processing in DTC.

- If the streaming buffer turns out to be too small for sampling the disk dumping gets aborted, instead of retries; if one track does not fit, others are not likely to fit either.

- There is a new error message shown if there is a hardware problem detected with the index signals; this is especially useful when imaging hard-sectored disk with a not fully compatible drive, e.g. imaging a disk with 32 hard-sectors with the drive index sensor hardware timing calibrated for detecting only fewer signals.


GENERAL:

G64 writing requires G64 files with mastering information, which can be produced by DTC with image format 22a (<-i22a>). These G64 files should work with all emulators. This functionality will later be replaced by IPF files with full mastering information as required. If a G64 is missing mastering information, you will receive a warning.

THIS FEATURE IS HIGHLY DEPENDANT ON THE 5.25" FLOPPY DRIVE USED. Many "modern" 5.25" drives don't write DD data correctly. Some can be switched into DD mode by setting jumpers or by setting pin 2 of the Shugart interface to the correct state. This state is controlled by parameter dd and setting it (e.g. <-dd1> or <-dd0>) will set the high density control line appropriately.

Both drives, your mastering drive, as well as the 1541 (or 1541II or 1571) on your C64 must be perfectly aligned. Otherwise advanced protections, like anything that has to do with half or fat tracks, will not work at all.

For more information, please read the "Writing back to a real disk" section of the manual.


If you encounter any problems, please let us know by posting here:

http://forum.kryoflux.com


When supplying a bug report, please do include the following information:

- hardware used (type of CPU, RAM, USB connection, devices attached etc.)
- software used (operating system, service packs, additional software)
- exact step-by-step description how and when the problem occurs

Please use the forums for bug reports, do not submit tickets for this.


Thank you for your support,
The Software Preservation Society
