New Macintosh Firmware Updates for Floppy Emu
Here’s another big Macintosh firmware update for the BMOW Floppy Emu disk emulator, and it’s got some good stuff! Writable MOOF images, in-emulator disk formatting, performance improvements, and a significant bug fix. If you’re the impatient type, skip the rest of this text and download the new firmware now from the Floppy Emu project page. And as always, you can also buy a new Floppy Emu Model C at the BMOW Store. Or just sit back and enjoy this completely gratuitous screenshot of a logic analyzer capturing some disk operation.
Writable MOOFs
The 221201M update introduced support for MOOF disk images, a new image format that’s designed to capture all the low-level disk information needed for copy-protected software. Today’s update extends MOOF support by adding write capability, instead of treating MOOFs as read-only, which is essential for a few software titles that require writing to the boot disk. Print Shop, Carmen Sandiego… I’m looking at you. This sounds like a small change, but turned into a major effort to get it working reliably.
If you need to format a MOOF (see below), I recommend using the Blank 400K.moof and Blank 800K.moof disk images that are provided in the firmware’s Examples subdirectory, rather than using any random MOOF. The provided blank images have been tweaked to guarantee every track has a number of bits that’s an exact multiple of eight. This results in the best possible SD Card I/O performance, and reduces the chance of a formatting failure.
In the weeks since MOOF support was first introduced, the Moof-a-Day collection at archive.org has also grown from 52 to 78 titles, so check them out!
In-System Disk Formatting
All the supported disk image types can now be formatted directly on the Floppy Emu, from the attached Mac or Lisa. MOOF, DiskCopy 4.2, and raw images can all be formatted. In-system formatting normally isn’t necessary – you can usually use a pre-made blank disk image instead. But it’s essential for a few software titles like Seven Cities of Gold that require formatting a save disk directly from within the game. It’s also helpful when using disk copy tools to copy a real disk to a disk image, because most disk copy tools will automatically attempt to format the destination disk.
This is a big change, and the amount of effort that it required is way out of proportion with the value of the new feature, but I stubbornly wanted it anyway. In-system formatting has been a sore point for the Floppy Emu since the very beginning, and for a long time I believed it was impossible for technical reasons, but the work on MOOF writes helped me to realize that was only half-true.
To quote Aladdin’s Robin Williams quoting William F. Buckley, in-system formatting comes with a few, uh, provisos, a couple of quid pro quos. Here they are.
DiskCopy 4.2 and raw disk images can be formatted with a standard format, using standard address marks and data marks, standard sector sizes, standard checksumming… you get the idea. A DC42 or raw disk image format will fail if you attempt to create a non-standard disk format, like a disk that uses D5 18 3F to mark the start of each sector instead of the standard D5 AA 96. That’s because these disk image types don’t actually contain any of this format information, and it’s just implied to use standard defaults. I haven’t yet found any example where this is an issue, but if it ever comes up, formatting a MOOF disk image will allow for esoteric format types that intentionally break the standard.
For those who are paying very close attention, there’s also a subtle difference between 400K/800K formatting and 1440K formatting. The 400K/800K format is a true format, where every sector is written as zeroes, and then a new file allocation table and root directory are created. To employ a more modern term, it’s like doing a secure erase of the disk image. The 1440K format is more like doing a quick erase – it creates a new FAT and root directory, but doesn’t actually modify any of the sectors except the ones in the FAT. The Floppy Emu fools the Mac into thinking it zeroed all the sectors, but the old data is still hiding in there, which you can see if you view the disk image with a hex editor.
Formatting performance may vary depending on your SD card’s write cache behavior. If the format fails, try again or use a different SD card.
Disk images must be formatted as the same size as they were before formatting. When the Mac asks if you wish to format a disk as one-sided or two-sided, choose wisely. Attempting to reformat a 400K disk image as an 800K disk will lead to disappointment.
As mentioned earlier, for best performance when formatting a MOOF disk image, use the blank MOOF images provided with the firmware. These have been tweaked for optimal I/O speed.
1440K Disk Emulation Fixes
If you’ve been using 1440K disk emulation before now, I apologize. It’s been semi-broken for years, and I didn’t even realize it. I discovered there was a bug that could sometimes introduce invalid MFM clock bits into the bitstream, causing the Mac’s disk controller to freak out and think an error occurred. In the best case this substantially degraded the speed of disk transfers, and in the worst case disk transfers would fail outright with a message like “a disk error occurred”. After fixing this bug, 1440K disk emulation is dramatically better. It’s a very noticeable difference.
This is a short section with only a single paragraph, so I’ll repeat myself once more. This small fix makes a great difference, and if you use 1440K disk emulation very often then you’ll want this.
Performance Optimizations
The MOOF pseudo-random number generator has been greatly improved, and is used to create so-called fake bits or weak bits in certain MOOF disk images. The old random generator was pretty lousy, because I didn’t realize it might be important to get a specific profile of random bits. The bits need to mimic the random-seeming behavior of a real disk drive’s read head when no magnetic flux is present. The poor-quality randomness may have caused problems for some MOOF disks that employ copy-protection based on weak bits. The new pseudo-random number generator is a 16-bit linear feedback shift register, with a cycle length of 65535 that’s about the length of a whole track, and with a post-processing step to ensure that only 30 percent of the random bits are 1s. To maintain real-time bit streaming, the code must be optimized to generate each new random bit in less than two microseconds, along with other housekeeping tasks.
To accelerate data transfers from/to the SD card, Floppy Emu will now ignore the tag bytes contained in DiskCopy 4.2 disk images while it’s in Macintosh floppy emulation mode. The Mac doesn’t use these tag bytes anyway, so they’re just a waste of time. Lisa floppy emulation mode still supports tag bytes, as they’re an essential part of the Lisa filesystem. If you were doing something non-standard involving tag bytes on the Mac with Floppy Emu and DiskCopy 4.2 images, and this firmware update causes you problems, let’s talk.
SD transfers have also been optimized in other ways. If the Floppy Emu is in the midst of loading a track’s worth of data from the SD card, and it suddenly discovers it no longer needs that track because the head stepped to a different track, it will now abort the transfer ASAP instead of finishing the whole transfer and then discarding it. This actually happens a lot. The result is there’s less time on average between when the head steps to a track and the data for that track begins streaming from the Floppy Emu, which helps reduce the chances of disk I/O hiccups.
The raw SPI transfers from/to the SD card have also been substantially accelerated. The actual SPI clock hasn’t changed, and is still 10 MHz, but the dead time between each byte and the next one has been reduced. What dead time, you ask? The microcontroller in the Floppy Emu unfortunately doesn’t have any SPI buffering, so the CPU needs to intervene after every byte to queue up the next byte and start it, which can badly hamstring performance. With a core clock of 20 MHz and an SPI clock of 10 MHz, it should theoretically be possible to transfer a bit every 2 core clock cycles and a full byte every 16 clock cycles. But with a typical SPI polling loop like the one in the SD library I used, it needed 26 clock cycles instead of 16, only about 60 percent of the theoretical best performance. Not great.
I rewrote the innermost loop to do a blind transfer of each byte instead of polling for completion, employing some cycle-counting to ensure that each new byte would be started at exactly the right time. This improved performance to 18 clock cycles per byte, about 90 percent of the theoretical max. The loop could easily be timed for 17 or 16-cycle transfers, but the SPI hardware fails at this speed. I suspect the hardware needs 1 SPI clock (two core clocks) to reset its internal state before the start of the next byte, but the datasheet mentions nothing about this.
I hope you enjoy all these new features and improvements. That’s it for me until sometime next year. Happy holidays!
Download the latest Floppy Emu firmware from the project page.
Read 18 comments and join the conversation18 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Great work!! Happy holidays!
The firmware file femu.bin in femu-221221M.zip is exactly the same as in femu-221201M.zip and is reporting the version as 221201. Did the wrong file get included?
Thanks, it’s fixed now.
great work !
im work with the EMU since a short time with my several Mac Classic II and have some beginner questions to Mac HD20 ( sorry for that 😉 ) maybe fitting here in new Mac femu update comment
– the HD20 6.0.? has 100 MB space – can i make this space bigger than 100 MB by myself – or it is limitet to the 100 MB ?
– another idear is: to copy, duplicate an empty Mac HD20 6.0.? , rename it, and copy it back to the SD to creat another more HD20 100 MB disk file , several, like fits to SD card space ?
– and last , if there is no HDD in the Classic II and i want to boot from EMU HD20 –
the Clasic II says 6.0.? is to old to boot with CL II – it has to be 7.01, 7.1 newer ( up to 7.5 )
can i copy, overwrite or install the 6.0.?system on the EMU Mac HD20 file with system 7.1 , so i make a boot able HD20 EMU with system 7 to boot a Classic II ?
greetings MacMadNTTom2
ahh – i read something over the Mac HD20 that is it a RAW file and can be up 2 GB –
but i dont know what this means and how cab i make the HD29 100 MB bigger by myself —
Please use the customer support link here if you have individual questions that aren’t related to this firmware update. The Floppy Emu instruction manual has a discussion of disk images. You can use a command line tool such as dd to create a blank disk image, by generating a file containing nothing but zeroes (the size of the file must be a multiple of 512).
Looking forward to trying this update as i do frequently using 1440k disks. Also as a side note, I received a Duo Dock with a Duo 230 laptop for a gift this year. I found that connecting the FloppyEmu directly in place of its floppy drive did not work. It resulted in the computer complaining about an uninitialized disk in the drive, even with no image mounted. Ill try this update and see if it makes any difference. As far as I can tell it should be compatible. It also might be my machine, it has a few other quirks and I was trying to reinstall the os when the issue was discovered. Now I need to make a stack of floppies i guess.
Great news!!
I’ll try this soon when I have time, is the daisy chain support (FD behind HD20) still implemented? It seems you dropped it since the “hd20-0.8E-F14” firmware (I still use “hd20-0.7G-F14.5” for my emulated HD20).
@Elliott
I experienced the same behaviour with my duo 2300c and external HDI20 modified cable to floppy emu before. A real external floppy drive works fine. It’s the only mac I own which wouldn’t accept Floppy Emu! The only problem in testing this new firmware with it is to find the Duo and its power adapter in my mess…
Another thing I’ll probably try soon is to format a virtual disk in MS-DOS and see if the image is readable on PC with gotek for example.
I answer myself! I successfully tested “daisy-chaining” between HD20 and FD (2 floppy-emu boards and custom HDI20 cable) on my powerbook 100 running system 6.0.7 and your latest firmware, works fine, it’s not broken 😀
I also tested formatting a macintosh .dsk image (in ms-dos format) via “apple file exchange” and transferring txt files on it. I could then read back the image with “winimage” on my pc, was correctly detected as ms-dos disk image and I could read back the files correctly, great!!!
Just still have to try with my Duo 2300c when I find it 😉
Glad to hear it! Yes the HD20 daisy-chaining support is still present. I haven’t heard of any problems specific to the Duo Dock before now. Is the floppy drive a standard 20-pin cable connector?
Yes it is (standard desktop auto-inject floppy drive). Personally I never tested floppy emu in my duo dock but only with my custom HDI20 cable (I also use it for my powerbook 100) and duo minidock (HDI20 and ADB ports), same issue as Elliott…
I finally found my duo! Unfortunatly, same behaviour as before… Even If the disk is correctly read, the finder gives an error, after clicking OK same error so you have to hard reboot the computer. The same message appears indifferently with or whithout a disk image inserted!
http://tjjq.free.fr/mac/IMG-5853.JPG
Suspecting a Mac os 8.6 bug I tried with a 7.5.2 boot disk image. In this case no error message (probably cause of the very shrunk system in this disk) but all the menu bar items are dimmed and any click outside the bar makes it flash. Hard reboot required here too.
http://tjjq.free.fr/mac/IMG-5854.JPG
I then tried the same boot disk but a real one this time in my external HDI20 floppy drive, no problem at all, I can open files and use menu bar.
Concerning this late December 2022 firmware and its early Dec 2022 predecessor firmware:
Whenever I attempted to switch out 3.5 disk emulation mode to HD20, I got a freeze of my floppyemu in the submenu where the switch is performed. I couldn’t reach the point where a change was commited, so I stayed in 3.5 disk mode.
I was able to go forward one step by checking out the emumode.txt file present. You can manually change its content from 0 (3.5 mac disk mode) to 1 (HD20 mode) using a modern computer. Once put back in the floppyEMU, it was strangely still in 3.5 disk mode, but I was able to go to the mode selection menu, have it freeze again, but after resetting, the mode would stick to HD20.
Next up, I figured out that my HD20.dsk 100 Mb, did I make this one myself) doesn’t want to boot at all and might be the culprit here. Once I used another file called HD20System32.dsk (20 Mb, probably was provided by BMOW but I renamed it?), all is well. But it still freezes in the same location of the submenus, forcing me to resort to manual editing of the config file.
I never experienced these kinds of problems in all the firmwares I’ve been using since like 2019.
I ruled out that’s it’s a problem for my 2019 unit because I bought a 2nd one for failure proof at the tail end of 2022 and it exhibits the same behavior.
Could you tell me specifically what firmware version number you’re seeing this with, and what model of Floppy Emu?
Please note that you can’t combine emumode.txt with manual selection of the emulation mode – it’s one or the other. Emumode.txt is intended to help vision-impaired users. If you have normal vision then I recommend deleting emumode.txt and setting the emulation mode through the regular method.
Steve – removing the non-working extra HD20 file did not do the trick.
Deleting the emumode.txt *DID* the trick. I can swap modes without the floppyemu freezing.
The same behavior existed for my 2 floppyemu units (both model C version 1.7) . One bought around 2019 and the other at the end of 2022. Both were updated to 221221M’s firmware and had the problem, which started for me in early december with the previous 221201M firmware.
Having the same issue as Thomas. Have 2 different Powerbook Duo 2300C, both running 8.6 and have no issues with using the external floppy connected using the mini dock or the floppy adapter, but have the same issue with using a custom HDI-20 cable to connect the FloppyEMU. An error continuously loops saying the “Disk has failed to initialize because the disk is locked” and you are forced to reboot. You can get this error to stop popping up if you change the disk emulation mode to CD/HDD. It will stop the error from popping up, but it also does not seem to actually work for CD/HDD emulation. (I didn’t test CD, only HDD). I tried all available firmware versions and all had the same exact results. I created 2 different cables both came from known working floppy drives with no issues to eliminate the variable that it could be wiring.