Reading 2040 disks on a Catweasel

I recently hooked up my Catweasel Mk3 that I bought some time ago, and have been able to read a number of my old 1541 disks, so I will be making some of my old software available online soon.

However, it seems to get all errors when reading my PET disks, which were written by a 2040 ieee488 dual disk drive. The 2040 was roughly compatible with the 1541, in that you could read the disks it wrote on the 1541, though it was recommended not to write to 1541 created disks on a 2040 and vice versa.

But the catweasel acts as though there is nothing on the disks at all. Can't ID them, all tracks read as errors. The 1541 disks I tried read so clean I am surprised. Is it possible that 2040 disks just degraded over the 30 years while the others did not, or does the CW driver have some problem with 2040 family disks?

Doubtful. What does a histogram show?

Unlikely

Unlikely

Which one is unlikely? That the disks have failed, or that the CW driver has trouble with 2040 disks that it does not have with 1541?

Which histogram do you mean, the one of the blocks on the disk from a failed read, or the "signal" one?

For most of the disks, the block map is 100% red, all failed. However, I just did a disk which is showing one stripe of green (track 0) and a mix of dark red, light red and a couple of yellows in track 1. So that is a partial read. However, I can't be dead sure what drive wrote some disks, but this one does seem to be a 2040 one. So it may just be those disks don't live this long.

It's unlikely the disks have failed (unless they've been intentionally erased). The histogram from the failed read would help. (I mean the time-domain histogram that you get with the Linux cwtools).

Floppy data, particularly 5.25" data, doesn't just evaporate.

I'm a wuss

I'm a wuss

I put the catweasel into a dual boot machine and tried it first in WinXP because to run it in linux I need to compile the thing into the kernel which is more work. I guess I will try it later in linux and see what happened. I tried telling it to use 48tpi and then back to 96tpi on one disk and even though the disks are 96tpi that made it read one PET disk all green, so perhaps these disks really did fade in the garage for so many years.

I have a few PET floppy disks that at first attempt to read them appeared to be completely blank. I tried a 3040, a 2031 and a 1541-II, various initialization commands. Suddenly part of the directory appeared, and last time I tried almost (!) all files from the floppies would read off a 1541-II connected to a PC with the XM-1541 cable.

The 2040 stores 35 tracks on a 48 tpi disk so that setting seems correct. Even if you use a 96 tpi QD floppy disk, the data is still recorded at the lower density. Perhaps you are mixing up with the 8050, 8250 drives which store 77 tracks on a 100 tpi disk?

Are you sure that you're not dealing with 8050 or 8250 drives? Those use a 100 TPI format.

Well, to the best of my recollection, though it's been 30 years, I only had a 2040 (though I may have rom upgraded it to 4040) and the 1541. When I was developing PAL and POWER for the C64, I tended to do it on the PET, and write out disks on the 2040 which I could then read in the 1541 and try on the C64. C64 was too annoying a keyboard to develop on.

Later, I moved things to a Unix machine and I wrote an assembler in C, and then had it transmit the binaries into the C64 over a serial port I got for it. Alas, a lot of that is lost on hard to read QIC tapes now. (I try to read them but it breaks their elastic.)

I will give a whirl at the 8050 format, but it doesn't find it in detect mode. Who knows, the memory is a blur and maybe I had an 8050 at some point. The 2040 is sitting in the garage. I could dig out it an the PET and see if they still run but even if I read the disk I have no way to get it off the PET, except I guess writing another disk on the 2040.

100 tpi drives are pretty scarce on the ground. Do you have any?

Reads fine on linux

Reads fine on linux

Well, I was able to read the 2040 based disk with cwtools on linux with no errors.
(Well, almost. The cw driver fails to install because Individual re-used a bus ID from an ISDN card, and the driver for that card installs and blocks the cw driver. You have to remove the "netjet" driver for this "Tiger Jet" card and then cw can be loaded.)

So linux is the way to go. Though one thing that the Windows tools have that is handy is a disk detect mode. Anybody written a tool like that for linux, one which reads the first few tracks and sides, figures out what kind of disk it is (from a subset list) and then reads and stores an image of the disk?

That would be handy to make a bulk floppy scanning station. If I had that, I would probably hire a teen-ager to just feed in my thousands of old floppies. Of course to get really fancy, you would want a tool that does not need keyboard operation, it detects when the door has closed and a new floppy is present, and beeps to say when it's been read (or if it got errors and should go into the not-yet-read pile). And to be perfect at this, it would support two drives so you could be changing the one disk while reading the other.

If such a tool existed it would be handy to make stations to do that in various cities so people could come in with their old boxes of floppies and all that old stuff could be preserved. I figure you could read several per minute if it were done right.

But for now it seems there is a bug in the Individual windows drivers that makes them not understand the 2040's floppies.

I use a DOS utility that I wrote that scans track by track and simply stores 128KiB of sample data in a file. It's about as accurate a representation as you can get. Interpreting the sample data is left to the user...

Yes, sounds like it can be done but is some work.

I spoke too soon on my luck. Some of the PET disks now scan fine but others are showing odd problems. I have one with bad tracks on the inside and outside (but all errors on tracks 0-4 and errors on the inside too, with one borderline track with partial errors.) That may just be a bad disk, I guess, but I saw some odd pattern to them. The directories are in the center so they read OK but of course some of the files are damaged.

Some disks don't read at all, though, just like before. Some might be Apple ][ disks. I tried the "mac_5.5" profile (16 sectors, single density) but get all errors there too so I wonder if there is something different there. I have a small number of Apple ][ disks, a fair number of pet/2040 disks, Various 1541 C64 disks, Atari 800 floppies (just a few), tons of PC 5.25s 360k and 1.2m, tons of xenix 720k DSDD5.25s and 1.2Ms, and then rafts of PC and Atari ST 3.5s. Yikes. So how do I interpret a cwtool histogram?

FM disks typicall show two peaks--at n and 2n intervals. MFM disks show three at n, 1.5n and 2n intervals. GCR generally show 4 or more, depending on the modulation details, roughly equally-spaced. Apple II disks qualify as GCR and will show either 2 peaks or 3 peaks at n, 2n and 3n, depending on the Disk II sequencer ROM used (5 of 8 or 6 of 8 encodings) with n = 500 nsec.

Consider that you may have an out-of-alignment drive on the 2040 that created some of those floppies.

That was known to happen in the old days, and sometimes you got a disk to do better by opening and closing the door etc. So the histogram is showing some sort of location for where transitions were found? On the 4n tracks I see these peaks sometimes very sharp sometimes a bit rounded, and on the 4n+2 tracks I see broad rounded things which seems right. I don't suppose anybody ever went so far as to write a reader that read the odd tracks as well to look for mis-alignment, possibly combining tracks together to find out what was there? I don't think I have anything so crucial as to call for that, but it would be cool. I mean today's computers have so much space and speed that you could just read the thing as a dense analog recording and fix it all in software. Obviously the expensive data recovery guys do that some of the time. I'll report back when I learn more.

Some "fixing" is necessary, even when you copy a disk back, due to aliasing. I'll guarantee that if you tot up all of the Catweasel intervals reading index-to-index that they don't match the rotational period.

Recovery is less an analogue process than it is using "smarts", since digital recording is pretty much a saturation affair. However, when alignment gets off, a lot of residual noise gets picked up and makes the recovered signal look pretty cluttered.

The high-potency data recovery rigs for floppies (probably all trashed by now) use a non-contact process where the medium is coated with a colloidal iron suspension, such as Magnasee and read using a laser. Very cool and extremely slow.

There have been 5.25" drive mechanisms made that use a double-stepper arrangement ("coarse and fine") to accurately place the heads (e.g. Drivetec), but this does nothing to help with azimuth issues. You could probably rig up an affair yourself using a precision reduction drive driven by an external stepper coupled to the existing head carriage.

I've wondered about cannibalizing an Iomega Bernoulli drive as a way to perform non-contact reads on floppies... But the bottom line is that floppy drives were constructed primarily to afford low-cost storage and the construction reflects that.

Here, by the way are some examples of disks with problems. This disk reads fine in the center but the edges are 100% read error with a borderline transitional track. That doesn't sound like an aging problem, is it perhaps alignment and is there something that could be done about that?

reading track 0 try 0 (sectors: good 0 weak 0 bad 21) (/dev/cw0raw0)
reading track 4 try 0 (sectors: good 0 weak 0 bad 21) (/dev/cw0raw0)
reading track 8 try 0 (sectors: good 0 weak 0 bad 21) (/dev/cw0raw0)
reading track 12 try 0 (sectors: good 0 weak 0 bad 21) (/dev/cw0raw0)
reading track 16 try 0 (sectors: good 0 weak 0 bad 21) (/dev/cw0raw0)
reading track 20 try 0 (sectors: good 0 weak 0 bad 21) (/dev/cw0raw0)
reading track 24 try 0 (sectors: good 0 weak 0 bad 21) (/dev/cw0raw0)
reading track 28 try 0 (sectors: good 0 weak 0 bad 21) (/dev/cw0raw0)
reading track 32 try 0 (sectors: good 0 weak 0 bad 21) (/dev/cw0raw0)
reading track 36 try 0 (sectors: good 0 weak 0 bad 21) (/dev/cw0raw0)
reading track 40 try 0 (sectors: good 6 weak 0 bad 15) (/dev/cw0raw0)
reading track 44 try 0 (sectors: good 21 weak 0 bad 0) (/dev/cw0raw0)
reading track 48 try 0 (sectors: good 21 weak 0 bad 0) (/dev/cw0raw0)
reading track 52 try 0 (sectors: good 21 weak 0 bad 0) (/dev/cw0raw0)
reading track 56 try 0 (sectors: good 21 weak 0 bad 0) (/dev/cw0raw0)
reading track 60 try 0 (sectors: good 21 weak 0 bad 0) (/dev/cw0raw0)
reading track 64 try 0 (sectors: good 21 weak 0 bad 0) (/dev/cw0raw0)
reading track 68 try 0 (sectors: good 19 weak 0 bad 0) (/dev/cw0raw0)
reading track 72 try 0 (sectors: good 19 weak 0 bad 0) (/dev/cw0raw0)
reading track 76 try 0 (sectors: good 19 weak 0 bad 0) (/dev/cw0raw0)
reading track 80 try 0 (sectors: good 19 weak 0 bad 0) (/dev/cw0raw0)
reading track 84 try 0 (sectors: good 19 weak 0 bad 0) (/dev/cw0raw0)
reading track 88 try 0 (sectors: good 19 weak 0 bad 0) (/dev/cw0raw0)
reading track 92 try 0 (sectors: good 19 weak 0 bad 0) (/dev/cw0raw0)
reading track 96 try 0 (sectors: good 2 weak 0 bad 16) (/dev/cw0raw0)
reading track 100 try 0 (sectors: good 0 weak 0 bad 18) (/dev/cw0raw0)
reading track 104 try 0 (sectors: good 0 weak 0 bad 18) (/dev/cw0raw0)
reading track 108 try 0 (sectors: good 0 weak 0 bad 18) (/dev/cw0raw0)
reading track 112 try 0 (sectors: good 0 weak 0 bad 18) (/dev/cw0raw0)
reading track 116 try 0 (sectors: good 0 weak 0 bad 18) (/dev/cw0raw0)
reading track 120 try 0 (sectors: good 0 weak 0 bad 17) (/dev/cw0raw0)
reading track 124 try 0 (sectors: good 0 weak 0 bad 17) (/dev/cw0raw0)
reading track 128 try 0 (sectors: good 0 weak 0 bad 17) (/dev/cw0raw0)
reading track 132 try 0 (sectors: good 0 weak 0 bad 17) (/dev/cw0raw0)
reading track 136 try 0 (sectors: good 0 weak 0 bad 17) (/dev/cw0raw0)
35 tracks read (sectors: good 267 weak 0 bad 416)

The histogram is attached from a the raw_14 profile (should I use raw_14i or just the 1541) On tracks 40 and 96 it's not a contiguous block of good sectors.

Hmm, can't attach but the histogram is at:

http://www.templetons.com/debug/hist-2040-middleok.gz

If you are curious I have put some other histograms of unreadable disks up, one that is marked "pet program pack" and thus should be 2040, and another marked "apple checkers" which should be an apple 2 disk but could possibly be a pet one. They are in http://www.templetons.com/debug

Without spending a bunch of time on your data, have you considered that perhaps these are 100 TPI floppies? The on-again/off-again nature of the histograms seems to suggest that as a possibility.

Chuck(G) said:

Without spending a bunch of time on your data, have you considered that perhaps these are 100 TPI floppies? The on-again/off-again nature of the histograms seems to suggest that as a possibility.

Click to expand...

Sure looks like it to me, but although this is the third time you've mentioned it we haven't heard from the OP...

Once more: 8050/8250 disks and drives are incompatible with pretty well everything and can NOT be read with the same drive as the other CBM or Apple disks, regardless of what software you're using! Only a 100TPI drive like an 8050/8250 will read 'em.

As I said before, while it's not impossible that the brain can develop holes after 30 years, I don't believe I ever had an 8250, or in particular used it for this purpose. These disks in particular were used for transfer from Pet to C64 and so would not have been in that format. And the ones which have the middle of the disk being OK are obviously not 100tpi because I am reading the middle of the drive fine, at regular density, single sided, and the directory is recovered. The disks that I can't read at all are another matter, I don't yet know if they are PET or Apple (or perhaps even Atari 800 5.25) but I will keep at it. The Windows CW driver has the autodetect mode but it fails to detect them. It uses the first few tracks (outer tracks presumably) and it could be that if those went bad, the autodetect can't handle it, while it would autodetect more correctly from the center. Didn't the PET/1541 write out from the center?

Sorry; like Chuck, just trying to rule out some possibilities and since you're not sure whether the disks are Commodore, Apple or Atari, it seemed possible that there is an 8050 disk or two in there; I certainly mix up my 8050 and 2040 disks occasionally.

You would presumably be able to read some tracks with a 48TPI drive, but the sectors/track would be higher.