KryoFlux v3.00 Windows 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.



KryoFlux v2.72 Windows release package

Both x86 and x64 builds are available, however as usual x64 is the
recommended one.

This release officially drops support for Windows XP although it might
still work, depending on service packs installed. You will now need at
least Windows Vista to run the KryoFlux host software.

For more in-depth details, please read the manual.

- Lots of internal updates and fixes for edge cases found by the beta
testers and the community
- Full graph support with user defined parameters. Graphs may be optionally
generated whenever DTC reads a track from either stream files or a KryoFlux
board.

Please see dtc -h for the available options. The default is to not create
any graphs. Tracks that are not accessed during the read command do not
generate graphs, but for example reading an entire disk image uses all the
tracks. Graphs do not rely on guide formats or any other information, other
than the sample data taken from a specific track. A new graph is rendered
each time a track has been read in track read calibration mode - this is by
design.

-pg: graph type
1: a heat map generated from the flux reversal samples
2: sample heat map + consistency bars
Note: consistency graphs require significantly more processing, than the
sample heat map alone, hence generating these graphs takes more time. The
consistency bars represent how well aligned are the samples on each
revolution sampled from the same track. Each horizontal bar at the bottom
of the graph represents one revolution sampled from the same track. The
green coloured areas in a bar represent areas that match samples taken at
a different revolution from the same track area. Red areas are
inconsistencies.

A track image that has all green consistency bars has consistent samples
for all revolutions imaged. Consistent samples are not necessarily good
samples; e.g. a disk defect might produce consistently bad readings for
each revolution, however consistent data is unlikely to change due to
redumping a track, unless e.g. the disk surface gets cleaned between
sessions. Disk defects, as well as certain copy-protections always generate
other artefacts that are automatically highlighted in the heat map, such as
areas with "weak" bits, or without any flux reversals. A weak bit area is
expected to produce inconsistent reading on each attempt. Note, that due to
various reasons, consistent data does not mean identical sample values.

-pf: graph flip mode
0: disabled
1: side 1 is from a flippy disk
2: flip sample data for both sides

-pw: the graph width for rendering in pixels
-ph: the graph height for rendering in pixels
-px: the origin of the graph rendering on the x axis
-py: the origin of the graph rendering on the y axis
-pd: the graph domain; the graph is rendered for the time period
between [px, pd]
-pr: the graph range; the samples are rendered for each sample in the
range [py, pr]

Graphs are rendered as if the track was imaged at a stable, exact 300RPM.
Therefore the default domain setting of [0.0, 0.2] represents an entire
revolution between two index signals, which is exactly 0.2s at 300RPM. The
default range setting [0.0, 2e-5] represents flux reversals that are at
most 20us long. Note, that all samples get processed while generating a
graph, but depending on the settings the visible domain and/or range can
be different.

All domain and range parameters can be negative, ie you can shift the view
to a "proper" coordinate system. For these parameters scientific notation
is accepted as well for easier input, e.g. 2e-5 is 0.00002.

If flip is enabled, the data on the selected sides gets flipped as if the
disk was turned over.

-pf1 has similar effect to -y for reading
-pf2 is just there for completeness

Keep in mind that whatever you set for a guide format etc. has no effect at all
on the graphs - including flippy mode set with -y.


- graceful termination of the KF hardware attached if the user presses
CTRL-C
As a consequence of this, the program does not stop instantly for CTRL-C,
and will attempt to move the head of the active drive to track 0, ie the
head shouldn't get stuck at a track below 0 on a flippy modded drive. Note,
that terminating the process by e.g. closing the command prompt or Task
Manager when using Windows cannot be gracefully terminated, so terminating
the DTC process does not shut down the hardware gracefully in those cases.
 

- prevent using a stream file with broken index signal data (generated by
some third party tools)
- ensure that broken index data does not cause invalid calculations and
NaNs for the cell conversion and thus later crashes at random stages of the
analyser pipeline

Trying to use any stream file affected reports "Some index positions could
not be found" or "Can't open image file: <name>" errors depending on the
kind of operation where accessing the stream occurred. If in any doubt,
just try to convert the stream file to any image format, that will always
show "Some index positions could not be found" error for the incorrect
files.

[As a side effect, broken streams generated can no longer be written to a
real disk with the new DTC, regardless of whether they caused a crash or
not in previous DTC releases]


- using CTRL-C should be possible during drive spin up before writing

 
KryoFlux v2.51 Windows release package

This is a maintenance release that improves speed and reliability of DTC.
No new features were added.


Changes from 2.20 to 2.50:


NEW:

- completely rewritten cell band detection and noise detection, filtering
  should now be spot on for SD and HD disks.

- processing pipeline rewrite and added x64 executable. DTC is now up to
  300% faster than previous version (e.g. conversion from stream to CT
  raw). 64bit version of DTC is recommended for 64bit versions of
  Windows. You will need at least Windows Vista to use the 64bit
  version.
  
  Please make sure to use correct version of capsimg.dll and place
  in correct directoy. 
  
  on 32bit systems: place 32bit dll in Windows/System32
  
  on 64bit systems: place 64bit dll in Windows/System32
					place 32bit dll in Windows/SysWOW64
					
- with new capsimg.dll you can now directly load CT raw (stream 
  coming soon) images in emulators, e.g. WinUAE, FS-UAE,
  Hatari, STEem, Spectaculator and many more.

- support wildcards ? and * when specifying the source image for image
  conversion or writing to disk. The file that has been selected by the
  program using the wildcards is being displayed at the beginning of the
  operation.
  
 - GUI now supports density line to be set and offers additional fields
  for image local and global parameters.
  
- one more thing: added technology preview of RepliFlux technology. With
  this feature, KryoFlux can now write back stream data without further
  analysation or conversion. As this is only a preview in this release,
  certain limitations apply (will be removed by later releases): The disk
  must be index aligned. Weak bits and no flux areas are likely to fail.
  
  To replicate a disk, create a stream dump, then write it back with
  
  DTC -fD:\dump\track -w
  (where the dump would be in "D:\dump" with the stream files being called
  "track00.0.raw", "track00.1.raw", etc.)
  
  We need your feedback here, visit our forums! Be sure to check the 
  manual addendum in the docs folder.
  
   
CHANGED:

- improved quality of CT raw image renderer

- improved quality of G64 image renderer

- improved data recovery capability for various disk formats

- improved analysis of the recorded cell bands

- unreadable CTR file generation fixed for samples that contain more than 5
  revolutions


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 do read page 29ff. 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