> The disadvantage of this technique was that there was no interoperability with PC diskettes possible, at all, even with software changes. For the Macintosh, this changed with the introduction of the Macintosh SE in 1987. The Macintosh SE had a new floppy drive controller, the ‘SWIM’ (Super Woz Integrated Machine) and a new disk drive which could read and write both Macintosh CLV and PC CAV formatted diskettes.
Pardon my nitpick, but there were two versions of the SE and the author has the dates mixed up here. The original 1987 model had the same disk capabilities as the Mac Plus except it could have two of them installed internally instead of just one on the Plus. Or one 800K drive and an internal SCSI HDD in the other bay — your choice! (Mine actually has all three thanks to a third party internal HDD bracket!)
The FDHD (floppy disk high density) version was released in 1989 as a standalone computer and also as an upgrade kit for the original model containing one (1) SuperDrive, SWIM, updated ROM, and little “FDHD” and “800K” badges to put next to the upgraded and remaining original drives respectively.
SE and SE HD, and if you took the 400 or 800k version of the second floppy from your Mac plus, you could use it as a third floppy. I tried this on an SE and it worked, but never tried it on a SE HD. I thought that some early MacIIs had iwm chips in them, and with A FD HD upgrade you got a SWIM chip and a pair of ROMs to put in.
Feels slightly surprising, at least from the comfort of my 21st century armchair, that they went to all that effort for 800 KB per disk. The Atari ST (with an off the shelf 1772 FDC) had no problem with 800 KB - 2 sides, 80 tracks, 10 sectors per track, 512 bytes per sector - and that seemed perfectly reliable.
The Amiga did its own thing, same as the Mac, but at least it got some extra storage. 880 KB per disk!
(880 KB was also an option on the ST, but only for disks written a track at a time, which was impossible to guarantee if using the OS. With 11 sectors per track, writing individual sectors wasn't reliable as the gaps between them are so small. The OS didn't support irregular disk geometry so you couldn't have more sectors on the outer tracks.)
It's all just an evolution of their existing disk drive technology that started well before the last-minute decision to go with the Sony 3.5" drive.
The variable drive speed comes of the development of the "Twiggy" drive, which was an 850 kB 5.25 disk format originally intended for the Apple III in 1980 but never worked reliably.
BTW, the Atari ST uses the same floppy disk format as the IBM PC, 360 kB per side.
The Amiga uses a variable drive speed like the Mac, but they eke out extra capacity by eliminating sectors. This allows an extra 512 bytes per track, but the trade off is that the disk controller can only read or write an entire track at a time, rather than individual sectors.
An infamous Apple II copy protection scheme used the same trick to expand 5.25 disk capacity from 16 sectors to 18 sectors (512 bytes per track).
The Amiga is fixed RPM or CAV, not CLV like the og Mac. With one exception- later models could halve the RPM to read/write HD floppies (1.44MB PC or 1.76MB Amiga).
360 KB/side was indeed the default for the Atari ST, but there were numerous tools (I think Fastcopy III was the one I usually used) to format with more sectors per track, and 10 sectors/track (so 400 KB/side) was the standard recommendation if you just wanted more data per disk and no hassle. More than 80 tracks was also an option, and 81 or 82 tracks was apparently also reliable. That never sat right with me though, so I didn't do it.
(18 sectors per track with 256 byte sectors is also possible with the 1770 series. This was one of the disk format options on the BBC Micro. Definitely not written a track at a time! There just wasn't the memory for that.)
You only read the data sheets. The twiggy drives had 4 heads to cut latency and had two access windows one in the back like all 5.25 and one in the front for the extra heads. The Lisa used this too.
Hardware got better really quickly in the 1980's and 90's, including floppy disks. By the end of the 20th century, there were 120MB floppies. Basically Moore's Law seemed to apply to spinning rust for awhile.
LS-120 drives were floptical drives that were backwards-compatible with 3.5" 1.44MB disks. IIRC you needed special media to use the 120MB capacity, but the same slot could accept the common 1.44MB disks and give you much better performance than normal floppy drives. The successor LS-240 drives also had the ability to write 32MB to a standard floppy disk using shingled magnetic recording.
If Zip disks, CD-R and USB flash drives hadn't showed up, these drives would have been pretty widely recognized as the next generation of floppies.
Almost all digital formats die in obscurity. 3” floppies, 5v SmartMedia, Jazz disks, and DAT were good ideas in the moment that were not good ideas a moment later. The logistics of reading even popular formats like Qic 40 and ADAT today are hard.
The most ironic thing, IMO, is that at the time everyone seemed to be holding their breath for Castlewood's 'Orb drive', which promised the perfection of a fast and big storage media.
It was delayed so long that by the time it actually reached the market it didn't get noticed.
Nope, NeXT had magneto-optical 128 MB drives, somewhat related. They were 3.5" but using an entirely different media, and were absolutely incompatible with ordinary floppies.
NeXT cubes used a 256 Mb optial drive, and some slabs has. 128Mb optical, and someone said that the turbo color slab had a 230Mb optical drive. Mine did not.
NeXT boxes used magneto-optical disks, which usually meant a laser was used to heat the magnetic material during the write process, and at lower intensity to read data optically. The optics in a floptical drive are just part of the head alignment servo mechanism, so it was probably much easier to make them cheap and backwards-compatible with mainstream floppies.
"Ordinary" floppies peaked in 1988 (yes, before IBM 1990 PS/2 2.88 ED) with 'Triple' or '2TD' format developed and shipped by NEC inside PC-88 VA3. 13MB unformatted, _9,120 kB_ formatted capacity. Triple because it tripled track density from 80 to 240 while reusing ED barium ferrite magnetic media and perpendicular recording head of ED drive, same ~100KB/s speed.
There was also the Sony HiFD Which was 200MB and used the same form factor disks as FDHD drives, thus maintaining compatibility.
It had a 'click of death'-like failure like Zip did though, and lost the battle during its recall and redesign. (IOMEGA were lucky in that the click of death didn't really kill Zip's market until about the time that CDR/CDRW was beating them anyway)
With some PC drives you could push the cylinders and sectors and get the same size. There were a couple of utilities out there to do it. However, not all PC drives were alike. So you could do that on your machine and your buddies machine would not read it at all.
I was given a Macintosh SE model M5010 and a M5011 in 2020. Both have bad hard drives, but the batteries are not leaking. I'm not sure when I'll get around to working on them.
It's interesting how much of the (latency sensitive) data processing is done on the main CPU; I've not used early Macs much, but given they have a multitasking GUI, would user input be noticeably delayed during disk activity, or could it cause problems to e.g. move the mouse rapidly while it was accessing the disk? 16 CPU cycles per bit sounds like it wouldn't leave much time for anything else.
Early Macs are not really multitasking in the sense that newer machines are. Each running application has to hand back control to the operating system as a part of its main loop (think like video game main loop if you are familiar with that)
In the same way, disk operations themselves are generally blocking and will hand back control to the OS and apps during their read/write cycles so that other things can happen on the computer.
Hard real time was pretty easy to do on the Mac because you could run code in interrupt handlers. For example, dragging the mouse (e.g. to pull down a menu) suspended all processing in the system so that it would be responsive. The floppy driver might have run at an even higher priority, causing the mouse to skip during I/O.
The Macintosh would disable any interrupts that were not level 4 or higher when accessing the floppy disk to prevent data loss. This was basically everything other than the programmers switch. It did however have a check to see if the serial port received data while it was busy with the floppy disk so that could be serviced before a buffer overrun occurs.
Yes! You got the icon with the oval windows! Now try this in your emulatiom: if you named a disk '.Sony' you can kiss the data good bye. The drivers name is '.sony' too. Someone named their hard disk '.' and that was the beginning of multiple software problems.
There are two sets of kryofluxed floppies on archive.org. the 800k image is 58Mb, and all four floppies have errors at 60~65%. All the data is extractable except for the bad regions so... It looks like they kryofluxed the disks to preserve what data they had left, but it's not a solution. It's a huge waste of space, can you imagine a box of disks all inflated to 73 times their size?
Apple got Sony to make cav drives, (MacIIx and SE HD to the 9600 )and when they raised the price, no floppy. Sneaker net was over until USB drives became cheap.
One disk on archive that is unrecoverable is Adobe Type Manager. The areas where the fonts are is corrupted, but the data is available elsewhere, but the program isn't.
Now it sits in the cloud ( someone else's hard disk ) in a corrupted state. Wish I had an SE 30 to restore the disk, and put it's compressed image up as a replacement.
It says 800k/400k, but all his images are 800k. The filesystem may be different, but for diskcopy 4.2, it never made a difference. ( MFS vs hfs ). I am sure that for kryoflux, it does not make a difference either.
It does not show how kryoflux assists in recovery. They can be archived, and preserved, but not recovered. ( Just try the 800k ATM disk on archive.org )
The easiest solution is get a late model vintage mac that still has a floppy drive. the late model drives can read pretty much all mac floppies. the machine will be able to image the disk and copy it to usb(pci usb card) or over a network.
Or you can get something like a Greaseweazle[1] and go that route if you want to do more advanced extraction.
As far as I recall, none of the USB drives of the iMac era could read 400/800K GCR disks, they were PC drives that could only use 720/1440K disks. The Imation SuperDisk drives could also use their own 120MB “floptical” disis. Later versions extended it to 240MB, and could also write 32MB to a standard floppy disk.
MFS refers to the file system used on 400K disks. 800K disks used HFS.
An in-depth dive into the Macintosh floppy drive system, including the fascinating IWM (Integrated Woz Machine) custom floppy controller. The level of fidelity to properly emulate the Macintosh disk drive is impressive, and this should be an essential resource to any aspiring Macintosh emulator developers.
Pardon my nitpick, but there were two versions of the SE and the author has the dates mixed up here. The original 1987 model had the same disk capabilities as the Mac Plus except it could have two of them installed internally instead of just one on the Plus. Or one 800K drive and an internal SCSI HDD in the other bay — your choice! (Mine actually has all three thanks to a third party internal HDD bracket!)
The FDHD (floppy disk high density) version was released in 1989 as a standalone computer and also as an upgrade kit for the original model containing one (1) SuperDrive, SWIM, updated ROM, and little “FDHD” and “800K” badges to put next to the upgraded and remaining original drives respectively.
See https://bylenga.ddns.net/FDHD/MacSEservice.pdf#page=87