Context, since it's not spelled out with a lot of background in the article: most floppy drives spin at a fixed RPM, which is referred to as a Constant Angular Velocity (CAV: ie, no matter how far out on the disk you are, the disk rotates by a constant angle per second). This means that towards the outer edge of the disk more magnetic media is passing under the head per second than towards the inner edge of the disk (with a larger circumference, a constant angle will represent a longer chunk of media). If you're writing the same number of bits per second, this means each bit takes up a larger amount of magnetic media at the outer edge compared to the inner edge.
If, instead, the drive spins at a Constant Linear Velocity (CLV: ie, the same amount of magnetic media passes under the head per second no matter where on the disk you're accessing[1]), each bit can take up the same amount of magnetic media, which means you can store more bits per track towards the outer edge of the disk. Macs did this in order to increase the amount of data you could store, at the cost of additional complexity in the drive to support spinning at different rates. It also means that 800K Mac disks (the largest format which used variable rates) can't be read on normal PCs, which lack support for variable rates.
FluxEngine works at a lower level than the standard PC floppy interface - it allows the OS to look at the actual magnetic flux data on the disk, whereas the standard PC floppy interface will only pass back the interpreted bits. Even if the disk is spinning at a constant RPM, knowing where the head is located allows that magnetic flux data to be turned back into the appropriate bitstream (or vice versa for writing) and allows handling CLV disks even though they're in a CAV drive.
“at the cost of additional complexity in the drive to support spinning at different rates”
I don’t think there was that much extra hardware in the drive, originally. Bytes read from a buffer at every horizontal scan line controlled the speed of the drive through PWM (http://www.mwftr.com/416F20/Apple%20macintosh%20BYTE1984.pdf. That probably changed later, as that method doesn’t cater for multiple floppy drives, and created a hard link between screen resolution and controlling floppy disk speed (the hardware driving the screen also processed the PWM bytes that controlled disk speed (and the bytes that produced audio output. 370 scan lines times 60Hz gives you 22,2 kHz))
And nitpick on note [1]: that code shows 5 different speeds (four if statements and one ‘otherwise’ return value)
BTW, I have a branch of the FluxEngine client library which can also talk to a Greaseweazle, so if you have one of those you should --- soon, I hope --- be able to use the FluxEngine client to write Mac disks on a Greaseweazle.
I have one of these - I've put it and a 3.5" drive into an old USB HDD enclosure. It works really well. I have about 1,000+ old Amiga floppies that I'm slowly archiving.
Yes, it does this job well: Basic Amiga floppy reading and writing. And thus I recommend to anyone who already has an Arduino (and doesn't have e.g. a stm32) and needs to write Amiga floppies to bootstrap the Amiga they just obtained somewhere.
The point to GreaseWeazle and FluxEngine is that they aren't Amiga specific, they can handle the weirdest formats, dump copy-protected formats as-is for preservation and recover data from damaged and otherwise unreadable disks.
These kinds of projects are really cool. Relatedly I found myself wondering the other day if anyone has done any work on making hardware and software to interface with Smart Media Card.
Specifically in my case, I have a Korg Triton Le 88 ROMpler keyboard that has a slot for Smart Media Card and my thinking is that instead of buying a Smart Media Card reader and card and all of that stuff it’d be cool to open up the keyboard and solder a connector onto the pins that the card slot of the keyboard connects to, and then with a bit of extra hardware to be able to connect my computer to it so that I can expose files directly from the computer to the Triton Le and have the Triton Le see it as though there was a Smart Media Card there. And hopefully that way being able to make new sample files and load them without going through an intermediate step of putting them onto external media.
And also because with the right parts this solution would be more readily replaceable, whereas Smart Media Card is an obsolete format that to my knowledge is no longer being created so Smart Media Cards are hard to come by [0] [1]. xD to SMC adapters exist though [2], but again connecting the computer directly would be more convenient and either way I don’t use xD for anything else so don’t really want to buy xD cards. And the only memory card reader I have for my computer anyways is SD/microSD only also, because that’s the only kind of memory cards I currently use.
AFAIK it is almost the same as xD except for the physical specifications (they're both just raw SLC NAND flash), and there's far more information about the latter (also including a leaked spec which you can easily find) so I would also look there.
Also, in relation to what you said about xD and SMC being the same that explains why those adaptors go that way I suppose. Will check out the details about xD for sure.
I built myself a FluxEngine some time ago and I absolutely love it. I've used it to read some not-so-common disk types: MS-DOS, CP/M, Amiga and C64 format 5.25" floppies; MS-DOS, MSX and Amiga 3.5" floppies, all without a hitch.
This is great because I have a Mac SE/30 with a 800K drive and no way to create 800K disks for it using images off the Internet. Which means a lot to me.
In my case, I used a Mac LC as the 800k floppy <-> SCSI interface, because I already had one in the collection. It's more bulky than the FluxEngine adaptor though!
The full route from Internet to Mac SE 800k floppies was: WiFi -> MacBook Pro 2014 -> USB-PATA hard drive -> PowerBook G3 Wallstreet (screwdrivers) -> SCSI HDI-30 to DB-25 adaptor -> SCSI hard drive -> Mac LC -> 800k floppy -> Mac SE.
The SCSI drive had to be formatted Mac OS Standard (HFS) not Mac OS Extended (HFS+) if I remember right. Copying data each way took half an hour, so the FluxEngine would be a lot smaller and quicker.
An SE/30 should have a SuperDrive[0] so at the very least you should be able to write a 1.44MB floppy with a Disk Copy 4.2 image file, then restore the image to a 800K GCR diskette from the SE/30.
Some SE/30's are upgraded SE's; these typically feature the original HD and floppy drive. I own one of these, though I upgraded those components in the late 90's.
Ah I see. You may be able to swap in a SuperDrive still since the SE/30 ROM supports it. I have a dual-800k SE without the FDHD ROM upgrade, so I feel your pain :)
This is why I was so excited when I heard about this. I have a Mac Classic II in the role of "transfer station" - it has a SuperDrive (the floppy drive, not the CD/DVD drive), so can read both standard IBM 1.44MB disks as well as the Mac 800K ones. But it's been getting a bit temperamental recently, mainly due to failing capacitors and an old SCSI hard drive.
FluxEngine completely eliminates the need for it - I can download a 800k system disk image, write it to a physical floppy disk, and use that. What's more, transferring individual files is easy now too: I can read back the physical disk to a DiskCopy image, and either mount that in an emulator such as Mini vMac, or convert[1] it to a raw disk image and mount it with hmount[2]. (The reverse process is similar).
If, instead, the drive spins at a Constant Linear Velocity (CLV: ie, the same amount of magnetic media passes under the head per second no matter where on the disk you're accessing[1]), each bit can take up the same amount of magnetic media, which means you can store more bits per track towards the outer edge of the disk. Macs did this in order to increase the amount of data you could store, at the cost of additional complexity in the drive to support spinning at different rates. It also means that 800K Mac disks (the largest format which used variable rates) can't be read on normal PCs, which lack support for variable rates.
FluxEngine works at a lower level than the standard PC floppy interface - it allows the OS to look at the actual magnetic flux data on the disk, whereas the standard PC floppy interface will only pass back the interpreted bits. Even if the disk is spinning at a constant RPM, knowing where the head is located allows that magnetic flux data to be turned back into the appropriate bitstream (or vice versa for writing) and allows handling CLV disks even though they're in a CAV drive.
[1] Except it doesn't actually do that - there's only 4 different speeds, as you can see in https://github.com/davidgiven/fluxengine/blob/7eaf3de5723436... .