• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

Integrated Tashtari Machine: Floppy Drive Emulator


Well-known member
I've given this a lot of thought over the past week, and I came up with a rough design that supports the necessary features to emulate the majority of copy protection schemes (synchronized sectors, weak/fake bits) while playing back WOZ or MOOF images on the Mac, but with some caveats: only GCR disks (no MFM), only bitstreams (no flux timings), and only reads (no writes). Plus, it'd require some pre-computation, so a Mac/PC-side client application would be necessary. It feels kind of clunky and compromised. I'm not ruling it out, but I think more people's needs would be better met by something that has the same feature set as the Floppy Emu on the Mac, so I'm going to concentrate on that first, at least...


Well-known member
Hope I didn't open Pandora's Box for you there!
Nah, even if I don't end up supporting copy protection, I learned a lot, particularly about the Superdrive. Better to learn sooner rather than later, given that even seemingly small details can lead to big redesigns.


Well-known member
I've been working on a floppy emulator on and off for at least a year now and the project has gone through more redesigns than I care to count, but I think I'm making progress. Here's an somewhat-rambling update.

In the current design, the "Super Tashtari Integrated Machine" (STIM, in a nod to the SWIM) is a firmware for the PIC12F1840 (same chip as I used for TashTalk), the function of which is to do bitbanging, which is my favorite thing to design and arguably the hardest part to handle in a larger embedded system, in order to be a counterpart of sorts to the SWIM/IWM chips. It handles bidirectional communication in the dual languages of GCR (400 and 800 KB disks) and MFM (720 KB and 1.44 MB disks), translating to and from an easy-to-understand 8-bit UART protocol.

On the receive side, it handles well-behaved disk writes, intelligently interpreting address and data marks and doing de-nibblizing as appropriate for GCR and translating both mark and data bytes into 8-bit bytes for MFM. On the send side, it handles well-behaved disk reads, intelligently interpreting address and data marks and doing nibblizing as appropriate for GCR and intelligently detecting and translating mark bytes for MFM. On the send side, there's also a mode to send a raw GCR bitstream and inject random noise into large gaps, in imitation of the behavior of a real disk drive; this mode can be used to imitate some types of copy protection.

The design using STIM is something of a departure from my past designs where I was trying to put all components of the interface into a single chip and separate that from a chip which behaved exclusively as the frontend. I'm moving away from that and instead separating the MCI into three logical components:
  1. Reception and transmission of magnetic flux transitions
  2. Multiplexing of signals on the RD line in response to CA2, CA1, CA0, and SEL
  3. Reception of commands on CA2, CA1, CA0, and SEL when CA3 is pulsed
Component 1 is STIM. Component 2 must be handled by logic of some kind, whether it's an SPLD, a simple multiplexer, or one of these interesting GreenPAK mixed-signal ICs (the SLG46824). Component 3 is probably best handled by the larger embedded system that's also communicating with STIM.

STIM is basically complete. I'd still like to give it the capability to handle DCD signals so that a device using it could imitate the Floppy Emu and emulate DCD devices, but this is a lower priority given that TashTwenty already does an excellent job of this on its own. Other components are still in flux (ha).

Anyway, nobody pays attention to wordy posts on their own, so have a picture of the other thing I've been working on, the "body" of TashFloppy:


It's a sandwich of two PCBs, easy to manufacture, easy to assemble, and in a Floppy Emu-like form factor. Cute, no?