HD20 Firmware 0.2: Fewer Bugs, More Emus
I’ve fixed most of the outstanding bugs in the HD20 emulation firmware. If you’ve been holding out for a way to attach huge SD card storage to your vintage Mac, this new firmware version is actually worth using. It’s still a read-only disk, and the data transfer rate can be improved further, but otherwise it’s totally usable as giant boot disk or a tool for transferring files between your vintage Mac and other machines. There doesn’t appear to be any limit on maximum disk size except the OS limit of 2 GB. If you already have a Floppy Emu board, you can use this with only a firmware update! And if you don’t have one, get one now!
- Fixed handling of the holdoff drive state. Now you can go crazy with the mouse during disk I/O without causing any problems.
- The disk’s Get Info window now says “Floppy Emu” for the disk location.
- Disk icon is a soothing round shape.
HD20 Firmware 0.2A-F65
See my previous post for notes about which Mac models are compatible, and how to apply the firmware update.
Read 5 comments and join the conversation5 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
I like your drive icon 🙂
This is very great, I am kinda interested in how you were about to fix the mouse movement issue and how you got in there and named the Where: What you want 🙂
Super Awesome, is all i can say…
IS write ability kinda looking slightly complex?
Thanks man!
Thanks! In the DriveStatus struct that I reverse-engineered here, it turned out the padding was actually the drive name. I had a hunch that might be it, so I tried putting text in the padding and also the reserved fields.
For the icon, it’s a 256 byte icon structure, but it turned out that the first 128 bytes is the icon and the second 128 is the icon mask. Again, I just kind of guessed it was something like that, given the math.
The mouse movement fix required understanding how the “holdoff” mechanism is supposed to work. When the Mac wants the drive to pause, it switches the drive state from 1 (read/write) to 0 (holdoff) in the middle of a group of 8 bytes. The drive is supposed to see that, and pause at the end of that group of 8. It turned out that the code I wrote to handle this was actually more-or-less correct, but there was a bug in the CPLD logic that meant the data from the AVR microcontroller was never sent to the Mac while in state 0. So as soon as the Mac switched to state 0, the rest of the bytes in the current group of 8 wouldn’t get transferred properly. If I’d had a logic analyzer on the output, that would have been obvious. Instead I wasted a lot of time chasing wrong theories.
Basic write ability shouldn’t be too difficult, I hope. Optimizing writes might be slightly harder, hopefully I can save one block to the SD card even while I’m receiving the next block from the Mac. Or else buffer up a bunch of block writes in RAM, then write them all back to the SD card at once.
I’m going to take a break for the holidays, but will aim to clean up the rest of this stuff soon.
That is great man!, thanks a lot for all your effort!
sounds like maybe your gut is more right then the written docs.
Hey Steve thanks for making this amazing product. Will the mac see all the programs on the emu as if they are already on the hard disk ?
It works the same way as the floppy disk emulation. On the SD card, there’s just a single file, which is a Macintosh disk image file. It represents an entire hard drive. If you’ve ever used a Macintosh emulator like Mini vMac or Basilisk II, then you’ve seen these. They usually end with a .dsk or .hfv extension. The Macintosh will see all the files that are *inside* that disk image file.