English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   project.SPS (was CAPS) (http://eab.abime.net/forumdisplay.php?f=45)
-   -   KryoFlux Support Thread - post all your problems here (http://eab.abime.net/showthread.php?t=51167)

billy 24 February 2010 01:32

KryoFlux Support Thread - post all your problems here
I've started some work looking into reading 5-1/4" flippy disks and have a few questions. I'm not sure if this is the best place to post the questions.

I pulled a few different 5-1/4" drives that are known to have been working on IBM compatible systems and have attached them to the KyroFlux beta 3 installation I have. Each drive provides its own interesting results.

The first drive a Mitsubishi MF504C-318U seems to read disks but with some speed problems:


D:\kryoflux_1.0b2\dtc>dtc -m2 -y -f1541/GEOS.Side1.1 -g1 -i6 > GEOS.Side1.1.log
28.1 : Drive speed problem detected
34.1 : Drive speed problem detected

D:\kryoflux_1.0b2\dtc>dtc -m2 -y -f1541/GEOS.Side1.2 -g1 -i6 > GEOS.Side1.2.log
34.1 : Drive speed problem detected

D:\kryoflux_1.0b2\dtc>dtc -m2 -y -f1541/GEOS.Side1.3 -g1 -i6 > GEOS.Side1.3.log
02.1 : Drive speed problem detected
74.1 : Drive speed problem detected

D:\kryoflux_1.0b2\dtc>dtc -m2 -y -f1541/GEOS.Side1.4 -g1 -i6 > GEOS.Side1.4.log
44.1 : Drive speed problem detected
48.1 : Bad sector found

D:\kryoflux_1.0b2\dtc>dtc -m2 -y -f1541/GEOS.Side1.5 -g1 -i6 > GEOS.Side1.5.log
26.1 : Drive speed problem detected
40.1 : Drive speed problem detected

D:\kryoflux_1.0b2\dtc>dtc -m2 -y -f1541/GEOS.Side1.6 -g1 -i6 > GEOS.Side1.6.log
42.1 : Drive speed problem detected

D:\kryoflux_1.0b2\dtc>dtc -m2 -y -f1541/Testdrive.Side0.0 -g0 -i6 > Testdrive.Side0.0.log
14.0 : Drive speed problem detected
62.0 : Bad sector found

D:\kryoflux_1.0b2\dtc>dtc -m2 -y -f1541/Testdrive.Side0.1 -g0 -i6 > Testdrive.Side0.1.log
62.0 : Bad sector found
64.0 : Bad sector found

D:\kryoflux_1.0b2\dtc>dtc -m2 -y -f1541/Testdrive.Side1.0 -g1 -i6 > Testdrive.Side1.0.log
56.1 : Bad sector found
60.1 : Drive speed problem detected
Similar results are seen reading side0 or side1.

Which brings up the first question, what is the best mechanism to calibrate a flippy drive prior to use? And should the calibration process be run prior to each read or will the calibration persist? I presume calibration needs to be run prior to each side0 vs side1 change?

I've run the following command, but I'm unsure of the actual usage, D:\kryoflux_1.0b2\dtc>dtc -f1541/calbration1 -g0 -c1 -i6

The next drives a CHINON FZ-502 (Rev.C) and a CHINON FR-506 (Rev.B) using the same or any other cable I have, reject the control codes sent from the KryoFlux


D:\kryoflux_1.0b2\dtc>dtc -f1541/calbration1 -g0 -c1 -i6
KryoFlux DiskTool Console, v1.00 beta 3, uiv.1, Feb 18 2010
(c) 2009-2010 Istvan Fabian, Softpres, www.softpres.org
Licensed for private, non-commercial use only.

00.0 : Control command rejected by the device
00.0 : Control command rejected by the device
00.0 : Control command rejected by the device
00.0 : Read operation failed

D:\kryoflux_1.0b2\dtc>dtc -c2
Control command rejected by the device
CM: maxtrack=0
Any thoughts on either of these symptoms?

IFW 24 February 2010 10:29

KF detects all sort of problems automatically and tries to work around them if it can. You'd still get these reported fyi.

1, Signal problems, or drive problems.
Check cabling, use a shorter one if you can.
Note, that you can get away with this as long as you don't see a "Read operation failed" message the read was actually good, DTC automatically retries bad reads on each track according to the number set with the -t command - the default value is 5 times.

2, The drive is simply not connected properly, could be for example the cabling reversed for drive0/1, a jumper on the drive, lose connection, failing to power the drive properly etc.
The board firmware tried to control the drive, but it failed to respond within a few tries. As a result the board tells the host that it cannot control the drive attached - or actually there is no drive properly/attached. A command is rejected when it does not change the state of the system, in this case probably the drive couldn't seek to track 0 within any reasonable time.
You could check if the motor is actually on when this happens, drive led is lit then turned off etc, but something is definitely wrong.

You can get a detailed log of what commands and results were reported exactly by enabling the output of device level communication. Add 1 to the -l command value. Ie 15 if you used 14 before.

Track read calibration is recommended to be run when you try a new drive or if you think there is a problem.
You should however run maximum track calibration before using a new drive to ensure that you don't try to seek beyond the point that the drive is really capable of. It is highly recommended to only use drives that report back 83 (ie they can use 84 tracks) in track calibration mode.

Edited to reflect that this is the right thread to post these questions

Loedown 24 February 2010 11:12


Originally Posted by IFW (Post 645453)
This thread may not be the best place to discuss in detail, but feel free to contact directly or at:

Quite the contrary, Istvan, one of the reasons why Catweasel never took off is that problems are essentially ignored, the simple fact that you've come along and addressed all the issues raised here shows that SPS / Kryoflux is a project that won't be ignored.

That's good for business and bottom line.

My two cents.

IFW 24 February 2010 11:40

Agreed, just this thread was meant to be for announcements :)
Maybe open a new, support oriented one?

IFW 24 February 2010 14:53

Edit: old support related posts have been moved here - so this is the right thread to post your questions :)

mr.vince 24 February 2010 14:55

Here it is... ;)

I know these errors from when I forget to power the drive. It could be the drive has problems with the signal levels because the ATMEL only outputs 3.3V, not 5. This behaviour was expected to some degree and therefore gets addressed in the manual.

What you could do is actually wire open collector level shifters between the ATMEL and the drive...

Another option would be getting a complete unit pre-assembled...

billy 25 February 2010 02:06

1 Attachment(s)

Originally Posted by IFW (Post 645557)
Edited to reflect that this is the right thread to post these questions

Thanks for all your effort and for moving my question where it needed to go. :great

I think there may very well be an issue with the jumpers or other configuration of the CHINON drives, but I haven't found the solution yet. When I attempt to calibrate a CHINON on the Kryoflux, the drive is at rest and once I send the command to the drive the motor starts to spin and a few more commands are received, but the entire process fails with a 'Control command rejected by the device'

dtc>dtc -l15 -c2

v1.4 Nov 10 2004 14:49:33

000007da: status=0
000007ee: status=0
00000802: reset=0
00000c44: descriptor=C2 DiskSystem/version=1.00/date=Jan 3 2010/time=20:54:07
00000c58: density=0
00000c6c: min_track=0
00000c80: max_track=83
00000c94: motor=1
00000fa5: side=1
00000fb9: track=65535
Control command rejected by the device
CM: maxtrack=0
000010f4: motor=0
Now on to something more dear to my heart.
I was a C-NET and Image sysop for years back in the 80's and 90's. I still have all my originals but some of them are physically damaged. I know the media is tweaked, see here: Attachment 24363

What in your opinion is the best mechanism using KryoFlux to extract and keep whatever is left of the bits on whats left of the media?

In the case of my C-NET 64 DS-2 original, if I read the data twice, it comes back with two different .d64's and the files in the image are truncated at different locations. I don't hold KryoFlux responsible, on the contrary, I just want to know how to preserve the most of what I have for future manual retrieval.

7521f03340a09405474957edf317c143 *C-NET64.BBSvDS-2SerialOriginal1xxx.read2_s0.d64
6f1c66034de33d8040b1b32472645414 *C-NET64.BBSvDS-2SerialOriginal1xxx.read2_s1.d64
d5781a1fc156b4d67640db2e7735485a *C-NET64.BBSvDS-2SerialOriginal1xxx_s0.d64
6a3cbbfc70df57dceeb9387c3a09b31c *C-NET64.BBSvDS-2SerialOriginal1xxx_s1.d64
Thanks again for your work, maybe something good will come from these damaged media tests.

IFW 25 February 2010 09:27

1, Yes, the log confirms that the drive does not seek, or the track0 signal is not working.

2, Are you talking about real professionally duplicated originals or disks created by yourself?
For duplicated originals the only preservation I could recommend is to generate stream files for later analysation.
For user generated disks D64 is fine.

Note; the only way the KF would generate different D64 files at all is if it can sometimes read more or less data compared to other attempts.
CBM's drive firmware and most transfer programs that depend on that tend to replace illegal GCR nybbles with FF. Eventually they just match the very weak xor based checksum.

KryoFlux's host software does not work that way.
It verifies each and every nybble individually to be a legible GCR code and if it is not, even if the checksum is ok, the sector is marked bad - which is the right approach given how weak the checksum is.

I'll post a bit later about how to get the best read out of the disk.

IFW 25 February 2010 10:51

Just two additional notes:
- disks like that would surely signal drive speed problems as well if they can't be rotated properly
- all Apple DOS/firmware code (and again any application that uses that code e.g. to transfer disks) uses the same approach as well replacing bad data with some other values, resulting in eventually "good" reads - while in fact they are bad.
KF's host software checks nybble validity in the case of all Apple formats as well, just like it does with CBM.

IFW 25 February 2010 11:19

For a better chance of getting a good read:
- you could try and set the number of revolutions to sample to a higher value, e.g. for 5 samples -r5
- set the number of retries per track to a higher value, e.g. for 10 retries -t10

Changing the default values (especially -r as that is not conditional on the read being good or not) can significantly increase the time it takes to image a disk.

You can make the output much easier to read if you are looking for errors in an image by using -l8, restricting output to the format analyser results only.
As long as you are seeing OK for a track it's perfectly good. If you see OK* then the read is good, but there are things that might need your attention. Usually that means the track contains deviations from the expected format (that the image created can't fully represent, such as different ID values for sectors, changed track numbering and the like), however the data itself is error free.
The GUI version will give you a summary, but I am considering adding a simple summary to the console version as well at a later beta stage.

I'd also recommend creating stream files from bad disks, those could be used for data recovery at a later time - they are quite big though, so only recommended for bad disks (that have any value) and original duplicated disks, where they are mandatory for preservation.

mr.vince 29 April 2010 18:18


The "old" schematics included with the beta have a "bug". The write protect line is not present. This needs to be addressed.

If you're into etching something, please wait for the next beta which will include information on what needs to be changed. Changing the old schematics is not planned atm, as we're already working on new ones with our hardware partner.

All times are GMT +2. The time now is 22:43.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.

Page generated in 0.04251 seconds with 11 queries