For Lisa computer owners, and Macs with only one floppy connector, disk drive emulation can be awkward sometimes. The Apple Disk Drive A/B Switch aims to eliminate that awkwardness. Available now from the BMOW Store, this board makes it possible to attach a Floppy Emu and a real floppy disk drive at the same time, and select between them with an A/B switch. Both drives will be powered, but the computer will only “see” one drive at a time, depending on the switch position. If you’ve got a single-drive system, and want to work with physical floppy disks and the Floppy Emu without a lot of cable swapping, then this is for you.

The board design is about as simple as it gets. A 20-pin ribbon cable connects the “IN” port to the computer’s logic board. The Floppy Emu is attached to “Disk A” and the real floppy drive to “Disk B”, or the other way around – it doesn’t matter. All of the power and data signals are shared between all three of the connectors on the A/B board, except for the ENABLE signal. By moving the A/B switch, you can alternately connect the computer’s ENABLE signal to either Disk A or Disk B. Both disks also have a 3.3K ohm pull-up resistor on their enable inputs, to ensure they’re disabled while they’re not selected with the switch.

There was some interest in designing customized versions of this A/B board, so I’ve posted the Eagle design files. The design is released under the Creative Commons BY-SA license, and you’re welcome to use it in your own designs.

On the road to Apple II floppy disk emulation, I’ve picked up a couple of new members for my retrocomputing collection. Above is a classic Apple IIe – let’s call her Edna. The eBay seller didn’t believe much in bubble wrap or other packing materials, so Edna suffered a cracked corner and bent bottom plate during shipping, but she still works just fine. Below is a boxy fellow I’m calling Gary, an Apple IIgs with ROM revision 01. I also picked up an Apple 3.5 Drive and a 5.25 Drive, and some blank double-density disks. None of the computers or drives came with any bootable disks, though – a fact that would soon create trouble.

 
Apple II Video Out

When powered up, both computers beeped and seemed to be working OK, but without a monitor I was working blind. The IIgs has an RGB video port that looks like the video connector on a Macintosh II, but none of my Mac video adapters could get any picture from it. I later learned it’s an analog RGB signal at TV frequencies, not VGA frequencies, and is unlikely to work with anything but a true IIgs monitor or a few other CRTs from the 80’s. That meant I was stuck with composite video for both machines – that yellow RCA plug that harks back to the days of Nintendo NES.

What do you connect a composite video signal to in 2015? I tried my living room TV and it worked fine, but I wanted a desk-sized monitor instead of a 40-something inch HDTV. I tried the composite video input on my Dell 2007WFP LCD monitor, but got nothing but a blank screen. Hmmm. After doing some reading, I learned that the composite video output from the Apple IIs isn’t quite NTSC standard, and the 2007WFP rejects marginal video signals like the Apple’s. The similar Dell 2001FP LCD monitor was reported to work well with Apple IIs and other vintage computer equipment, though, and I was lucky to find someone local selling an old 2001FP. Success! Now, anybody want to buy a used Dell 2007WFP?

 
Bootstrapping with No Disks

With working video, I could boot Edna and Gary, hit control-reset, and have fun typing “STEVE IS GREAT” programs in BASIC. But to really do anything interesting, I needed some disks. For the IIgs, I discovered that you can download a Disk Copy 4.2 image file of IIgs software, use a vintage Mac to write the image to a 3.5″ disk, and the IIgs will happily boot from it. That was great, but it still left me without an easy way of transferring or making 5.25″ disks, or any way of making disks directly with Edna.

Fortunately there’s an excellent piece of software called ADTPro, that can be used to bootstrap an Apple II computer without any other hardware. It works by connecting to the Apple’s cassette in port or serial port, and transfers disk images from a server on a modern PC. Less fortunately, the IIgs doesn’t have a cassette input port, and Edna didn’t come with a serial card. I also didn’t have a Mini-DIN-8 to DB-9 serial cable for making a serial connection to Gary, so that left a cassette port connection to Edna as the only option.

To make a long story short, the ADTPro cassette audio method didn’t work. The first part of the bootstrap process went fine, and I could load the ADTPro client on Edna using the cassette link. But to actually transfer any disk images required two-way communication using two audio cables: one from the PC’s headphone out to the Apple’s cassette in, and another from the Apple’s cassette out to the PC’s microphone in. I’ve only got one PC that even has an analog audio input, and the line level was too low for the ADTPro software to hear the data coming from the Apple. No amount of config changes or level boosting seemed to help. After reading about it, this appeared to be a common problem.

I finally broke down and hand-built a Mini-DIN-8 to DB-9 serial cable for the IIgs, using an Imagewriter II printer cable and a DB-9 cable. It was a lot of fiddly soldering and beeping out wires and swearing at burnt thumbs, but I eventually got it to work. Of course, I learned later that I could have just bought a pre-made cable that’s designed for use with ADTPro. Oh well. With a working serial connection, I can now transfer both 3.5″ and 5.25″ disk images to Gary using ADTPro, and make 5.25″ disks with Gary that will work with Edna. Yes!

 
Floppy IIGS

The point of all this Apple II business is to get Floppy Emu working on Apple II systems. Floppy Emu has a 19-pin D-SUB connector and can emulate 800K disks, and the IIgs has a 19-pin D-SUB connector and can read 800K disks. So maybe you can just plug it in, load a IIgs disk image, and it will work? Sadly, it’s not that easy, and a direct plug connection to a IIgs doesn’t work. I’m not entirely sure why, but it’s something I’ll be investigating closely.

I’d heard from a couple of people that Floppy Emu did work with the IIgs, if you used part of an Apple 3.5 Drive to make the connection. If you open up an Apple 3.5 Drive, inside is a standard Sony 800K floppy drive (identical to those used in early Macs), and another small board called the daisy chain board. The daisy chain board is what’s actually connected to the computer. The board has an internal private connection to the Sony drive, as well as another 19-pin D-SUB where a second daisy-chained drive can be connected. The photo below shows a partially disassembled Apple 3.5 Drive, with the daisy chain board tucked inside, just behind the actual floppy drive mechanism.

With a screwdriver and some gentle tugging, I was able to further disassemble the drive, separating the daisy chain board from everything else. On the underside of the daisy chain board, not pictured, are some electronics and a custom controller chip of some kind. What does it do? Hmmm.

I took the newly-liberated daisy chain board, and connected it to the IIgs using a 19 pin D-SUB to 20 pin ribbon cable – basically the same cable that I sell in the BMOW store. Then I attached the internal drive connector to a Floppy Emu, running the normal Macintosh floppy firmware.

And it worked! I was able to boot GS/OS from an emulated disk on the Floppy Emu with no troubles. I did notice one oddity, however. After accessing the disk, the IIgs always left the disk motor on. Even when the computer wasn’t doing anything, the status LED on the Floppy Emu board continued to flash, and the LCD said “read”. I’m not sure if this is some quirk of my setup, or an issue with the Macintosh floppy firmware being not quite 100% IIgs compatible.

 
The Mysterious Daisy Chain Circuit

So what does this daisy chain board actually do, that allows the Floppy Emu to work on the IIgs? A detailed answer will have to wait for a future post, but as best as I can tell, it’s just some lightweight interface circuitry that helps identify the drive to the computer, and enable it at the correct time. Other than that, it doesn’t seem to get involved with the actual control of the drive or the data transfer in any way. There’s a schematic of the daisy chain board here: page 1 shows the whole board, and page 2 shows what’s inside of the “DSIC” box on page 1.

It looks like pin 4 of the 19-pin D-SUB (pin 7 of the 20-pin ribbon connector) is used as an extra enable signal, for selecting between 3.5″ and 5.25″ disks on the daisy chain. The drive’s RD line is connected both to the computer’s RD line as well as the computer’s WRPROT line. Then there’s some complex-looking enable circuitry involving a 74LS123 one-shot. As far as I can figure, its behavior is this: if the computer enables the drive by asserting /DRIVE1 and /EN3.5IN, then it can afterwards de-assert /DRIVE1 and the circuit will keep the drive enabled for about a second. But if the computer de-asserts /EN3.5IN, or asserts /DRIVE2, then the drive will be disabled immediately. I have no idea why that behavior is important, but there it is.

About half the schematic is related to the daisy-chain circuitry and the eject button, neither of which I need. (Here’s an edited version of the schematic with all the daisy-chain and eject logic removed.) The enable circuit with the one-shot is confusing, but the rest looks like it might not be too difficult to duplicate. Then I could make a little adapter board that allows the Floppy Emu to plug into a IIgs without sacrificing an Apple 3.5 Drive. Maybe even build the necessary circuitry into future versions of the Floppy Emu. Now I need to set out my tools and get to work!

About six weeks ago, I made a post titled “The $11185 Connector”, about my search for the increasingly rare 19-pin D-SUB and the price quoted by one Chinese factory to manufacture them. This post attracted a lot of negative comments, and I eventually removed it, but the original post was republished here. The point of the post was that custom manufacturing of DB-19s was going to cost substantially more than I’d hoped, and given the small sales volume of Floppy Emu boards that need the DB-19s, it probably didn’t make economic sense for me to commission new manufacturing. Instead, I’d have to research possible DB-19 substitutes.

Earlier today, I discovered two more sites where that post was linked/republished, and a parallel discussion had sprung up without me knowing about it. That was strange and a little uncomfortable, like finding people talking about you behind your back. The themes of these commenters were similar to the comments on my original post:

1. Why are you using a DB-19? Don’t you know it’s obsolete? Your design is crap.
2. You’re doing it wrong.
3. You’ve a naive idiot.
4. You’re a racist asshole.

Some of these comments were understandable, if inflammatory, if you didn’t know what I was building and why. For the sake of any readers who don’t normally follow the BMOW blog, I use DB-19 connectors for a vintage computing product called Floppy Emu, which plugs into the external DB-19 floppy port of a 1980’s or 1990’s Macintosh computer. Apple chose the DB-19 back in 1984, and I’m stuck with it. The sales volume is fine for a hobby product, but very low by any professional standard. $11185 to manufacture a batch of new DB-19s would be more than an entire year’s net profit.

That’s not to say that $11185 isn’t a fair price for the work involved, or that Chinese manufacturers should work for pennies while I rest my feet on their backs and smoke a cigar. It’s a custom-made part, so there will be engineering setup costs involved before they can make anything, and of course they’ll expect me to pay those costs. That’s perfectly fair. In my naivety I hoped that existing DB-25 or DB-15 machinery might be easy to adapt for building DB-19s, so the setup cost might be only $1000 or so. Apparently that’s not the case.

A few people suggested I was foolish for using Alibaba to find D-SUB manufacturing contacts, saying that I’d never find the best price that way. That’s probably true, but being a single-person low-volume business, I don’t have a Rolodex of contacts at worldwide manufacturers whom I can phone up to ask for quotes. If there’s a better way to find possible manufacturing partners, I’d love to know about it.

Quite a few people linked sources for DB-19s that they found on the web. Unfortunately those leads were all dead-ends. There are at least a dozen electronics suppliers whose sites claim to have DB-19s in stock, but if you call them to place an order, you’ll find they don’t actually have them, or only have a handful. I’ve scoured the web pretty thoroughly, and bought all the large DB-19 supplies I could find. I may have overlooked some, but if so, they’re well-hidden.

A huge number of people suggested I take DB-25 connectors, which are readily available, and cut six pins off the end to make a DB-19. And for a one-off project for personal use, that might be the best solution. I don’t actually manufacture the Floppy Emu boards myself, though – they’re made in batches of ~100 at a time by an electronics assembly company. I spoke to them about the possibility of making DB-19s this way, and they weren’t enthusiastic. They were willing to try it, but believed it would be an awkward, error-prone, and manually time-intensive process that would yield inconsistent results.

 
Today

I eventually found a supply of 500 old stock DB-19 connectors in Eastern Europe. Depending on the Floppy Emu sales rate, which fluctuates wildly, this should last me anywhere from three months to a year or so before another “DB-19 crisis” hits. So what then?

After more research, I also found another D-SUB manufacturer whose bid was significantly cheaper than the first one. Buying DB-19 connectors from them would still be a very large expense, and would require pre-purchasing 5 or 10 years worth of supply, requiring a lot of faith in the long-term sales prospects of Floppy Emu. But if I can’t find another good option, this may be the best solution.

I also worked on a couple of possible DB-19 substitutes, pictured below. They’re just 19 pins sticking out of a custom-made PCB, with a cable connector on the back. They work, but they lack the surrounding shield of a normal D-SUB, and don’t look very professional. I used a pair of rectangular LEDs as alignment guides!

The version on the left uses individual D-SUB crimp pins, with the crimp portion cut off each one. It’s a bit of a hassle to assemble, soldering it is awkward, and it costs $4 for the pins alone. But the result fits well in the D-SUB socket. The version on the right uses standard 0.1″ square pin header. The pin spacing isn’t quite right for a D-SUB and the pins are supposed to be round and not square, but the result is close enough that it seems to work fine, and it’s less hassle to put together.

The most promising lead is from IEC, a vendor of cables and connectors that used to sell DB-19s before they exhausted their stock. On two occasions, their salespeople told me DB-19s were discontinued and they wouldn’t be getting any more. But I later received email from someone at the company saying they were working on getting more DB-19s, using some kind of new manufacturing process. In fact, during the time I’ve been typing this post, I received another email from him saying they expect to have something available by June! Assuming we’re talking about the same part, and the price is similar to what it was before, that could be the answer I’ve been looking for.

How can you deal with signals that might be inputs or might be outputs, in a way that’s safe and won’t damage sensitive electronics? In my last post I described three different types of Apple II family floppy drives. Since then, I’ve started looking further into SmartPort emulation for the Floppy Emu, which would extend 800K floppy and hard drive emulation support to the Apple IIc and IIgs. The required pinout on the D-SUB 19 pin connector is almost the same as what’s currently used by Floppy Emu, but not quite identical (inputs to the computer marked in bold):

Comparing the Floppy Emu pinout to the IIc and IIgs, a few pins must change from computer outputs to computer inputs. And a few other pins marked with * take on a new bidirectional behavior, being used both to control the floppy drive and to sense the type of the connected drive. All the non-power pins for Floppy Emu are connected to a CPLD, and can be switched from inputs to outputs with a firmware change, so by itself that’s not a problem. The trouble arises if you want to use a single Floppy Emu board on different computers at different times, functioning in different modes. If the Emu is configured for the wrong mode for the computer it’s presently attached to, it could damage both the Emu and the computer. Sooner or later somebody (or me) would make that mistake.

Let’s look at what this means for SmartPort emulation on an Apple IIc or IIgs. On the IIgs, pin 4 is no longer a ground pin, but instead is used to switch between Apple 3.5 drives and other types of drives. We’re not trying to emulate an Apple 3.5 drive yet, so we can safely ignore that difference and continue to use pin 4 as GND. On the IIc, pin 9 is an external interrupt. We don’t need that for SmartPort emulation, which is fortunate because it’s not even connected on the Floppy Emu end.

Pin 10 is the main problem. On the Mac, it’s an output from the computer, but on the whole Apple II line it’s an input. It either indicates the disk’s write-protect status (normal disks), or serves as an ACK signal (SmartPort). If the Floppy Emu is configured to output a WPROT or ACK signal on pin 10, and is connected to a Mac that outputs PWM on pin 10, the two chips will fight each other and cause damage. Zap!

Pin 16 is also a problem. On the Mac and the Apple II/II+/IIe, it’s either an output from the computer, or a +5V connection that will look like a constant logical 1 output. But a SmartPort device turns things around, and uses pin 16 on its daisy-chain port to determine if the next device in the chain is also a SmartPort device. It has an internal pull-up on the daisy-chain pin 16, and it checks the value on that pin. If it sees 0, that means the next device is also a SmartPort device, and if it sees 1 it means it’s not a SmartPort device or there is no device present. The IIgs may behave the same way, although I’m not sure. So in order for Floppy Emu to be detected as a SmartPort device, it may need to output 0V on pin 16. That’s another potential for two chips fighting. Zap again!

 
Playing It Safe

The question is how to make an Apple II SmartPort mode firmware for Floppy Emu, while avoiding potential electrical damage if you accidentally set the wrong mode on the wrong computer.

Caveat Emptor – I could do nothing. As long as you switched into Apple II mode after connecting the Emu board to an Apple II, and switched into Mac mode before disconnecting from the Apple II, you would never have two chips fighting on the same line. But that’s a poor solution. What if you borrowed a Floppy Emu from a friend for use with your Mac, and you didn’t know what mode it was in? Or you just plain forgot?

Physical Adapter – I could build a small passive adapter that sits between the computer and the Floppy Emu board. An inline resistor of about 100 to 330 ohms on pin 10 should prevent possible damage if two chips were fighting. The same solution would probably also work on pin 16, although correct functioning would depend on the value of the SmartDisk pull-up resistor and the logic threshold of the chip it used to sense the value of pin 16. But I’d really like to avoid requiring an adapter if I can. It would be so much nicer if you could just plug your Floppy Emu straight into your IIgs or IIc and have it work.

Detection – Maybe I could somehow detect whether the attached computer is an Apple II or a Mac, and only switch pins 10 and 16 to outputs after confirming it’s an Apple II. That sounds good, but how? Is there a way with the existing hardware that the CPLD could tell if pin 10 is being actively driven with some value, instead of just floating? Or maybe try to detect a SmartPort reset state before switching the pin directions? I’m not confident the SmartPort reset state won’t also be triggered accidentally by Mac drive logic like the HD20 control routines.

Button Push – I could require the user to push a button to “confirm” Apple II SmartPort mode, each time the Emu board was reset, before switching the pin directions. That would be a little inconvenient, and would still have some potential for damage if you pressed the confirmation button when you shouldn’t have. But it’s the best solution I’ve thought of thus far.

I’ve begun looking into the possibility of Apple II disk emulation with the existing Floppy Emu hardware. The recent research project into Lisa floppy emulation turned out well, so why not do it again with another vintage Apple computer? A cursory check of connector pinouts suggests it’s at least theoretically possible, though it would require major changes to the emulator firmware. But Rome wasn’t built in a day, so let’s start.

There are a confusing number of different Apple II family models and floppy drives. Some are 5.25 inch drives, and some are 3.5 inch. Some use a 19-pin D-SUB connector, and some use a 20-pin ribbon connector. Because of these differences, “Apple II disk emulation” won’t be a single emulator mode, but several different ones depending on the Apple II model and disk image being used.

This summary of Apple floppy drive models gives a nice overview. For the purposes of Apple II emulation, the drives can be organized into three categories: the venerable Disk II and its cousins (Disk IIc, Unidisk 5.25, Apple 5.25, Duodisk 5.25), the SmartPort-based Unidisk 3.5 (A2M2053), and the Apple 3.5 external drive (A9M0106).

 
Disk II Emulation

Emulation of low-density 5.25 inch Apple floppies would be useful for the Apple IIe and earlier models. These computers used a Disk II controller card in an internal slot. The controller card has two 20-pin ribbon connectors, each of which can be connected to a Disk II drive. The pinout of this 20-pin connector is almost identical to the pinout of Floppy Emu’s 20-pin connector. So with the right firmware (five words that gloss over a huge amount of work), you could plug a Floppy Emu directly into the controller card and emulate a Disk II floppy drive. Or plug two Floppy Emus into each of the two controller card connectors, and emulate two drives. With a custom multi-ended cable, it might even be possible to emulate two drives with a single Floppy Emu.

The only obvious mismatch is at pin 20. On the Mac, PWM is an output that controls the rotational speed of the 400K floppy drive. But on the Apple II, WPROT is an input that indicates whether the disk is write-protected. So depending on the emulation mode, pin 20 on Floppy Emu would need to behave like either an input or an output, and that’s a problem. The Emu uses a CPLD to interface with the computer, and it’s easy enough to modify the CPLD to change a pin between acting as input or output. But in practice this would be problematic and dangerous.

Let’s say your Floppy Emu board was configured in Apple II mode, and you plugged it into your Mac, with the intention of switching it to Mac floppy mode. But before you could even access the mode select menu, you’d have two outputs fighting each other on pin 20, possibly damaging the Floppy Emu, the Mac, or both. You could work around this problem by connecting the Emu to and Apple II and then switching to Mac floppy mode from there, but it would be an awkward and error-prone process. Some kind of passive adapter could probably solve this problem, with an inline resistor on pin 20, but I’d prefer to find a solution that doesn’t require extra hardware.

To complicate matters a bit more, there are two different standards for Apple 5.25 floppies. DOS 3.2.1 and earlier stored 113.75 KB per disk, 256 bytes per sector, 13 sectors per track, 35 tracks per side. But DOS 3.3 and later used a more efficient GCR encoding to store 140 KB per disk, 256 bytes per sector, 16 sectors per track, 35 tracks per side. As I understand it, this change also required a new version of the Disk II controller card. Was the newer one backwards compatible with the old format? Then there was ProDOS, which I believe used the same low-level format as DOS 3.3, but with a different filesystem. So Disk II emulation might actually involve two or three separate emulation modes, depending on the specific disk image being used.

The later cousins of the Disk II switched to a 19-pin D-SUB connector instead of the 20-pin ribbon connector, but the drive itself remained basically the same. The 19-pin connector pinout matches Floppy Emu’s 19-pin connector just as well as the 20-pin, with no problems except the collision of PWM and WPROT on the same pin. That means it should be possible to connect a Floppy Emu in Disk II mode to an Apple II with a 19-pin controller card, or with a 19-pin external floppy port such as found on the Apple IIc.

 
SmartPort: Unidisk 3.5

Next we have the Unidisk 3.5, an 800K floppy drive using the SmartPort communication protocol. Unlike the “dumb” Disk II, the Unidisk 3.5 was an intelligent device, communicating with the Apple II using a high-level request/response protocol that abstracted away the details of tracks and sides. From what little I’ve read about SmartPort, it sounds fairly similar to the HD20 protocol that I implemented a few months back for the Mac. It looks like there are already a couple of SmartPort-based disk emulators out there: UNIDISK and an SmartportCFA. That gives me hope that the SmartPort protocol wouldn’t be too difficult to implement.

Here’s where my understanding of things starts to get fuzzy, so if I say anything here that sounds incorrect, please let me know. It looks like the Unidisk 3.5 works on the Apple IIc, but only with certain ROM versions. There’s also a sub-model called the Apple IIc+, but I’m unclear if that’s anything more than a ROM upgrade, or what disk-related features the IIc+ offers over the IIc. The Unidisk 3.5 is also supported on the Apple IIgs, but it’s not recommended, because the performance is worse than can be achieved with non-SmartPort drives.

Did Apple ever sell other SmartPort drives, besides the Unidisk 3.5? I saw one source that mentioned SmartPort could support up to four drives per connection, and up to 32 MB per drive. If that’s true, could a SmartPort implementation on the Floppy Emu provide pseudo hard drive capability to the IIc and IIgs? I’m not sure.

How does the IIc or IIgs detect that a connected drive is a SmartPort drive, as opposed to a dumb 5.25 drive, or a non-SmartPort Apple 3.5 drive? Maybe it just sends a SmartPort request, and checks to see if anything responds. Or maybe there’s a pin that’s used to sense the drive type. The docs refer to a /3.5DISK signal on pin 4 of the 19-pin D-SUB, though I’m unclear how it’s used. More on this later.

Comparing the pinouts of the Floppy Emu 19-pin D-SUB connector with the Apple IIc and Apple IIgs, they mostly match up, but there are some noteworthy differences. There’s some disagreement about the published pinouts too, depending on which source you trust. I believe these are correct, and the Apple IIc+ is the same as the IIgs:

There’s the same collision between PWM and WPROT that we saw previously, and I’m still not sure how best to resolve it. Then there’s this /3.5DISK signal on pin 4 of the IIc+ and IIgs, where others have an extra ground pin. What the heck? How is that used? Is it an input, an output, or both? The usage of pin 16 varies, but that shouldn’t cause a problem for the Emu, assuming the firmware is changed appropriately.

The biggest discrepancy is at pin 9, which isn’t physically connected on the Floppy Emu board. This is some kind of external interrupt on the IIc, which I think can be safely ignored. But on the other systems, pin 9 is used to select the second drive in a two-drive configuration. That means the Emu will be limited to emulating only a single drive, which is probably fine since that’s all it does anyway.

 
Apple 3.5 Drive

Last of the bunch is the Apple 3.5 Drive. Unlike the others, this drive functions on the Macintosh as well as on Apple II systems. It is not a SmartPort drive. How does that bit of magic work? I wish I understood it. Internally it’s the same Sony 800K mechanism that’s in the Unidisk 3.5 and in standard Macintosh floppy drives like the M0131, so the difference is only in the interface circuitry. I believe the Apple 3.5 Drive is supported on the Apple IIc+ and the IIgs, but it may also be supported on the standard model IIc – source seem to conflict on this point.

How does the computer know that an attached floppy drive is an Apple 3.5 Drive, and not a Unidisk 3.5 or other SmartPort drive, or a dumb 5.25 drive? I’m not sure, and the lack of documentation is frustrating. You can’t just plug a Macintosh floppy drive directly into a IIgs, so obviously there’s some difference in the way it identifies itself to the Apple II, but what is it? If I can find the answer, then I think the existing Floppy Emu firmware should work as-is for Apple 3.5 Drive emulation on the IIgs and IIc+.

Incidentally, if you have an Apple 3.5 Drive, you can remove its drive mechanism and substitute a Floppy Emu in its place. Combined with the 3.5 Drive’s internal daisy-chain board, this combination works today with the current firmware, on the Apple IIgs (and presumably also the IIc+) for 800K disk emulation. See Bryan Villados’ example on the Apple II Enthusiasts group.

 
/3.5DISK Mystery Signal

The biggest mystery at the moment is how an Apple II system can detect what type of floppy drive is connected, and this /3.5DISK signal on pin 4 seems to be part of the answer. For detecting the difference between a dumb 5.25 drive and a SmartPort Unidisk 3.5, I think /3.5DISK must be irrelevant, because the standard model Apple IIc lacks the /3.5DISK signal but can still use a Unidisk 3.5 drive. Also, SmartportCFA successfully emulates a SmartPort drive, and doesn’t even connect pin 4. My guess is the computer sends some kind of SmartPort “init” command that will fail in a predictable way on a dumb 5.25 drive. Exactly how that works will have to wait for a deeper investigation of the SmartPort protocol.

Most likely, the /3.5DISK signal is used only for detecting the Apple 3.5 Drive. If the Unidisk can be detected by a SmartPort query, then /3.5DISK is probably only for distinguishing between an Apple 3.5 and a dumb 5.25 Disk II drive. That sounds easy enough, but when I start to look at the details, I quickly get lost.

First: is /3.5DISK 0 for 3.5 inch drives and 1 for 5.25 drives, or vice-versa? Most sources refer to it as /3.5DISK or 3.5DISK*, both of which imply it’s an active low signal where 0 means it’s asserted, so 0 should mean to enable the 3.5 drive. This is also consistent with the fact that the Macintosh has pin 4 permanently tied to ground, and in order for the Apple 3.5 drive to function on a Mac, it would need to interpret the 0 volts on pin 4 as the assertion of /3.5DISK. However, this discussion from comp.sys.apple2 says it’s actually the opposite: 0 enables the 5.25 drive and 1 enables the 3.5 drive. Maybe the writer is just mistaken, but I’m not so sure.

Second, and more fundamentally: is /3.5DISK an input, or an output? If the purpose is to detect what type of drive is connected, then it should be an input. None of the documentation I’ve seen actually specifies, but from a few odd comments and schematics, I’ve inferred that it’s actually an output. As best as I can determine, then, /3.5DISK acts more like a secondary enable signal than a drive type detection signal. When /3.5DISK is asserted, then the attached Apple 3.5 drives should respond, and when it’s not asserted the dumb 5.25 drives should respond. Combined with the /ENABLE1 and /ENABLE2 signals, this would provide a way to control two drives of each type, and four drives total (not counting SmartPort). But there’s a problem with this interpretation – the dumb 5.25 drives don’t know anything about /3.5DISK. They think pin 4 is a ground connection, so they’re not going to play along nicely. Obviously I’m missing something, because this just doesn’t add up.

The comp.sys.apple2 discussion that’s linked above further confuses the issue. It refers to /3.5DISK as “an extra enable” line, but also says “The Apple 3.5 drive uses this signal (on its daisy-chain connector) to sense whether a 5.25″ drive (or SmartPort drive?) is connected at the end of the chain.” In this context where it’s used to “sense” a drive’s presence, it sounds like /3.5DISK is an input. Maybe it’s actually some kind of clever circuit that’s both an input and an output, depending on the context.

A final question: what’s the difference between the Apple 3.5 drive and a standard 800K Macintosh floppy drive? The Apple 3.5 drive works on both an Apple IIgs and a Mac – how does it accomplish this? If the answer were only related to the /3.5DISK signal, and that signal was strictly an output from the IIgs, then a Mac 800K drive ought to happily ignore that signal and still respond to the /ENABLE1 signal, and work fine on a IIgs. But that’s not what happens, so there’s a piece of the puzzle I’m missing.

I’ve merged the Lisa floppy emulation functions into the latest Mac version firmware, to create a super universal firmware! it’s a single firmware for Floppy Emu with support for Mac and Lisa, floppy and HD20, raw disk images and Disk Copy 4.2 images. It also brings the benefits of writable DC42 disk images to the Mac. Sorry, it does not make sandwiches or wash your car, but it does nearly everything else. Press the SELECT button while the Emu is displaying version info on the LCD, you’ll enter a config menu where you can choose to operate as a hard disk, Mac floppy drive, or Lisa floppy drive. The new hd20-0.7B-F14.5 universal firmware is available now.

A few other odds and ends:

 
Checksums

After some discussion, I’ve altered the strategy for updating Disk Copy 4.2 checksums. I still don’t have a good solution for keeping the checksums updated when the disk image is modified, but instead of leaving the old (wrong) checksums in place, this new firmware sets the checksums to zero upon the first write to a DC42 image. Hopefully this will make it clearer for some future archivist who may encounter the modified image file, and he’ll understand the checksum was intentionally zeroed, rather than the image file being corrupted.

dc42cksm – I wrote this simple command line program to view the checksums in a Disk Copy 4.2 disk image file, and optionally to update the checksums if they’re not correct. If you ever have some burning need to copy a modified DC42 file off your SD Card, and import it back into Disk Copy 4.2 on the Mac, this tool can fix up the checksums for you. It’s a Windows command-line executable, but the source code is also included if you want to recompile it for OS X or Linux.

 
Blank Disks

Todd Meyer pointed out that blank 400K disks created under Lisa Office System 3.0 and 3.1 aren’t usable under Lisa Office System 2.0. The difference seems to be similar to the distinction between MFS and HFS disks on a vintage Macintosh system, except I don’t think the Mac ever used two different filesystems for the same sized disk. Thanks to Todd for providing a working LOS 2.0 blank disk image, which I’ve included with the lisa-emu-1.0S7-F11 firmware (below), and for the femu-on-Lisa photo that appears above.

 
A Spare Firmware

In case any problems are discovered with the new universal firmware hd20-0.7B, I’m also releasing an updated version of the Lisa-specific firmware, lisa-emu-1.0S7-F11. This is identical to the 1.0S6 Lisa firmware that I released yesterday, except that the checksum in the DC42 image file will be set to zero upon the first write to the disk.

 
???

The Lisa computer is a strange beast. It was the first mainstream home computer to feature a GUI instead of a text-based interface. It’s been interesting working with the Lisa while I developed the new floppy firmware, and for a time I thought maybe I’d like to get a Lisa system of my own when the time comes to return this borrowed machine. But the Lisa never really grew on me, and I can’t exactly say I’ll miss it when I need to give it back.

Running the Macintosh OS under MacWorks isn’t too bad, except that the machine has twice the bulk and weight of a contemporary Mac system. It’s just… unwieldy. That’s not meant as a dig against the Lisa – pretty much all computers of that era were unwieldy by today’s standards – but it’s impressive how much slimmer Apple was able to make the Mac 128K just a year after the Lisa, using most of the same technology except for the internal hard drive.

From the viewpoint of someone in 2015, the native Lisa OS (Lisa Office System) is truly baffling, ugly, and awkward. I’m not surprised Apple had such trouble selling Lisa systems before MacWorks came along. As the first real GUI computer, it’s no wonder Apple didn’t nail it 100% on the first attempt, so I don’t fault the Lisa or its designers for that. It’s fascinating to see this example of an early GUI, in contrast with the continuing improvements that appeared later in the Mac and other GUI systems.