Kryoflux Flippy Disk Preservation Commands

All questions about how to use KryoFlux go here.
ZrX
Posts: 474
Joined: Tue Dec 06, 2011 9:09 pm

Re: Kryoflux Flippy Disk Preservation Commands

Post by ZrX » Tue May 15, 2018 10:08 am

Instead of -b-8 use -a2 -b-6 to correct the track offsets that are off by 2 at the moment.

User avatar
mr.vince
Posts: 2099
Joined: Tue Oct 05, 2010 5:48 pm

Re: Kryoflux Flippy Disk Preservation Commands

Post by mr.vince » Tue May 15, 2018 8:44 pm

Seems this disk was replicated on a broken drive.

JasonCA
Posts: 32
Joined: Tue Oct 11, 2011 3:37 am
Location: California

Re: Kryoflux Flippy Disk Preservation Commands

Post by JasonCA » Wed May 16, 2018 8:10 am

ZrX wrote:
Tue May 15, 2018 10:08 am
Instead of -b-8 use -a2 -b-6 to correct the track offsets that are off by 2 at the moment.
Fantastic! Thank you ZrX! :D

Below is the results of the dump using the parameters you suggested:

Code: Select all

DTC.exe -l15 -fC:\Dumps\Dump1\track -i0 -fC:\Dumps\Dump1.d64 -g2 -k2 -y -a2 -b-6 -i6a -r5 -d0 -p -e83 -dd1 -l8 
KryoFlux DiskTool Console, v2.72_Win32, uiv.1, Mar  9 2018, 16:50:41
(c) 2009-2018 KryoFlux Products & Services Ltd.
Developed by The Software Preservation Society, www.softpres.org
Licensed for private, non-commercial use only.

-6.1[00]: CBM DOS: OK*, trk: 001, sec: 21, *H +8
-4.1[02]: CBM DOS: OK*, trk: 002, sec: 21, *H +19
-2.1[04]: CBM DOS: OK*, trk: 003, sec: 21, *H +21
00.1[06]: CBM DOS: OK*, trk: 004, sec: 21, *H +13
02.0[00]: CBM DOS: OK*, trk: 001, sec: 21, *H +21
02.1[08]: CBM DOS: OK*, trk: 005, sec: 21, *H +21
04.0[02]: CBM DOS: OK*, trk: 002, sec: 21, *H +21
04.1[10]: CBM DOS: OK*, trk: 006, sec: 21, *H +18
06.0[04]: CBM DOS: OK*, trk: 003, sec: 21, *H +21
06.1[12]: CBM DOS: OK*, trk: 007, sec: 21, *H +19
08.0[06]: CBM DOS: OK*, trk: 004, sec: 21, *H +19
08.1[14]: CBM DOS: OK*, trk: 008, sec: 21, *H +19
10.0[08]: CBM DOS: OK*, trk: 005, sec: 21, *H +19
10.1[16]: CBM DOS: OK*, trk: 009, sec: 21, *H +18
12.0[10]: CBM DOS: OK*, trk: 006, sec: 21, *H +21
12.1[18]: CBM DOS: OK*, trk: 010, sec: 21, *H +21
14.0[12]: CBM DOS: OK*, trk: 007, sec: 21, *H +21
14.1[20]: CBM DOS: OK*, trk: 011, sec: 21, *H +17
16.0[14]: CBM DOS: OK*, trk: 008, sec: 21, *H +18
16.1[22]: CBM DOS: OK*, trk: 012, sec: 21, *H +14
18.0[16]: CBM DOS: OK*, trk: 009, sec: 21, *H +16
18.1[24]: CBM DOS: OK*, trk: 013, sec: 21, *H +15
20.0[18]: CBM DOS: OK*, trk: 010, sec: 21, *H +19
20.1[26]: CBM DOS: OK*, trk: 014, sec: 21, *H +17
22.0[20]: CBM DOS: OK*, trk: 011, sec: 21, *H +16
22.1[28]: CBM DOS: OK*, trk: 015, sec: 21, *H +21
24.0[22]: CBM DOS: OK*, trk: 012, sec: 21, *H +16
24.1[30]: CBM DOS: OK*, trk: 016, sec: 21, *H +21
26.0[24]: CBM DOS: OK*, trk: 013, sec: 21, *H +16
26.1[32]: CBM DOS: OK*, trk: 017, sec: 21, *H +21
28.0[26]: CBM DOS: OK*, trk: 014, sec: 21, *H +17
28.1[34]: CBM DOS: OK*, trk: 018, sec: 19, *H +8
30.0[28]: CBM DOS: OK*, trk: 015, sec: 21, *H +16
30.1[36]: CBM DOS: OK*, trk: 019, sec: 19, *H +14
32.0[30]: CBM DOS: OK*, trk: 016, sec: 21, *H +21
32.1[38]: CBM DOS: OK*, trk: 020, sec: 19, *H +19
34.0[32]: CBM DOS: OK*, trk: 017, sec: 21, *H +21
34.1[40]: CBM DOS: OK*, trk: 021, sec: 19, *H +19
36.0[34]: CBM DOS: OK*, trk: 018, sec: 19, *H +18
36.1[42]: CBM DOS: OK*, trk: 022, sec: 19, *H +19
38.0[36]: CBM DOS: OK*, trk: 019, sec: 19, *H +19
38.1[44]: CBM DOS: OK*, trk: 023, sec: 19, *H +17
40.0[38]: CBM DOS: OK*, trk: 020, sec: 19, *H +17
40.1[46]: CBM DOS: OK*, trk: 024, sec: 19, *H +16
42.0[40]: CBM DOS: OK*, trk: 021, sec: 19, *H +17
42.1[48]: CBM DOS: OK*, trk: 025, sec: 18, *H +16
44.0[42]: CBM DOS: OK*, trk: 022, sec: 19, *H +18
44.1[50]: CBM DOS: OK*, trk: 026, sec: 18, *H +13
46.0[44]: CBM DOS: OK*, trk: 023, sec: 19, *H +19
46.1[52]: CBM DOS: OK*, trk: 027, sec: 18, *H +16
48.0[46]: CBM DOS: OK*, trk: 024, sec: 19, *H +19
48.1[54]: CBM DOS: OK*, trk: 028, sec: 18, *H +15
50.0[48]: CBM DOS: OK*, trk: 025, sec: 18, *H +12
50.1[56]: CBM DOS: OK*, trk: 029, sec: 18, *H +14
52.0[50]: CBM DOS: OK*, trk: 026, sec: 18, *H +16
52.1[58]: CBM DOS: OK*, trk: 030, sec: 18, *H +16
54.0[52]: CBM DOS: OK*, trk: 027, sec: 18, *H +14
54.1[60]: CBM DOS: OK*, trk: 031, sec: 17, *H +17
56.0[54]: CBM DOS: OK*, trk: 028, sec: 18, *H +11
56.1[62]: CBM DOS: OK*, trk: 032, sec: 17, *H +17
58.0[56]: CBM DOS: OK*, trk: 029, sec: 18, *H +13
58.1[64]: CBM DOS: OK*, trk: 033, sec: 17, *H +17
60.0[58]: CBM DOS: OK*, trk: 030, sec: 18, *H +15
60.1[66]: CBM DOS: OK*, trk: 034, sec: 17, *H +17
62.0[60]: CBM DOS: OK*, trk: 031, sec: 17, *H +17
62.1[68]: CBM DOS: OK*, trk: 035, sec: 17, *H +17
64.0[62]: CBM DOS: OK*, trk: 032, sec: 17, *H +17
64.1[70]: CBM DOS: <unformatted>
66.0[64]: CBM DOS: OK*, trk: 033, sec: 17, *H +17
66.1[72]: CBM DOS: <unformatted>
68.0[66]: CBM DOS: OK*, trk: 034, sec: 17, *H +17
68.1[74]: CBM DOS: <unformatted>
70.0[68]: CBM DOS: OK*, trk: 035, sec: 17, *H +17
70.1[76]: CBM DOS: <unformatted>
72.0[70]: CBM DOS: <unformatted>
72.1[78]: CBM DOS: <unformatted>
74.0[72]: CBM DOS: <unformatted>
74.1[80]: CBM DOS: <unformatted>
76.0[74]: CBM DOS: <unformatted>
76.1[82]: CBM DOS: <unformatted>
78.0[76]: CBM DOS: <unformatted>
80.0[78]: CBM DOS: <unformatted>
82.0[80]: CBM DOS: <unformatted>
84.0[82]: CBM DOS: <unformatted>

Enjoy your shiny new disk image!
Please consider helping us to preserve media and continue development:
www.softpres.org/donate
I will enjoy my shiny new disk! :)

JasonCA
Posts: 32
Joined: Tue Oct 11, 2011 3:37 am
Location: California

Re: Kryoflux Flippy Disk Preservation Commands

Post by JasonCA » Wed May 16, 2018 8:32 am

mr.vince wrote:
Tue May 15, 2018 8:44 pm
Seems this disk was replicated on a broken drive.
I guess so! I had a few in a row where I needed: -a2 -b-6 :o

The other one shown below is the other one I recently ran into is: -a2 -b-8

Code: Select all

-8.1[00]: CBM DOS: OK, trk: 001, sec: 21
-6.1[02]: CBM DOS: OK, trk: 002, sec: 21
-4.1[04]: CBM DOS: OK, trk: 003, sec: 21
-2.1[06]: CBM DOS: OK, trk: 004, sec: 21
00.1[08]: CBM DOS: OK*, trk: 005, sec: 21, *H +3
02.0[00]: CBM DOS: OK*, trk: 001, sec: 21, * +20
02.1[10]: CBM DOS: OK*, trk: 006, sec: 21, *H +7
04.0[02]: CBM DOS: OK*, trk: 002, sec: 21, *H +21
04.1[12]: CBM DOS: OK*, trk: 007, sec: 21, *H +10
06.0[04]: CBM DOS: OK*, trk: 003, sec: 21, *H +21
06.1[14]: CBM DOS: OK*, trk: 008, sec: 21, *H +8
08.0[06]: CBM DOS: OK*, trk: 004, sec: 21, *H +21
08.1[16]: CBM DOS: OK*, trk: 009, sec: 21, *H +6
10.0[08]: CBM DOS: OK*, trk: 005, sec: 21, * +21
10.1[18]: CBM DOS: OK*, trk: 010, sec: 21, *H +8
12.0[10]: CBM DOS: OK*, trk: 006, sec: 21, *H +21
12.1[20]: CBM DOS: OK*, trk: 011, sec: 21, *H +6
Do these parameters:

-a<trk> : set side 0/a track0 physical position (default 0)
-b<trk> : set side 1/b track0 physical position (default 0)

Only affect the Stream files? Originally, I thought -a and -b would adjust the stream files post processing. However, it seems once you apply these parameters it remains permantly adjusted in the stream.

Also, the usage of -a and -b don't seem to have an effect when converting a Stream file to a d64 or g64 file.

JasonCA
Posts: 32
Joined: Tue Oct 11, 2011 3:37 am
Location: California

Re: Kryoflux Flippy Disk Preservation Commands

Post by JasonCA » Sat May 26, 2018 9:23 pm

I've spent the last week dumping some disks so that I can put these Kryoflux Flippy/C128 commmands to test. I have since generated a good many dumps to play with before continuing forward. :)

During the capture process, some disks that I thought were Flippy disks are in fact Double Sided non flippy disks upon further examination. :o

I think one of the shortcomings of Kryoflux, is not being able to readjust the tracks once the stream file is captured. For example, having captured a non flippy Double Sided disk using the flippy commands, you can clearly see in the Kryoflux GUI that there is data on Side B: it exists in the stream data.

Knowing I have flippy dumped stream files with Double Sided disk data, I am not able to utilize the following commands to have Kryoflux to extract the data from stream:

-a<trk> : set side 0/a track0 physical position (default 0)
-b<trk> : set side 1/b track0 physical position (default 0)

Even though the stream files themselves contain the data, it seems the only remedy is to be forced to have to re-dump the disk making the stream file capture useless. Is this correct? :(

For preservation, I though the purpose of stream files were to blindly capture the raw flux in one pass (multiple revolutions in a preservation mode) where the stream files could be used to generate output formats later on. I can understand the reverse case where you couldn't pull data out of a stream file if the stream file was generated on a non flippy modified drive. However a stream file that was created via a flippy modified drive, I don't understand why the stream couldn't extract Side B of a Double Sided disk since the data is sitting there in the stream file.

Is this a short coming of the available commands to extract the data at this time through the DTC command lines?

In such cases, is the only path forward to re-dump double sided disks and to discard the Flippy captured preservation streams? Or are the other commands that can be used to extract the data? :?

User avatar
mr.vince
Posts: 2099
Joined: Tue Oct 05, 2010 5:48 pm

Re: Kryoflux Flippy Disk Preservation Commands

Post by mr.vince » Sun May 27, 2018 9:54 am

If I get this right you have a problem with the relative physical offset. This can't be changed later on, as you're setting the range when you are dumping the disk. I don't see how one could readjust tracks; you're dumping e.g. 80 tracks and you start relative to the original TRK00 signal. In this case if you work with -8, you're getting -8 to 71. It's of course not possible to change this later on as if you'd e.g. want to do -4 to 76, then you'd be missing the additional tracks (72 - 76).

Or am I getting this wrong?

JasonCA
Posts: 32
Joined: Tue Oct 11, 2011 3:37 am
Location: California

Re: Kryoflux Flippy Disk Preservation Commands

Post by JasonCA » Sun May 27, 2018 8:40 pm

mr.vince wrote:
Sun May 27, 2018 9:54 am
If I get this right you have a problem with the relative physical offset. This can't be changed later on, as you're setting the range when you are dumping the disk. I don't see how one could readjust tracks; you're dumping e.g. 80 tracks and you start relative to the original TRK00 signal.
Yes, I made mention to this in my previous post where I said:
I can understand the reverse case where you couldn't pull data out of a stream file if the stream file was generated on a non flippy modified drive.
If a STREAM was created via a non flippy modified drive, then data would not be contained where you could adjust the tracks to generate a FLIPPY disk. I agree with you: you'd miss the early tracks a FLIPPY disk.
mr.vince wrote:
Sun May 27, 2018 9:54 am
In this case if you work with -8, you're getting -8 to 71. It's of course not possible to change this later on as if you'd e.g. want to do -4 to 76, then you'd be missing the additional tracks (72 - 76).

Or am I getting this wrong?
However on a flippy modified drive, I am not sure where you are getting 71? I am sweeping physically from -8 to 82 on my dumps. Am I not (see dump example below)? And considering it's a Flippy drive, why would I not want to so if the drive if capable of it? After all, the goal is preservation.

According to your manual:
[] brackets indicate that the real value is different from the theoretical value. The first number(s) before the colon ‘:’ are the physical track numbers being processed as the drive sees them - the tracks we want to dump at the moment.

Here my drive is going from physical locations (-8.1) to (8.2):

Code: Select all

-8.1[00]: CBM DOS: OK*, trk: 001, sec: 21, * +12
to

Code: Select all

82.0    : CBM DOS: <unformatted>
The STREAM has therefore collected the full sweep of data.

Being a Flippy modified drive, wouldn't the drive be capable of physically covering the full range of a disk at all times if commanded to do so? In Flippy mode, the drive physically steps back as far as possible and then proceeds stepping forward until the drive reaches the physical end of the drive. That full physical range that is sweeps should be able to capture either a Flippy disk or a Double Sided disk in a STREAM, correct? ;)

I'd also like to point out, that since we are discussing end tracks being captured in the STREAM file, a lot of the time they may contain no data or simply be unformatted on a Double Sided disk. So even if I lost one or two tracks at the end, it may not be that big of a deal. However, the STREAM containing the full and complete sweep of tracks, it should be noticeable to Kryoflux if the end tracks had data or didn't to begin with.

Or, am I missing something?

Example of full sweep Flippy dump:

Code: Select all

-8.1[00]: CBM DOS: OK*, trk: 001, sec: 21, * +12
-6.1[02]: CBM DOS: OK*, trk: 002, sec: 21, * +15
-4.1[04]: CBM DOS: OK*, trk: 003, sec: 21, * +15
-2.1[06]: CBM DOS: OK*, trk: 004, sec: 21, * +5
00.0    : CBM DOS: OK*, trk: 001, sec: 21, * +13
00.1[08]: CBM DOS: OK*, trk: 005, sec: 21, * +4
02.0    : CBM DOS: OK*, trk: 002, sec: 21, * +14
02.1[10]: CBM DOS: OK*, trk: 006, sec: 21, * +12

... Continues with data on both sides

60.1[68]: CBM DOS: OK*, trk: 035, sec: 17, * +17
62.0    : CBM DOS: OK*, trk: 032, sec: 17, * +15
62.1[70]: CBM DOS: <unformatted>
64.0    : CBM DOS: OK*, trk: 033, sec: 17, * +13
64.1[72]: CBM DOS: <unformatted>
66.0    : CBM DOS: OK*, trk: 034, sec: 17, * +14
66.1[74]: CBM DOS: <unformatted>
68.0    : CBM DOS: OK*, trk: 035, sec: 17, * +15
68.1[76]: CBM DOS: <unformatted>
70.0    : CBM DOS: <unformatted>
70.1[78]: CBM DOS: <unformatted>
72.0    : CBM DOS: <unformatted>
72.1[80]: CBM DOS: <unformatted>
74.0    : CBM DOS: <unformatted>
74.1[82]: CBM DOS: <unformatted>
76.0    : CBM DOS: <unformatted>
78.0    : CBM DOS: <unformatted>
80.0    : CBM DOS: <unformatted>
82.0    : CBM DOS: <unformatted>
If the STREAM really contains the data for both a Flippy disk and Double Sided disk and my only coarse of action is to be forced to re-dump, then that to me is pretty sad that I am not able to convert to a format that would otherwise exist in the STREAM data. :(

brightcaster
Posts: 141
Joined: Fri Nov 08, 2013 10:48 pm

Re: Kryoflux Flippy Disk Preservation Commands

Post by brightcaster » Mon May 28, 2018 3:28 pm

I'm sorry to repeat myself again, but don't forget, that the drive is spinning the wrong direction on the second side if you read a flippy disk in a dual head drive (without flipping it).

So the data-stream has to be corrected (turned reverse) directly after you read a single track from the second side. I gues this is done directly after reading and before creating a streamfile (to make shure that the streamfile contains correct data).

That would mean that you have to know about flippy or dual side format before you create a streamfile! Otherwise the streamfile would contain wrong (reverse direction) data for the second side....

David

SomeGuy
Posts: 172
Joined: Wed Feb 18, 2015 8:18 pm

Re: Kryoflux Flippy Disk Preservation Commands

Post by SomeGuy » Mon May 28, 2018 8:00 pm

I don't have a flippy modded drive, so do not know exactly how this would work, but if you are saving a stream file while generating the .g64/.d64 file from this then it looks like you are using a "guided" stream dump. That has some differences from a preservation stream dump. For one, it looks like in the case of flippy disks it is omitting tracks that it thinks should not have data? (Or is this only because of the offset command?)

Perhaps try making just a preservation dump first. I *think* the kryoflux will then dump both sides on all tracks, but I am not sure. It looks like you might have to specify the offset commands for both heads and then specify more tracks.

Once you have a full preservation stream dump, then you can feed that stream dump back in to the Kryoflux software to decode to .g64/.d64 or whatever format.

I don't know how the track offset commands will react to stream file input, but if that does not work you could at least write a batch file to rename each trackxx.x.raw file to whatever the software expects.

The upshot of using a full preservation stream dump first is you can get ALL data in one pass and figure out what is on the disk later. The down side is it has no way to retry bad sector reads, aside from saving multiple revolutions. Usually the best thing to do is decode right after making the preservation dump, and then redump again if there are bad sectors. However, that can be a headache if there are lots of bad sectors.

Although, the sad truth is you do have to know a bit about what is on the disk to ensure it is dumped properly. This is especially true of 5.25" disks where disks can be 48TPI, 96TPI, 100TPI, high density, or low density sometimes with no visible clues. If these don't match, then the dump will be worthless.

User avatar
mr.vince
Posts: 2099
Joined: Tue Oct 05, 2010 5:48 pm

Re: Kryoflux Flippy Disk Preservation Commands

Post by mr.vince » Tue May 29, 2018 7:46 pm

For the avoidance of doubt: what kind of flippy mod is this? Panasonic or Newtronics?

Post Reply