Replacing the Internal Disk of a Powerbook 150 with a CompactFlash Card

Click on a picture to see it full size

Bottom half of the Powerbook, with the CF adapter in the original hard drive bay.	Closeup of the drive bay, with the CF card and hack circuit in place.

Some time ago I acquired a second-hand Macintosh Powerbook 150, with the idea of using it as a portable device for playing Interactive Fiction. It worked well in this role for about a year, and then its hard disk died. I put it aside while I pondered what, if anything, to do with it.

Recently I came up with the idea of replacing the disk with a CompactFlash memory card. These cards have the ability to emulate an IDE device, and there are adaptor boards available which will enable them to be plugged into a standard IDE bus. This would be perfect, I thought: silent, low power, and rugged!

Unfortunately, it didn't quite work. Everything plugged together okay, but the Powerbook refused to recognise the CF card as a disk. The Internal HD Format utility said "No ATA device found in the drive queue."

To try to find out what was going on, I wrote a program to make some calls directly to the ATA Manager. I found that the CF card responded correctly to these, which was encouraging: there appeared to be some chance it could be made to work.

Next I took a look at the drive queue, a data structure belonging to the File Manager which is supposed to contain an entry for each physical drive. It only contained one entry, the one for the floppy drive.

The question which arose then was: how exactly was the entry supposed to get into the drive queue? Apple's Inside Macintosh documentation isn't very clear about that, but after a lot of poking around, it appeared that it was supposed to be done by the driver for the device concerned, when the driver is opened. And on the PB150, the ATA device driver resides in the ROM.

So the next few evenings were spent disassembling and tracing through the ROM driver trying to find out why it wasn't creating a drive queue entry. Eventually I tracked it down to the contents of the first word returned by the CF card in response to an "Identify Device" ATA command.

This word contains bits signifying various things about the device, and the one causing the problem was bit 15. The driver checks that this bit is 0, and if it's not, it refuses to deal with the device. And the CF card was returning a 1 in this bit.

Now, I'm not sure what the driver thinks this bit means. According to one version of the ATA Standard I've seen, it means that the device is an ATAPI (ATA Packet Interface) device. If that were true, I would have been in serious trouble, because ATAPI uses a very different protocol.

However, a later version of the Standard (ones covering ATAPI as well as ATA) say that an ATAPI device is not allowed to respond to the Identify Device command at all; you have to use a different command, Identify Packet Device, to get the corresponding information. If the device responds to Identify Device (and is therefore an ATA device), bit 15 of word 0 should be 0 -- except that the special value $848A means that it supports an extra set of commands called the "CFA Feature Set", where CFA stands for CompactFlash Association. And, being a CF card, it was of course returning this value!

My guess is that whoever wrote the driver was going by the earlier version of the ATA Standard (which was quite likely current at the time) and assuming that a 1 there meant the device was ATAPI. Whatever the reason, this bit was clearly ruining my day.

Before going any further, I needed to find out whether this was the only problem. I made a copy of the ROM driver and turned it into a RAM driver, with a patch to stop it caring about that bit, and arranged for a program to install it in place of the ROM driver.

It worked -- a drive queue entry was installed, and I was able to use the Internal HD Format utility to format it, mount it, and install a System on it.

It didn't do me all that much good, however, because I still had no way of booting from the CF card. Getting it mounted required booting from a floppy and running a program. I could have lived with that if I could then have changed over to running a system from the CF card, but I couldn't think of any way to do that. In System 6 you used to be able to "switch launch" by holding down the command key while launching an application on another drive, but that no longer seems to be possible since System 7. Once you're using a System, you're stuck with it until you restart -- which would wipe out any custom driver I had installed.

So I started thinking about ways to hack the hardware to make it boot from the CF. The most obvious approach would have been to pull the ROM off the board and replace it with a patched copy. But I didn't fancy the idea of messing with a multilayer surface-mount PCB carrying chips with microscopically small leg spacings. (Modern computer construction is really spoiling us hardware hackers' fun.)

What to do, then? Well, if I couldn't change the software to deal with the device, maybe I could change the device so it looked the way the software was expecting. This approach seemed much more practical, because, as luck would have it, the IDE-to-CF adaptor board I purchased happened to have, in addition to the 44-pin 2mm-spacing connector for the "compact" IDE cable, a set of holes for mounting a standard 40-pin 0.1-inch spacing connector. If I fitted a socket to that, I would have easy access to the whole IDE bus.

After some head-scratching, I came up with the circuit shown in the diagram below. It "snoops" on the IDE bus, waiting for the host to issue an Identify Device command. When that happens, it modifies the first word of data sent back to the host from the device, changing bit 15 from 1 to 0. Then it goes back to sleep and leaves everything else alone.

To cut this ever-growing story mercifully short, it did the trick perfectly. After plugging it in, the next time I switched the Powerbook on, it started up -- in total quiet!

So, now I have my ideal portable I.F. device -- completely silent, low power, and rugged enough to use balanced on my knee without any fear of provoking another head crash. And the distinction of containing a neat piece of hardware hackery!


This shows the 40-way header socket that I fitted to the CF adapter board.	Top view of the hack board.	Bottom view of the hack board. A DIL header with the pins pushed through mates with the 40-pin socket shown at left. I had to arrange one additional connection for +5V.

Where did I get the adaptor board?

I ordered my adaptor board from flashmemory.com.au in Australia. Another Australian source is everythinglinux.com.au. There are many US sources as well; try googling for "compactflash ide adaptor".