Skip to main content
Home Forums Interface information for 400KB Floppy drive Interface information for 400KB Floppy drive
Thread

Interface information for 400KB Floppy drive

Interface information for 400KB Floppy drive 68k 43 posts Nov 24, 2009 — Dec 11, 2009
I have started work on a project to emulate the floppy drive used in the original Macintosh.

My goal is a device which is plug compatible with the Apple external 400KB floppy drive. It will store images on some sort of modern storage medium.

I have been reading up on the Integrated Woz Machine when I realized that I am studying the wrong part. I need to learn about the floppy drive. I am looking information on the floppy drive and how to interface to it. From there I should be able to design a device that has the same behavior. I have tried googleing it, but my google-fu is failing me.

We have some guys here that really know these machines inside and out, so I am hoping that someone can point me in the right direction.

My goal is a device which is plug compatible with the Apple external 400KB floppy drive. It will store images on some sort of modern storage medium.
Thanks for taking up this project, whatever the outcome.

I presume you are looking for more than the pinouts.

This is probably a really good place to start.

This device has insufficient memory capacity to replace a Mac drive, but that's just a detail. The unit supports emulating an Apple ][ drive, and IWM is *basically* the same as the Apple ]['s controller. Understanding this thing should pretty much tell you all you need to know.

My goal is a device which is plug compatible with the Apple external 400KB floppy drive. It will store images on some sort of modern storage medium.
Thanks for taking up this project, whatever the outcome.

I presume you are looking for more than the pinouts.
Yeah I've never interfaced to any sort of storage device before. So I really have no idea what data and commands the drive expects. So really if I could figure out how any floppy works that would be a good start.

Yeah I've never interfaced to any sort of storage device before. So I really have no idea what data and commands the drive expects. So really if I could figure out how any floppy works that would be a good start.
The original Inside Mac volumes should help as well, since they describe the disk drive's hardware, controller lines, format, and such.

So I really have no idea what data and commands the drive expects. So really if I could figure out how any floppy works that would be a good start.
Ah. That's what I though. Well DogCow is right Inside Macintosh is a good place to start if you haven't already.

I took a look at Inside Macintosh. It did some useful information, but it mostly described the software interface to the disk controller. I am looking for information on the interface between the disk controller and the disk drive.

Really the thing is that I don't have a bloody clue how you make a floppy disk drive work. So I think I need to expand my search to floppy disks in general and then focus on the Mac drive.

do you have an oscilloscope?

Really the thing is that I don't have a bloody clue how you make a floppy disk drive work. So I think I need to expand my search to floppy disks in general and then focus on the Mac drive.
A disk comprises tracks. Each track has a number of sectors. The mac makes things interesting in that

(a) it uses variable speed and more sectors on outer tracks

( B) it does not use the standard IBM MFM format.

A disk controller controls a drive by stepping the head in and out, and reading the data from the head. It's up to the controller to decode the series of sectors as read by the disk.

Each sector is preceeded by a header which says which sector number and track. Then a gap, then the data. When the data is written it has to wait for the correct sector header, then write the sector following the gap.

http://en.wikipedia.org/wiki/Group_code_recording Look for the work "Wozniak"

do you have an oscilloscope?
Yes I do, but is one of those cheap Radio Shack Scope Pens. I think it only goes to 2MHz, but that should work for this.

I think I am going to pick up on those USB Logic Analyzers. They are fairly inexpensive, I have found a couple for about $150.

Right now I am in the information gathering stage.

do you have an oscilloscope?
Yes I do, but is one of those cheap Radio Shack Scope Pens. I think it only goes to 2MHz, but that should work for this.

I think I am going to pick up on those USB Logic Analyzers. They are fairly inexpensive, I have found a couple for about $150.

Right now I am in the information gathering stage.
Well just the fact that you even have that pen (trust me I almost bought it many times before getting my tabletop eater 20mhz scope) makes me feel better about your abilities, reason why I would even care is because eventually I would like to do a similar thing with my //C (among other mods) ... but first I gotta get it working again we have strong mains in this area and it pushed an already failing cap over the edge, gotta muster up willpower and money to do a full restoration on it now heh

I've done some embedded systems work before.

In college my senor project was a 4'x2' display that showed the internal data flow of the pipe line of a MIPS process. I designed the controller for the nearly 500 LEDs that were on the display. It was a PIC that communicated with an IBM PC over RS232 and used a series of multiplexors, a few darlingtion arrays and a couple of latches to drive the LEDs.

I actually have a good understanding of digital logic, so my understanding of electronics is only so-so. So I have a lot of learning to do. Which is why I am looking for all of the manuals I need to read.

I purchased a Arduino Duemilanove from sparkfun along with the screw shield. The Screw shield is a kit so I get to pull out my soldering iron right away.

I figure I have a good set of information now. So now I need to read it in depth and start making notes. Then I figure I get the Arduino going and figure out how to do some basic I/O. It has been a few years since I programmed a Microcontroller so I have to dust off some of the ol' cobwebs. In fact I still have a whole box of PIC microcontrollers, but I don't have a programmer anymore. I figured I would give the Arduino a go because it is popular and has a low entry cost.

After a day and a half of reading I realize I have a long road ahead of me. I figure I'll first try to interface to the floppy and read and write data to it. That would also be helpful and modern systems can't read or write 400/800K disks.

I am really looking forward to this project, because right now storage is a black box that I understand how it works. I don't like black boxes.

For those interested my notes so far. I think I am going to go buy a printer, because I hate reading on the computer. Can't scribble notes on the pages that way. :-D

http://www.downloads.reactivemicro.com/Public/Users/David_Craig/AppleIWMSpec1982.pdf (IWM notes)

http://en.wikipedia.org/wiki/Group_code_recording#GCR_for_floppy_disks (GCR wiki page)

http://support.apple.com/kb/TA39910?viewlocale=en_US (Apple notes with some floppy info)

Apparently Apple II and Macintosh floppy drives work the same way. Information on the 16 Sector Apple II disk controller might help.

http://www.brutal-deluxe.fr/documentation/iwm/iwm_19840426.pdf (Software control of IWM on Apple II. This has good GCR information)

http://www.scribd.com/doc/200852/Apple-IIc-Reference-Manual-Volume-1-1984Apple0300814A (Apple IIc Reference manual)

http://www.1000bit.it/support/manuali/manuali.asp (Bunch of Apple Manuals)

http://www.willegal.net/phpBB3/viewtopic.php?f=3&t=5 (Post about building a Disk II Controller)

http://www.willegal.net/appleii/appleii-disk-int.htm (A Disk II to PC Interface)

http://www.weihenstephan.org/~michaste/pagetable/mac/Inside_Macintosh.pdf (Inside Macintosh. Has good information about the data structure on the disk and the software interace to the IWM, plus the Pinout for the conector)

http://www.scribd.com/doc/201423/Understanding-the-Apple-II-by-Jim-Sather-1983Quality-Software (Chapter 9 is the floppy chapter. It looks to have a lot of good information on how a floppy works and how the Disk II controller works)

http://bitsavers.org/pdf/westernDigital/FD179X_Data_Sheets_May80.pdf

(Data sheet for Western Digital floppy controller. Contains some good information about the signals sent to the IBM 3740 and System/34 Floppy drive)

http://pdf1.alldatasheet.com/datasheet-pdf/view/128746/NEC/WD37C65C.html (Western Digital controller used in the PC/AT. Mentions SA450 drive interface. What is that???)

http://www.bitsavers.org/pdf/shugart/39013-1_SA450_OEM_Manual_Oct80.pdf (Manual for the Shugart SA450 Floppy Drive. This is good. Read and understand this. Need a similar manual for the drive used in the Mac.)

viewtopic.php?p=2361 (Has information about the ROM version and compatible drives. Also has lots of good links about the floppy drives.

Looks like the Sony Model number for the 800K drive is MFD-51W or some variant there of. Need to find a manual for it. Which Sony Division made it. Looks like Sony Storage. DUH!!! The Sony part number for the 1.4Mb disk drive is MP-F75W-01G. ALso

* Sony MPF 42A

* Mitsubishi MF355F-592MA

* Mitsubishi MF355F-2592MA

* Mitsubishi MF355F-3592MA

http://sony.storagesupport.com/

Dosen't look like the sony manual is available on the internet. So we'll have to go buy what we have on the Disk II.

good selection of notes!

and I use arduino quite a bit, the programing of it is pretty easy, you should have little issue picking it up (ps if you have any questions and the arduino forum is acting up feel free to ask)

For those interested my notes so far. I think I am going to go buy a printer, because I hate reading on the computer. Can't scribble notes on the pages that way. :-D
I don't know if you saw/skipped over the link I threw in about The Semi-Virtual-Diskette device, but if you missed it, well, just thought I'd point it out again. The page has complete construction details for a device that's capable of emulating the Apple Disk ][, including the source code for the PIC microcontroller. Unless you're intent on starting completely from scratch this device is already halfway there.

The thing that's "unique" about the Mac drive relative to the Disk ][ is the Macintosh 400/800k drives have a variable speed motor that turns at a different speed. (That's mentioned in the Apple knowledge base article you found.) This allows the drive to cram more sectors into the outer tracks of the disk than the inner ones without having to vary the data rate. What follows is a couple of completely pointless paragraphs I dreamed up which might help you visualize the situation in your head, assuming you're having any trouble. (Which you probably aren't.)

Floppy disks are like record players, in the sense that they read "from the outside in", unlike CDs and DVDs which read from the "inside out", in terms of what's considered "track 0". Imagine, say, a disk spinning slowly on a record player at a constant speed, say, one revolution every ten seconds, or 6 RPM. Pick up a piece of chalk and hold it against the record for one second, near the edge. (the edge is "track 0") You'll get an arc-shaped mark 1/10th of the diameter of the record. That's a "sector". Now take the chalk and hold it on the record for one second near to the hub. (In Mac terms this is "track 79") You'll also get a mark 1/10th of the diameter of the record *at that distance from the hub*, which means this sector is physically a lot shorter than the sector near the edge, as measured with a ruler. With "normal" disk formatting that's how sectors are written to a disk, same number of them per track from outside to inside. Since each sector contains the same amount of information in a sense you're "wasting" space on the outside of the disk, since in theory the magnetic medium should be able to retain data at the same density everywhere on its surface.

Now, imagine the same experiment with the record player, except instead of your hand with the chalk floating free you have a lever attached to the chalk which is connected to a potentiometer which controls the rotational speed of the record player. With this arrangement, the record player runs slower the farther you are from the hub. The record is still turning at 6 RPM when you're making chalk marks near the hub, but when you make a mark near the edge the record player is turning at only 4 RPM. Holding the chalk there for one second will make a mark only 1/15th the diameter of the record, meaning that near the edge you can fit 15 sectors instead of the 10 sectors you got with the constant speed record. The number of sectors per track diminishes as you approach the center, but the overall the sectors are closer to a uniform size then they are on the constant speed disk.)

Anyway. this is why, according to the Apple KB article, a 400/800K floppy disk has 12 512 byte sectors in tracks 0-15, while it only fits 8 in tracks 64-79. And thus the big difference between an Apple ][ disk, which has a constant 13 or 16 256 byte sectors on all 35 tracks, and a Mac disk. Looking at the Mac drive pinouts I just Googled there's a pin labeled "PWM" which says "Motor speed control". If you can find documentation as exactly what sort of signal is present on that port that's going to be the key to adapting a "constant speed" disk emulator design to working on a Mac. If the Mac directly drives the motor via Pulse-width modulation then I imagine you'll have to monitor that line and deduce how many pulses per second the Mac outputs at different disk locations. (And of course incorporate pulse counting into the finished unit so the microcontroller driver software behaves appropriately and provides the correct number of sectors to the Mac at at any given time.)

Blawblawblawyackityshmackity.

Floppy disks are like record players
No they aren't. Floppy diskettes are like records. Floppy diskette drives are like record players. ;)

Also they aren't like records, a record has a single (or double in the case of Monty Python's Matching Tie and Handkerchief) groove which starts at the outside and finishes in the middle.

Whereas a diskette drive has concentric tracks. You may be interested to know that a CD also uses a spiral. Also it is important to mention the "index", this is a pulse given by the drive on every rotation of the disk and is used to mark the start/end of a track. This is how the reader knows if a sector is missing, ie, it does not read the disk forever waiting for the sector to appear, it reads until it has received two index pulses. This is also used during formatting so you know when to start writing out sector one on each track.

Floppy disks are like record players
No they aren't. Floppy diskettes are like records. Floppy diskette drives are like record players. ;)

Also they aren't like records, a record has a single (or double in the case of Monty Python's Matching Tie and Handkerchief) groove which starts at the outside and finishes in the middle.

Whereas a diskette drive has concentric tracks. You may be interested to know that a CD also uses a spiral...
*snicker*

Yeah, I was glossing over the "spiral vs. track" bit because I figured it should be obvious once we're talking about "tracks" being discrete hops, but fair catch. I just wanted to make it clear that "track 0" is the *outside* edge of the disk rather then the center (because if you reverse it starts making very little sense why you'd want the disk to spin slower on the lower tracks and faster on the higher ones...), and since you start playing records from the edge... anyway.

Who knows, of course. These kids today might never have ever seen a record player in the flesh. ;^b

Also it is important to mention the "index", this is a pulse given by the drive on every rotation of the disk and is used to mark the start/end of a track. This is how the reader knows if a sector is missing, ie, it does not read the disk forever waiting for the sector to appear, it reads until it has received two index pulses. This is also used during formatting so you know when to start writing out sector one on each track.
The question here is whether the Mac uses an index pulse. The Disk ][ didn't, it just used a software timing loop to make a wild guess about how long a track was. Tellingly the Mac drive pinout appears to be missing an "index" pin.

Looking at the Mac drive pinouts I just Googled there's a pin labeled "PWM" which says "Motor speed control". If you can find documentation as exactly what sort of signal is present on that port that's going to be the key to adapting a "constant speed" disk emulator design to working on a Mac. If the Mac directly drives the motor via Pulse-width modulation then I imagine you'll have to monitor that line and deduce how many pulses per second the Mac outputs at different disk locations.
The PWM signal is well documented in Inside Macintosh and Apple Macintosh Family Hardware Reference. A PAL reads the disk-speed buffer in RAM and generates a PWM. However, the 800K drive generates its own signal, without any signal from the Mac.

without having to vary the data rate.
That's a good thing, right? In terms of building an emulated peripheral.

Have you come across the Catweazel?

Catweasel Disk Controller ISA
Catweasel is a universal floppy disk controller that uses unmodified PC diskdrives. The Catweasel can read nearly any disk format including:

* all PC-formats (180K up to 1440K)

* Amiga DD and HD (also 5,25" formats)

* Atari 9, 10 and 11 sektor disks

* Macintosh 720K, 800K, 1440K (DD, GCR, HD)

* Commodore 1541, 1571, 1581 (C64, C128 and 3,5" C-64 disks)

* XTRA High density with 2380KByte per disk

* Nintendo backup station 1600KB format

* Atari 800XL (all MFM formats, FM under developement)

* Apple IIe disks (Apple DOS 3.3 and up)
There's one for sale here.

If you are going to emulate the 400K drive itself, it is completely dumb. What it receives is encoded RLL data which goes thru an amplifier straight to the write head. To read, the head's output is amplified, shaped and clipped and sent as a raw RLL stream to the interface. The other signals are a line for MOTOR ON, for READ ENABLE, one for WRITE ENABLE, a line for pulses to the stepper motor to step OUT, and another line to step IN, one track per pulse. The 400K drive also has a PWM signal which drives the motor at varying speed / voltage, so the disk rotation rate changes, but the data bit rate is constant (wow & flutter neglected). The IWM in a first generation Mac is exactly the same as the IWM in an Apple //c or an Apple II non-integrated disk controller.

The HD20 and other drives which plug in to the floppy port use it as a fast serial port with several parallel control lines, and they have their own driver inits which go in the system folder. They do not actually emulate a floppy's hardware. You will find it a lot easier to follow that example.

Otherwise, you will have to really emulate a rotating disk. The first stage of formatting, the Mac writes a long track of zeros, then a gap marker, then waits for the mark to come around to see how fast the disk is rotating, then adjusts speed to make the track the right length, etc... then it writes a sector of data, and another as needed until the track is complete. Reading, the Mac looks for a track / sector marker, waits for the sector it needs, or steps to another track if necessary, then decodes the data, checksums it, and so on. Writing data, it looks for the track and sector, waits for the preceding sector's end mark, then turns on the record amp and writes a sector of data, then reads the track back to check for errors. Emulating all that ain't easy.

The PWM signal is well documented in Inside Macintosh and Apple Macintosh Family Hardware Reference. A PAL reads the disk-speed buffer in RAM and generates a PWM. However, the 800K drive generates its own signal, without any signal from the Mac.
If later drives ignore the PWM and self-adjust their speed then that should make life "easier"... presumably the later drives change speed depending on which track they're on, so one should be able to do the same thing with an emulated version and not bother counting pulses. (The Apple KB article showed the disk speed/sector counts changing every 16th track, thus in theory the microcontroller driver should only need to handle 5 "track sizes".)

I'm not sure Arduino is the best platform in the world to do this project on. You'd probably want to have at least enough fast RAM to buffer a full track. (SD card memory isn't fast.) Doesn't the AVR only have like 1K?

2k, starting tomorrow I will be working with some old school 64k ram and the arduino on a non related project, to see how easy/bad it is

If the mac is generating the pwm on the early machines, its not really an issue, the arduino can handle it

presumably the later drives change speed depending on which track they're on, so one should be able to do the same thing with an emulated version and not bother counting pulses.
I had never thought of it that way, but consider that the Superdrives were all capable of reading and writing to 400K disks, and none received and external speed signal. That said, the Superdrive receives a +5V signal on what is the 400K drive's PWM pin (via a PWMPU resistor on some Macs), which could theoretically be used to calibrate pulses. But, this signal is not present in the Mac Portable and the 800K drive does not use that pin at all (on Macs), so that is not likely. Not exactly sure what the +5V signal is for on the Superdrives (with Macs, if anything), but it is the primary reason a 400K drive should not be connected to a SWIM-chipped Mac.

presumably the later drives change speed depending on which track they're on, so one should be able to do the same thing with an emulated version and not bother counting pulses.
I had never thought of it that way, but consider that the Superdrives were all capable of reading and writing to 400K disks, and none received and external speed signal. That said, the Superdrive receives a +5V signal on what is the 400K drive's PWM pin (via a PWMPU resistor on some Macs), which could theoretically be used to calibrate pulses. But, this signal is not present in the Mac Portable and the 800K drive does not use that pin at all (on Macs), so that is not likely. Not exactly sure what the +5V signal is for on the Superdrives (with Macs, if anything), but it is the primary reason a 400K drive should not be connected to a SWIM-chipped Mac.
calibration and RTS are two different things, since were getting into NOW superdrives (op was about 400k drives only, please don't confuse the subject)

Wow guys lots of great information here. This exactly what I hoped would happen.

Development work has stalled as I expected because of the Thanksgiving holiday here in the US. I did buy a printer over the weekend, so tomorrow evening I intend to get going again.

My Arduino board arrived so I can start experimenting with the Microcontroller. I also share the concern that the memory is too small, but well just have to see what happens. My number 1 requirement is to share this project so that it can help others. I want a solution that would be easy for the end user or another party to build, because I have no desire to go into manufacturing. This is why I chose the Arduino. My goal is to require no electronics assembly work by the user, other than building the correct wiring harness.

My understanding is the the only differences between the 400KB and 800KB drives are the 800KB drives are double sided and ignore the PWM speed control signal. So I think I will start by experimenting with the 800KB drives, because I really don't want to take the chance of borking my 512K Mac. So I also need to find a easy to open IWM equipped mac.

If you don't mind risking such a machine...your best bet would be a Mac II. Otherwise, you could gut an external Apple 3.5" drive for the adaptor board and connect it to an IWM-equipped compact, along with your project.

If you are going to emulate the 400K drive itself, it is completely dumb. The IWM in a first generation Mac is exactly the same as the IWM in an Apple //c or an Apple II non-integrated disk controller.
The HD20 and other drives which plug in to the floppy port use it as a fast serial port with several parallel control lines, and they have their own driver inits which go in the system folder. They do not actually emulate a floppy's hardware. You will find it a lot easier to follow that example.
Henry, thanks for sharing this information with us. I enjoy reading all the tidbits of Macintosh lore you post here.

My Arduino board arrived so I can start experimenting with the Microcontroller. I also share the concern that the memory is too small, but well just have to see what happens. My number 1 requirement is to share this project so that it can help others. I want a solution that would be easy for the end user or another party to build, because I have no desire to go into manufacturing. This is why I chose the Arduino. My goal is to require no electronics assembly work by the user, other than building the correct wiring harness.
I assume you're planning to use an SD card "shield" to store the images on? In any case, this looks to me (from my casual, ignorant perspective) to be a *hard* problem if you don't have sufficient RAM to work with. I guess you'll have to experiment, but lacking sufficient memory to buffer a full track means you'll either have to stream bits straight on/off an SD card in real time, or hope that buffering a single sector (512 data bytes plus encoding. Unless your firmware is smart enough to just save the data portions and discard/generate all the other pulses as necessary in real time, in which case I guess it's just 512 bytes. Doing that would probably rule out using "copy protected" or other nonstandard images.) is sufficient and you'll have enough time between individual sector boundaries to flush the buffer and refill it. Having sufficient RAM for a full track would let you do buffer flush/refills during the head-stepping events, and since the stepping speed of a drive track-to-track is measured in milliseconds that gives you *much* more time to fiddle with an SPI-connected memory device than the microseconds you'll get between the data pulses on a track itself.

(The "Semi-Virtual-Disk" gets by with a 1K internal ram PIC microcontroller, but its external memory store is a "custom-formatted" 256K block of SRAM that's partially driven by an auto-incrementing counter, not a sector/file-oriented flash device.)

Just one more thing to note... it looks like the Mac floppy drive *isn't* a completely dumb device. Look in your copy of "Inside Macintosh", the hardware section, and read the bit starting from "Reading from the Disk Registers". Roughly the same information is presented on this page about low-level programming the IWM in the Apple IIgs, search for "Accessing Disk Drive Status and Control Bits". To quote from the that page:

(...)"In addition to programming the IWM, it is also necessary to program the drive itself, which is somewhat "smarter" than the 5.25-inch drive (even though it is a "dumb" device).
The 3.5-inch drive contains several internal status bits which the user's program can examine, and several internal control switches which

the user's program can use to control various functions of the drive. These status and control bits are accessed by the CA0...LSTRB switches

mentioned above and by the SEL line (bit 7 of DISKREG). CA0...CA2 and SEL form a 16-way switch which selects the desired control or status

function, and the LSTRB switch signals the drive to perform a control function." (...)
In other words, it looks like the Mac floppy drive "remembers" some things that a normal *completely dumb* Shugart-interface drive (IBM PC and most of the rest of the world) doesn't have to. For instance, on the Shugart pinout there's a separate pin for "step" and "direction". If "step" goes high with "direction" held low, then the head steps inward (to a "higher" track".) If a "step" pulse occurs and "direction" is high, then the head moves outwards to a "lower" track. On the other hand, it looks like the Mac drive gets a "stepping direction" written to its onboard register as a discrete event, and then future "step" commands will either increment or decrement the track until a new direction is set.

This actually is quite a lot different from how the Apple ][ drive works, as documented here. On that drive the control lines *directly* control the stepper motor phases. (This is also mentioned in the IWM programming page:

"... For a 5.25-inch drive, the switches CA0...LSTRB control the stepper motor which positions the read/write head over the desired track. For a 3.5-inch drive, these switches have become general-purpose control lines. Using these control lines will be described later..."
(Commentary: Boy, sure seems like Apple loved reusing control lines in incompatible ways on their floppy disk connectors...)

Anyway, I guess what that all boils down to is some of the drive control notes you might have on Apple ][ drives aren't actually directly applicable, and that your firmware will have to statefully manage some things that a Shugart-drive emulator wouldn't have to deal with. (Since things like "step direction" in that case would be explicit based on the state of the interface lines when the command is issued, not implicit like they are on the Mac.)

And, wow, now I know more then I ever wanted to about the Macintosh's floppy drive interface. Bleah.

...Just one more thing to note... it looks like the Mac floppy drive *isn't* a completely dumb device. Look in your copy of "Inside Macintosh", the hardware section, and read the bit starting from "Reading from the Disk Registers". Roughly the same information is presented on this page about low-level programming the IWM in the Apple IIgs, search for "Accessing Disk Drive Status and Control Bits". To quote from the that page:

...
Dude you just hit it out of the freaking park. That is the most concise explanation of the 400/800KB drive I have read. Even the biography is an excellent source of information.

Things are looking clearer now. I was going on the assumption that the Disk II and the 400KB worked the same way. They don't, and that was causing me lots of confusion. That also explains why you couldn't attach a Disk II to a Mac. If the worked the same way then it would be possible.

Now that I have a better understanding of the IWM I think it would be possible to attach a Disk II to a Mac. One would just need to write the appropriate driver. Of course if I had figured that out 20 years ago that might have been a useful thing to do.

The next step is to track down a 400 or 800KB drive and attach it to my Ardunio and read some data from the drive.

...(Commentary: Boy, sure seems like Apple loved reusing control lines in incompatible ways on their floppy disk connectors...)

...
That also explains why they were able to attach the HD20 to a floppy controller also. The Disk II interface and the IWM are very impressive yet disturbing at the same time. It created a very flexible controller but it leaves the software very tightly coupled to the drive mechanism. In modern systems that would be a big no-no, but 30 years years with the high cost of hardware I would say that was the right thing to do.

mp.ls