Interface information for 400KB Floppy drive

[Bunsen]

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.

 

[H3NRY]

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.

 

[Gorgonops]

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?

 

[Osgeld]

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

 

[Mac128]

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.

 

[Osgeld]

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)

 

[redrouteone]

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.

 

[LCGuy]

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.

 

[trag]

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.

 

[Gorgonops]

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.

 

[redrouteone]

...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.

 

[Gorgonops]

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.

Heh. No problem, I occasionally try to be useful. Funny thing was the only reason I opened up my PDF of the first-edition "Inside Macintosh" was I wanted to see if it said what the track-to-track stepping time of the Mac drive was. Once I started reading it I realized, uhm, oh, this might be useful to point out.

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.

There are all sorts of dire warnings about how hooking up an Apple II drive can "fry the IWM" in your Mac... I wonder if the Mac is missing some circuitry that the IIgs *does* have that would let it safely operate in the "control the stepper motor directly" mode (buffering/amplifiers/drivers external to the IWM? Or does an Apple II drive ground the PWM signal, causing a meltdown?), or if it's simply a software thing. (The Mac ROM defaults to incorrect assumptions about drive instead of trying to query it, and running in the wrong mode alone is enough to overdrive the chip? )

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.

Ironically, if you could find the appropriate documentation for the protocol used to communicate with the HD20 there's a good chance it would be substantially easier to emulate than a floppy drive. As H3NRY noted earlier, when running the HD20 the IWM would essentially behave like a high-speed UART. If it transfers data in neat sector-size chunks and dispenses with the data encoding/timing pulses a floppy drive needs then it would be fairly trivial to grab data sectors straight off a memory card as needed, and timing might be a lot less critical. If anyone has a link to a document chronicling the secret recipe for speaking to an HD-20 it might be an apropos time to trot it out.

(You could potentially figure it out, if no other way, by sicing a 68000 disassembler against the either the 128k Mac Plus ROM, which can boot one natively, or the HD-20 init. But trying to interpret such a thing would suck.)

 

[Mac128]

If anyone has a link to a document chronicling the secret recipe for speaking to an HD-20 it might be an apropos time to trot it out.

We've been begging for this for years. I wonder if it is because Apple broke their own rules to developers and used the floppy port, rather than the serial port, which gave them a substantial speed edge over the competition, and therefore guarded the recipe like a state secret, that we do not have more information about it. I think only one or two other third party developers ignored Apple's rules and came up with a floppy port drive on their own, and Apple may have even bought into one of them, Quark, to build the HD-20.

As for the Disk II, definitely a valid question about the warnings of plugging one into a Macintosh. But I do wonder why, even 20 years ago, one would want less disk space than a 400K disk which barely contained a Mac System as it was. A Disk II held at most 140K, barely 1/3 of the Mac drive. I think Apple attempted something similar to this with their Twiggy FileWare drives, a 5.25" drive with 860K, which Apple could never get to work reliably, which may have had more to do with their double sided implementation than the variable speed control. But a 430K single sided-drive might have been just dandy. Still the hardware must be designed to take advantage of the speed adjustments. All in all, no great loss the drives may not be hardware compatible.

 

[redrouteone]

I did some research and found that the SWIM and pretty close to the IWM. I took a look at the Linux Mac floppy driver code and apparently a command is sent to the drive it switch it from GCR to MFM modes.

I still don't have a 800KB drive, but I do have a 1.4MB drive. In fact I picked up a LCIII today just for its floppy drive. I think it will be useful so I can do some experimenting with the drive and interface with out worrying about damaging my beloved IIsi or 512K Mac.

So my first course of business is to attach the drive to my Arduino and see if I can send the command to eject the disk.

 

[redrouteone]

Well about the time I pulled out the soldering iron I realized something. If I want to understand how the drive works it would be much better to spy on it while the Mac is using it.

So new plan. I have a good set of documentation on how to control the IWM and SWIM. So I am going to control the IWM manually and use the Arduino to spy on it. Then I try to capture those command and respond to them.

 

[H3NRY]

Just to make things interesting, Apple has a bunch of different floppy drives with different software interfaces which all plug into the floppy port / IWM / SWIM / IBM chips. There is the disk II which is a more or less standard Shugart drive. There is the early 800K 3.5" drive for the Apple II which has its own 6502, buffer RAM, and IWM chip inside and which talks to the host like a HD20. There is the 400K Sony drive in the early Mac, which is nearly as dumb as the disk II but uses step pulses instead of directly pulsing the stepper motor windings. There is the 800K drive without built-in intelligence as used on the Mac and IIgs, and lastly the 1.4M + 800K Super Drive, and the 1.4M only drive used in late model PPC Macs. The main reason you don't want to plug a DiskII into a Mac is the plugs are wired differently and 12V can get applied to 5V circuits.

The idea of running the HD20 init thru MacNosy or equivalent sounds intriguing. I wasn't the software engineer on the ProApp floppy port HD project, so my knowledge of how it worked is limited, but there were drivers for it for Apple IIs and Macs. It took a long time to get that drive debugged, and by the time it shipped the Mac Plus was out and SCSI drives were cheaper & faster. The ProApp drive found buyers in the Apple IIc community, for which it was the only choice on the market.

Something else which I haven't seen mentioned is the 3.5" disks read and write at about twice the bit rate of the 5.25" diskII, which is why the Apple IIe and previous required a smart drive. It takes a 2MHz 6502 to write a 3.5" disk. Way back when, I disassembled and commented the disk driver in the Mac ROMs. I wonder if I still have that.

 

[JDW]

I wonder if I still have that.

While searching for it, please also remember to keep an eye out for your MacDraw schematics.

 

[Mac128]

There is the early 800K 3.5" drive for the Apple II which has its own 6502, buffer RAM, and IWM chip inside and which talks to the host like a HD20. There is the 400K Sony drive in the early Mac, which is nearly as dumb as the disk II but uses step pulses instead of directly pulsing the stepper motor windings. There is the 800K drive without built-in intelligence as used on the Mac and IIgs, and lastly the 1.4M + 800K Super Drive, and the 1.4M only drive used in late model PPC Macs.

Just to be clear on these points: The 800K 3.5" drive for Apple II (UniDisk) is identical to the drive mechanism used in the Macintosh. The only difference is that the Apple II version includes an added circuit board which can be easily removed allowing the drive to be used with a Mac. The Superdrive also used 400K disks, which presumably behaved identically to the 800K but only wrote one side. Also of note, an 800K & 1.4MB Superdrive will behave as a 400K or 800K drive when plugged into an IWM Mac depending on what the ROM supports (with appropriate cable blocking the PWM pin, otherwise the drive will malfunction). A 400K drive cannot be used on a Mac equipped with a SWIM chip because of the permanently high signal output by the PWM pin), but the 800K drive can be.

I was surprised to read from you that Apple ever dropped support for Superdrives in its PPCs which shipped with floppy disks. The last Apple supplied floppy was in the PowerBook G3 (Wallstreet) and will support all three formats. The last G3 Apple floppy disk equipped desktop counterparts were all discontinued prior to that and I always thought they included Superdrives as well. The subsequent PowerBook G3 (Lombard) would accept a floppydrive expansion bay module, but only supported 1.44MB – not sure if that was a hardware limitation of the third-party manufacturers or Apple dropping support for the Superdrive.

 

[redrouteone]

Well good news and bad news. I decided to take a look at the Developer Note for the LCIII and it states this.

The Macintosh LC III uses a new floppy disk controller circuit, SWIM2, that is part of the Sonora chip. Because the SWIM2 controller is different from the original SWIM, software that accesses the controller directly will not work with the Macintosh LC III. The only way for software to access the floppy disk is through driver calls documented in Inside Macintosh.For situations where direct access to the raw track data is required, use the Diagnostic Raw Track Dump call described in the Macintosh Technical Note M.DV.SonyDriver.

So the information I have for the SWIM and IWM is no good. But It looks like that might just be ok. Having access to the Raw Track data will be very useful going forward. So I am off to take a look at the M.DV.SonyDriver tech note. Even if it does not have the information to control the SWIM2, Linux runs on the LCIII so I am sure I can get the info from the floppy driver.

 

[Dog Cow]

Just to be clear on these points: The 800K 3.5" drive for Apple II (UniDisk) is identical to the drive mechanism used in the Macintosh. The only difference is that the Apple II version includes an added circuit board which can be easily removed allowing the drive to be used with a Mac.

I connected a UniDisk up to the Classic a few months back when I was archiving disks and needed as many drives I could get. Now, it's been awhile and I don't remember if it worked or not. It ought to check again. It could be that the previous owner of the drive lobotomized it, though I doubt that.

The subsequent PowerBook G3 (Lombard) would accept a floppydrive expansion bay module, but only supported 1.44MB – not sure if that was a hardware limitation of the third-party manufacturers or Apple dropping support for the Superdrive.

That's likely. Apple probably got a different manufacturer to create the slimmer drive needed in the laptop. I noticed that the drive in the Quadra 605 (with dust flap and different head arm assembly) appears to have been made by a company other than Sony.