Whoo, long time since I've updated this thread.
The USB frontend with the PIC16F1454 did not pan out, unfortunately. I think it behooves me to return to the idea of a more Floppy Emu style frontend, probably targeting the PIC16F1788 and its whopping 2 kB of SRAM. I have the hare-brained idea that I can keep three sectors in memory at a time and that'll be enough - the current sector on the current side, the next sector on the current side, and a sector on the opposite side at the ready for if the SEL signal suddenly flips. With some trickery in the way the SD card is formatted (FAT32 with a big cluster size), I can actually keep a cluster map of a whole floppy disk image in what remains of the SRAM, and thus avoid the fragmentation problems that seem to be plaguing the Floppy Emu lately...
I still would really like to figure out a way to make an RPi act as the frontend. If I could just get the latency down to the point where it could deliver data in time for the backend, that'd make so many things so much simpler - build a backend and your frontend is "download this image onto an SD card and stick it in your favorite RPi". Unfortunately, SCHED_FIFO and dedicating a core to the frontend process isn't enough. PREEMPT_RT might be enough, but there's an awful lot of outdated documentation on the subject of real-time Linux and I haven't unwound it yet.
So much to do. But a life full of projects is a life well-lived, so I press on.
...Oh, and I'm calling it TashFloppy now. I've got a brand to maintain. =)
The USB frontend with the PIC16F1454 did not pan out, unfortunately. I think it behooves me to return to the idea of a more Floppy Emu style frontend, probably targeting the PIC16F1788 and its whopping 2 kB of SRAM. I have the hare-brained idea that I can keep three sectors in memory at a time and that'll be enough - the current sector on the current side, the next sector on the current side, and a sector on the opposite side at the ready for if the SEL signal suddenly flips. With some trickery in the way the SD card is formatted (FAT32 with a big cluster size), I can actually keep a cluster map of a whole floppy disk image in what remains of the SRAM, and thus avoid the fragmentation problems that seem to be plaguing the Floppy Emu lately...
I still would really like to figure out a way to make an RPi act as the frontend. If I could just get the latency down to the point where it could deliver data in time for the backend, that'd make so many things so much simpler - build a backend and your frontend is "download this image onto an SD card and stick it in your favorite RPi". Unfortunately, SCHED_FIFO and dedicating a core to the frontend process isn't enough. PREEMPT_RT might be enough, but there's an awful lot of outdated documentation on the subject of real-time Linux and I haven't unwound it yet.
So much to do. But a life full of projects is a life well-lived, so I press on.
...Oh, and I'm calling it TashFloppy now. I've got a brand to maintain. =)
