Easiest way I can think of, is use the floppy port as a "Serial port" and send control codes (outside of normal floppy codes) to the device to change images, receive image info, etc.. using maybe a control panel on the mac?
That's kind of what I was thinking, but I have no idea how the floppy communications go. The floppyemu would include a check for requests and have a couple commands available that would be equivalent to how the push buttons work, except for the list and disk queue "position".
I'm working on 1.44 MB floppy support right now. I'm optimistic it'll work, at least for read-only, hopefully for read-write.
Formatting floppies isn't really practical for a couple of reasons. Raw image formats like .DSK don't store the sector headers and other stuff that's written during formatting - they only store the actual sector data. The firmware could ignore all that header stuff and just save the sector data, but then "formatting" would really just be "fill with zeroes". In that case, I don't think formatting would serve any purpose that couldn't also be met by just copying a new blank disk image onto the SD card, but maybe I'm missing a case where it would be useful? The other problem with formatting is that the Mac does a ton of floppy writing without pausing to verify anything, which never gives the SD card a chance to catch up with the incoming data, so it fails with a buffer overrun.
It should be possible to write some kind of front-end software to control Floppy Emu directly from the Mac, so you don't have to push its buttons. I was never too excited about that idea personally - it wouldn't let you choose a boot disk for example, and I just prefer unmodified system hacks. But if someone else wants to tackle it, great! You could use some kind of magic bytes written to the floppy to switch it in and out of command mode. For example, if you wrote a sector to address 0 that began with the string "Floppy Emu Command", then the remaining bytes could be interpreted as a command, instead of actually being written to the floppy image.
FYI, I have also added DiskCopy 4.2 image support in the latest firmware.
Once I have 1.44 MB support working (I hope), and iron out a few more bugs, I'm going to build some Floppy Emus and offer them for sale for anyone who doesn't want to do the assembly themselves.
I thought I was close to getting 1.44 MB disk emulation working, but now I've run into a wall. The concepts are the same as 800K disks, but 1.44 MB uses MFM instead of GCR encoding, and all the sector headers and footers and checksums and timings and things are different. At first when I tried to read a 1.44 MB disk sector through Floppy Emu, I got error -67, couldn't find an address mark. That basically means the Mac couldn't make any sense at all of my emulated disk signal. But then after some fixes I started getting error -69, bad address mark. From disassembling the ROM routines, I can see that -69 means it successfully read and recognized the address mark (A1 A1 A1 FE), but then either the address block CRC was wrong, or one of several possible low-level SWIM errors occurred.
At first I thought I must have a bug in my CRC logic, but I've checked and re-checked it about 20 times, and compared it to several different references, including Apple's SWIM user guide. Unfortunately I can't just look at the ROM disassembly to examine the CRC logic, because it's all internal to the SWIM chip, and the ROM routine just checks for the presence of a CRC error flag on the SWIM.
Now I'm wondering if maybe the CRC is actually correct, but one of the other low-level SWIM errors is happening and causing error -69. These are things like a bit cell that's too narrow/too wide, marginal transitions, overrun, etc. The fact that A1 A1 A1 FE was received successfully makes me think this stuff is probably OK, but maybe not.
I tried writing a simple program to directly access the SWIM to read the floppy, so I can look at the bytes as they come off disk, and check all the various SWIM error flags if there's an error. But I couldn't get the program to work - it was a bastardized conversion of an assembly example to C, and I think I was missing some required code for initializing the SWIM.
Beyond that, I'm kind of stumped at what to try next. I still don't know if it's actually a CRC problem, or something else. I thought about having the firmware step through all 65536 possible CRC values to see if any of them work, but there's no real way to automate that. If I could get my test program working it would help, but I'm probably too clueless at classic Mac programming to make it work. A couple of other ideas I had:
1. Solder a test point onto the board somewhere, and modify the firmware to send the "read head" signal to it, then view the signal on a scope. I'm not sure what this would prove, other than that the signal looks like what I think it's supposed to, which is more-or-less already proven by the successful receipt of A1 A1 A1 FE.
2. Try to implement MFM write support, then attempt to format a virtual 1.44 MB floppy, and look at the signal coming from the Mac on a scope. This would be pretty complicated to set up, but might be helpful.
3. Put a real Superdrive on a bench, with appropriate +5, +12, and -12 power supplies, and use an Arduino or something to control it so I can view the raw track signal on a scope. Probably a major amount of work, but the result would be informative.
I'm not really excited about any of those options, so if anyone's got any other good ideas on how to approach debugging this, I'm all ears! I'm tired of seeing this error -69 with no other feedback to help me move forward.
My understanding of the SWIM isn't really up to snuff, but who knows maybe I'll stumble on something.
When the machine first boots and the .Sony driver is loaded, it checks to see if the system has a SWIM controller, and stores the result in SonyVars, everything else will refer to that.
When a disk is inserted, the driver tries to figure out what kind of disk it is, whether it's a 400k GCR, 800k GCR, or 1440k MFM. It first tries to read a GCR sector, then checks if the inserted disk is 1440k. If the GCR sector read succeeds and the disk is 1440k, it fails with -400. Otherwise, if the GCR sector read was successful, it's a GCR disk and then goes and figures out if it is single or double sided.
If the GCR read fails, it flips the SWIM into MFM mode, and then tries to read a sector again. I think it then checks a block size code looking for code 2, which seems to indicate a block size of 512 bytes.
Something else that might be interesting is if there's an MFM CRC error, it seems to put the SWIM's error register, handshake register, and CRC into the tags data. So it might be possible to get some debugging information out of that...
Once upon a time I started on a program that uses the .Sony driver directly to read sectors and tag data, and tries to save it all even if there are errors reading. I really haven't looked at it in quite a while, but it may be relevant here. http://synack.net/~bbraun/macsrc/floppydd0.002.cpt.hqx
Ah, checking the error info stashed in the tags data may be exactly what I need! I noticed the ROM routine was saving it somewhere, but didn't understand how. I'll spend some time with Inside Mac tomorrow, and try to make a program to read it. I'll check out your floppy driver example too, thanks! Every piece of info helps.
I discovered that my address mark checksum actually passes for at least one sector, but fails for others, so I think I'm on the right track but wrong on some detail. Hopefully the leads you mentioned can point me the rest of the way.
Wow. That is an impressive collection of documentation! Thanks!
In my case, I'm 95% sure the problem is that the microcontroller isn't feeding bits to the CPLD fast enough to keep up with the MFM bit rate. I think it's sending the right data, just not fast enough, so an underrun occurs. The tags data returned by the Sony driver that bbraun pointed out gives evidence of the bit slippage. I was able to precompute the MFM signal for an entire sector address block, and send the precomputed data to the CPLD, and it was received successfully by the Mac with no CRC error. So I think if I can optimize the code enough to do MFM encoding on the fly without creating an underrun condition, it should work.
Awesome! I'll have to give it a shot later tonight or tomorrow.
I also ordered parts to build the remaining 3 floppyemu PCBs left over from my first order. I've never really wanted a dual drive SE before, but it'd be pretty fun to have two floppyemus attached to the front drive slots with the cable routed through the opening.