KryoFlux^® Support Forums

I can't check at the moment but if I recall correctly it could be important that the syncs end at a byte boundary so that the GCR data can be directly found and interpreted as expected. Also I think that I have seen some disks where the physical order of sectors does not match the logical one, so th...

Heureka and Langenscheidt both used track formats that include mixed densities and as such can unfortunately not be represented in G64 images. This is simply a limitation of the G64 file format and can not be fixed as easily as adding remastering information. Btw: As far as I remember the tracks als...

Oh, just saw that ZrX already answered but anyway... You can zoom in using the mouse wheel until you see single dots. These are actually the data. In your screenshot the bands are approx. 4, 6 and 8 µs which are for bit sequences 01 (2 bits), 001 (3 bits) and 0001 (4 bits) at 2 µs respectively. As a...

I should get one of these Mindscape disks to do analog dump of the sector to see how it was really written. After looking at the flux data of two different disks with this protection I'm quite sure it's a quiet section like what you have figured out for Cyan Loader. I own the same Road Runner versi...

@ZrX: Yes, that's almost correct. The drive code reads the first 16 raw GCR data bytes of track 1 sector 0 where 2nd byte must be D5 7th byte must be AA 8th byte must be D4 the value of 4th, 5th or 6th byte must change on two consecutive reads With AGC involved it's hard to judge from the raw random...

If we have proof of ownership (which is the case when dumps are submitted) people will eventually do get IPFs for their C64/C128 games. But the IPF format must be extended to support GCR encoding (not really much more than adding new enum constants) and the processing toolchain needs to be changed b...

Perfecly possible. I have an original "Run the Gauntlet" disk with side 0 containing the content that should be on side 1 and side 1 is unformatted.

A few mintues ago you should have received responses through the ticket system.

The sectors can be decoded but there's still something odd with the checksums and/or the track format which needs further investigation. Until this has been done it's unclear if any of the sectors are really erroneous or not as all sectors are found to be bad. There are 6 sectors of 512 bytes per tr...

Tracks 80.0 and 80.1 both contain 18x exactly the same sector. Even the sector number is the same. That's why DTC detects only one sector. Also, only *H (header extra data found) is logged but not +n (modified sectors found). As a result the GUI shows "Good*" but not "Good*+Modified&q...