Parts Order By Mail
Today I ordered the parts needed to build three Floppy Emu boards, the Macintosh floppy disk drive emulator. Everything should be here by next week, so I can start building! In these small quantities, the total cost for the parts is about $47 per board, which is a lot more than I’d hoped. If I ever sell assembled Floppy Emus, they’ll probably need to have a retail price over $100 to cover the cost of assembly, testing, packaging, and a small profit to make it worth the time required.
In addition to being a “real” device instead of a hand-wired breadboard prototype, the new board will also use different parts than the original. The biggest change is the switch to an ATMEGA1284P AVR microcontroller, which has 16K of internal RAM to allow experimentation with different write buffering strategies. The CPLD is different too, with a Xilinx XC9572XL replacing the Altera-powered module that I scavenged from Tiny CPU for prototyping use.
Although the board has a footprint for a Xilinx JTAG header, I didn’t actually order the header, nor do I own a Xilinx JTAG programmer. I’m counting on programming the CPLD indirectly via the microcontroller, using the method described in Xilinx app note 058. If I can’t get that to work, I’ll have to go back and buy the header and a Xilinx programmer, which will mean more delays and more money. I’m keeping my fingers crossed that the indirect programming method turns out OK.
Read 12 comments and join the conversation12 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
I should have asked this before you had the boards made. What would it take to make this a universal floppy emulator?
Universal in what way?
I know the this is outside the scope of the project, but, it would be awesome to have an all-in-one FDD emu to use with mac’s, pc’s etc.
i.e. push a button to switch it between various operating modes.
Kelle,
There are plenty PC compatible floppy emulators out there, but currently none are available for the Mac. This will be the first! 🙂
Steve,
Looking forward to further update to this exciting project!
duxbridge,
My comment wasn’t a dig on this project. I’ve been corresponding with Steve regarding this and other projects, he knows I support and appreciate his efforts. As an engineer myself I know what it’s like when others ask for more functionality before the dust even settles on first iterations. Yes, this is the first Mac fdd emu… guess what would be even better than that? a universal fdd emu, and Steve will deliver that first as well… if so chooses. Keep up the good work Steve!! no harm meant 😉
Ah I understand now. The PC has a physically different floppy connector, and a pretty different signaling method with all signals on individual wires instead of a common bus. Then the data encoding method is also different. A universal emulator could probably be done, but isn’t really something I’m interested in now. HxC Floppy Emulator is a good solution for PCs and other vintage computers.
Are you still using an 8GB SD card? If so, I assume it’s formatted to FAT32. That can slow things down. Try making a single 2GB partition on the card and formatting it to FAT16 to see if that helps.
I didn’t see you mention the format anywhere, so if you’ve already tried this I’m sorry.
It is FAT32 formatted, but the FAT api is only used during initialization, to locate the floppy image file, which I require to be contiguous. All the actual read/write operations are performed using low-level SD block transfers for the fastest possible speed.
Sorry, I thought you were using sdfatlib for writes, or does that use low-level SD block transfers?
Looks like write_multiple_blocks (cmd25) is your only hope for speeding up writes to all cards. I’m surprised that SD cards have such a problem with multiple small transfers but I don’t have much experience of them. A similar project I did for an old 80’s micro used CF cards as a previously unsupported hard drive and I never had a problem with timeouts. Then again it wasn’t a fussy Mac and probably patiently waited until writes were completed 😉
I’ll be interested to see how things progress, maybe I’ll finally get round to making something to replace the 4040 floppy drives on my old Commodore PET and it’s IEEE-488 interface. The disks also used GCR encoding but it was done on the fly by a hardware(!) GCR decoder inside the drive.
Right, I am using sdfatlib, but it has functions for accessing the card at both a high level (FAT) and low level (raw SD transfers). So I use the high level FAT API to perform an fopen on the floppy disk image file, verify that the file is contiguous, and get the SD block number of the start of the file. Then I close the file. After that, I use low level SD transfers to do the actual reads and writes. The write performance numbers that I posted earlier are all using write_multiple_blocks. With individual block transfers, it’s even worse.
The issue is that there’s no timeout mechanism or “wait until complete” in the Mac driver. There’s no need for one, because on a real floppy there’s nothing to wait for, and nothing that can time out. So that makes this project more challenging. 🙂
FYI, a friend of mine previously designed an SD card disk emulator for the Commodore PET, which might interest you: http://www.bitfixer.com/bf/PETdisk
Hope upping the memory to 16k works out then. I’ll contact bitfixer, should have known someone would have beaten me to it with the PET project.
That just leaves me having to finish the Tatung Einetein “Boot from USB without changing the original boot ROM” project. At least I’ve got the USB/FAT adaptor wired up and working: http://postimage.org/image/9i9j9mdv1/