Floppy Emu Update: WOZ Writes, Dual 5.25 Emulation, and More!
Today I’m excited to introduce a major new feature update for the BMOW Floppy Emu Disk Emulator. The latest firmware for use with Apple II computers adds the three most frequently requested new features: writeable WOZ and NIB disk images, formattable disk images, and dual 5.25 inch floppy drive emulation. Each of these three was tricky to implement, and I’ve lost track of how many times I said these things were too complex or the hardware couldn’t support it. Forget all that, because here it is! This is the biggest set of changes to the firmware in the whole history of the Floppy Emu, requiring some extensive rework under the hood. I hope the results are worth it.
The new firmware is version 0.2Q-F29. You can download the latest firmware here: firmware
WOZ and NIB disk images are now writeable!
This is great for copy-protected programs that need to save some information to the disk, like your Print Shop printer settings or your Castle Wolfenstein game progress. While the sector-oriented disk image types like .PO, .DO, and .DSK have supported writes since day one, the bitstream disk images (WOZ and NIB) typically used for copy-protected programs were previously treated as read-only by the emulation engine. No more. Your Wolfenstein games will now be safely saved.
Getting this to work was challenging, because the Floppy Emu wasn’t originally designed to handle raw bitstreams. A few simplifying assumptions were made in order to bridge the gap. It’s possible a few programs may cause trouble if they perform writes in a very non-standard way, though I haven’t yet found any real-world examples. The firmware doesn’t make assumptions about sector sizes or layouts or headers, so it should work OK even if the written data doesn’t look like standard DOS/ProDOS sectors. For example, Wolfenstein writes sectors whose data header begins with the bytes D5 DA AD instead of the normal D5 AA AD.
WOZ disk images contain a read-only flag in their header. Writing to the disk image will be disabled if this flag is set.
You can format 5.25 inch disks!
This is great when making disk copies, or if you need to create a save disk from within a game like King’s Quest. In-emulator disk formatting makes life much more convenient when copying or saving data. I have striven to make formatting a feature that “just works” as much as possible, but there are a few important details to know.
Successful formatting is dependent on the write caching behavior of your SD card. If the card introduces too many long delays during writes while it flushes its internal cache, the format may fail. In most cases you can just try again and it’ll work. If the format keeps failing, try a different SD card.
Many disk duplication tools do a simultaneous format and write of the target disk. Some will also do a bit-level copy, attempting to duplicate hidden details of copy-protected source disks. Cracking tools like Copy II+ may not work correctly when the target disk is a Floppy Emu disk image. Use DOS 3.3’s COPYA or ProDOS’s Duplicate Disk utility, both of which work fine.
Formatting is also dependent on the type of disk image used, and potentially also on the disk image’s metadata. In short: if you need to format a disk, use this Blank.woz disk image and you’ll be fine. Only NIB and WOZ disk image types support true formatting. All other types will retain standard DOS/ProDOS sector layouts and volume number 254 regardless of how you attempt to format them. NIB disk images have tracks that are about 4% bigger than normal, which is sort of like a disk drive that spins 4% too slowly. DOS 3.3 still formats a NIB just fine, as will games using normal RWTS routines, but ProDOS will complain the drive is too slow. Formatting WOZ disk images is more reliable, but it must be a WOZ image of a normal disk with normal track lengths and track layouts. If you just grab some copy-protected WOZ disk image and try to format it, it may fail. The provided Blank.woz should format nicely using most Apple II programs.
Dual 5.25 inch drive emulation is here!
Now the Emu hardware can emulate two 5.25 inch drives at once, which is great for two-disk games and for reducing disk swapping. This feature is available on the Floppy Emu Model C, so you may wish to consider an upgrade if you have an older model and frequently use 5.25 inch floppy emulation. Dual 5.25 emulation mode is compatible with any Apple II computer or 5.25 inch disk controller with a 19-pin D-SUB (DB-19) connector, except the Apple IIc. The IIc and the rectangular 10×2 pin disk connector both lack the necessary disk I/O signal for controlling a second drive. Both could theoretically be supported in the future with some kind of Y-cable adapter that plugs in to two separate disk connectors. Coming soon, maybe?
Don’t use Dual 5.25 mode in combination with the optional BMOW Daisy Chainer or A/B Switch. It will cause disk errors and could damage the Floppy Emu or your daisy-chained 5.25 inch drive.
Dual 5.25 mode emulates two daisy-chained 5.25 inch drives on a single Floppy Emu board. When using this mode, care must be taken to avoid accidentally creating a forked daisy chain with two branches. This could cause the Floppy Emu and another daisy-chained or A/B-connected 5.25 inch drive to fight with each other, possibly damaging them both. To avoid this, select single 5.25 inch emulation mode when using the Daisy Chainer or A/B switch.
Read 39 comments and join the conversation39 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Great work Steve!
Thanks for supporting the Floppy Emu and the entire Apple retro community. I plug it every chance I get.
Way to go, Steve!
Amazing work as always Steve, you continue to add value to your products. May you never tired of making “Really Cool Stuff” (TM) for the Apple II and I hope, if not get rich, at least do extremely well off of your endeavors.
Question: currently I have a Model B, but this makes me want to pull the trigger and buy a Model C. However…does the dual 5.25″ drive configuration work on a IIC+ vs a IIC or are we talking IIGS and IIe with the proper controller card?
Thanks!
Are the non model C features limited to the B/C or will you release an updated firmware for the A?
Amazing!
To follow Joe Seeley’s question, the IIC+ can daisy chain 2 5 1/4 drives. This implies that the dual emu could work as the line for the second drive is there. Will it?
I don’t have a IIc+, but I’m 99% sure it’s compatible with dual 5.25 mode. Hopefully a IIc+ owner can try it and confirm. The WOZ writes and 5.25 inch formatting features should be possible to back-port to the Model A, but it will take some time due to hardware differences. I’ll try to find time to work on it this weekend.
Thanks, When I get mine I will test.
Thanks Steve! Appreciate looking at backporting for us OG model A users.
New firmware for Model A is now available. Don’t forget that the Model A also needs the Universal Adapter in most cases in order to write to 5.25 inch disks. I forgot this and wasted a couple hours trying to figure out why it wasn’t working.
Thanks for the update. I do have a question about the dual 5.25” mode however.
Is it possible to use two floppy emu’s like this on a iigs (using the daisy chainer?
Floppy emu 1 in 3.5” disk mode
Floppy emu 2 in dual 5.25” mode.
I am currently using a wdrive as a 5.25” on,y drive, but it sounds like with the new software using dual floppyemu might be better for me, if I works as above.,..
@Richard Moore yes, that would be fine. There’s only a concern if the Floppy Emu is in dual 5.25 mode *and* a third 5.25 inch drive is connected downstream with the Daisy Chainer, because it would create a forked daisy chain.
So much to comprehend here; thanks, Steve!
“The IIc and the rectangular 10×2 pin disk connector both lack the necessary disk I/O signal for controlling a second drive.”
The Iic is my Apple II computer of choice.
What do you mean by “the rectangular 10×2 pin disk connector?”
My //c has the DB-19, as does most //c’s that I have worked with.
Is this the internal connector?
I have yet to install my Internal/External Drive Switcher for Apple IIc.
@MichaelLAX the standard rectangular 10×2 pin disk connector is found on the Disk II Controller Card as well as on the motherboard of the IIc and IIc+ (and Macintosh and Lisa). This type of connector only has the I/O signals for controlling a single disk drive.
So, may I ask, why is dual floppy emulation not recommended for only the //c and not the //c+?
@MichaelLAX the external DB-19 connector on the IIc+ has the I/O signal needed for controlling a second drive (99% sure – waiting for a IIc+ owner to confirm). It’s pin 9 of the DB-19 connector. The IIgs also has it, and the Disk 5.25 Controller Card, and most third-party disk controller cards. The external DB-19 on the IIc uses pin 9 for an unrelated purpose, and the computer doesn’t support having two external 5.25 inch drives, because it already has an internal one.
Wow, Really amazing evolution! Great work Steve! I have to translate it into Japanese immediately and let my friends know…
I don’t suppose the lessons learned in getting Dual 5.25 to work could be applied to making a dual 3.5 mode (for the IIgs at least, or 3rd-party contollers)? It would pretty amazing to have two Emus acting as a full set of four floppies.
Thanks so much for the dual disk support! This morning I was literally just contemplating whether this was something you could pull off and BOOM you pulled it off.
Is there a way to use favdisks to autoload both disks 1 and 2?
It’s greedy, but I wanted to second the post above and also ask if this dual drive technique could be applied to 3.5” disks as well in the future. Thank you, I have ordered a second floppy emu to have both 3.5 & dual 5.25” droopy emu drives attached at the same time via the daisy chainer.
This is the deciding feature to propel me to buy the unit. As an Apple //c user, I’d like to see an enhanced version of the internal board that would allow the internal floppy to serve the following roles:
1. Behave normally, while floppy emulator behaves as drive 2.
2. Behave as drive 2, while floppy emulator behaves as drive 1.
3. Sit disabled, while floppy emulator behaves as drives 1 and 2.
4. Spin and move the head under the control of the 65C02, while the floppy emulator grabs data from the read-data wire (allowing high-speed disk imaging with the ability to accurately record signals with precise timing).
5. Spin and move the head under the control of the 65C02, while the floppy emulator supplies data (allowing the creation of disks from Woz files, even if they have more data per track than the 65C02 could normally write).
I think these could be accomplished by using a dual non-inverting buffer chip to buffer the drive 1 select and write-data signals, and then passing them to the floppy drive via ~470 ohm resistors. Run both sides of the drive-1 select resistor and the drive side of the write-data resistor to an external connector, and the internal drive would work normally when nothing back-drives the signals, but an external device could override the signals driven by the Apple //c. Do those sound like plausible features?
Thank you, Steve! This is fantastic news, and propelled me into buying the Model C (I have been rocking the Model B)!
Gave it a try on the IIc+ and the dual floppies mode works, nice job.
“Successful formatting is dependent on the write caching behavior of your SD card.”
Can you recommend a specific brand/ model number to use so that this doesn’t occur?
The only micro SD card I have is the one I purchased from you.
In brief: no I can’t. Formatting should work with most SD cards, and I’ve yet to find an SD card where formatting flat-out didn’t work. If it fails one time, you can try formatting again and it will likely succeed. I’ve successfully tested with the SD cards I’m selling now (since July 2020), which are 4GB cards manufactured by Phison. The issue is that SD cards have an internal controller and write cache that determine when the SD media actually gets written. The details are a black box, generally not something that manufacturers document or advertise. The cards are designed for high average write throughput, but there can sometimes be a long delay writing a single block, like a burp in the data stream. There’s some discussion of this issue here: https://www.reddit.com/r/embedded/comments/908mwj/sd_card_throughput_occasional_pausedelay/
There’s definitely some irony here, in that 2021 technology sometimes struggles to match the performance of 1970’s technology. Floppies are a direct storage medium with small capacity and low data rates, but once the read/write head is in place, the data transfer rate is 100% constant and the latency is zero. No caching or buffering or transaction overhead to worry about. It’s sort of like how despite all the advances in telecommunications, call quality on an iPhone is in some ways inferior to a POTS telephone from the 1950s.
The 1970s technology has latency between when one starts the drive or moves the head and when one can actually start writing. What’s different compared with an SD card is the only way to accommodate the latency is to add sufficient delay to allow for the worst case, at least when doing a blind whole-track write.
Out of curiosity, I wonder how much data could be written on a 5.25″ floppy with specialized equipment in such a way as to be readable by a stock Disk II. Even just using the stock controller on my Apple //c I’ve pushed the capacity over 210K (sixteen double-hi-res pictures), but I wouldn’t be surprised if that could be pushed to 240K by using a faster data rate on the outer tracks.
I received my emu in the mail on 2/9, started putting it together on 2/11, discovered the button block was missing and emailed Steve. He responded a little later, shipped the replacement 2/12, I got it today, 2/16, and have it together. Now to test it on my 2c+.
@Steve good to hear that there shouldn’t be a card problem. Now I just have to wait until you figure out how to make 2 drives work for a //c 😉
+1
I\’m blown away by Steve\’s dedication to this project. Rarely (if ever) have I received such a wealth of new functionality in an embedded device– even from \”major\” manufacturers. Hats off to you, Steve. I really appreciate how your work makes my retrocomputing experience better and better.
Looking into how to support Floppy Emu dual drives on the Apple IIc. I could build a fixed-function adapter to do it, but my head is exploding trying to visualize a way to also include internal/external drive swapping like the current adapter. So there would be three possible settings:
Normal: motherboard -> internal drive, DB19 -> external drive 1, 5V -> external drive 2
Swapped: motherboard -> external drive 1, DB19 -> internal drive, 5V -> external drive 2
Dual-Drive: motherboard -> external drive 1, DB19 -> external drive 2, 5V -> internal drive
I think I need a 3P3T switch?? Not the most common piece of hardware.
I think you just need a DP3T switch, which is pretty common.
For example, at Digikey, the EG2315 is $0.58 in quantity 1 or $0.47 in quantity 100.
Use side A to connect Apple’s internal-drive select to internal select, emu 1, or emu 1.
Use side B to connect Apple’s external-drive select to emu 1, emu 2, or internal select.
I forgot to mention that a pull-up should be added for the signal going to the internal drive, and probably included for the external drives unless the Floppy Emu would include them.
Otherwise, if you don’t like the idea of using pull-ups, one could use a 3PDT switch to connect the internal drive to Mboard/5V/DB19, Emu0 to DB19/Mboard/DB19, and use a triple 3-input NAND to connect EMu1 with the NAND of the the switched IntDrive, Emu0, and the inverse of MBoard.
As another alternative, you could use a pair of DPDT switches, one of which swaps the roles of the motherboard and DB19 signals, and the other of which either connects the floppy to one of the outputs from the first and connects emu2 to 5V, or connects that same output from the first switch to emu2 and connects the the floppy select to 5V.
I think the most robust approach would probably be to use pull-ups but then put the drive select wires through buffers so they get driven with solid highs and lows, but the dual DPDT approach would also be quite robust.
Hi Steve, is there any timeframe for when the Floppy Emu bundle will be back in stock?
Thanks!
Steve,
Have loaded 0.2R & 30 firmware onto my rev C floppy emu. However, I am still having problems when trying to format emu floppy images using Apple Pascal rel 1.1 Formatter program on an APPLE II europlus.
It fails with a Bad media / write protected error message.
Thoughts please
Peter
I’d like to see some kind of A/B switch that would allow switching between the Floppy Emu with dual 5.25″ support and a DuoDisk. Would that be possible?
Steve — do you ever plan on going into the tech details on what it took to get NIB writing to work on the Floppy Emu? Given what is missing in NIB files, making it work for reading, let alone writing, with a real Apple II is a great accomplishment. I would definitely love to hear more details on this.
In theory NIB should be easier to work with than other formats like PO or DSK, because NIB represents exactly what’s physically on the disk, instead of the logical data (sector contents) contained in PO and DSK images. NIB is just a raw bitstream that’s output as-is. But the Floppy Emu hardware isn’t really designed for this, although maybe it should have been. The Emu is inherently a byte-oriented device and it can only really output groups of 8 bits at a time, where the MSB is always an implied 1 and only 7 actual bits are handled by the hardware. With some ugly overloading of control signals, I was able to squeeze in an 8th bit.
But it’s still not quite right due to the limitations of the NIB format itself. NIB assumes a fixed number of bits per track, when in reality the number of bits can vary slightly due to how it was originally formatted. The actual bit rate can vary too, faster or slower than the nominal 4 microseconds per bit, but NIB files don’t have a way of handling this.
NIB writing is also theoretically easy, since no interpretation of the incoming bitstream is needed: you just overwrite part of the original NIB bitstream with a new bitstream received from the computer. In practice this is hard due to various latencies in the Floppy Emu, its byte-oriented nature, its limited RAM, and slow write speeds of SD cards. NIB writes get quantized to a byte boundary, and the first couple of bytes written will be lost due to latency switching between read and write mode. Normally these are padding bytes so it doesn’t matter. When writing a single sector, this works OK. When writing an entire track at once, as during formatting, it can have trouble if the RAM fills up and data can’t be flushed quickly enough to the SD card.
In my opinion, NIB should be considered a legacy format now, and the WOZ bitstream format is a better solution for the problem NIB was meant to solve. But for non-copy-protected disk images, I still prefer the standard formats like PO and DSK. They directly represent the disk’s 140KB of data, rather than dragging in the details of low-level encoding on the desk media.