BMOW title
Floppy Emu banner

Jumbo OLED Fun

A few days back, a discussion on the Apple II Facebook group asked about large format Floppy Emu displays for people with vision difficulties. Here’s a 2.42 inch OLED that’s a simple drop-in replacement for the OLED in Floppy Emu Model C. With more than 3x the screen area of the standard OLED, that’s a big increase in display size!

This particular OLED was $17.99 and can be purchased here. The only minor issue is that the rightmost column of pixels appears on the left side of the display – some sort of off-by-one error.

Read 2 comments and join the conversation 

Daisy Chain Design Vote

Vote for your preferred Floppy Emu daisy chain design option! I’ve been working on this concept for several weeks, and wrote about it here, here, here, and here. I’ve now realized there are two different paths I could follow, with different feature sets and likely costs. For those who are potentially interested in the daisy chain adapter, I’d like to know which option you’d prefer.

Option 1 is what I’ve been discussing all along. It’s an intelligent adapter based on a microcontroller or CPLD, that allows for pretty much any valid combination of Floppy Emu mode and daisy chained drive types. It auto-detects the modes and types, so there’s nothing to configure. It has some LEDs to show the detected types or other debug info. And it also fixes some other minor problems with Floppy Emu daisy chaining like this one. I’m about 90% sure it will work, but there may be weird rare bugs. Retail price will likely be somewhere in the 30’s (very rough guess).

Option 2 is a “dumb” adapter, somewhat similar to the retired Universal Adapter for Floppy Emu Model A. It’s a fixed configuration of a few 7400-series logic chips. It supports the most useful combinations of Floppy Emu mode and daisy chained drive types, but does not support all combinations. Drive types are not auto-detected, and must be manually chosen with a switch. There are no status or debug LED’s. It doesn’t fix the other minor problems. I’m 100% sure it will work. Retail price will likely be somewhere in the 20’s (very rough guess).


  Option 1 Option 2
Design Smart Dumb
Disk Type Detection Automatic Manual Switch
Configurations Emu 3.5 with chained 3.5
Emu 3.5 with chained Smartport
Emu 3.5 with chained 5.25
Emu Smartport with chained 5.25
Emu 5.25 with chained 5.25
Emu 3.5 with chained 3.5
Emu Smartport with chained 5.25
Emu 5.25 with chained 5.25
Status LEDs Yes No
Minor Fixes Yes No
Development Time Slower Fast
Confidence 90% 100%
Cost $30’s $20’s

For the sake of this discussion, Unidisk 3.5 emulation mode counts as Smartport. Note that neither option 1 nor 2 supports Emu Smartport with chained Smartport.

Option 1 is certainly the most flexible, and has the best cool factor. With a change of firmware, it could even do other cool disk-related things I haven’t dreamed of yet. And I’ve already sunk a lot of time into designing it.

But I can’t escape the feeling that I’ve lost sight of the core purpose and over-engineered a solution. There’s a lot to be said for a keeping-it-simple design, and that’s what option 2 is. Auto-detection is very nice, but is flipping a switch really so bad? Would anybody really miss the two disk configurations this option lacks? Option 2 could be built easily, but option 1 would have to be programmed and tested after assembly, adding time and cost.

What do you think? Despite how much time I’ve spent working towards option 1, I’m leaning towards option 2. Because it’s probably more important that this thing works rock-solid in the common use cases, and is as affordable as possible, than that it has every whiz-bang feature that only 1% of people will care about.

Read 20 comments and join the conversation 

Daisy Chain Adapter Progress

I’m still working away on the daisy chain adapter concept for Floppy Emu, and I’ve prototyped something that mostly works. It’s a real mess on the breadboard. There’s an AVR microcontroller in there somewhere, plus some open drain buffers, some NAND gates… I think I also saw an engine controller from a 2003 Ford Focus. Yikes. I solved the pulldown problem described in my previous post by incorporating the proposed SR latch circuit.

For readers who may have forgotten, the goal of this project is to design a Floppy Emu accessory that:

  1. adds a daisy-chain output port, to attach more drives
  2. addresses some existing Floppy Emu daisy-chain limitations
  3. possibly includes a signal debugging interface or other goodies

It’s imagined as a T adapter. Power and input signals will come from the computer or the upstream drive in the daisy chain. One branch of the T will connect to a Floppy Emu. The other branch will connect to a real disk drive, or multiple drives in a chain. From a logical perspective, these drives will appear downstream from the Floppy Emu. This will enable the use of complex multi-drive setups involving a Floppy Emu and other drives that may not be possible otherwise.

After looking at this concept from every angle, I’ve concluded it will need these elements:

  • combinatorial logic – roughly 8 inputs and 8 outputs
  • three or four bits of state, ideally implemented as SR latches
  • open drain buffers
  • power-on reset circuitry
  • maybe a clock source
  • assorted levels shifters, pull-up resistors, etc
  • a DB-19 male and a DB-19 female

My leading plan is to use a simple AVR microcontroller as the heart of the device. But since that’s far from an obvious choice, let’s take a look at some alternatives.

Discrete logic – I could build the whole thing from common 7400-series parts like NAND and NOR gates, with a few extras for things like power-on reset. But the part count and total cost would be higher than the alternatives. It would also prevent me from experimenting with different logic equations and different behaviors.

Parallel ROM – An 8 input, 8 output logic equation can be implemented as a 256 byte ROM. It’s reprogrammable. But the ROM wouldn’t help with the other needed elements, and in-circuit reprogramming of a parallel ROM is annoying. 5V ROMs are also increasingly rare and more expensive than the alternatives.

CPLD – This was my original plan, and is still a possibility. Any combinatorial logic can be easily programmed or changed in a CPLD. But there are headaches. CPLDs don’t like to make latches. Without latches, I need a clock source, which some otherwise-promising CPLD types lack. Most CPLDs are also 3.3V or 1.8V, requiring 5V level shifters on both the inputs and outputs.

AVR – Even the simplest AVR microcontroller can run at 5V, has a built-in clock, has a power-on reset circuit, and has built-in pull-up resistors. They’re extremely flexible for debugging or experimentation. And they’re cheap: for the cost of two or three 74LS00 chips, I can have a full-blown microcontroller. The combinatorial logic can be implemented in code. Read the inputs, do a table lookup for the logic function, set the outputs, repeat.

Logic Delays

The one big drawback of an AVR solution is that the combinatorial logic function will be much slower than the alternatives. Even with a tight code loop, the delay from input to output will be 1 or 2 microseconds, compared to 10 to 100 nanoseconds for the other alternatives. This delay will put the processed disk control signals slightly out of phase with the other disk signals. (Yes I know there are some microcontrollers with built-in programmable logic, but I’m not going there.)

Beyond some level, the combinatorial logic delay will cause disk errors. So how fast does it need to be? The short answer is 1) it depends, and 2) I don’t know.

It depends, because some signals appear more sensitive to delay than others. From my limited tests, the PHI3 signal is much more sensitive than the /DRIVE1 and /DRIVE2 enable signals. So one option is to partially handle PHI3 with hardware gates, and do the rest in software.

The exact level of tolerable delay is something I’ll need to test, and I’m not sure where the worst-case scenario lies. A PHI3 delay of 3.5 microseconds prevented a 3.5 inch drive from working, but 2.5 microseconds seemed OK. /DRIVE1 and /DRIVE2 appeared able to tolerate delays up to 20 microseconds. But I don’t completely trust those numbers yet.

So what now? I’m attracted to the AVR solution, and I think there’s a good chance it’ll work, but I won’t really know until I design and build a PCB and test it thoroughly. There are too many problems with signal integrity and grounding in my breadboard circuit to fully trust it. I’m undecided how to handle PHI3. Maybe I’ll design a PCB that can either handle PHI3 in software or in hardware gates, and try both ways. Then I’ll need to design a second, final version of the PCB once I’ve found the timing limits. Onward!

Read 2 comments and join the conversation 

Circuit Fixes and Pulldown Problems

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.

Read 7 comments and join the conversation 

Introducing the Floppy Emu Model C

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.


  • 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!

Read 16 comments and join the conversation 

Part Selection and Schmitt Trigger Oscillator

I often obsess over little details of my circuit designs, and the daisy-chain adapter for Floppy Emu is no exception. The design needs a small CPLD for the daisy-chaining logic, and for various reasons I have narrowed the choices to the Lattice ispMACH LC4032ZE and LC4032V. These are both 32 macrocell CPLDs, and are very similar except for a few details:

LC4032ZE – 48 pins, 0.5 mm pin pitch, 1.8V core, built-in oscillator

LC4032V – 44 pins, 0.8 mm pin pitch, 3.3V core

The 4032ZE is the newer of the two options, and the 4032ZE supply at distributors is a bit more plentiful. It also has a built-in 5 MHz RC oscillator with +/- 30% accuracy, which can be divided down to the kHz range or lower frequencies without using any macrocells. As it happens, the daisy chain adapter needs a clock source in the kHz range for periodic tasks, but the exact frequency isn’t too important, so this is perfect.

The drawbacks of the 4032ZE are its core voltage and its pin pitch. With a 1.8V core serving 3.3V I/O to and from 5V disk drives, I’d need to design a three-voltage system. In practice that means an additional voltage regulator, some extra decoupling capacitors, and a bit more headache with the board layout. 0.5 mm pin pitch means the pins are very tightly spaced. It creates a greater likelihood of soldering errors and hard-to-see solder shorts during assembly. Basically it will make assembly and testing of boards more challenging.

The 4032V looks like a good alternative, with a 3.3V core and a much wider pin pitch. But it lacks any built-in oscillator. If I want a clock source, even an inaccurate one, I’ll have to provide one externally. That will add a bit to the board cost and complexity. The 4032V itself is also slightly more expensive than its twin. In the end, it’s not obvious to me whether the 4032V or 4032ZE is the better choice overall.

Which one would you choose?

Schmitt Trigger Oscillator

If I choose the 4032V, then I’ll be looking for a simple and inexpensive way to provide an external clock signal to it. Something around 10 kHz would be preferred. I can probably tolerate inaccuracies in the frequency of 50% or more, over time on the same board or between different boards.

I could use a single chip oscillator like a MEMS oscillator, but I’m drawn instead to the idea of a Schmitt Trigger RC oscillator. It’s cheaper, and it also has a nice old-school vibe. The circuit is simply a single inverter with its output fed back to its input through a resistor, and with its input also connected through a capacitor to ground.

The frequency of the Schmitt Trigger RC oscillator depends on the values of the capacitor and resistor, the hysteresis of the inverter, and the supply voltage. Calculators exist to help predict the frequency, but in practice I’d probably need to tune it experimentally.

I’m fine with some variation in the frequency, as long as it doesn’t vary wildly. A variance of 2x or more could become problematic. Given the tolerance of the capacitor and resistor values, temperature-dependent capacitance changes, process variations between inverters, and possible supply voltage fluctuations, what range of frequency variation is a Schmitt Trigger RC oscillator likely to experience?

Would I be better off paying more for a standard oscillator, even though I don’t need the high accuracy? Or would I be better off using the 4032ZE with its built-in oscillator, and not stressing about the core voltage and pin pitch?

Read 7 comments and join the conversation 

« Newer PostsOlder Posts »