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.