Floppy Recovery Case Study #3 – 2S/HD No Go
This is why you never should use 2S/HD floppies in a Commodore Vic20/64/128 environment.
I have chosen to focus my work on two floppies since they both carry the most common issues when it comes to force-write with a VC-1541 onto HD-Floppies.
When we analyze the actual floppy-disc we see there are some really nasty scratches on it. Those scratches would have in a normal scenarion occurred from either dirt in the sleeve or badly stored.
However in this case the sleeve is smooth and had no indications of this at all. So the under-laying problem is when the VC1541 is writing to a HD floppy it will try to write over several of tracks at once. Which will cause mixed TPI error. A HD contains more 96tpi than a DD floppy that contains 48tpi. This is not a good starting point but it gets worse when the VC1541 is trying to read from the floppy.
In this case someone had already tried this and we can se the result and yes it’s looking really bad.
When zooming in we can see this is bad and the error/errors are nasty. Note: NEVER EVER USE HD floppies with a VC1541! You’re just making problems which are a pain to deal with.
Due this is an extremely time consuming task I have only focused on track 27, to give you an idea how much work and time there is to it.
The first read with 40 retries still show there are errors left to be dealt with.
The second reading is not better and even more errors remains. Keep in mind every reading is saved as a separate file, which will be dealt with in the final process.
In this reading I have switched from fast-read to original-read -speed. This is due I want to have different readings using different methods. Everything to get as much data as possible. As we can see the first sector is actually read now! So it means we’re on our way.
Here we can see we finally succeeded to get a 100% copy of track 27. 100% of the data is rescued and saved to file.
To get a better visual understanding we clearly see the red mark show different values from the individual reads. This is why I had to re-read this track many times to finally get 100% results. Also the readhead was going crazy from time to time but no damaged was done!
The data is read and yes this is an exact copy of track 27. In order to complete the task I had to make many different track reads to be able to combine them all into 35 tracks, which is the standard of a c64 floppy image.
To get a better understanding and well document which errors to keep track on. I wrote them down. The more info and data we have the easier it will be to get the massive work done.
The underlined numbers are where the errors are and are the tracks we need to work on. The circled numbers are 100% okay.
As we still ca see there are lots of work to be done and we just need to continue!
To really show the process and get a vivid understanding what’s going on. We can see 7 blocks/sector are being read but 6% are missing -“Back to school baby!”. Did I tell you this took time?
Sure one side seem to look great and this should go smooth.
However, the other side is not looking too great.
Yet again, we see the horrible scratches and we know what to do and we also know how to determine the problems. Let’s go!
As a matter of fact this was even worse than the other floppy and took ages to get done with. Track 30 on Side A was totally unreadable. NEVER use HD floppies….just saying when you have it in your face.
Yes I made it! Even if the way to get here was one heck of a massive work it was possible. But to be honest this is indeed one of the hardest work I ever done! So think again before throwing your floppies away! You CAN do it, if you just know HOW to do it. So don’t be the one to judge what to do and not to do, leave it to a professional like me. See what I mean 🙂
Here are all the raw files needed to be combined into ONE .d64 image.
Let’s analyze a bit what’s going on.
The “zeta_01b.d64” and “Zeta_2a.d64” files are written via Kryoflux to be used as a reference. The image could not be used due artifacts when reading from too “new hardware”, it simply misread the tracks and sectors.
The TR files are separated Tracks to be used to combine into a whole .d64 file. All of the files were written via openCBM + XUM1541+.
The 1-1 and 2-2 files are half files of the actual floppy image. This due limitation in the D-64joiner software. Once again it’s all about to be that “Clever and Smart”, to accomplish the goal!
Never use 2S/HD floppies when you wish to write data from a VC1541 and never try to read them back, if you’re not sure how to do it.
Have a nice day and keep your data safe,
(C)2017 Xiny6581 – 25/5-2017