-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Integrated Tashtari Machine: Floppy Drive Emulator
- Thread starter tashtari
- Start date
tashtari
PIC Whisperer
IT'S ALIIIIIIVE!!!
In other words, I just got writes working for the first time this morning. Can now read and write 800 kB GCR floppy disks using the backend (and my prototype frontend)! I'm excited but also tired, it's been a long haul to this point...
Nonetheless, I'm thinking about what I want to do next. There are a number of possibilities...
The obvious one is to move on to MFM (1.44 MB and 720 kB) floppy disks and prove that backend functionality out. That's probably the biggest potential crowd pleaser, and the most important step on my way to saying that I've matched the functionality of the Floppy Emu.
A less obvious one is working on proving that formatting disks and formatting-while-writing disks works. This is something I had thought the Floppy Emu couldn't do, but it seems like it can now. Not as important a piece of functionality but something I want to have working.
Another is working on raw GCR disks (WOZ and MOOF images). The backend has a mode that will take a raw GCR bitstream and inject random bits into empty spans, duplicating a behavior of a real floppy drive that is necessary for many copy protection schemes to work. This should work as soon as there's a frontend to take advantage of it, but should only counts in horseshoes.
Yet another is DCD (Hard Disk 20-type devices). As I think I mentioned previously, the backend currently has no support for this, but I planned things out so that it could be added later with minimal friction. When fully implemented and supported by a frontend, this should allow a single backend device to emulate a chain of DCDs as well as a floppy drive.
One that's purely fun would be a Battlestar Galactica (or Knight Rider) style bar of LEDs that can be mounted in the floppy drive slot, reflecting where the head is located on the disk and whether a write is in progress. A neat feature of my design is that such a device can be added without any need for the backend to support it or even know that it exists.
You might notice, dear reader, that as I talk about this, I'm drawing a distinction between the backend and the frontend and talking about "proving" various pieces of functionality. TashFloppy (or Integrated Tashtari Machine, I'm not sure what its final title will be) is a backend, a device that allows another embedded system to easily emulate a Macintosh floppy drive and DCD chain using a simple UART, rather than a finalized product. I'll release my prototype frontend when it's ready or near enough to ready, but it's not my intention that these should be two halves of a single whole. Rather, I'd like to see TashFloppy/ITM be used in multiple finished products according to different needs - various varieties of integrated floppy drive replacements along the lines of the many SCSI drive emulators out there, brick-on-a-leash devices like the Floppy Emu, maybe even single-purpose floppy-port dongles.
I'm not sure I'll be the one to create one of these frontend devices, but one that I might take a stab at is a frontend based on the PIC16F1454 and the SPI SRAMs that my prototype frontend is based on. Potentially this could look like a device that lives inside a Mac, replacing its floppy drive, and connects via USB to a PC host that uploads and downloads floppy images on demand.
Not sure. But it's nice to feel like a milestone has been passed and the world is full of possibility. As always, I love to hear the community's thoughts and inputs and questions and comments. If it weren't for y'all, I might well be nerding about something entirely else...
In other words, I just got writes working for the first time this morning. Can now read and write 800 kB GCR floppy disks using the backend (and my prototype frontend)! I'm excited but also tired, it's been a long haul to this point...
Nonetheless, I'm thinking about what I want to do next. There are a number of possibilities...
The obvious one is to move on to MFM (1.44 MB and 720 kB) floppy disks and prove that backend functionality out. That's probably the biggest potential crowd pleaser, and the most important step on my way to saying that I've matched the functionality of the Floppy Emu.
A less obvious one is working on proving that formatting disks and formatting-while-writing disks works. This is something I had thought the Floppy Emu couldn't do, but it seems like it can now. Not as important a piece of functionality but something I want to have working.
Another is working on raw GCR disks (WOZ and MOOF images). The backend has a mode that will take a raw GCR bitstream and inject random bits into empty spans, duplicating a behavior of a real floppy drive that is necessary for many copy protection schemes to work. This should work as soon as there's a frontend to take advantage of it, but should only counts in horseshoes.
Yet another is DCD (Hard Disk 20-type devices). As I think I mentioned previously, the backend currently has no support for this, but I planned things out so that it could be added later with minimal friction. When fully implemented and supported by a frontend, this should allow a single backend device to emulate a chain of DCDs as well as a floppy drive.
One that's purely fun would be a Battlestar Galactica (or Knight Rider) style bar of LEDs that can be mounted in the floppy drive slot, reflecting where the head is located on the disk and whether a write is in progress. A neat feature of my design is that such a device can be added without any need for the backend to support it or even know that it exists.
You might notice, dear reader, that as I talk about this, I'm drawing a distinction between the backend and the frontend and talking about "proving" various pieces of functionality. TashFloppy (or Integrated Tashtari Machine, I'm not sure what its final title will be) is a backend, a device that allows another embedded system to easily emulate a Macintosh floppy drive and DCD chain using a simple UART, rather than a finalized product. I'll release my prototype frontend when it's ready or near enough to ready, but it's not my intention that these should be two halves of a single whole. Rather, I'd like to see TashFloppy/ITM be used in multiple finished products according to different needs - various varieties of integrated floppy drive replacements along the lines of the many SCSI drive emulators out there, brick-on-a-leash devices like the Floppy Emu, maybe even single-purpose floppy-port dongles.
I'm not sure I'll be the one to create one of these frontend devices, but one that I might take a stab at is a frontend based on the PIC16F1454 and the SPI SRAMs that my prototype frontend is based on. Potentially this could look like a device that lives inside a Mac, replacing its floppy drive, and connects via USB to a PC host that uploads and downloads floppy images on demand.
Not sure. But it's nice to feel like a milestone has been passed and the world is full of possibility. As always, I love to hear the community's thoughts and inputs and questions and comments. If it weren't for y'all, I might well be nerding about something entirely else...
tashtari
PIC Whisperer
This isn't working yet, I suspect the reason is to do with the first sector the Mac sees after formatting a track. It writes a track with address marks and blank data marks and then reads it back, hoping that it will see the first sector it wrote as soon as it switches from writing to reading, and for some reason it doesn't and retries formatting the track until it gives up. Going to have to work on this more, but I'm not 100% sure my GCR protocol analyzer is working correctly, so it may be difficult...
This is now working! It's not as robust as it could be against copy protection schemes, in particular ones that require sectors on the disk to be aligned, but this is a characteristic of the prototype frontend, not the backend, and a future backend could easily implement better support. The main focus of this effort is to shake bugs out of the backend and it absolutely has, notably one insidious one where the transmitter's UART receiver would, under the exact wrong combination of circumstances, overflow and sulk and send out an endless stream of junk data until power cycled.
Also, the support for raw GCR disks is read-only only for the moment. I'm going to have to implement a new mode in the receiver that's happy to relay empty space (the current GCR receiver pretends it's a reverse IWM and regards empty space as meaningless).
I think this is next. My 512ke has been a real trooper throughout this process, enduring endless power cycles in addition to what must be thoroughly baffling floppy drive behavior, but I think it's time to give it a break and move on to, say, the Classic II...
tashtari
PIC Whisperer
Aaaaand 1.44 MB MFM floppy disks are working! (Though read-only only at the moment.) Turns out the backend's MFM transmitter had some serious timing issues that led to some bizarre behavior, now fixed.
Hopefully 720 kB floppy disks will Just Work, though I haven't tested them yet because I'm not 100% sure how the Mac is meant to treat them. Presumably you have to use something like Apple File Exchange to keep the Mac from saying, oh, a double density disk, want me to format it as a GCR disk for you?
In any event, next up will probably be write support for either MFM or raw GCR disks.
Hopefully 720 kB floppy disks will Just Work, though I haven't tested them yet because I'm not 100% sure how the Mac is meant to treat them. Presumably you have to use something like Apple File Exchange to keep the Mac from saying, oh, a double density disk, want me to format it as a GCR disk for you?
In any event, next up will probably be write support for either MFM or raw GCR disks.
It's been a while, but 720K MS-DOS disks are treated the same as 1.44M ones as far as I remember. If Apple File Exchange is installed it's pretty seamless. 800K Apple II disks work with Apple File Exchange as well; I don't know if 1.44M ProDOS disks were supported or not since the Apple II SuperDrive wasn't on sale very long.
Iesca
Well-known member
720k DOS disks are unreadable on pre-SWIM Macs that only had 800k drives, as they only read GCR encoding and not MFM. You needed a special external floppy drive that dealt with the encoding for you, like the Iomega Floptical, a DaynaFile, or the Kennect Rapport adapter with its accompanying Drive 2.4 floppy drive (among others, I'm sure).
cheesestraws
Well-known member
System 7 or above, you need PC exchange installed and a 1.44 FDD (as those support MFM). Then when you put in a low density floppy, it will offer you to format it in Mac or DOS formats, and do GCR or MFM based on that, IIRC.
tashtari
PIC Whisperer
One bug later, MFM writes are working!
Still need to fiddle a bit to make sure 720 kB disks are working too, but 1.44 MB disks are working and that's by far the most important thing. I also wrote the backend side of the raw GCR receiver, which ended up being a lot more compact than I had expected (which leaves more room for the DCD receiver when I get to that), so that's cool.
As far as that bug goes, apparently neither disabling the PIC's UART receiver nor fully resetting it empties out its FIFO, contrary to what I thought - it has to be emptied out manually. Since I wasn't doing that, when entering a write, the next-to-next-to-last byte was getting stuck in the FIFO and being interpreted as a command when the write was over and the receiver was reenabled. Most of the time this didn't matter, but sometimes that byte was a "force eject disk" command, leading the Mac to suddenly complain that there was no disk in the drive. Tricksy tricksy little bugses.
Anyway, getting the raw GCR receiver proven out is the likeliest next step.
Postscript: While testing MFM writes, I was pleased to note how much faster this was compared to the Floppy Emu, though I will freely admit this isn't a fair comparison, as I'm using SRAM as a backing store rather than an SD card. It does, however, stoke the imagination some with what might be possible using a more polished SRAM-based frontend - that is, instead of working with images on an SD card, you upload the image you want to insert as a disk via USB and download it on eject to update your local copy. Whether everyone would want to tether their vintage Mac to a modern machine like that is an open question, but it would make certain use cases a lot easier... food for thought.
Still need to fiddle a bit to make sure 720 kB disks are working too, but 1.44 MB disks are working and that's by far the most important thing. I also wrote the backend side of the raw GCR receiver, which ended up being a lot more compact than I had expected (which leaves more room for the DCD receiver when I get to that), so that's cool.
As far as that bug goes, apparently neither disabling the PIC's UART receiver nor fully resetting it empties out its FIFO, contrary to what I thought - it has to be emptied out manually. Since I wasn't doing that, when entering a write, the next-to-next-to-last byte was getting stuck in the FIFO and being interpreted as a command when the write was over and the receiver was reenabled. Most of the time this didn't matter, but sometimes that byte was a "force eject disk" command, leading the Mac to suddenly complain that there was no disk in the drive. Tricksy tricksy little bugses.
Anyway, getting the raw GCR receiver proven out is the likeliest next step.
Postscript: While testing MFM writes, I was pleased to note how much faster this was compared to the Floppy Emu, though I will freely admit this isn't a fair comparison, as I'm using SRAM as a backing store rather than an SD card. It does, however, stoke the imagination some with what might be possible using a more polished SRAM-based frontend - that is, instead of working with images on an SD card, you upload the image you want to insert as a disk via USB and download it on eject to update your local copy. Whether everyone would want to tether their vintage Mac to a modern machine like that is an open question, but it would make certain use cases a lot easier... food for thought.
tashtari
PIC Whisperer
I took a break from working on raw GCR writes to get formats working. GCR formats were easy, I just had a bug that was incrementing the sector in the wrong place. MFM formats were a bit tougher, I had to implement support for faking the INDEX signal, which on a real drive indicates when the disk has made one full revolution. Faking it on reads is easy, the frontend just tells the backend when it wants an index pulse to appear (though it's not clear whether the Mac ever actually uses the INDEX signal in this case). Faking it on writes is a bit tougher; what I ended up doing was having the index pulse show up after about one and a half sector times' worth of writing, thus ensuring that it only really became a factor when the Mac was formatting a disk. This should be the only time the INDEX signal is used anyway, but who knows.
Getting raw GCR writes working is proving a bit tough on the PIC/SRAM based proto-frontend, I think the chip may just not have the power to pull it off. That leaves me with untested code in the backend, which I don't like, but at this point enough of the backend has proven solid that I can start thinking about a 'real' frontend using a beefier embedded system of some kind.
I put the code for the proto-frontend up on Github. At this point, anyone who might like to play with the quasi-complete project can do so, though it's by no means polished - you'd have to be pretty willing to get into the weeds to get something running. If you want to, though, let me know, I'm happy to help.
Getting raw GCR writes working is proving a bit tough on the PIC/SRAM based proto-frontend, I think the chip may just not have the power to pull it off. That leaves me with untested code in the backend, which I don't like, but at this point enough of the backend has proven solid that I can start thinking about a 'real' frontend using a beefier embedded system of some kind.
I put the code for the proto-frontend up on Github. At this point, anyone who might like to play with the quasi-complete project can do so, though it's by no means polished - you'd have to be pretty willing to get into the weeds to get something running. If you want to, though, let me know, I'm happy to help.
tashtari
PIC Whisperer
Nothing big to report in the past week, I've mainly been polishing and rearranging, trying to get things set up for an implementation of DCD (Hard Disk 20) drives. Space is getting kind of tight in the receiver part of the PIC trio that makes up the backend, but I'm hoping it will still be possible.
Meanwhile, I'm getting more interested in the PIC16F1454 USB/SRAM frontend I proposed before. Porting the already-working code from the PIC16F1708 proto-frontend should be pretty straightforward, and the 1454 is about 50% faster than the 1708, so things like raw GCR writes might become possible. The main challenge is going to be USB, which is a complicated beast that I've never really done anything with before...
If I'm successful, this will look like a device that tethers the user's Mac (via the floppy port) to a modern machine (via USB). The user will select the image they want to use via a program on the modern machine, which will upload it to the frontend via USB, and the frontend will use the backend to "insert" it. Once ejected, the image will (optionally) be downloaded back to the modern machine, updating the image file in place. This is more or less what the proto-frontend is doing now, except images are being uploaded and downloaded via the UART at 500 kHz, which is a fair bit slower than USB would be.
In this way, the user's disk image collection can live wherever they want - on a hard drive, on a network share, &c. - and can easily be shared between real and emulated Macs. It's a different paradigm than the Floppy Emu and I'm not sure whether it's better or worse, but it's within reach, and that's the most important thing.
By a back-of-the-envelope calculation, backend devices will probably sum to around $20 of parts, frontend devices to around $30 of parts.
Anyway, that's where my mind is at the moment. As always, watch this space...
Meanwhile, I'm getting more interested in the PIC16F1454 USB/SRAM frontend I proposed before. Porting the already-working code from the PIC16F1708 proto-frontend should be pretty straightforward, and the 1454 is about 50% faster than the 1708, so things like raw GCR writes might become possible. The main challenge is going to be USB, which is a complicated beast that I've never really done anything with before...
If I'm successful, this will look like a device that tethers the user's Mac (via the floppy port) to a modern machine (via USB). The user will select the image they want to use via a program on the modern machine, which will upload it to the frontend via USB, and the frontend will use the backend to "insert" it. Once ejected, the image will (optionally) be downloaded back to the modern machine, updating the image file in place. This is more or less what the proto-frontend is doing now, except images are being uploaded and downloaded via the UART at 500 kHz, which is a fair bit slower than USB would be.
In this way, the user's disk image collection can live wherever they want - on a hard drive, on a network share, &c. - and can easily be shared between real and emulated Macs. It's a different paradigm than the Floppy Emu and I'm not sure whether it's better or worse, but it's within reach, and that's the most important thing.
By a back-of-the-envelope calculation, backend devices will probably sum to around $20 of parts, frontend devices to around $30 of parts.
Anyway, that's where my mind is at the moment. As always, watch this space...
Reasons.
Well-known member
I do like that idea! I don't know if this is a common situation, but I have a SE/30 on my desk and often want to move files between it and my Mac Studio. I think the workflow you're describing would fit my needs better since I could just keep the tether between the machines permanently connected instead of having to do the SD card swap dance. The FloppyEMU is a great product but it really shines when you have to take it offline; if you've got a dedicated modern computer it's a bit overkill.
(I'm also having a bear of a time avoiding non-contiguous files on the FloppyEMU, too, though I'm sure this is my own incompetence.)
(I'm also having a bear of a time avoiding non-contiguous files on the FloppyEMU, too, though I'm sure this is my own incompetence.)
Last edited:
Similar threads
