Writing 800kB Mac disks with FluxEngine
cowlark.com
cowlark.com
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... .
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)
Arduino-based, can read/write regular Amiga floppies but not much more: http://amiga.robsmithdev.co.uk/
STM32-based, can deal with pretty much everything: https://github.com/keirf/Greaseweazle/wiki
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.
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.
Please do try and get that upstreamed.
edit: I just realized you're the author in the first place!
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.
[0]: http://forum.vintagesynth.com/viewtopic.php?t=104354
http://affon.narod.ru/CARDS/phys10ei.pdf
http://affon.narod.ru/CARDS/elec10ei.pdf
http://affon.narod.ru/CARDS/fmtl10ei.pdf
http://affon.narod.ru/CARDS/fmtp10ei.pdf
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.
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.
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).
[1] https://www.bigmessowires.com/2013/12/16/macintosh-diskcopy-...
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.
[0] The combo 400K/800K GCR & 1.44MB MFM 3.5" floppy drive, not the combo DVD/CD-RW drive when they recycled the name a decade later: https://www.siber-sonic.com/mac/superfloppy.html
With a little serial port help, to get the data into it.