Well, it's been almost two years since I last posted on this project, and over three years since I started trying to spear the white whale that is a full-featured open-source Mac floppy drive emulator. Here's what's been going on and where things stand now.
By way of background, one of the most challenging aspects of the Macintosh MCI (Microfloppy Control Interface) is the way it multiplexes signals. Nearly all of the lines on the floppy controller are outputs from the Macintosh to the drive. Only one, the "read" line, is an input from the drive to the Macintosh, and the MCI repurposes the "phase" lines on the floppy controller, originally intended to control stepper motors, as selector lines for one of sixteen possible one-bit registers maintained by the drive. As a result, some kind of programmable logic is basically necessary to make a floppy drive emulator for the Macintosh.
TashTwenty, thanks to a bit of luck in how the drive controller is used, is able to emulate the register set using a single CLC (Configurable Logic Cell) peripheral, a relatively simple and somewhat unconventional programmable logic device that lives within the PIC. However, the number of CLCs in a single PIC is too few by far to emulate the more complex register set used to communicate with the floppy drive and something more sophisticated is necessary. This threw me for a long time.
At first, I tried using ATF16V8 SPLDs, but those were too simple; I also tried using ATF22V10s but ran into trouble programming the chips, besides the fact that my design using them cut some corners, so I abandoned SPLDs. The next candidate I looked at was a series of devices called GreenPAKs, neat little chips able to run at 5V with a whole mess of logic blocks that can be connected together in myriad ways. These got tantalizingly close to working, but again fell short of what I needed. CPLDs and FPGAs would certainly have enough logic to do what I need, but add complexities that I don't want to deal with - low voltage levels, inconvenient packages, staggeringly bloated software packages. Yuck.
Honestly, if I were a better electrical/computer engineer, I'd probably have given up my unconventional paths in favor of using a more sophisticated microcontroller paired with a CPLD or FPGA. But I make no claim to be electrical or computer engineer, much less a conventional one. What I am is a PIC whisperer - it says so right underneath my forum user icon - and that informs my latest approach. Here's the code:
A UART-based interface for the Macintosh MCI (Microfloppy Control Interface). - lampmerchant/tashfloppy
github.com
A trio of PIC16F1704s, pooling their CPU cores, their memories, their peripherals, and most importantly, their CLCs, to work as one to handle
all aspects of communicating with the Macintosh MCI - from register multiplexing to handling commands, to bitbanging both GCR and MFM. It does for the MCI what TashTalk does for LocalTalk - it allows just about any embedded system with a UART to emulate a floppy drive, taking as much of the load off as it can. Just supply it with a prompt and steady stream of data and you're off to the races.
It is the
backend to any type of floppy emulator
frontend a person might want to create, be it a brick-on-a-leash like Floppy Emu, a smart network interface like FujiNet, or - and this is what I dream of - something that replaces the floppy drive in a Macintosh both functionally
and aesthetically.
So what's the status of this project as defined above? I believe it to be functionally complete and operational. I have, however, run into a major snag in proving it out.
I wrote a prototype frontend that connected to a SPI PSRAM chip, downloaded an image to it, and supplied data to TashFloppy from the PSRAM. Unfortunately, I couldn't get the PSRAM to work properly - it kept having massive numbers of bit errors. It doesn't appear to be the PIC firmware's fault, either the chips I got were faulty or my skills at soldering SOICs are so poor that I damaged them in the course of attaching them to SOIC-to-DIP adapters. I don't know.
My next step, I think, is to find an appropriate larger-scale embedded system to perform the same function. The safest option would be to find one with enough RAM to hold a whole disk image. It is certainly possible to hold the image in flash or on an SD card - this is what Floppy Emu does, after all - but for purposes of testing the backend, I want the frontend to be as simple as possible. I'd like to find one that supports MicroPython, which someone suggested to me over on the
TashRouter thread, ideally.
The other thing I could work on in the meantime is DCD/HD20 support. I haven't written this yet, but I have a place in the firmware where it's planned to go. If all goes to plan, a single device using this backend will be able to emulate a full chain of devices - multiple DCDs and a floppy drive - all at the same time.
So that's where things stand. If anyone's got any suggestions for a MicroPython-supported board with a lot of RAM, or wants to work with me on creating a frontend of some kind, or just thinks this is cool and wants to know more, I'm all ears. =)
