I’m continuing work on the daisy chain adapter concept for Floppy Emu, and I’ve run into a problem. There’s a pulldown resistor on the Floppy Emu board that’s too weak (resistor value is too large) to reliably pull the voltage all the way down to the logic low threshold. This causes upstream drives and computers in the daisy chain to sometimes mis-detect what type of drive the Floppy Emu is currently emulating, resulting in a malfunction of the whole chain. I’d like to add some extra circuitry between the Emu and the upstream drive to fix this problem, but the details are complex and I haven’t found any great solutions. Here are some diagrams to illustrate what’s happening:

Figure 1 shows a Floppy Emu connected directly to an Apple IIGS.

Figure 2 shows a Floppy Emu daisy-chained to an Apple 3.5 Drive, A9M0106.

Apple designed a disk interface with double-purposed signals. Depending on the disk drive type, the data signal EN35 is either an input to the drive (3.5 inch drives), or is pulled low by the drive (5.25 inch and Smartport drives). The double use requires an open drain driver or inline resistors, to avoid potentially shorting power to ground if both ends drive the signal with different values.

For equipment that’s “3.5 inch aware”, it can detect whether a daisy-chained drive is a 3.5 inch drive by monitoring the voltage of EN35. The SR latch in figure 2 shows one example. At reset, it assumes the daisy-chained drive is not a 3.5 inch drive. But if EN35 is ever observed to go high, then it knows the daisy-chained drive *is* a 3.5 inch drive.

 
Need More Pulldown

On a real floppy drive’s input, EN35 is either connected to an input buffer or tied directly to ground. But Floppy Emu can do either one, depending on the emulated drive type, and that’s where the problem appears. To protect the Emu’s CPLD chip when EN35 is treated as an input, there’s an inline protection resistor of 1K (Model B) or 330 ohm (Model C). When the Emu wants to pull down EN35, it must do it through that resistor. This forms a voltage divider with the resistor in the upstream equipment, preventing the EN35 voltage from being pulled fully to 0 volts.

In figure 1, with the Model C’s 330 ohm pulldown, the voltage at Vt is pulled down to 2.0 volts. That’s not low enough for equipment (like my proposed daisy-chain adapter) to detect as a valid logic low. With the Model B’s 1K pulldown, the situation is worse, and the voltage at Vt is only pulled down to 3.3 volts. When the pulldown is inactive, the voltage measured at Vt is about 4.9 to 5.0 volts.

In figure 2, with the Model C’s 330 ohm pulldown, the voltage at Vt is pulled down to 0.49 volts. That almost works, with correct behavior about 75% of the time. On the Model B with the 1K pulldown, the voltage at Vt is only pulled down to 1.16 volts. That’s not low enough, and the circuit doesn’t work correctly. By butchering a board and testing various resistances, I found that a 200 ohm pulldown works reliably.

 
Potential Fixes

I’m in search of a magic circuit that can be inserted between Floppy Emu and the upstream device, that will fix this ugly problem:

When Floppy Emu is driven from the Apple IIgs as in figure 1, I can control both the “magic circuit” and the buffer used to sense the EN35 voltage, so a solution is relatively simple. But finding a solution that works with the Apple 3.5 drive (figure 2) is more difficult, because that feedback path to the SR latch is outside my control.

Passive Resistors – How about adding an extra pulldown resistor to bias the EN35 voltage lower? Or some kind of voltage divider? I don’t think that can work. An extra pulldown would need to be fairly strong in order to pull EN35 to a reliable logic low, so it could no longer reach a reliable logic high.

Voltage Controlled Pulldown Booster – Maybe the magic circuit could monitor the EN35 voltage, and if it ever went below ~3.5 volts, the circuit could activate a second strong pulldown to bring the voltage to 0 volts. The problem with this idea is that it would create a feedback loop. Once the second strong pulldown was activated, it would hold the voltage at 0 and keep itself activated forever.

Current Controlled Pulldown Booster – Maybe the magic circuit could monitor whether more than 1 mA is flowing into the Floppy Emu, meaning that the pulldown is active. Then it could engage a pulldown booster of some type to bring the voltage to 0 volts. This sounds like a job for a BJT, perhaps, but I’m not sure. Once the second pulldown was activated, I think all the current would flow through that pulldown instead of to the Floppy Emu, causing the booster circuit to shut off again. Maybe there’s a solution here, but I don’t see it.

Bidirectional Level Shifter – I’m not actually doing level shifting here, but level shifters have the useful property of electrically isolating the two sides. The classic bidirectional shifter based on an N channcel MOSFET won’t work here, though. It prevents a high voltage from damaging a lower-voltage circuit, but does nothing to help if a low voltage source is too weak. Maybe there’s a solution based on some other bidirectional isolation technology?

Op Amp, or Diode – Sure, why not? Now I’m just naming random electronic components, hoping for a solution. Try enough permutations, and something must work…

 
Final Thoughts

The only plausible path that I see right now is a state-based solution, similar to the SR latch that’s in the Apple 3.5 drive. This could be used to enable one of two buffers that isolate the sides of the circuit, such that the direction of data flow is always definitively in one direction or the other. Data flow would be assumed to go from the Floppy Emu to the upstream device until proven otherwise. And a weak pullup on the Floppy Emu side would compensate for the weak pulldown.

I’m not thrilled with this solution, because it’s state based, requires reset circuitry, and overall seems cumbersome. I’ll elaborate more in a future post. Meanwhile if you have other suggestions, please leave a note in the comments box.

Today I’m thrilled to announce the newest member of BMOW’s Floppy Emu disk emulator family – the Model C. Floppy Emu is a floppy and hard disk emulator for classic Apple II, Macintosh, and Lisa computers. The new Model C introduces an eye-catching 1.3-inch 128×64 OLED display, with crisp text and amazing contrast. Fonts are more detailed, and the OLED shows eight lines of text for better context when scrolling through a long list of filenames. The new display is a real treat for the eyes.

The extra resolution of the OLED helps a lot. Text characters are 5×7, compared to 3×6 characters on the previous generation LCD. This provides a nice improvement in legibility.

The Model C also features a new push-pull style micro-SD card holder, for improved durability. Some past customers lobbied for the change to a push-pull vs push-push style, and after some experimentation I decided that I agreed. This is the same style of SD card holder found in most mobile phones today, and if you’re the sort of person who’s constantly inserting and removing the SD card then you’ll appreciate this change.

With the introduction of the Model C, Floppy Emu is also moving to a gloss piano black color scheme. It won’t impact the disk emulation, but it sure looks good.

The same great disk emulation features from earlier models are also supported in the Model C. It’s directly compatible with the entire Apple II line, emulating 5 1/4 inch disks, 3 1/2 inch disks, or Smartport hard disks all without the need for a separate adapter. Of course classic Macintosh and Lisa disk emulation is supported too. Model C reads and writes emulated 140K, 400K, 800K, or 1.4MB floppy disk images, or hard disk images up to 2GB, if supported by your Apple computer.

Features

• Apple II Floppy – 140K (5 1/4 inch) and 800K (3 1/2 inch) disks
• Apple II Hard Disk – Smartport disk volumes up to 32 MB
• Macintosh Floppy – 400K, 800K, and 1.4MB disks
• Macintosh Hard Disk – HD20-type disk volumes up to 2 GB
• Lisa Floppy – 400K and 800K disks, Lisa Office System and MacWorks
• See the compatibility table for more details

 
Model C Case

A new board requires a new case, so today I’m also announcing the Frosted Ice Acrylic Case for Model C. The cut-out surrounding the SD card has been enlarged, to make it easier to remove from the push-pull card holder. The opening in the top has also been repositioned and resized to fit the OLED, and there’s a subtle engraving surrounding it.

The new case is designed specifically for the Model C. If you need a case for the older Model A or B, I’ve still got that too.

All of this new hardware is available now on the Floppy Emu product page, or directly from the BMOW Store. Thank you for supporting retro computer designs!

Some Apple II computers can daisy-chain disk drives: connect multiple disks, one after another in a single chain. I’m exploring options for the BMOW Floppy Emu disk emulator to support daisy-chaining more flexibly than it does now. I’d love your thoughts on whether you’d find this personally useful – please read below and leave a note in the comments section.

 
Daisy Chain Basics

Daisy-chaining makes it possible to connect many different disk drives to the same computer, without needing a separate disk controller card for each drive. Among early Apple computers, only the Apple II family has daisy-chaining capability – the Macintosh and Lisa don’t support it. Even among Apple IIs, daisy-chaining is only very useful on the Apple IIgs, the rare Apple IIc+, and to a lesser extent the Apple IIc. Other Apple II models lack the necessary hardware or the ability to control multiple types of drives, so this discussion will focus on the IIgs.

The Apple IIgs supports three different types of disk drives:

• “dumb” 3.5 inch drives, like the Apple 3.5 Drive (A9M0106)
• “smart” drives, like Floppy Emu’s Smartport HD mode, or the Apple Unidisk 3.5 (A2M2053)
• 5.25 inch drives

At most two drives of each type can be placed in the chain, six drives in total.

 
Drive Ordering and Boot Limitations

A critical requirement is the ordering of drives in the daisy chain: the dumb 3.5 inch drives must appear before the smart drives, which must appear before the 5.25 inch drives. This requirement stems from the way the disk port’s control signals are multi-purposed to serve several different types of drives, where some types didn’t yet exist when the older types were designed. You can try physically connecting the drives in a different order, but some of them won’t work and may even be damaged.

The ordering requirements have the side-effect of constraining the computer’s options for boot disks. With complex daisy chains, these constraints can become inconvenient and annoying.

Dumb 3.5 inch drives and smart drives are placed in a single logical group that’s mapped to slot 5. Only the first drive in that group can be used as a slot 5 boot drive. If two dumb 3.5 inch drives are connected, only the first can be used to boot the computer. And if both a dumb 3.5 inch drive and a smart drive are connected, only the 3.5 inch drive can be used to boot the computer. The smart drive can never serve as a boot drive, in this case.

 
With the Floppy Emu

The Floppy Emu was originally designed as a Macintosh device, and it lacks a daisy chain output connector. That means it can work happily in an Apple II daisy chain with other drives, but only as the last drive in the chain. Often this isn’t an issue, but for some combinations of emulation modes and disk drives, it causes difficulties. Here are some Apple IIgs setups that aren’t currently supported, due to Floppy Emu’s absence of a daisy chain output:

• Floppy Emu in Smartport HD emulation mode, combined with one or two 5.25 inch drives.
• Floppy Emu in 3.5 inch emulation mode, combined with one or two 5.25 inch drives.
• Floppy Emu in 3.5 inch emulation mode, combined with another 3.5 inch drive, where Floppy Emu serves at the first (boot) drive.
• Floppy Emu in 5.25 inch emulation mode, combined with another 5.25 inch drive, where Floppy Emu serves at the first (boot) drive.

Giving a daisy chain output to the Floppy Emu would enable all of the above setups. Unfortunately it would also add more complexity to the device, because the daisy chain output isn’t simply another physical connector with its data signals bussed from the daisy chain in. It’s a complex logic device whose behavior must change depending on what type of drive is being emulated, whether that drive is currently enabled by the computer, and what type of drive (if any) appears next in the daisy chain. Depending on the circumstances it must alternately cross-over, gate, or otherwise modify the disk control signals. This would require a new programmable logic device, likely a small CPLD similar to the one Floppy Emu uses for disk emulation. But the added cost and complexity would be little benefit to anyone except Apple IIgs owners.

I’ve been exploring a different route – a stand-alone daisy chain adapter rather than a modification to the Floppy Emu. This adapter would function like a T splitter, taking Floppy Emu’s place in the daisy chain, with a connection for the Floppy Emu as well as a standard daisy chain output for additional drives. This would provide a daisy chaining option for Floppy Emu owners who want one, without negatively impacting anything else.

Note there’s still one Apple IIgs setup that can’t be supported: Floppy Emu in Smartport HD emulation mode, combined with another 3.5 inch drive, where Floppy Emu serves as the boot drive. The Apple II drive ordering and boot requirements make this combination impossible, as described earlier (except for some very awkward work-arounds). This has nothing to do with the Floppy Emu or its lack of a daisy chain output – the same limitation exists with other 3.5 inch and smart drives.

My question to you, Apple II reader, is whether a stand-alone daisy chain adapter would interest you for enabling the Apple IIgs daisy chain setups listed above. It would be clearly a niche item for a niche product, so I’m unsure if it makes sense.

Aside from the cost of manufacturing and possible low demand for this adapter, the biggest hurdle would be finding a supply of female DB-19 connectors for the daisy chain output. This could be a major challenge. When the global supply of male DB-19 connectors was exhausted a few years ago, I had to commission the manufacturing of 10,000 new ones to continue with Floppy Emu production. That was very expensive, and I definitely can’t afford to do something like that here. Hopefully enough DB-19F’s are still in a surplus parts warehouse somewhere!

Good news, Apple II fans – support for .WOZ disk images is now available on the BMOW Floppy Emu disk emulator!

The .WOZ disk image format is an exciting newcomer to the vintage computing world. First released in 2018, it was developed by John K. Morris with the goal of being the most accurate possible representation of data encoded on an Apple II floppy disk. Other disk image formats omit certain “unimportant” data like sector headers, or make other simplifications and assumptions about the disk data. These assumptions are fine for standard software, but they fail for vintage copy-protected software that intentionally violates the standards. Some formats like NIB come closer to capturing all the low-level details of the floppy data, but still fall short. With the WOZ format, it’s possible for the first time to run heavily copy-protected vintage Apple II software directly from a disk emulator, without the need to “crack” the protection. This includes software using copy-protection techniques like cross-track synchronization, intentional invalid or blank regions of the disk, and even the dreaded Spiradisc spiral data tracks.

WOZ format caught my attention when it was first announced last year, and I read through the documentation, but concluded it would be too time-consuming and difficult to add to the Floppy Emu. I was skeptical that some of the timing requirements for cross-track synchronization and other WOZ featues could be met without pre-loading the entire disk image into RAM. The Emu hardware doesn’t have enough RAM to pre-load a full disk image, so the idea looked like a non-starter, and I shelved it. But after a steady trickle of inquiries I finally took a second look at WOZ a couple of weeks ago, and was able to make it work. I was right about the time-consuming part, but wrong about the rest – I eventually found solutions to the technical challenges that worked on the existing hardware. The result is worth it. Many thanks to John for answering my questions and providing sample disk images for testing.

About Floppy Emu: Floppy Emu is an external disk emulator for classic Apple II, Macintosh, and Lisa computers. Using disk images stored on an SD card, it can emulate 5.25 and 3.5 inch floppy disks, Smartport hard disks, Unidisks, and HD20-type hard disks.

 
Apple II Copy Protection Tricks

I discussed Apple II copy protection techniques a couple of years ago here. The WOZ format addresses three major areas:

Non-standard data (example: Rescue Raiders) – Normal Apple II floppy disks have 16 sectors per track, 256 bytes per sector, with a standardized sector header beginning with the famous D5 AA 96 byte sequence. Copy-protected disks throw all the standards out the window. To avoid any possible confusion, WOZ stores each track as a single very long bit sequence, without making any assumptions about what the bits mean, or how many bits there are. The track can even have fractional bytes, with a bitsteam size that’s not a multiple of eight.

Fake random bits (example: Print Shop Companion) – Normal floppies have data on every track. Even if there’s unused space on the disk, valid sectors will still be present – they’ll just be marked as unused. Copy-protected disks may have tracks that are truly blank, with no magnetic flux transitions. A true blank track is different than an empty/unused track. The drive hardware goes slightly haywire when attempting to read blank tracks, turning up its auto-gain control until it begins to see flux transitions that aren’t really there. The result is that reading a blank track will return a random sequence of bits that’s different each time it’s read. Copy-protected software can check for this. Because there’s no way to write a truly blank track on a standard Apple II floppy drive, this is an effective method of copy-protection.

A related protection technique is to include disk bytes with three or more consecutive zero bits. These can’t be read reliably by Apple II floppy drives, and they appear as random bits, similar to blank tracks. Copy-protected games can read the same bytes multiple times, to verify that random bits appear where they should.

The WOZ format solves both problems by specifically marking tracks and bits that should be treated as random, rather than as standard zero bits. The Floppy Emu firmware can then use a pseudo-random number sequence to generate such bits when needed.

Synchronized tracks (examples: Take 1, Archon, Frogger) – On a normal floppy disk, each track is a narrow ring of bits on the magnetic media, and the ring can be rotated at any angle relative to its neighbors without affecting the software. But some copy-protected disks rely on a specific rotational synchronization between neighboring tracks. For example they may require that sector 0 of the first track is physically adjacent to sector 0 of the next track. Because Apple II disk drives ignore the disk’s index hole, this track-to-track rotational synchronization is impossible to achieve when writing disks on a standard drive, and requires special mastering disk hardware. “Take 1” is a good example of software that relies on this type of cross-track synchronization.

WOZ format stores each track’s bitstream relative to the same reference angle. That preserves the cross-track synchronization information. But it’s up to the Floppy Emu to maintain a consistent rotational angular velocity for the emulated spinning floppy disk while stepping between tracks or performing other operations that temporarily interrupt the bitstream. This was the most difficult part of getting WOZ working on the Floppy Emu hardware. It required maintaining microsecond-level timing information about the current state of the bitstream, even while servicing hardware interrupts, reading data from the SD card, or updating the display.

Some copy-protected games take cross-track synchronization even further. They include a double-wide track that spans the width of two normal tracks. The software starts reading from the first track, and then steps to the next track while reading. Reading and stepping at the same time – that’s just evil. “Archon” is one example of this double-wide synced track protection method.

The ultimate in synchronized track copy protection for Apple II is Spiradisc, as found in “Frogger”. The data begins on track 0, but after less than a full disk rotation, the data jumps to track 0.25 and immediately continues. From there it follows the same pattern, with a short data section on each quarter track before jumping to the next track, spiraling all the way through the disk. Once I got Spiradisc working on the Floppy Emu hardware, I knew things were looking good.

And more – Other copy-protection tricks that are addressed by the WOZ format include monkeying with the soft switches, resetting the latch midway through a byte, and storing data on quarter and half tracks (The Bilestoad). It’s a jungle out there!

There’s an incredible variety of copy-protection schemes used by vintage Apple II software. Even with the addition of WOZ support to the Floppy Emu, you may still encounter some protected software that doesn’t work correctly. Some games such as Frogger apparently work only when using a real Disk II controller card, and the built-in disk port of an Apple IIc or IIgs won’t work. A few protected titles may work intermittently or not at all, for reasons that aren’t clear. If a game doesn’t boot on the first attempt, give it a second try. Typically the protection check happens only once during booting, and then you’re good to go.

 
What’s Included

• support for WOZ1 and WOZ2 format disk images
• cross-track synchronization capability
• fake random bits support
• disks with more than 35 tracks
• internal upgrade from half-step to quarter-step precision
• related improvements for NIB support

 
TL,DR

“My God, man! Stop talking and just give me the download link!”

Floppy Emu firmware 0.2G contains all the new features described above. This was a major change to some fundamental parts of the emulation code, and there may be unknown bugs, so this firmware is a “beta” release. If you don’t have a specific need to use .WOZ disk images, then stick with the previous firmware version for now. But for those who like to live life on the edge, here it is:

for Floppy Emu Model A – apple-II-0.2G-F22
for Floppy Emu Model B – apple-II-0.2G-F23

You can also download some sample WOZ disk images. All of these have been tested successfully with Floppy Emu using the 0.2G firmware. – WOZ sample disks

Craig of apple-2.com has put together a great collection of Apple II software with a Floppy Emu theme. It’s a 32 MB bootable ProDOS disk image with an animated splash screen, and it uses the amazing Bitsy Bye program launcher to select from a variety of included games and utility programs.

Floppy Emu can use this disk image to boot your computer, when the Emu is configured for Smartport hard disk emulation mode. Just rename the disk image to SMART0.PO and copy it to your SD card. It’s compatible with the Apple IIGS, Apple IIc and IIc+, and Apple IIe with Liron card.

Craig cautions that some of the included games like CANNON.BLITZ may not work correctly when launched directly from Bitsy Bye, due to a memory conflict. If you find a game that crashes when run from Bitsy Bye, reboot and select GAMES.CATALOG from within Bitsy Bye. Then type in “-CANNON.BLITZ” or “BRUN CANNON.BLITZ” and the game should run normally.

Download the disk image here: SMART0.PO

Don’t forget to check out apple-2.com’s other vintage download collections.

Looking for a discount on a Floppy Emu Deluxe Bundle, and want to spread some holiday cheer at the same time? BMOW is running a holiday promotion called Get 10 Give 10. Use the coupon code GET10GIVE10 during checkout, you’ll save $10 off a Floppy Emu Deluxe Bundle, and I’ll donate a further $10 to Samaritan House of San Mateo. It’s a chance to save money on retro computer hardware and do something good for the world too.

Floppy Emu is a floppy and hard disk emulator for classic Apple II, Macintosh, and Lisa computers. It uses an SD memory card and custom hardware to mimic an Apple floppy disk or hard disk drive. It’s perfect for booting your favorite games, transferring files from vintage to modern machines, and troubleshooting a computer without a working OS. The deluxe bundle includes the Floppy Emu, an acrylic case, and an SD card with a collection of vintage Apple software disk images. Full details are available here.

Samaritan House provides food, shelter, healthcare, housing, financial assistance, and more to low-income and homeless persons in the San Francisco Bay Area. Even in the midst of Silicon Valley’s affluence, there are many people struggling just to meet the basic needs of daily life. A small boost at the right time can help them regain self-sufficiency. Samaritan House operates a broad variety of free services and one-on-one assistance with caring staff. I’ve seen first-hand what they can do, and it’s amazing.

If you’ve had your eye on a new Floppy Emu, or need a second or third unit for your growing computer collection, here’s your opportunity. Thank you for supporting the good work of Samaritan House!

Enter the coupon code GET10GIVE10 during checkout to take advantage of this offer.