Catweasel

[Bruce Tomlin]

A few weeks ago I dug up a Copy II PC Deluxe Option board from my stuff and tried to get it to work, but couldn't. (It was a Rev A, which might have had something to do with it.) (FWIW, last week I found I also had a non-Deluxe Option Board, but it was already too late.) So I decided to try the more modern option, a Catweasel board.

 

Basically, this does the same thing as the DOB, which is to be a disk controller that returns the spacing of the magnetic transitions, rather than trying to decode them into data. This not only lets you read and write GCR formats, but variable-speed formats as well. The original version (MK1) was an ISA card, followed by an Amiga-only MK2, then an Amiga/PCI MK3. The current MK4 version is PCI-only. It also has sockets for two SID chips (the MK3 only had one SID socket).

 

Since it's only been mentioned in passing in a few threads, it really needs its own thread.

 

First of all, what I was aware of without too much googling, and what anyone else interested in one of these things should be aware of, is that the hardware is good, but the vendor software support is pretty lame. The hardware can talk to a drive directly, or it can sit in between your PC disk controller and the drives. (Note that the MK4 needs a flipped cable to the PC controller, not the one that it comes with, or the drives will be swapped.)

 

But the non-vendor software support? There's a program called cw2dmk which tries to read all sorts of FM/MFM IBM-sector format disks. I've found that this works effortlessly with everything other than Atari disks, which are complicated by a slower disk motor (the track length needs to be increased), and flippy disks. It will copy to the .DMK format, which is basically raw FM/MFM track data.

 

Flippy disks are a big problem, but it's not the Catweasel's fault. The disk drives for Atari, Apple II, and Commodore didn't care about the index hole, and I think some of them were actually unable to read the index hole. So users were always punching a write-protect notch and using the other side. TRS-80 users had to cut a new index hole too, which is why they aren't a problem. The problem is that modern floppy drives (especially 1.2M HD drives) do not enable the head data until they see index holes. There is a trick that can be done to replace the index hole detector with a reed switch and a magnet on the motor hub, but it's better to just find a 360K disk since 80 track flippy disks shouldn't exist for Atari, Apple, and Commodore. (Note that the second head can't be used to read flippy disks even if you reverse the track data, since it's offset by a few tracks!)

 

So anyhow, I've got shoe boxes full of Atari, Apple, and Commodore disks, and I want to read them. The Atari disks are no problem with the right options to cw2dmk, but Apple and Commodore used two completely different GCR formats. So I've been trying to write programs to read those disks. I've done GCR decoders for 16-sector Apple and Commodore, and I built a program around the Apple decoder. I've been making lots of .NIB images so far, but eventually it will be nice to have file copy utilities. (By the way, the Apple nibble sector encodings are every bit as twisted as you would expect from Woz-ware.) I'll also want to hook up 3.5" and 8" drives eventually. I have quite a few 8" disks that I would like to read, and maybe a dozen total drives, and the main thing I need is to make a cable.

 

It isn't all that hard to program for if you can get access to the I/O ports. This is probably easiest under Linux if you use cw2dmk as an example, but I can see it being made to work under OS X with sufficient IOKit-fu. The main thing that I haven't seen officially documented is that the track data returned by the card is a sample value of 0-127, with the index hole flag in the high bit.

 

So to clarify things, here's some common disk types, and whether a Catweasel is a good solution:

 

TRS-80 - yes (cw2dmk)

CP/M - yes (cw2dmk)

Atari - yes, but an SIO2PC cable might be a better idea depending on what you're doing

Apple 5.25" - not yet (I'm working on that)

Apple 3.5" - an older Macintosh with the Disk Copy program is probably best for 3.5" ProDOS/IIgs disks

Commodore - not yet (I'm working on this too), but a serial drive cable may be a better idea

Amiga - maybe, but if you already have a post-500 Amiga that may be a better option

Macintosh - an older Mac with Ethernet is probably the best way, even for 400K disks (the Disk Copy program will make images of them even when the OS doesn't support them)

 

Another reason to get a Catweasel, depending on the driver support, is that it could theoretically (lots of stuff about the Catweasel is "theoretical") be driven directly by an emulator. This is especially useful for C64 emulators (it has a SID socket and joystick ports) and Amiga emulators (it has Amiga mouse and keyboard connectors). It would even be able to pass the data from copy-protected disks to the emulator.

 

And then there's the issue of copy protection. This reads the raw transitions from the disk, but even that doesn't mean it can copy everything. Normally the data is only supposed to have only one or two zero bits (no transition) between one bits (transition). But when a section of the disk has no transitions, the automatic gain control of the floppy drive will turn up the amplification until it starts reading noise as data. This is the source of so-called "weak bits", and requires a bit-copier program to read a track multiple times and analyze the results. This is another case where the CW is only as good as the software. The hardware can be made to create a copy protected disk with every trick short of burning holes in the disk, but what makes weak bits work is that the floppy drive itself can't read them reliably.

 

So anyhow, am I the only AA-er so far to have one of these or does someone else have one too?

[Curt Vendel]

Hi Bruce,

 

I bought a Catweasel ISA version last year also with hopes it was going to be a lot more useful then it actually turned out to be, its really just a piece of h/w waiting for people to write drivers for it, which really isn't mentioned when you purchase it.

 

I had hoped to use it to read Amiga disks I have on my PC, but instead I just ended up using the remote connection software between my Amiga and PC and reading the disks in and saving them onto my PC's HD.

 

 

Curt

 

 

A few weeks ago I dug up a Copy II PC Deluxe Option board from my stuff and tried to get it to work, but couldn't.  (It was a Rev A, which might have had something to do with it.)  (FWIW, last week I found I also had a non-Deluxe Option Board, but it was already too late.)  So I decided to try the more modern option, a Catweasel board.

 

Basically, this does the same thing as the DOB, which is to be a disk controller that returns the spacing of the magnetic transitions, rather than trying to decode them into data.  This not only lets you read and write GCR formats, but variable-speed formats as well.  The original version (MK1) was an ISA card, followed by an Amiga-only MK2, then an Amiga/PCI MK3.  The current MK4  version is PCI-only.  It also has sockets for two SID chips (the MK3 only had one SID socket).

 

Since it's only been mentioned in passing in a few threads, it really needs its own thread.

 

First of all, what I was aware of without too much googling, and what anyone else interested in one of these things should be aware of, is that the hardware is good, but the vendor software support is pretty lame.  The hardware can talk to a drive directly, or it can sit in between your PC disk controller and the drives.  (Note that the MK4 needs a flipped cable to the PC controller, not the one that it comes with, or the drives will be swapped.)

 

But the non-vendor software support?  There's a program called cw2dmk which tries to read all sorts of FM/MFM IBM-sector format disks.  I've found that this works effortlessly with everything other than Atari disks, which are complicated by a slower disk motor (the track length needs to be increased), and flippy disks.  It will copy to the .DMK format, which is basically raw FM/MFM track data.

 

Flippy disks are a big problem, but it's not the Catweasel's fault.  The disk drives for Atari, Apple II, and Commodore didn't care about the index hole, and I think some of them were actually unable to read the index hole.  So users were always punching a write-protect notch and using the other side.  TRS-80 users had to cut a new index hole too, which is why they aren't a problem.  The problem is that modern floppy drives (especially 1.2M HD drives) do not enable the head data until they see index holes.  There is a trick that can be done to replace the index hole detector with a reed switch and a magnet on the motor hub, but it's better to just find a 360K disk since 80 track flippy disks shouldn't exist for Atari, Apple, and Commodore.  (Note that the second head can't be used to read flippy disks even if you reverse the track data, since it's offset by a few tracks!)

 

So anyhow, I've got shoe boxes full of Atari, Apple, and Commodore disks, and I want to read them.  The Atari disks are no problem with the right options to cw2dmk, but Apple and Commodore used two completely different GCR formats.  So I've been trying to write programs to read those disks.  I've done GCR decoders for 16-sector Apple and Commodore, and I built a program around the Apple decoder.  I've been making lots of .NIB images so far, but eventually it will be nice to have file copy utilities.  (By the way, the Apple nibble sector encodings are every bit as twisted as you would expect from Woz-ware.)  I'll also want to hook up 3.5" and 8" drives eventually. I have quite a few 8" disks that I would like to read, and maybe a dozen total drives, and the main thing I need is to make a cable.

 

It isn't all that hard to program for if you can get access to the I/O ports.  This is probably easiest under Linux if you use cw2dmk as an example, but I can see it being made to work under OS X with sufficient IOKit-fu.  The main thing that I haven't seen officially documented is that the track data returned by the card is a sample value of 0-127, with the index hole flag in the high bit.

 

So to clarify things, here's some common disk types, and whether a Catweasel is a good solution:

 

TRS-80 - yes (cw2dmk)

CP/M - yes (cw2dmk)

Atari - yes, but an SIO2PC cable might be a better idea depending on what you're doing

Apple 5.25" - not yet (I'm working on that)

Apple 3.5" - an older Macintosh with the Disk Copy program is probably best for 3.5" ProDOS/IIgs disks

Commodore - not yet (I'm working on this too), but a serial drive cable may be a better idea

Amiga - maybe, but if you already have a post-500 Amiga that may be a better option

Macintosh - an older Mac with Ethernet is probably the best way, even for 400K disks (the Disk Copy program will make images of them even when the OS doesn't support them)

 

Another reason to get a Catweasel, depending on the driver support, is that it could theoretically (lots of stuff about the Catweasel is "theoretical") be driven directly by an emulator.  This is especially useful for C64 emulators (it has a SID socket and joystick ports) and Amiga emulators (it has Amiga mouse and keyboard connectors).  It would even be able to pass the data from copy-protected disks to the emulator.

 

And then there's the issue of copy protection.  This reads the raw transitions from the disk, but even that doesn't mean it can copy everything.  Normally the data is only supposed to have only one or two zero bits (no transition) between one bits (transition).  But when a section of the disk has no transitions, the automatic gain control of the floppy drive will turn up the amplification until it starts reading noise as data.  This is the source of so-called "weak bits", and requires a bit-copier program to read a track multiple times and analyze the results.  This is another case where the CW is only as good as the software.  The hardware can be made to create a copy protected disk with every trick short of burning holes in the disk, but what makes weak bits work is that the floppy drive itself can't read them reliably.

 

So anyhow, am I the only AA-er so far to have one of these or does someone else have one too?

950989[/snapback]

[supercat]

Does anyone make a device to do an analog capture of floppy disk data? It would seem such a device might be able to read disks whose quality had degraded to the point that they were otherwise unreadable. Formatting, of course, wouldn't be an issue.

 

Given that video cards routinely capture data at a 14MHz bandwidth, the 2MHz-or-lower bandwidth required for floppies shouldn't be difficult to capture by relatively conventional means.

[+remowilliams]

I've got an old catweasel for an Amiga 1200 and the new catweasel MK IV.

 

Sweet piece of hardware. No software to use it with in any manner I'd like

[Bruce Tomlin]

Does anyone make a device to do an analog capture of floppy disk data?  It would seem such a device might be able to read disks whose quality had degraded to the point that they were otherwise unreadable.  Formatting, of course, wouldn't be an issue.

Actually, what CW does is in fact a true "analog" capture, in the sense that the spacing of the bits is an analog value, and it gets sampled with 7-bit resolution. Laserdiscs (and video tapes) are analog in the same way. There are pits and non-pits, with no such thing as a "half-deep" pit. Only the leading and trailing edges of the pits are used to generate the signal. Since the only thing that matters on a floppy disk is the magnetic transitions, this is esentially the same thing, only the signal on a laserdisc is much more complex (it's an overmodulated wideband FM signal with half a dozen sub-bands in the modulation signal).

 

But since the floppy disk data is digital, the transitions should be spaced by two or three specific values. The analog component is merely an error value.

 

Right now what cw2dmk does is take a histogram of the samples on first the track to find the two or three peaks in FM and MFM data (equivalent to 13 vs 16-sector Apple GCR bits), decide on threshold values, then process the transition as either a 1 bit, a 1 and a 0 bit, or a 1 and two 0 bits. Much cooler would be to keep track of the most recent few transitions, then decode each sample based on recent values. That would esentially be a software PLL.

 

So far I've been trying to tweak the threshold values when reading a hard-to-read disk. This can be a bit tricky, especially for MFM/16-sector GCR when you have two values to tweak, and some tracks may need different thresholds from the other tracks.

 

The ultimate coolness would be a program to visually display the transitions and what they translate to, and when there was a data error, it would let you decide which way an iffy transition goes, or to delete or add transitions. Then it could recompute the checksum and the decoded data, and you could decide if you were right. This would allow for full recovery of many errors, by making use of the inherent redundancy in timings and bit encodings and checksums, and even in the underlying data (such as English plaintext).

 

And here is some proof that Woz is a true evil genius. He came up with totally scrambled bit orderings just because they made for less 6502 code:

 

// decode 13-sector nibbles
void post_nibble_13(void)
{
   int i,j;

   i = 0;
   for (j=0; j<51; j++)
   {
       buf[i++] = (secbuf[204 - j] << 3) |  (secbuf[103 + j] >> 2);
       buf[i++] = (secbuf[255 - j] << 3) |  (secbuf[ 52 + j] >> 2);
       buf[i++] = (secbuf[306 - j] << 3) |  (secbuf[  1 + j] >> 2);
       buf[i++] = (secbuf[357 - j] << 3) | ((secbuf[103 + j] & 0x02) << 1 )
                                         |  (secbuf[ 52 + j] & 0x02)
                                         | ((secbuf[  1 + j] & 0x02) >> 1 );
       buf[i++] = (secbuf[408 - j] << 3) | ((secbuf[103 + j] & 0x01) << 2 )
                                         | ((secbuf[ 52 + j] & 0x01) << 1 )
                                         |  (secbuf[  1 + j] & 0x01);
   }
   buf[255] = (secbuf[409] << 3) | (secbuf[0] & 0x07);
}

// decode 16-sector nibbles
void post_nibble_16(void)
{
   int i,j,k,n;

   j=0;
   k=0;

   for (i=0; i<256; i++)
   {
       n = secbuf[j++] >> k;
       buf[i] = (secbuf[i+86] << 2) | ((n << 1) & 2) | ((n >> 1) & 1);
       if (j>85) { j=0; k=k+2; }
   }
}

[supercat]

Actually, what CW does is in fact a true "analog" capture, in the sense that the spacing of the bits is an analog value, and it gets sampled with 7-bit resolution.

951208[/snapback]

 

True, but the signal and amplitude read from the head is also an analog value, even though it's never used as such in any floppy data format. The issue is that if magnetic domains become weak or bleed, the automatic gain control may either fail to detect phase reversals because they're too weak, or may detect phase reversals where there really aren't any because of noise or bleed.

 

The situation is something analagous to trying to scan a faded barcode off a stained label. It may not be possible on a single pass to determine which parts are white and which ones black, but if the data is read in greyscale (or better yet in this case, color) it may be possible to find a combination of brightness/contrast settings that will read valid data.

[ijor]

Hmm, sorry, but there is a lot of misinformation here.

 

> Basically, this does the same thing as the DOB

 

No. They work at two different levels. The DOB (or the OB, or the EOB) works at the PLL level. The Catweasel works at the flux transition level.

 

> The main thing that I haven't seen officially documented is that the track

> data returned by the card is a sample value of 0-127

 

It is officially documented. See the Insider MK3 section on the manufacturer website.

 

> Another reason to get a Catweasel, depending on the driver support, is that

> it could theoretically (lots of stuff about the Catweasel is "theoretical") be

> driven directly by an emulator.

 

This is already supported by at least one emulator.

 

> It would even be able to pass the data from copy-protected disks to the

> emulator.

 

Well, this deserves a whole thread by itself. In first place the hardware is still not ready for this. Or more precisely, the firmware is not yet ready. But IMHO, even with the necessary fixes in the firmware, I don’t see this being implemented in practice, at least not in the near future. Again, it’s quite long to explain and elaborate (if you are interested, let's open a specific thread).

 

> Normally the data is only supposed to have only one or two zero bits (no

> transition) between one bits (transition). But when a section of the disk has

> no transitions, the automatic gain control of the floppy drive will turn up the

> amplification until it starts reading noise as data.

 

Sorry, but most of this is technically incorrect. In first place there is no direct relation between transitions and bits, this depends on the encoding. No transition doesn’t mean a zero bit, and a transition doesn’t mean a one bit. If, for example, you write a long sequence of zeros in MFM (the encoding used on the PC among many other systems), you’ll get one transition for each bit (even when all the bits are zero).

 

It is also wrong that the absence of transitions provokes noise. This depends on other factors. There are some advanced protections that have no transitions for a long period, and still they don’t produce any noise.

 

> The hardware can be made to create a copy protected disk with every trick

> short of burning holes in the disk, but what makes weak bits work is that the

> floppy drive itself can't read them reliably

 

There are others protections that the hardware can’t create, not only physical alterations of the media. But the Catweasel can reliably read and reproduce weak bits. I was using the CW to copy weak bits for many years.

 

> I bought a Catweasel ISA version last year also with hopes it was going to be

> a lot more useful then it actually turned

 

The VAPI (and Pasti) write back tools support the Catweasel. You’ll be able to write back every A8 disk that I know (including those with weak bits). The imaging tools support the Catweasel as well.

 

> Does anyone make a device to do an analog capture of floppy disk data? It

> would seem such a device might be able to read disks whose quality had

> degraded to the point that they were otherwise unreadable.

 

Yes, there are such devices. But they are not actually manufactured for sale. They are custom made for labs and data recovery services. It is not very good for the purpose of reading damaged disks though. They are better for reading deleted data .

 

> Actually, what CW does is in fact a true "analog" capture, in the sense that

> the spacing of the bits is an analog value

 

Not exactly. We are talking about two completely different levels of analog reading. One thing is to read the analog magnetic flux (which requires a custom drive and head assembly). A completely different thing is what the CW does, which is to digitalize the time interval between transitions

[Bruce Tomlin]

Hmm, sorry, but there is a lot of misinformation here.

 

> Basically, this does the same thing as the DOB

 

No. They work at two different levels. The DOB (or the OB, or the EOB) works at the PLL level. The Catweasel works at the flux transition level.

Hmm. I'm not quite sure what the difference, or what even "the PLL level" looks like, but I didn't realize there was another way to encode things.

 

> The main thing that I haven't seen officially documented is that the track

> data returned by the card is a sample value of 0-127

 

It is officially documented. See the Insider MK3 section on the manufacturer website.

Link? I found some documentation, but I didn't see where it specifically said this. The web site is kind of disorganized when it comes to things like this. Anyhow, it's obvious from looking at source code.

 

This is already supported by at least one emulator.

Which in Catweasel terms means "exactly one emulator"? :-)

[ijor]

Hmm. I'm not quite sure what the difference, or what even "the PLL level" looks like

 

PLL stands for Phase Locked Loop. For a detailed technical description it might be better to google PLL. There are quite some good tutorials about this.

 

Essentially, it’s the most critical part of an FDC (although PLL are used in many other applications as well). Its task is basically to recover the clock signal from the incoming pulses. In most FDCs it is closely coupled to the Data Separator, because at a given encoding recovering the clock implies recovering the data as well (by separating the data from the clock).

 

The DOB hardware provides direct access to the PLL output. So what you get is a 16-bit word with each bit set or not depending on the presence or absence of a flux transition. This is before the Data Separator. There is no data separation because there is no fixed encoding. If you are familiar with the Amiga, this is actually almost the same that you get with the Amiga FDC; except that the PLL clock in the DOB is software programmable.

 

This means, btw, that the DOB can’t directly read or reproduce intra-track bit-rate variations (the most popular protection in the 16-bit era). Bit-rate variations are detected in software by measuring the DMA time. I don’t know for sure how, an if at all, it can reproduce this. It has a programmable PLL, and output clock. So you do can write inter-track bit-rate variations.

 

Which in Catweasel terms means "exactly one emulator"?  :-)

 

Probably yes . I just said at least because I can’t be sure if there aren’t more.

 

Link?  I found some documentation, but I didn't see where it specifically said this.  The web site is kind of disorganized when it comes to things like this.

 

It is. You must understand that Individual Computers is a very small company. And the Catweasel was initially targeted for a very reduced market. The popularity of Vintage computing lately changed this a bit.

 

To give you an idea, I’ll tell you how it was when I bought my first MK1. I contacted Jens (Individual Computers owner and developer) and told him I will buy one but only if he would give me the programmer’s specs. He wasn’t very happy, no specs or programming info at all were released at that time. He agreed, but he said that he would send them to me in hardcopy, and that I must give him my word that I will never even transcript the info to my own PC (just in case somebody could hack my PC and grab them). Fortunately this was changed even before he shipped. So there was no need for this

 

Furthermore, after developing some stuff for the MK1, I told him it would be great to make a PCI version. He said “no way”, this is just a small niche market (this was obviously before MK3

 

Btw, if you like this kind of stuff, check the Discovery Cartridge for the Atari ST. Still today, after about 15 years, it is the best product of its kind. It works more or less like the CW. But it was designed by the biggest expert in copy protection that I ever knew (and as can you see, I know quite a bit about floppy copy protection myself).

[Dav]

So anyhow, am I the only AA-er so far to have one of these or does someone else have one too?

950989[/snapback]

 

 

I have one, I'm hoping to use to copy sega arcade floppy disks. I haven't gotten around to doing anything with it yet though. I'm not sure if it will be sufficient for the task or not. Apparently Anadisk can read the disks, but no one's been able to make a copy yet.

 

 

I have a couple of boxes of apple 2 stuff around here somewhere I might run through it too if it works out.

[Bruce Tomlin]

I have a couple of boxes of apple 2 stuff around here somewhere  I might run through it too if it works out.

Well, my Apple II disk reader may be a quick hack, but I've made a lot of good .NIB images from it. I think I even booted one or two of them. And it has no problem with 13 sector disks. But it's still not ready for prime time yet.

 

Last week I hacked up something which extracts .ATR images from .DMK images (it doesn't support double-sided disks or mixed-density track 0, but most disks seem to be flippy and consistent density). The best part is that it can verify images I've already dumped so that I know what to go back and re-dump, now that I know how to tune the -o parameter to adjust the transition size thresholds. The wierd part is that six sides on four disks were formatted on a drive with a bad track 0 sensor/stop, so they start with track 2.

 

I've also got a bunch of C64 disks I want to dump, but I haven't got them to read reliably. A better data separator algorithm would probably help. And I've got a box of another hundred or so Atari disks that I still need to dump.

 

Now if I could only find an HD drive with flippy support. I've got one drive that works at all, and two Chinon drives (one I've had for a long time, another I got last weekend for a buck) that apparently won't step the head. They have a jumper that would probably do the trick, but if they can't step, the jumper is useless. I really don't want to mod the only drive I have that works.

[telengard]

So anyhow, am I the only AA-er so far to have one of these or does someone else have one too?

950989[/snapback]

 

 

I have one, I'm hoping to use to copy sega arcade floppy disks. I haven't gotten around to doing anything with it yet though. I'm not sure if it will be sufficient for the task or not. Apparently Anadisk can read the disks, but no one's been able to make a copy yet.

 

 

I have a couple of boxes of apple 2 stuff around here somewhere I might run through it too if it works out.

957187[/snapback]

 

This device is somewhat similar and I'm keeping my eye on it. It doesn't support Atari yet but I'm hoping the next incarnation will...

 

http://www.thesvd.com/SVD/

 

~telengard

[+remowilliams]

This device is somewhat similar and I'm keeping my eye on it.  It doesn't support Atari yet but I'm hoping the next incarnation will...

 

http://www.thesvd.com/SVD/

 

~telengard

957464[/snapback]

That is a very different type of device. And one that I've been waiting for to support formats other than the TRS80. Apple support now - Nice!

[Dav]

So anyhow, am I the only AA-er so far to have one of these or does someone else have one too?

950989[/snapback]

 

 

I have one, I'm hoping to use to copy sega arcade floppy disks. I haven't gotten around to doing anything with it yet though. I'm not sure if it will be sufficient for the task or not. Apparently Anadisk can read the disks, but no one's been able to make a copy yet.

 

 

I have a couple of boxes of apple 2 stuff around here somewhere I might run through it too if it works out.

957187[/snapback]

 

This device is somewhat similar and I'm keeping my eye on it. It doesn't support Atari yet but I'm hoping the next incarnation will...

 

http://www.thesvd.com/SVD/

 

~telengard

957464[/snapback]

 

 

That is interesting, I was thinking of doing something like that myself. That would be very useful for sega arcade boards as they don't just load once and run, they keep loading constantly.

[ijor]

I've also got a bunch of C64 disks I want to dump, but I haven't got them to read reliably.

 

I never try it myself, but the CW is supposed to come with a built-in C64 driver. Did you try it?

 

Now if I could only find an HD drive with flippy support.

 

I never seen such a drive. But why you want an HD drive, why not use a DD one? With a DD drive you can also easily write back, but not (easily) with an HD one.

[Bruce Tomlin]

I've also got a bunch of C64 disks I want to dump, but I haven't got them to read reliably.

I never try it myself, but the CW is supposed to come with a built-in C64 driver. Did you try it?

I don't run Windows (except for my video player box, and I'm not touching that). And I don't want to install Windows to use this, either.

 

Besides, I don't want it to "access" the contents of disks a file at a time, or even through an emulator. I want to make disk images in the more advanced nibble formats like G64. (My Apple II dumper already makes proper .NIB files.) Then I can extract stuff from that at my leisure. And I want the the extra options like cw2dmk has which let you tweak the bit decoding for troublesome disks. There are quite a few Atari disks that I couldn't have dumped with zero errors if it weren't for the post-compensation adjustment in cw2dmk.

 

The point is that I want to make an archival dump of as many disks as possible, as fast as possible, making sure they have as few data errors as possible, then I will put the original disks back in the box. And I will also know which ones I had trouble reading, in case I come up with better tricks later to recover bad sectors.

 

And I mostly did the C64 stuff because it wasn't that much extra work after getting Apple II working. Anyhow, it turns out that the "reliability" problem was simply me not noticing that it was seeing bogus index blocks and ignoring them, and a bug derived from that which broke my wraparound detect.

 

Now if I could only find an HD drive with flippy support.

I never seen such a drive. But why you want an HD drive, why not use a DD one? With a DD drive you can also easily write back, but not (easily) with an HD one.

Because it's 80 tracks, duh. I'm not only dumping 40 track disks. Also, there are reasons to write disks with 80 track drives sometimes.

 

Also, it would mean that I could use just one drive for 5 1/4" disks, then I could put a 3 1/2" or 8" drive as the second drive. (but I'll probably get a second CW card and hook it up to a 3 1/2" and 8" drive)

 

And only now am I realizing how few 5 1/4" floppy drives I'm seeing during my thrifting runs. I'm lucky I already had the two good ones I'm using.

Edited November 2, 2005 by Bruce Tomlin

[Bruce Tomlin]

My C64 problems were even stranger than I thought. On the Apple II, you can get away with just looking for the address mark nibble ($D5), because it's not supposed to appear anywhere but at the start of an address or data block. I suppose if you start unsynchronized in the middle of sector data, you might see one, and I may have already worked around this problem the wrong way for the Apple II. FM and MFM also have rules that prevent an address mark byte pattern from appearing in the middle of data.

 

But you can't do that on the C64, because it doesn't use special or invalid bit combinations for address marks. If you start scanning in the middle of a data block, you'll probably find a $07 or $08 pattern in there somewhere. And since the C64 doesn't use the index hole, you don't know where you might start.

 

I added a sync bit counter and verified that at least 16 sync bits (not counting the first five or so before they overflowed the accumulator) had been seen. After processing a byte in the gap state, whether it was a mark byte or not, the sync bit counter was reset. After that, all my problems went away.

[ijor]

I never seen such a drive. But why you want an HD drive, why not use a DD one? With a DD drive you can also easily write back, but not (easily) with an HD one.

Because it's 80 tracks, duh. I'm not only dumping 40 track disks. Also, there are reasons to write disks with 80 track drives sometimes.

 

Also, it would mean that I could use just one drive for 5 1/4" disks, then I could put a 3 1/2" or 8" drive as the second drive.

 

I'm afraid you'll need to choose. Either install two drives (one DD and another HD). Or otherwise you'll loose something, either flippy or 80 tracks support.

 

If you do happen to find an 80 tracks that can read the flippy side, let us know.

 

Lastly, I guess you already know that is possible to modify a drive for accessing the flippy side. There are some instructions and tips on the CW web site.

 

But note that writing back DD disks with an 80 tracks drive (disregarding the flippy issue) is, at best, quite complicated.

[supercat]

I added a sync bit counter and verified that at least 16 sync bits (not counting the first five or so before they overflowed the accumulator) had been seen.  After processing a byte in the gap state, whether it was a mark byte or not, the sync bit counter was reset.  After that, all my problems went away.

958792[/snapback]

 

I think the hardware looks for ten, but yeah that's necessary.

[Bruce Tomlin]

I'm afraid you'll need to choose. Either install two drives (one DD and another HD). Or otherwise you'll loose something, either flippy or 80 tracks support.

 

If you do happen to find an 80 tracks that can read the flippy side, let us know.

 

Lastly, I guess you already know that is possible to modify a drive for accessing the flippy side. There are some instructions and tips on the CW web site.

 

But note that writing back DD disks with an 80 tracks drive (disregarding the flippy issue) is, at best, quite complicated.

Yes, I know already. And yes, I have a 40 track DD (that is flippy compatible) and an 80 track HD. Yes, I've seen the mods many times. But I do not want to mod my only working HD drive. And yes, I've known about the issues with 40 track vs 80 track heads since at least the early '90s. And "lose" only has one "o" in it.

 

 

I think the hardware looks for ten, but yeah that's necessary.

Well, my 16 is counting the five more to get my accumulator == 0x3F, so it's really more like 21. I'll probably go ahead and reduce it a bit, since the most bits I saw that were bogus (again, not counting the first five) was four.

 

I'm still tweaking the Apple II code and

[ijor]

Or otherwise you'll loose something,

...And "lose" only has one "o" in it.

 

Just in case you didn’t note, I’m not from an English speaking country and my English is not very good. I’m sure that if you’ll check all my post you could find many more mistakes to correct.

[A.J. Franzman]

Just in case you didn’t note, I’m not from an English speaking country

959848[/snapback]

That might be easier if you would put it in the "Location" field of your profile.

[djpubba]

The VAPI (and Pasti) write back tools support the Catweasel. You’ll be able to write back every A8 disk that I know (including those with weak bits). The imaging tools support the Catweasel as well.

 

Does anyone actually have the Pasti write back tools that support Catweasel? I have a Catweasel MKIV and a lot of Atari ST original software. About 10-12% of my original disks are bad and I would love to be able to write new disks to restore my collection. But I can't find hide nor hair of Pasti write tools and the author doesn't respond to emails.

[Spirantho]

Hi,

 

Does anyone actually have the Pasti write back tools that support Catweasel? I have a Catweasel MKIV and a lot of Atari ST original software. About 10-12% of my original disks are bad and I would love to be able to write new disks to restore my collection. But I can't find hide nor hair of Pasti write tools and the author doesn't respond to emails.

 

I don't suppose it's much help to you but if I can find the PASTI file format I'll add support for it to my Catweasel disk-imaging program.

Reason I say it's probably not much help is because my program (and drivers) run under AROS and AmigaOS 4.x! Nonetheless, I guess it's possible someone here may be interested.

 

First I need to find the file format though....

[djpubba]

Can you derive the format from a disk image?