| |
ws
Registered: Apr 2012 Posts: 249 |
Repair/Retrace Floppy Image
I read it somewhere here out of the corner of my eye that someone recently released a tool that tries to follow block chains on a floppy image that is broken and tries to piece together what is possible to reconstruct.
I would really love to try that tool because i have an image of a floppy that contains files that would be great to look at, even if parts of it were broken.
Currently the files cannot even be loaded (actual read error) and for very very difficult reasons i cannot try and read the image again, though i believe i got the best dump of it.
Any ideas? |
|
| |
Acidchild
Registered: Jan 2002 Posts: 470 |
did you try to clean the magnetic disc on water already? |
| |
Krill
Registered: Apr 2002 Posts: 2940 |
You might refer to D64scan V0.3 or cc1541 V4.0 (specifically the -R restore option).
Both operate on .d64, though, and thus only on the higher filesystem level.
If you have a .g64 or other low-level image with broken sectors, try to fix those first and convert to .d64. |
| |
ws
Registered: Apr 2012 Posts: 249 |
@krill yes! thanks.
@Acidchild: is that seriously an option?
Good news is, i actually have access to the original disk and can try imaging it with a few drives. The question is, since i only own a Zoomfloppy for transfer to PC, is there a strategy to image a disk on the C64? Like have the disk read by a sophisticated custom reader and have the disk image stored in some compressed format on the C64 and then transfer it to PC? Something like that? Or is Zoomfloppy sufficient, regarding disk-drive-hardware-access?
Then i have another question: when the kernel floppy routines decide where to put the next block - is that always pretty random depending on how the prior contents of the disk look? Or is it, that if one analyzed the block-chains of many disks, would there be a certain pattern of block distribution from which one could try and guess where a next block would be, if the current block has an error, but the previous one(s) was/were okay? |
| |
Krill
Registered: Apr 2002 Posts: 2940 |
Quoting ws@Acidchild: is that seriously an option? Is. I'd suggest distilled water, though.
Quoting wsOr is Zoomfloppy sufficient, regarding disk-drive-hardware-access? Making flux-level images (16 MHz sample rate) with Zoomfloppy or similar gives you the best chances to repair broken sections, actually. :)
I'd certainly trust it more than anything running natively, as it doesn't have 1 MHz 6502 restrictions and is tried and tested for copy protections.
Quoting wsThen i have another question: when the kernel floppy routines decide where to put the next block - is that always pretty random depending on how the prior contents of the disk look? Or is it, that if one analyzed the block-chains of many disks, would there be a certain pattern of block distribution from which one could try and guess where a next block would be, if the current block has an error, but the previous one(s) was/were okay? When saving files sequentially, the resulting layout is rather predictable.
But once fragmentation becomes an issue (deleting files and saving differently-sized files over them), the layout becomes rather random. Many work disks from native setups exhibit fragmentation of varying severeness. :) |
| |
hedning
Registered: Mar 2009 Posts: 4702 |
If you get multiple reads of the (unprotected) disk, you can always use PyD64Fix V1.2 to combine the different reads: This "program [...] tries to combine several d64 images of the same physical floppy, into one image with less or without errors. Error detection is based on errormap part of d64." |
| |
Krill
Registered: Apr 2002 Posts: 2940 |
Quoting wsone could try and guess where a next block would be, if the current block has an error, but the previous one(s) was/were okay? Also note that a broken block is basically never broken completely (all 256 payload bytes of it), but only in parts so the checksum won't match. The T/S link may well be intact on a broken block. |
| |
Acidchild
Registered: Jan 2002 Posts: 470 |
I've transfered thousands of disks already and many of them were really dirty,so cutting off the disc and cleaning the magnetic disc with water is always an option. Yes,plain water is okay.done that so often already. |
| |
hedning
Registered: Mar 2009 Posts: 4702 |
Quote: I've transfered thousands of disks already and many of them were really dirty,so cutting off the disc and cleaning the magnetic disc with water is always an option. Yes,plain water is okay.done that so often already.
+1. Luke warm water and some washing-up liquid... wash off and let the disk dry on a clean tissue.. Put it in a clean disk sleeve and off you go. Repeat if necessary. My wife always love when I fill the kitchen with old disks. Not. Totally worth it? Yes. |
| |
ws
Registered: Apr 2012 Posts: 249 |
Awesome, guys! Thanks! Making more images on different drives right now. Later i will consider the disk cleaning. The BAM looks suspicious though, as if the errors followed a physical line on the disk surface? -pic-
d64scan gives me tons of garbage chunks currently, but very nice tool anyways!
@krill: just a guess - making a flux level image ... is that even possible with XUM1541 via USB? Even thinking of putting parallel cables into my drives and having to solder some whack connector makes me break in sweat.
Just a short timesaver for anyone who wants to try PyD64fix and has not yet any or python > v3.1 installed, here are two links that might make your life alot easier (if you are on Win10):
https://www.python.org/downloads/release/python-2718/
(later python3 versions have some changes in syntax, so loading disks is impossible)
https://www.lfd.uci.edu/~gohlke/pythonlibs/#pyqt4
(first pip install wheel, then install the pyqt4..... .whl with pip --> then, the gui mode works)
PS: All this is about a disk/image i got from a certain person a few years ago and the large-stack-of-floppies digitizing session ended with very sadface, because a program of personal value they programmed as a very young teenager is on the disk. The disk holds the only copy, ofcourse. |
| |
Krill
Registered: Apr 2002 Posts: 2940 |
Quoting wsAThe BAM looks suspicious though, as if the errors followed a physical line on the disk surface? -pic- Indeed, looks like there should be a scratch right across the disk somewhere.
Or maybe the disk was demagnetised around the head access hole at some time.
Quoting ws@krill: just a guess - making a flux level image ... is that even possible with XUM1541 via USB? Even thinking of putting parallel cables into my drives and having to solder some whack connector makes me break in sweat. Sorry, mixed it up with KryoFlux/Greaseweazle. So with ZoomFloppy, you should be able to create .g64 images with a 1570/71 or a parallel cable on a 1541.
.d64 is probably too high-level to properly repair. |
... 3 posts hidden. Click here to view all posts.... |
Previous - 1 | 2 - Next |