A modern //c-compatible external hard drive

I’d missed this in my searching around, but there is (going to be) an option for external mass storage on a //c, the SmartPort Virtual Hard Drive, which allows you to plug in a USB thumb drive, with a note from last month saying that deliveries may begin this month.

It does require a ROM 0 or greater //c, and at least two of my three //cs are only ROM 255 (I haven’t checked the third), so I’m going to need to upgrade one if I want to use it. But that shouldn’t be too much of a challenge, I hope.

I’ll definitely be keeping an eye on that.

I don’t fully approve

I’d never advise doing this to a drive that wasn’t irreparably dead, and I would actually think it would be a little bit cooler if the drive retained its original look rather than just being turned silver (though I understand how much work went into turning it silver), but—with those caveats—this Disk-][-as-external-USB-drive project is pretty cool.

Anthony kouttron diskii usb

[Photo credit: Anthony Kouttron; cropped and hosted here.]

Though it’s “//c”, not “2C”, and the Disk ][ couldn’t plug into a //c anyway, only into one of the other models with a 650-X104 card in it.

Which, come to think of it, makes me consider the possibility of creating a modern external device (perhaps CF based) that emulates the floppy drive’s responses to the signals coming over the standard disk connection. With quarter-tracked nibble images, virtually any floppy (even copy-protected ones) should be able to be simulated this way, and with some kind of external selector to switch floppies, you’d have something that would work sort of like the CFFA3000 but would also work for the //c and //c+ (which have no other real option for something like a hard drive). It doesn’t actually sound all that complicated, but it’s still well beyond my current capabilities.

Rambling about modern usefulness of vintage machines

So, I’ve been collecting a bunch of vintage machines, mostly because of the nostalgia value, but practically speaking, what good are they? What realistically might ever lead me to turn one of them on? Some of these are just visually appealing (the G3 and G4 iMacs, the G4 Cube), or have very strong nostalgia value (the Apple ][+), but some of the others are sort of interesting but I’d still kind of like to explore the possibility that they can still be actually used for something.

As a sort of prerequisite to that, there are a couple of considerations. One is that if they are going to continue to work, they need to not have dead hard drives, and they will also probably need to connect in some way to the modern machines.

For the most part, I think I will probably run the old machines on the operating system they shipped with, or at least not with the absolute maximum operating system they can support—the newer the OS, the more demanding it will be on the hardware and the slower the experience will wind up being. Which will mostly guarantee that I wouldn’t use them. Plus, at this point, capabilities are not as much an issue as usability—if there’s something that the LC II can’t do because it’s running too old of a system, the next computer over should be able to do whatever it is.

One concern I have about operating these machines in the modern world is that they need to have access to large storage, preferably replaceable large storage. There are a couple of categories of problems to address here. The oldest of my machines, the Apple II series computers, didn’t ship with any permanent large storage, but primarily used 140K floppies. It was possible, however, to buy hard drives for these machines. This was all done with expansion cards, and the earlier operating system (DOS 3.3) was pretty limited anyway in how large a space it could keep in mind at one time, so larger storage had to be split up into “volumes” since the largest disk DOS 3.3 can imagine is 400K. The newer operating system, ProDOS, can see partitions up to 32M, and GS/OS (which I can of course only use on the IIgs) allows up to 2GB partitions. These are of course laughably small data spaces by today’s standards, but of course one doesn’t need a lot of space for the software to run these old machines. So, with respect to “authenticity,” I think it’s fair to say that, since hard drives were made for these machines, introducing a hard drive (or something that works like a hard drive) retains the authentic experience. And, really, I don’t have much nostalgia for constantly swapping floppy disks, having bad sectors crop up, etc.

For these systems, there are a few different modern solutions that involve using Compact Flash cards in newly creating interface boards, and this seems ideal. First of all, CF cards are cheap and they have no moving parts. The only problem I foresee here is that finding CF cards small enough might wind up being a problem in the future. But, even if one were outright given to me, I’m not sure I’d want a true vintage hard drive for these machines. First of all, hard drives just fail. Using a 25-year-old 20MB hard drive is likely to very soon lead to tears. And while it’s working, it’s going to be loud. The CF card solutions, on the other hand, use a medium that’s modern enough that it’s trivial to connect them via a USB CF reader connected to current Macs (or even to the built-in SD reader in my MacBook Pro, though I haven’t yet been able to locate such an adapter). Which solves one of the other big issues with working with the vintage hardware: getting data in and out of them. I plan to eventually put CF drives in all of my Apple II-era machines. I’m eagerly awaiting the second run of the CFFA3000 card, which I will certainly get at least one of. I’ve already ordered a Focus IDE HD + CF controller card, I’m just waiting for it to be built (currently I’m guessing it’ll still be a couple of weeks away). Another option in this realm is the MicroDrive IDE controller, and perhaps I’ll consider getting one of these too, just to compare them. These are not an option for the //cs and //c+, but for my three ][+-type machines, my //e, and my IIgs, one of these storage options will really make it much more likely that I’d actually use them.

One complication in the Apple II area is that many disks were actually copy protected, to make it difficult to just hand around copies to all of your friends. This led to a pretty active cracking scene, and most things were reverse engineered or imaged in various ways that led to copyable versions, although this means that the only way you can run a lot of these programs/games is to use the version with the crack screen. And also, some things could be copied using specialized copy programs (Copy II Plus, Locksmith), but the resulting copy was still just as copy-protected as the original. The issue with all of this is that in the context of a hard drive that is supposed to have the contents of many disks on it, there’s a large chunk of the software that simply can’t be used that way. The only way to use these things is to boot the floppy disks. The CFFA3000 does have some compatibility with “nibble” images, but it is still stated as being incompatible with protected floppies. I’m not sure what the best solution to this will end up being. It might really be that the best solution for these is to just use real floppy drives, but for everything else the hard drive will be a big help. There’s a considerable cost, of course. The new cards are all in the region of $150, which is in many cases more than the entire machine is worth to an ebay audience. But the usability improvement probably justifies it. I also like the CF solution better than a real hard drive solution because CF cards are cheap to replace and easy to read/write on modern machines, and even though CF drives do have a limit on the number of writes you can do to them, the Apples II are not likely to come anywhere near those limits.

This does still leave the //cs and //c+ out in the cold, however. The options here are really limited. The compact form of these machines means that there are no expansion slots in which any kind of CF or hard drive card could go, and there is no external connector other than the serial connections for the printer and modem. Given that there is also no AppleTalk, they’re really stuck with floppy disks, possibly transferred over with ADTpro, but still ultimately stored on floppies. The //c+ is capable of using 3.5″ floppies, but at least two if not all three of my //cs are ROM 255 versions, which did not have support for 3.5″ drives. The best I could hope for here, really, would be some kind of front end file transfer program that could bring in a program over the serial port from a hosted catalog (like what ADTpro does) and then run it in place (ADTpro only allows for downloading disk images to be written to physical disks). As far as I know, there is no hardware solution available to the //c that can get me any closer than that for larger non-floppy storage, and the serial loader I’m imagining here probably has yet to be written.

There is a similar issue once we get to the older Macs, at least with respect to the life expectancy of the internal hard drives, though at least these all shipped with hard drives installed and know at least something about how to deal with them. The oldest Macs I currently have are three SE/30s and an LC II, which originally shipped with an 80MB SCSI hard drive. That’s a small hard drive. If the internal drive fails, which it will surely do at some point, finding a drop-in replacement will not be easy. Furthermore, the OS prior to System 7.5 had a limit of 2GB that it could see. But even a 2GB SCSI drive is going to be hard to locate. CF cards, on the other hand, quite easily get to 2GB. A CF card in a Mac worries me a little bit more than in an Apple II, because it’s more likely to start using swap space for virtual memory, and so more likely to hit the write-limit. But artmix on ebay (the manufacturer) currently sells some SCSI CF card interfaces, and I might just go for some, at least to try. Advantages I see here primarily is that even if the CF card dies, it’ll be much cheaper to replace the CF card than it will be to try to replace an actual hard drive. And, I can periodically, if I so desired, crack open the Macs and take out the CF card to transfer data to/from them or back them up (although this doesn’t sound like a great idea for the SE/30s. The hard drive in the LC II is trivially accessible, but in the SE/30 the hard drive is tucked away under some hardware that would need to be removed before I could get at the CF card inside. I guess I could get something like this SyCard CFextend 182E and position the cable in some way so I could get at the card without disassembling removing the video board, but the thing costs over $100, so I’d have to be really sure I’d actually want to change the card often).

Once we get to IDE Macs, such as the G3 and G4 iMacs, we start getting into Mac OS X territory (potentially, though as I stated at the outset, I’d probably be running Mac OS 8 or Mac OS 9 on many of them), where disk access gets even more intense. An option here is to just get a SSD drive like the OWC Mercury Pro Legacy, but they are expensive too. They’re likely to be more resilient for this kind of use than a CF-based solution, but if they fail, an entirely new drive is required. And the ability to just extract the “hard drive” to read on a more modern machine is lost. Also, on these early Macs, the first partition of a big drive has to be no larger than 8GB, and the whole drive can’t been seen past 128GB. And even those are pretty small to expect to find these days. I think the 1MHz iMac G4 can see bigger drives, but I don’t think the earlier ones can. The MDD Mac is supposed to be able to.

Of course, the expense here starts to pile up. In the case of the Mac machines, I may well hold off replacing their hard drives until I need to do so, since many of them do have working drives in them. For those that lack hard drives altogether, though, I may consider some of these CF or SSD options.

On to the other main obstacle I can see in making these older machines usable, which is connectivity. The newer Macs have ethernet capability and, some have Airport capability, so I will probably try to ensure that those connect in the modern way. I even have an ethernet card for one of the SE/30s, but I’m not sure how useful it will be. I do not anticipate putting an ethernet card in the LC II, because it has only one PDS slot, and that slot is reserved for the Apple IIe card. Most of the older Macs can speak AppleTalk, so I expect that I’m going to try to set up a small AppleTalk network among those machines so that they can talk to one another. And, the IIgs should also be able to participate in this as well, since it has both the port and the ability to use AppleTalk in ProDOS and GS/OS. None of the prior Apples II have AppleTalk ability, although an enhanced //e can use a Workstation Card to get on an AppleTalk network (and I am not sure at the moment whether my //e is enhanced or not).

The connectivity of the Apples II is most in question at this point. I have modems for two of them, although they don’t really have anyone to talk to over the phone line these days. I suppose it’s possible that if I could get them to ignore the lack of a dial tone I might be able to get them to talk to each other, though it seems a little bit silly. Still, I have these programs written for the Apple Cat that it might be nice to see running again, but it would require a second Apple Cat and I’m not sure that it wouldn’t actually require two phone lines as well, since phone lines did provide some power that the modems may be sensitive to (meaning that just running a phone cable from one modem to the other directly most likely won’t work). I might be able to rig something up if I ignore those modem cards and convince the Apple II that it’s talking with an external modem over a serial connection when it is actually talking to one of the Macs, emulating a modem. I can’t have been the first one to think of this, some kind of solution like this may well exist out there. This would require getting Super Serial Cards for the //e and ][+es, but they are still pretty cheap and plentiful at the moment. Though I might also want to stop and ponder what exactly the connectivity is useful for, too, in these cases. The Apple Cat is capable of turning things on and off (I think—I have the expansion card that allows for this, but I’m not sure that I have or can easily get the right interfaces that would get it to an actual power outlet), so perhaps if I could make the machine with the Apple Cat in it to be somehow addressable on the network I could get it to turn things (e.g., neighboring computers?) off and on. (That would be excellent if I had it set up so that if my modern office iMac freezes badly [as it sometimes has due to some kind of lockup of the Firewire ports], I could send a signal to the Apple ][+ and turn the iMac off and on again.) The biggest file transfers will probably really happen via CF cards, though, not serial connections with the modem port. So, what else would connectivity buy me? Mainly just the ability to save small, incremental files (perhaps for use in a disk image) somewhere they could be retrieved without pulling the CF card. And so maybe it isn’t really worth it, though I have to say, the thought of an unconnected computer does really make it feel isolated and lonely.

But on to the plan, what could these things be useful for? I have pondered the possibility of using the iMac G4s for art, and writing a screen saver that runs on all 6-7 simultaneously, but that doesn’t really seem useful. However, I think there is just no way that I’m going to be able to come up with something that six machines will be useful for. Perhaps I can get some form of XGrid working on them, so they can look for extraterrestrial signals or compute fractals. Maybe if I can get a fast enough connection with them going that screen sharing is possible, such that it’s effectively six extra monitors of some sort. Even if they aren’t actually sharing the screen, it would be easy enough to put PDFs I’m trying to read up on them, and they are pretty compact. The SE/30s are capable of running A/UX, and maybe I’d set one of them up running that, or, more likely, NetBSD. Once I’ve done that, the ethernet-connected one can be a little server of some kind. Though the strength of these old machines is not going to be found in fast transfer of large amount of data, it would need to be something useful that it could do just kind of directing traffic or handling low volumes of text. Apart from that, some of the vintage machines can be used to run games of their era that no longer run on newer machines—although I don’t really have much time to play them. Microsoft Word 4.0d or 5.1 is probably really super-fast under System 6, there might actually be a use for that, except that I don’t tend to use Word, and I have to be able to get the resulting files over to a modern machine.

I think there’s some work to be done here to try to find actually useful things that these old computers can do. I’d like to think of something clever that they do better than modern machines, though I suspect much of it will just revolve around interacting with other vintage machines in a way that modern machines no longer support.

BBooting the QX-10

I popped open the QX-10 again today and swapped the A and B drives. When I had them out, I observed that the B drive (the then Right drive, second picture) has a chip that the A drive (the then Left drive, first picture) lacked.

Epson drivea

Epson driveb

“Hmm,” I thought, “maybe that’s why the A drive wasn’t working. Maybe somewhere along the line it lost a chip it needs, maybe I’ll need to find a replacement chip.” I reversed the drives (and the DIP switch settings, which was probably the most important thing), reassembled, et voilà:

Epson bbooted

Cool. Except the (now) Right drive (still labeled “A” but now logically “B”) wasn’t working at all. Well, except that its activity light was coming on at a very, very low level and just staying lightly lit.

I was distracted from thinking about that further by the thought that I should right now back up the boot disk onto the new floppy media I had (though this was not going to be possible regardless, all of the copy functionality I had available on the boot disk requires both drives to be working). But, once I popped out the boot disk, I couldn’t convince the left drive to accept any further disks, even the one I had just popped out. The problem, I correctly guessed, is that spring return mechanism mentioned in the previous post about the drives wasn’t returning. The pad didn’t want to slide back, it needs to be lubricated. If it doesn’t slide back, then it remains in a kind of unready state where the physical disk capture mechanisms won’t go.

Epson drivespring

So, I took it all back out and decided that at least until I get that lubricated, I need the drives out in the open so that I can pop the pad back with my finger. So, now the QX-10 has its drives sitting on top, though it all still works as well as it did with them inside.

Epson drivesout

Until just a little while ago, I was thinking that what was wrong with the (now) Right drive is that it was missing that chip. This is the chip:

Beckman8993R150 chip

However, when I looked it up, the Peacon Vintage Blog wiki told me that it is: “a 150-ohm resistor network in a 14-pin package. It can be used to terminate the floppy disk drive bus.”


So, this is why only the (then) Right drive and not the (then) Left drive had one, and also might be the very reason why the (now) Right drive isn’t doing anything. The chip is a terminator. It’s telling the drive bus that the Left drive is the end of the line, and there shouldn’t be any more drives expected (even though the [now] Right drive is connected after it). So, now I still don’t know if the (now) Right drive works or not, since I disabled it by accident.

Not sure what I’ll do next. I might try to transfer the terminator chip to the (now) Right drive, or I might swap them back and see if I can do anything to get the (now) Right drive to work, since I have now seen that the rest of the machine basically works.


After setting up the Epson QX-10 and finding that, although it happily displayed “INSERT DISKETTE” on its monitor, it didn’t recognize any of the diskettes I inserted in response, I decided to pull it open quickly and take a look to see if anything presented itself as an obvious problem. The QX-10 came open pretty easily, just a few screws holding in the case, and a grounding wire of some kind to disconnect before I could flop it open.

Qx10 open

Inside, everything looked pretty clean, I didn’t see any obviously troubled capacitors or battery leaks (though I haven’t inspected it thoroughly really—if you see something in this picture that worries you, alert me!). One thing I did notice, though, is that cable from the drives to the motherboard appeared to be disconnected.

Qx10 drive cable disconnected

That seemed promising as a possible cause for the inability of the computer to respond to my disk insertions. But, I continued anyway to take the drives out of the case to have a look at them, since one thing that I noticed was that they were acting a bit “spongy”—this was clearly a system that hasn’t really been used in a long time. Also, the eject button on the B drive was bent (this can sort of be seen in the previous picture of the QX-10 assembled on my desk—there is more white showing because the eject button is angled down when it should have been straight), so I thought I’d take a look at that to see what could be done about it.

The drive mechanism is kind of interesting, once I saw how it worked, and it also helped remind me of how the disk insertions were supposed to go. What you do is insert the disk most of the way, and then at the end the disk itself pushes up against a little pad attached to the pretty visible spring. This causes a plastic bit to retract until a groove aligns with another spring-loaded capture mechanism that grabs the disk and closes a very small door around the front edge of the disk. The final step is to push in the eject button, which clicks into the closed position and presumably engages the head. Pressing the eject button a second time will pop everything back out into its original positions, pushing the disk out a little bit and making it available to retrieve again. The “sponginess” was in the motion of the pad attached to the spring, which was sluggish but after working it a little bit it became appropriately responsive. After considering the bent eject button on the B drive for a bit, I decided that it was just that the metal connector had been bent a little bit and I carefully just twisted it back up with a pliers. Fortunately, I managed to get it mostly straight again without breaking the plastic, which I was a bit worried about.

Qx10 drive out

Having basically inspected the situation, I then put everything back together and took care to attach the drive cable to the motherboard. I can’t be sure that it was originally disengaged because it is on a kind of quick-release mechanism, and so it could have popped out as I opened the case. Though, still, if it had been attached properly, that shouldn’t have been enough to pop it out.

Once I put everything back together, put in a boot disk, and turned it all back on again, though, I was still just faced with the “INSERT DISKETTE” message. No real progress seems to have been made.

Unfortunately, the QX-10 must boot from the left drive, there is no provision made for booting from the right drive if the left drive is broken or empty. So, probably the next thing I’m going to try is to swap the left and right drives and see if I can at least get the thing to boot. There is probably a limit to what I’m able to troubleshoot and fix with these drives, but if I can at least show that the problem is somewhere in the left drive, that will be progress. If it continues not to boot even after I swap the drives, I guess I may have to start looking to the connection wire or the motherboard itself. As a possible last resort, I could maybe get a new motherboard, there are a couple available on ebay as I write this, although I’m still a little ways away from being sure that would help anything.


This isn’t right. The drive I’ve got hooked up to my Kryoflux produced this little marvel today.

Floppy problem

Floppy light

Floppy scored

Guess there’s not much hope of retrieving whatever it was that was on that disk. Also, I think I’d better disassemble that drive and figure out what’s happening before any more disks are “archived.”

Subliminal Apple branding

Including Apple stickers with computers and other hardware was always kind of a goofy, childish thing, but I think it worked. People used them, people stuck them to their folders in school, to their file cabinets, very often (kind of superfluously) to their computers or disk drives.

AppleSticker old

Mine, for some reason lost to history, was installed on the inside of my computer, on the underside of the ][+ lid.

Home iiplus applesticker

Apparently, a previous owner of the 3.5″ floppy drive I recently got had one of the stickers on it (in the old style too, Motter Tektura), but then—too late—had second thoughts.

35drive appleshadow

Kryofluxing QX-10 disks

A more daunting project than using the Kryoflux to image old PC floppies is trying to image the floppies that I used on the Epson QX-10 I had for a couple of years.

There isn’t a lot out there on the QX-10, actually. There’s a page that has some information about the keyboard and components, an entry at the obsolete computer museum with some interesting information, a page in French about one person’s recent experiences with the machines. You can still download the operations manual from Epson. There are some information pages and some disk images.

There’s even an emulator, which was linked to from the “information pages” above. It’s part of a suite of emulators created by Toyisha Takeda, and you can download the lot and run them under VirtualBox running Windows 2000. It needs the ROMS in the same directory.

I got the emulator to start just fine. The keyboard layout is a bit bizarre, so I can’t just type B: to get to the B drive, because the : key is actually where my + key is. I type B+, it hears B:. But it does work. Though it also seems to constantly play an annoying squeal out of the speaker, so I had to turn the volume down.

Qx10 emulator running

The reason I’m interested in this primarily is that I ran, for a while, a small and mostly unused BBS on it. It wasn’t really ever advertised widely, but it was a somewhat extensive program, and ran natively on the QX-10. I’d like to see if I can recover it. In order to do that, I need to image the disks, which the Kryoflux should enable me to do. And if it can manage it, it is going to be a minor miracle, since the media in the disks looks terrible.

Blotchy qx10 disk

I imaged stream files with the Kryoflux, but the issue now is how to turn it into an image file that I can use in any sensible way. According to this page, the disk geometry is 40×16 256-byte sectors. When I ran it through the Kryoflux software, using MFM, 40-track distance, and 256-byte sectors, I just got a lot of sector-count mismatches.

Kryo qx10 256attempt

When I ran it through with 512-byte sectors, I got quite a lot of green (successfully-read) blocks, but it reports 10 sectors per track, which isn’t right.

Kryo qx10 mfm720attempt

A hex editor on the image confirms that I have read some real data from the disks this way.

Kryo qx10 mfm720 hex

But I have no idea what I could use to mount this image, and moreover, I don’t really trust it given the “10-sector” problem. Did it find 16 sectors and mix in 1K of garbage into 2-sector chunks? Did it lose 6 sectors? Was I wrong to expect 16 sectors in the first place? (Or is that actually 0x10, in which case it is correct?) I tried mounting it in FreeDOS and Win2K to see if I could use some CP/M disk readers to deal with them, but that didn’t work very well. The QX-10 emulator can read TeleDisk format, and a couple of versions of TeleDisk are available from the QX-10 disk image page, but neither was willing to recognize the mounted image as anything. Nor was Anadisk (linked to here) or the elusive 22disk (which I found a link to here). I even tried using Virtual Floppy Drive to try to fool those programs into thinking that the image I had was a real drive, but they’re all too “smart” and want something in the real (virtual) disk drive.

What I’d like to do is just get the files off those disks and onto a different CP/M machine. One possibility is to run the software one of the Apple ][ machines I now have with Z80 cards in them, that’s my current goal. (And in that form, they would also be usable in Virtual ][, since that emulates a Z80 card as well.) But I think I’m still a ways away from being able to do that.

Kryofluxing old PC disks (the Salon program lives)

So, my Kryoflux unit arrived, and I have set it up. No time for enclosures, I just used the box it shipped in as my enclosure.

Kryoflux enclosure

I ran a number of my old PC floppies through it, and for the most part had pretty good success. I recovered a number of old disks full of documents, like little journal entries of a kind of I’d written in high school. Should be interesting/embarassing to read at some point. And a working copy of WordStar, even. It was quite straightforward to install VirtualBox, FreeDOS, mount the images, and try it out.

Life 530 wordstar

It was less straightforward to actually get the files onto my computer. For that, I installed a Windows 2000 machine in VirtualBox, created a hard drive that I mounted in both the FreeDOS and Win2K machine, and then copied the files onto the shared hard drive in FreeDOS, and then out into a shared folder under Win2K. The reason for the circuitousness is that FreeDOS doesn’t support the additions required to use shared folders on the host machine.

There are also a few old programs I wrote, the most important of which is a program for scheduling appointments and charging clients in beauty salons. It’s actually quite complex, written in Clarion 2.1. I recovered the source files, and even the executable program still runs.

Salon calendar help

Salon appt setup

Success with ADTpro was surprisingly good

I took a shot at imaging some of my 5.25″ Apple floppies from the mid-80s today, using ADTpro talking to my IIgs over the modem port connected via a Keyspan dual serial adapter (driver here) to the USB port on my MacBook Pro. Two bits of good news to report: it’s actually quite quick, and it seems to be pretty fault-tolerant. ADTpro managed to read about maybe 70% of the disks I gave it without errors on either the front or back sides, which either means that ADTpro is good at retrying read errors, or that the floppies were still in pretty good shape. Many of the errors I encountered were actually ones I remembered, disks that had developed errors back when they were being used. I’m hoping that my Kryoflux, when it arrives, might be able to reconstruct some of those wayward bits as well.

Anyway, I imaged most of my highest priority floppies, mostly source code and experiments, not many of the games that already exist in disk images on the internet somewhere, but I intend to finish this first pass through the rest of them pretty quickly. The Kryoflux is not well suited to imaging the flip side of these disks, so I’m glad that the Apple is able to read most of the flip sides.

Among the things I had that I’m pleased still to have access to (because of how 1337 it makes me) is the source code to Cat-Fur. I forget the specifics now of how I acquired it, but I believe it is The Micron’s actual Cat-Fur 3.1 source code (uncommented, but with enough symbol labels that it probably isn’t just a disassembly of the binary file). I wrote a number of Cat-Fur modifications myself, which perhaps I’ll document here at some point. Cat-Fur was a huge part of my BBSing experience, but oddly it seems to have almost no representation on the internet of today, so if you don’t already know what it was you don’t have a very easy way to find out (it was a modem-specific file transfer program, designed for the special capabilities of the Novation Apple-Cat ][ modem, which had the ability to transfer at 1200 baud, but only half-duplex, so a complex handshake system was needed in order to permit two-way communication.).

Catfur src snip