|
24 February 2010, 01:32
|
#1 | ||
|
Registered User
Join Date: Jun 2005
Location: US / A
Age: 49
Posts: 134
|
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: Quote:
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 Quote:
|
||
|
|
24 February 2010, 10:29
|
#2 |
|
Moderator
Join Date: Jan 2003
Location: ...
Age: 52
Posts: 1,838
|
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 Last edited by IFW; 24 February 2010 at 14:59. |
|
|
|
24 February 2010, 11:12
|
#3 | |
|
Precious & fragile things
Join Date: Feb 2009
Location: Victoria, Australia
Posts: 1,946
|
Quote:
That's good for business and bottom line. My two cents. |
|
|
|
|
24 February 2010, 11:40
|
#4 |
|
Moderator
Join Date: Jan 2003
Location: ...
Age: 52
Posts: 1,838
|
Agreed, just this thread was meant to be for announcements
 Maybe open a new, support oriented one? |
|
|
|
24 February 2010, 14:53
|
#5 |
|
Moderator
Join Date: Jan 2003
Location: ...
Age: 52
Posts: 1,838
|
Edit: old support related posts have been moved here - so this is the right thread to post your questions
|
|
|
|
24 February 2010, 14:55
|
#6 |
|
Cheesy crust
Join Date: Nov 2008
Location: Hawk's Creek
Age: 48
Posts: 1,383
|
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... |
|
|
|
25 February 2010, 02:06
|
#7 | |||
|
Registered User
Join Date: Jun 2005
Location: US / A
Age: 49
Posts: 134
|
Quote:
 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' Quote:
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: 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. Quote:
|
|||
|
|
|
25 February 2010, 09:27
|
#8 |
|
Moderator
Join Date: Jan 2003
Location: ...
Age: 52
Posts: 1,838
|
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. |
|
|
|
25 February 2010, 10:51
|
#9 |
|
Moderator
Join Date: Jan 2003
Location: ...
Age: 52
Posts: 1,838
|
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. |
|
|
|
25 February 2010, 11:19
|
#10 |
|
Moderator
Join Date: Jan 2003
Location: ...
Age: 52
Posts: 1,838
|
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. |
|
|
|
29 April 2010, 18:18
|
#11 |
|
Cheesy crust
Join Date: Nov 2008
Location: Hawk's Creek
Age: 48
Posts: 1,383
|
FYI:
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. |
|
|
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | |
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Winuae Kryoflux support | Joe Maroni | support.WinUAE | 19 | 04 September 2013 14:36 |
| KryoFlux: IPF write support | mr.vince | News | 160 | 18 March 2012 10:07 |
| KryoFlux: IPF write support | mr.vince | project.SPS (was CAPS) | 0 | 07 July 2011 12:41 |
| WindowsKiller's HOL data problems thread | derSammler | HOL data problems | 32 | 06 December 2005 11:50 |
| Misc Comments from old support thread | Marcuz | project.ClassicWB | 2 | 17 May 2004 21:05 |
|
|
