BMOW title
Floppy Emu banner

Star Ring: Abusing the PCB Fab

Why use a PCB silkscreen when you could showcase the shiny gold metal layer? Why build a rectangular board when you could have strange and wonderful shapes? And why settle for a dull LED flasher when you could have something crazy? I went a little bit overboard with this one, and I’m unsure how to even describe it. It’s a wearable LED blinky, with some terrible (or amazing?) abuse of the PCB fabrication process, many eye-catching light displays, and careful attention to power usage to ensure long battery life. For lack of any better name, I’ll call it the Star Ring.


The PCB was made at OSH Park. Yes, the fab really will cut PCBs in this shape, and with a large hole in the middle too. Whatever is drawn as the outline layer in the design software, that’s what they’ll cut, so I won’t limit myself to boring rectangles. In this case the board is a 2-inch diameter ring, where a 1.5-inch diameter disc has seemingly been cut out of the center and repositioned behind the ring and overlapping it. In Eagle, it’s actually a many-sided polygon rather than a true circle, but the difference isn’t visible.

Second, the artwork. Rather than using the silkscreen to draw stars, moons, and planets, I put them into the top metal layer. Because this PCB was made with ENIG plating, the artwork appears as shiny gold. It’s a unique look, and it’s also extremely crisp and high resolution, much higher than I would get with the silkscreen layer. Some of those stars are only 0.4 millimeters across, but they still show up clearly when viewed under a 10x magnifying lens:


The board’s primary electronics are about as simple as you can get: just a microcontroller, a pushbutton, and some LEDs. Even including the CR2032 battery, current-limiting resistors, and a couple of capacitors, it’s a bare minimum of components. The microcontroller is an ATTINY84A, and is hidden on the back:

The ATTINY microcontrollers are like the little brothers of the better-known ATMEGA parts found in the Arduino and Floppy Emu. This was my first time using an ATTINY chip, and I was excited to give it a try. Aside from having less RAM and less flash memory than ATMEGA parts, I was hard-pressed to spot any difference. Those who scour the datasheet will discover that the ATTINY chips have fewer built-in hardware peripherals, or the peripherals have fewer features than their ATMEGA counterparts, but for most people the differences aren’t important. The great thing about ATTINY chips is that they come in small packages and are very inexpensive. This particular chip is only 80 cents in single-unit quantities.

Lighting LEDs with PWM

Each of the nine LEDs is connected to an ATTINY output pin, and to an 82 ohm current-limiting resistor. They’re amber LEDs with a forward voltage of 2.0 volts, according to the datasheet. With a 3.0 volt battery, the math says that will create a 1.0 volt potential difference across an 82 ohm resistor, resulting in a current of 12.2 mA. Unfortunately the math is completely wrong.

The CR2032 battery has significant internal resistance of about 15 ohms, which further limits the current. And the ATTINY output pin voltage will droop lower than the supply voltage when it’s delivering many milliamps of current, so the voltage applied to the LED will be something less than 3.0 V. The more LEDs that are lit simultaneously, the more noticeable this effect will become. I attempted to do some complex math and experiments with a dozen different resistor values, in order to find the optimum value, before I concluded that it didn’t really matter. Anything in the 60 to 120 ohm range is probably fine. With the 82 ohm resistors, my tests showed an LED current of 7.9 mA with a single LED lit, and 6.0 mA each with two LEDs lit.

Lighting up all nine LEDs is more challenging. It’s not possible to directly power all nine at the same time, because that would draw more current than the battery and ATTINY can provide. The LEDs would get noticeably dim, and the supply voltage would get pulled down, possibly to a voltage low enough to cause a microcontroller malfunction or reset. Star Ring creates the appearance that all nine LEDs are lit by turning them on and off very quickly, with no more than three LEDs ever turned on at the same instant.

With the necessity of modulating the LED duty cycle for power reasons, it was only a short step further to a full PWM control for each LED. This made it possible to change the brightness of the LEDs dynamically, creating a pleasing “analog” look that contrasts with the typical full-on/full-off illumination of typical LED displays. Lighting an LED with 2% duty cycle looks dim, lighting it with 80% duty cycle looks bright.

The ATTINY has two hardware peripherals that can handle this type of PWM, but because Star Ring has nine LEDs, I had to design a software PWM solution instead. With some passably optimized code, and the ATTINY running at 4 MHz, the 9-channel PWM LEDs blink at 1148 Hz. This is fast enough to be mostly invisible to the human eye. The software PWM supports 16 brightness levels, and each brightness level maps to a duty cycle between 0:64 (off) and 64:64 (100% on).

While developing the PWM code, I discovered something interesting about the human eye and brain. I assumed that an LED with 80% duty cycle looks twice as bright as one with 40% duty cycle, but I was wrong. In fact, I’m hard-pressed to notice any visible difference in brightness, and at most I will say the 80% looks slightly brighter. Because we humans have evolved to cope with vast brightness differences in our environment, from the dazzling noon sun to the faintest starlight, there’s a decidedly non-linear mapping between the energy output of a light source and its perceived intensity. There are various formulas that attempt to convert between the two, but I just created a conversion table and then tweaked the numbers until it looked good. The result is that an LED set to 50% brightness doesn’t get a 50% duty cycle of 32:64, but only 15:64.

Side note: I couldn’t use green or blue LEDs here, because their forward voltage is about 3.0 volts, the same as my battery voltage. In this circuit, green/blue LEDs would be very dim at best. With a 3.0 volt battery I’m effectively limited to using yellow or red LEDs.

Blinky Functions

Even with the help of PWM, it’s not possible to animate the LEDs all the time without exhausting the battery in a matter of hours. Instead, Star Ring implements 12 different LED animation patterns that play periodically, with each pattern being about two seconds long. The patterns span the range of my LED-blinking creativity: a spinning wheel that gradually slows (shown in the title image), a flickering candle, fireworks, stars that slowly fade in and out, and many others. Pressing the button wakes up the device and plays the next animation pattern. Once awake, the device will also spontaneously play a new pattern about once per minute. Once in a rare while, it will play a special longer pattern. If you’re a 9-year-old kid, this is like the equivalent of “rare” Pokemon cards, and will keep you engaged with the Star Ring for long periods just to get that payoff.


My vision for Star Ring is to make it a wearable device, either as a shirt/hat pin, a necklace, or something else. I haven’t yet figured out the best attachment method for clothing, so for the moment I’m hanging it off a shirt pocket zipper. If anybody has a great idea on how I could incorporate a pin or a snap into the PCB design, please let me know.

The periodic but infrequent animation patterns are intended to support the wearable design. Even if the battery allowed it, a constantly-animating LED display would quickly grow annoying and get switched off, or else would be tuned out and ignored. But when Star Ring periodically flares to life, it always grabs attention. “What that?” people will ask. Then as I stand talking to them, they’ll interrupt “oh it did it again!” It naturally draws people in, and is a great little accessory for the kinds of events that welcome a blinking PCB with stars and moons (whatever those might be).

Power Consumption and Battery Life

The CR2032 battery provides a paltry 220 mAh at 3.0 volts. That’s not much. The 220 mAh capacity also assumes a current draw of only 0.1 mA. If the circuit draws current at a higher rate, the effective battery capacity will be even less. But with a bit of experimentation, I was able to design the hardware and firmware to get a projected battery life of 1 year. Not bad!

While an LED animation pattern is playing, the current from the battery varies between 10 to 24 mA depending on the pattern. Clearly the Star Ring can’t afford to do that very often. With no LEDs illuminated but the ATTINY still running, the current is 2.9 mA, which is still far too high. To save power, in the time between each LED animation pattern the ATTINY slows its clock to 31 kHz, disables all hardware peripherals except the timer, and enters idle mode. In this mode the main CPU clock is halted, but the peripheral clock continues to run, so the device can be awakened from a timer interrupt or external pin change interrupt. The current from the battery in this state is only 99 microamps. Much better! According to the datasheet it should be even lower, about 10 microamps, but I’ll take what I can get.

But even 99 microamps is too much current for the long term. That rate of current would deplete the battery in three months all by itself, without ever illuminating the LEDs. To save more power, if an hour has passed without the button being pressed, the ATTINY will enter power-down mode. In this mode all clocks are halted, and the IO buffers are disabled except for the one pin connected to the button. The device can’t be awakened by a timer interrupt, but now requires an external pin change interrupt from the button. When in this state, the current from the battery is a minuscule 120 nanoamps. Yet this tiny amount of current is still enough to maintain the CPU state and the contents of RAM. As soon as the button is pushed, Star Ring immediately jumps back to life and continues with the next LED animation pattern.

Sometimes the operator may want to force Star Ring into power-down mode immediately, without waiting for the one-hour timeout. Pressing and holding the button for a few seconds will play a “shutdown” LED animation, followed by the device going immediately to power-down mode. The battery life in this state is effectively infinite, or as long as the shelf life of the battery. No further LED animations will play until the device is reawakened by another button press.

Next Steps

I don’t think this is a product for sale – unless 20 people immediately respond saying they want to buy a Star Ring. It would be challenging to mass produce, because the intentional misuse of the top copper layer for decorative purposes means it would be difficult to use a solder stencil and an oven to assemble the boards. Solder paste would stick to the exposed copper of the moons and stars, spoiling the design. So this is probably just a project of personal whimsy for myself, friends, and family.

Commercial or personal, I do have a couple of ideas for Star Ring version 2:

  • Put the battery on the back, and the ATTINY chip on the front. This would look better, since the battery is kind of ugly.
  • Add mounting holes, clips, snaps, or something else to provide for easy use as a wearable.
  • Use a right-angle pushbutton instead of a standard button. With a clothing mount, the standard button may be painful or socially awkward to push in, against the body. A right-angle button would push parallel to the body.
  • Use red/yellow dual-color LEDs, that are really two LEDs in a single package. It might require an ATTINY with more pins, or perhaps a couple of extra transistors, but it would enable many more creative possibilities for the LED animation patterns.

Happy blinking!

Read 10 comments and join the conversation 

Thoughts on Low Latency Interrupt Handling

How quickly can a modern microcontroller respond to an external interrupt? Is it possible to achieve consistent sub-microsecond response times, so that external glue logic like muxes could be replaced with software instead? That’s the question I raised at the end of my previous post. If it’s possible, then a hypothetical future redesign of the Floppy Emu could be built using a single fast microcontroller, instead of the present design that combines a slower microcontroller and a CPLD for programmable logic.

Defining the Challenge

When Floppy Emu is emulating a 3.5 inch floppy drive, the computer controls it using an interface similar to a 16-entry 1-bit memory. Or 16 1-bit registers. The contents of these registers are mostly status flags, like whether a disk is inserted, the disk is write-protected, or the head is at track 0. But some of the “registers” are actually dynamically changing values, like the instantaneous data bit at the current head position of the rotating disk, or the tachometer signal from the disk’s motor rotation.

Here I’ve renamed the actual signal names on the interface to help make things clearer:

A3..A0 – The memory address
R – The memory output bit (when reading memory)
WE – Write-enable

For reading data, whenever the address bits A3..A0 change, the value of R must be updated within 500ns. It’s like a memory with a 500ns access time. Also whenever a status flag changes, or one of the dynamic values changes, R must be updated if A3..A0 already contains the address of the value that changed.

This is exactly the operation of a 16:1 multiplexor.

For writing data, at a positive edge of WE, the register at address A2..A0 must be written with the bit from A3. WE will remain high for 1000ns before it’s deasserted. Given this design, only eight of the sixteen registers are writable.

These timing requirements and the interface details are taken from this spec for the Apple 1.44MB Superdrive controller chip. The Apple 400K/800K drives may have different timing requirements, but I’m assuming they’re the same, or else more forgiving than the 1.44MB drive requirements.

So the challenge is this: the Floppy Emu microcontroller must respond to reads within 500ns, and to writes within a 1000ns write-enable signal window.

Choosing the Hardware

There are a bazillion microcontroller options, which is great, but also daunting. Some mcus have features that could make them well-suited to this job, like high clock speeds, dual cores, special peripherals, or programmable logic. The choice is also influenced by my desire for a mainstream mcu, with broad availability, good documentation and community support, good development tools, and a positive long-term outlook. This leads me to eliminate some options like the Parallax Propeller and Cypress PSoC.

For this analysis, I’ll assume the microcontroller is an Atmel SAMD51. If I were actually building this hardware now, that’s what I’d probably choose. The SAMD51 is a fairly new 120 MHz ARM Cortex M4 microcontroller, and is like an upgraded version of the popular SAMD21 used in the Arduino Zero. Adafruit had a gushing review of the SAMD51 when it was released last year. It has a nice selection of hardware peripherals, including some programmable logic, and it’s fairly fast, and cheap.

The SAMD51 is a single-core mcu. As we’ll see, it’s unlikely that a second core would help anyway.

SAMD51 Peripherals

An interesting peripheral on the SAMD51 is the Parallel Capture Controller, and it looks perfect for handling writing data. At the edge of an external clock signal (or WE signal in this example), the value on up to 11 other external pins is recorded and stored in a buffer. Then an interrupt is raised, so that software can examine and process the stored value. If necessary, I think it’s also possible to connect the PCC to the DMA controller, so that incoming values are automatically moved to a memory buffer, and there’s no chance of an overrun if the mcu doesn’t process the data quickly enough. This should guarantee that when writing data, no write is ever missed, although the mcu may not necessarily immediately react to the write.

Using the PCC, I think I can check the box for writing data, and assume it will work fine on the SAMD51.

What peripherals might help with reading data? The SAMD51 has an event system, enabling its peripherals to be chained together in custom ways, without any involvement from the CPU core. For example, using the event system, an edge transition on an external pin can trigger an SPI transmission to begin. Or when SPI data is received, it can trigger an external output pin to go low, high, or toggle. It’s very clever, but after looking at the details, I couldn’t see any obvious way to use the event system to handle reading data.

The SAMD51 also has a programmable logic peripheral called the CCL, Configurable Custom Logic. This looks like exactly the right kind of thing to help with reading data, and it is, but there’s simply not enough of it. It’s like an inferior version of one-quarter of a 16v8 PAL. There’s a total of just four LUTs, and each LUT has only three inputs, so it’s quite limited. The linkage between LUTs is also hard-coded, making it difficult to combine multiple LUTs to create more complex functions. The LUT inputs and outputs can be external pins, other LUTs, or certain peripheral ports, but not arbitrary registers or memory locations. In practice I don’t think the CCL can handle reading data for Floppy Emu, although it might help with it in some small way.

After looking at all the hardware peripherals, none of them seem well-suited to handling reading data. The best solution looks like a plain old interrupt. Whenever A3..A0 changes, it will trigger an interrupt, and the interrupt handler code will update R with the new value. Will it be fast enough?

Interrupt Handlers

Here’s some pseudocode for the interrupt handlers. First, handling writing data with the PCC:

	registerNumber = (PCC_DATA & 0x07); // get A2..A0
	registerData = (PCC_DATA & 0x08) >> 3; // get A3 data bit

	internalState[registerNumber] = registerData;

	// set status flags here to step track, eject disk, etc. 
	// the main loop will do the actual work


Second, handling reading data with an external pin change interrupt. From my examination of the datasheet, it appears there’s only a single interrupt vector for external interrupts, and the interrupt handler must examine another register to determine which pins actually triggered the interrupt. That means the same handler must not only check the signals described above for reading data, but also other signals that require interrupt handling, like writeRequest (used when the computer writes to the disk) and multiple enable signals (used to select one of several disks that may be present).

bool driveEnabled = false;

		// enable input has changed
		EIC_INTFLAG &= ~ENABLE_PIN_MASK; // clear interrupt
		driveEnabled = (PIN_STATE & ENABLE_PIN_MASK);
		if (driveEnabled)

	if (driveEnabled)
			// writeRequest input has changed
			EIC_INTFLAG &= ~WRITE_REQUEST_PIN_MASK; // clear interrupt

			// set status flags here to handle beginning and ending
			// of disk sector writes in the main loop

			// the A3..A0 input pins have changed
			EIC_INTFLAG &= ~ADDR_PINS_MASK; // clear interrupt
			registerNumber = ((PIN_STATE & ADDR_PINS_MASK) >> ADDR_PINS_SHIFT); // get A3..A0

			if (internalState[registerNumber])
				PIN_OUTPUT_VALUE |= R_PIN_MASK; // set R to 1
				PIN_OUTPUT_VALUE &= ~R_PIN_MASK; // set R to 0

			else if (registerNumber == MOTOR_TACHOMETER_REGISTER)

There’s some extra code about enable and write request. For the address, the interrupt handler must also adjust the mcu’s pin mux to control what’s actually driving the output on the R pin. In most cases it’s a GPIO, and the value comes from the internalState[] array and is set in the PIN_OUTPUT register. But for some addresses, the selected value is a dynamically changing quantity that comes from an active SPI peripheral, or a timer/counter peripheral.

Interrupt Priority and Pre-emption

EIC_Interrupt_Handler should be given the highest interrupt priority, higher than interrupts for other events like button pushes or SD card data transfers. With a higher priority, I’m fairly certain the EIC_Interrupt_Handler will interrupt any other interrupt handler that might be running at the time. Isn’t that what’s meant by the “nested” part of the ARM’s nested vector interrupt controller?

What about the PCC_Interrupt_Handler, for writing data? Should it have the same priority, or a lower one? Should reads interrupt writes? Can that ever actually happen? Does it matter? I’m not sure.

Can the EIC_Interrupt_Handler interrupt itself? If A0 changes, and EIC_Interrupt_Handler begins to run, and then A1 changes, will the handler be interrupted by a second invocation of the same handler? I think the answer is no. But what probably happens is that the interrupt flag will be set again, and as soon as EIC_Interrupt_Handler finishes, the interrupt will trigger again and EIC_Interrupt_Handler will run again. That seems inefficient, but it’s probably OK.

Interrupt Timing

Now we come to the critical question: can EIC_Interrupt_Handler respond to changes on A3..A0 with a new value on R within 500ns?

My research suggests the answer is maybe, but it will be difficult. I found two discussion threads where people were attempting to do something similar with Atmel SAM Cortex M4 and M7 microcontrollers. The first used a 300MHz SAME70, and found a 300ns latency to the start of the interrupt handler. The second used a 120 MHz SAM4E and found a 200ns latency to the start of the handler. These are the delays from the input pin transition to when the interrupt handler begins to run, and they don’t include the actual execution time of the interrupt handler, which is probably several hundred nanoseconds more.

Why so slow? First, the Cortex M4 has a built-in interrupt latency of 12 clock cycles. That’s to do whatever the hardware does for interrupt processing – save the execution state, fetch the interrupt vector, and whatever other voodoo is required. At 120 MHz that’s already 100ns gone.

Then the first instruction of the interrupt handler code must be fetched from internal flash memory. At 120 MHz, the flash isn’t fast enough to supply data in a single clock cycle. It requires 5 wait states, so a read from flash memory needs 6 total clock cycles. That’s another 50ns. So even in the theoretical best-case performance, it will still be a minimum of 150ns before the interrupt handler can begin to run. The two real-world examples I mentioned above were slower.

What about these flash wait states? Does it mean that every instruction in the interrupt handler will need 6 clock cycles to load from flash? I don’t understand the details, but the answer is no. There’s some prefetching and caching happening. Also most instructions are 16 bits wide, and the flash has a 128 bit width, so several instructions can be prefetched and cached at the same time. At least for straight line code with no jumps, I’m guessing that the rest of the interrupt handler can run at speeds approaching 1 instruction per clock cycle at 120 MHz. If anybody knows of good reference data for this, please let me know.

If the flash wait states are a major problem, it may be possible to copy the interrupt handler code to RAM and run it from there. I’m assuming the internal RAM has zero wait states, but I might be wrong on that point.

So 150ns before the interrupt handler can begin to run leaves 350ns remaining. That’s 42 clock cycles at 120MHz. So the interrupt handler can be up to 42 instructions long, on its longest execution path? Not quite, because some common instructions like STR require two clock cycles. Assuming an average time of 1.5 clock cycles per instruction, those 42 clock cycles are only enough for 28 instructions. Can EIC_Interrupt_Handler be implemented in only 28 Thumb assembly instructions? Um… maybe?

Complicating Factors

A few other factors raise the difficulty bar further. If the main code ever disables interrupts, or performs any atomic operations, it will delay running of the EIC_Interrupt_Handler and cut further into that 500ns window. In code that uses lots of interrupts, sometimes it’s impossible to avoid needing critical sections where interrupts are briefly disabled, for example to check some value and then set another value based on the first one. Failure to do this can cause rare but serious bugs, if an interrupt intervenes between reading the first value and setting the second.

Another serious complication is the possibility of multiple back-to-back invocations of EIC_Interrupt_Handler. What happens if one of the A3..A0 inputs changes immediately after execution of the line:

registerNumber = ((PIN_STATE & ADDR_PINS_MASK) >> ADDR_PINS_SHIFT); // get A3..A0

The remaining code will output the value of R for the old A3..A0, then the interrupt handler will finish, then a new interrupt will trigger and the handler will be invoked again to process the new A3..A0 input state. The total latency from the change on A3..A0 to the final correct output value of R will be something like 1.5 times the latency for the normal case. In a system where the timing margins are already very tight, that may be enough to break it entirely.

I don’t see any way around this back-to-back invocation problem. Moving EIC_INTFLAG &= ~ADDR_PINS_MASK to the end of EIC_Interrupt_Handler wouldn’t help anything. It would actually clear the pending interrupt flag from the second change of A3..A0 without ever responding to it, resulting in incorrect behavior.


So can this work – is software interrupt processing viable with these kinds of timing requirements? Is there some optimization trick I can use in the interrupt handler to improve things? Should I even spend the time to attempt it? Maybe there’s some clever way to use the built-in CCL programmable logic that I’ve overlooked, to help accelerate the interrupt handler or even replace it entirely? Or should I just write off this idea as too difficult and too problematic, and continue using a separate programmable logic chip for a mux and glue logic? Decisions…

Read 10 comments and join the conversation 

Atmel-ICE + Floppy Emu. The Taste of Sadness

In all the time I’ve been developing Floppy Emu, can you believe I’ve never had a debugger? I use the Atmel AVRISP mkII to program the Emu’s ATMEGA1284 microcontroller, but the mkII only supports programming and not debugging. I don’t have a serial port or other logging mechanism either, so when I encounter mystery problems, I need to debuga them by displaying one-time error codes or blinking an LED. Not very convenient.

Last week I finally purchased a proper debugger – the Atmel-ICE. It supports both JTAG and debugWIRE debugging, which are the two interfaces used in the ATMEGA family of microcontrollers. The Atmel-ICE also supports Atmel’s SAM family of 32-bit ARM microcontrollers, which will be handy if/when I start working with those.

With excitement, I connected the Atmel-ICE to Floppy Emu’s 6-pin ISP port. I was able to communicate with the ATMEGA1284 chip, view its fuses, and reprogram it. Visions of breakpoints and memory dumps danced in my head – this was going to be awesome. Then I started a debug session, only to encounter this error:

ISP on Atmel-ICE does not support debugging. Device is only programmed.

Use Start Without Debugging to avoid this message.

Wha-wha-what? Does not support debugging??

I searched in vain for a debugWIRE option, but the only interface choices displayed by the software were ISP and JTAG. After a frantic documentation search I discovered the sad truth. I’d thought the ATMEGA1284 had both debugWIRE and JTAG debugging interfaces, but the presence of JTAG actually means the chip doesn’t support debugWIRE. Even though the necessary debugWIRE pins are right there, and debugWIRE is mentioned in the chip’s datasheet, and there’s a debugWIRE enable fuse on the chip. Ugh.

I confirmed that a test project configured for the ATMEGA328P causes the debugWIRE option to appear in the Atmel Studio software. But Floppy Emu doesn’t have a ATMEGA328P. As soon as I change the project’s device type to ATMEGA1284, the debugWIRE option disappears.

Unfortunately I can’t use the JTAG interface, because I didn’t plan for it, and there’s no JTAG connector on the Floppy Emu board. I can’t do micro-soldering surgery to create a JTAG port either, because the ATMEGA1284 JTAG pins are connected to the board’s Xilinx CPLD chip, to support runtime reprogramming of the CPLD.

I’ll continue debugging with a blinking LED. Debuggers are for wimps. 🙂

Read 2 comments and join the conversation 

Thoughts on Floppy Emu Redesign

I’ve been pondering what a redesigned Floppy Emu might look like – what ICs might be involved. So why mess with success? The current design combines a microcontroller with a CPLD, which has proven to be a powerful and flexible combination. But the specific microcontroller and CPLD that I chose have both become a bit outdated, hard to find, and too expensive relative to the alternatives. By replacing them both with more modern parts, I could probably gain better features while simultaneously improving the manufacturing outlook, for a perfect win/win. Or with a sufficiently powerful microcontroller, I might be able to completely eliminate the CPLD.


The CPLD (complex programmable logic device) is like a miniature FPGA, and is there to handle the timing-critical bit twiddling that the microcontroller can’t. It ensures the data bitstream appears at exactly the right speed, with no jitter, and also functions as a fancy parallel-to-serial shift register. For Apple II disk emulation, it helps make the work easier, and for Macintosh disk emulation it’s essential. The Mac treats floppy drives sort of like a 16×1-bit external memory, and microcontroller software isn’t fast enough to react to the changing address inputs and supply the correct data output.

The specific CPLD used by Floppy Emu is the Xilinx XC9572XL, which I mainly chose for being 5v tolerant. It works, but it can only store a very small amount of logic, which forces me to have separate and independent firmwares for Apple II and Macintosh emulation. With a larger and more capable chip, I could merge those into a single firmware.

The Xilinx XC9572XL is old enough that it’s approaching “legacy” status, and may be in line for discontinuation soon. Xilinx barely mentions it on their web site, and the chip has been sold out at all of their distributors for the past several weeks, which is worrisome. During the years I’ve been building Floppy Emus, the price of the XC9572XL has also steadily climbed to where it’s now more than double its original cost.

There aren’t many great alternatives, because it seems the whole CPLD market is slowly dying in favor of FPGAs, and most of what’s left has even smaller logic storage limits than the XC9572XL. The best option is probably a small FPGA instead, like one of the Lattice MachXO or MachXO2 devices similar to what’s in the Yellowstone disk controller.

A second idea is to replace the CPLD with a small, dedicated microcontroller, like something from the ATTINY series. With only one or two very simple tasks to do, maybe a mini-microcontroller would be able to keep up. I spent half a day pursuing this line of thinking, going as far as writing a first draft of the code for this hypothetical microcontroller, but decided to focus on other solutions first.


Floppy Emu uses an ATMEGA1284 microcontroller, which in 2018 is almost a joke. Its sole advantage is that it’s a close relative of the ATMEGA chip used in Arduinos, so there’s tons of example code available for it. But it’s woefully underpowered compared to basically any other microcontroller out there. Any of the popular 32-bit ARM microcontrollers would have significantly faster clock speeds, more memory, and better peripheral options, and would probably cost less too.

Sadly there are still no common microcontrollers with enough internal RAM to buffer an entire floppy disk image (140K to 1440K depending on the image type). That would vastly simplify the emulation, help fix some occasional emulation hiccups, and possibly lead to better handling of copy-protected disks. But that will have to wait until the 2020’s, it seems.

After looking at a whole range of options, I’ve got my eye on the Atmel SAM4S series of microcontrollers. These boast speeds up to 120 MHz, while remaining relatively inexpensive.

Single-Chip Design?

Earlier I mentioned that the CPLD is essential for certain types of disk emulation, where microcontroller software isn’t fast enough to react to changing inputs in real time. That’s true for an older 8-bit microcontroller like the ATMEGA1284 running at 20 MHz, but what about for a modern 32-bit ARM running at 120 MHz? That might be a different story.

The hardest test will be 3.5 inch floppy disk emulation for the Macintosh. When the Mac wants to check some item of drive state, like whether there’s a disk inserted or whether the disk head is at track zero, it sets four IO lines with the right values to select from among the 16 possible state bits. Then it reads the result on a fifth IO line. It works just like an asynchronous SRAM, and the drive (or Floppy Emu emulating a drive) never knows if or when the Mac is reading state info. The drive needs to constantly respond, so whenever one of those four IO lines changes, the value on the fifth IO line must be updated immediately to reflect the newly selected state.

This would be difficult to emulate in a microcontroller, especially if it also needed to do other work besides merely responding to changing address inputs. The microcontroller would need to enable a pin change interrupt on each of the four address lines, and the interrupt service routine would need to read the address lines and set the data line accordingly. In practice it would be even more complicated, because there are other IO lines like /ENABLE that would also need to be considered, and would need their own interrupt handlers.

Would it be fast enough? Maybe. By itself the code in the ISR would almost surely be fast enough. But there’s overhead to consider – the interrupt service latency, and the time needed to set up the ISR context and exit it again (saving and loading all the registers from the stack). Then there’s the complicating factor of other potential interrupts, or other invocations of this same interrupt, creating additional delays before the ISR actually starts running. And the further complication of some critical code sections where interrupts need to be disabled temporarily, creating yet more delays before the ISR runs.

How fast does it need to be, anyway? How much time elapses between when the Mac sets the four IO lines and when it reads the fifth line? Unfortunately I don’t know, and the worst part is there’s really no way to find out. Because there’s no external indication of when a read is occurring, there’s nothing I can measure with an oscilloscope or logic analyzer. But I can make some rough guesses, based upon examination of a disassembly of the floppy disk driver code in the Macintosh ROM. On the Macintosh Plus, there’s a whopping 6750 ns between address and data for most state reads, but some reads have a much narrower window of about 1500 ns, assuming I’ve interpreted the code correctly.

Are there other faster read examples, buried somewhere in the Mac Plus ROM that I missed? And do Macs with a higher clock speed than the Plus have correspondingly faster read behaviors of disk state info, or do they insert delay code to keep the speed constant? I don’t know, but the Mac Plus is likely far from the worst case. I’ll make a wild guess that a 500 ns response time would probably be fast enough. Keep in mind I’m talking about the speed between presentation of the four address IO lines, and reading state info on the fifth IO line, which is entirely different from the speed or data rate of the disk data itself. It’s not something that’s specced or defined in any official source; it’s just something that arises as a side-effect of the code in the Mac’s ROM.

Despite the uncertainty here, I think there’s a decent chance this could work, so I’m going to try some experiments to test my theories.

If even a 120 MHz microcontroller isn’t fast enough to handle this 4-address-1-data mechanism, I’ve sketched out a possible fallback plan that uses a few discrete logic chips – some muxes and latches and buffers. It’s arguable whether that would be preferable to just using a CPLD (or FPGA), and it would certainly be less flexible. But a small handful of discrete logic combined with a much faster microcontroller could still provide some major advantages, and simplify firmware design by reducing the number of programmable chips on the Emu board from two to one.

So there’s a lot to think about. And anything that grows out of all this ruminating won’t see the light of day for a long time. But I can’t resist daydreaming…

Read 15 comments and join the conversation 

Garbage In, Garbage Out

I’m beginning to suspect there’s something subtly wrong with my Apple IIe, which might explain a lot of strange intermittent errors I’ve recently observed with Yellowstone and Floppy Emu development. It’s hard to know what to conclude, but when you can’t trust your test equipment, it’s impossible to trust the validity of your test results.

Recently I used this Apple IIe to test my new Floppy Emu OLED prototype board. When connected to a standard Apple Disk 5.25 controller card, everything worked fine initially. But when I tried doing some ProDOS file copy operations, the Floppy Emu spontaneously reset to the happy face / self-test screen. DOH! I tried it twice, and the Emu reset itself during the copy operation both times. I concluded there must be something wrong with the prototype board.

Then I tried the copy test two more times, and got different results. The Emu prototype didn’t reset itself, but the OLED display went blank several times during the copy operations. Hmmm.

So then I tried a plain vanilla Floppy Emu Model B, the same hardware and firmware that I’ve been using successfully for more than a year. I found that when trying to boot the Apple IIe from a ProDOS v1.9 disk image, the Model B’s LCD went blank several times during booting. Huh? This happened in two consecutive test runs, but then mysteriously stopped happening. I also tried the same file copy operations I’d done with the OLED prototype board, and saw a similar behavior where the LCD went blank a few times during the copy. But as before, after reproducing the bug twice in a row, it stopped happening.

Finally I went back to the OLED prototype board, and this time everything worked fine. No more unexplained resets or display blank-outs.

Maybe there’s something wrong with the Apple IIe’s power supply, or some problem where it needs to warm-up for a while before it works reliably? My first OLED prototype board tests were the first time I’d powered on the Apple IIe in several days, so it was cold. During an hour of testing, the strange Floppy Emu problems I’d observed gradually disappeared. It doesn’t really make sense to me, but it’s the best explanation I can think of. This might also explain some strange unexpected resets of the Floppy Emu last month, when I tested it with the Yellowstone card. In fact, it casts doubt on all of my Yellowstone testing.

Read 9 comments and join the conversation 

Floppy Emu OLED Prototype

Displays, displays! I’ve built a prototype Floppy Emu board that uses a 1.3-inch 128×64 OLED display, instead of the existing 1.4-inch 84×48 LCD. It works, and it looks very nice. So is this the answer to my display worries? Take a look at the photos, and tell me what you think.

Why change displays? The current edition Floppy Emu uses an 84×48 LCD that’s a clone of the Nokia 5110 mobile phone display. It’s a decent module with a nice built-in backlight, but the displays have caused me a lot of headaches over the years due to their iffy quality control. Around 10-15% are dead on arrival and must be discarded during manufacturing and testing. A large fraction of the remainder exhibit flaky behavior until the LCD’s pressure-fit connector is manually fine-tuned. These LCD hassles consume too much of the manufacturer’s time and my time. The supply chain for the 5110 LCDs is also problematic, coming only from small eBay and Aliexpress sellers, instead of a major manufacturer who can provide documentation and support.

Last month I reviewed some potential replacement displays. There weren’t many great options, but after lots of consideration I settled on this 1.3-inch OLED. It’s similar to the 5110 LCD in many ways, being a 1-bit graphical display with an SPI interface. The physical size is a bit smaller than the 5110 LCD, but they’re close. Unfortunately the supply chain situation for the OLED is even worse than the 5110 LCD, and the cost is at least $2 more per unit. But if I can save myself $2 worth of hassle, it will be worth it. A few weeks ago I hacked up a Floppy Emu board to support the OLED, just to prove that it worked, and today I now have a proper OLED Emu prototype.

I For One Welcome Our New OLED Overlords

The first thing you’ll notice about the OLED is that the contrast is amazing. The display is bright and very crisp, and the photos can’t do it justice. I never thought the 5110 LCD looked bad, but the OLED looks far superior.

The extra resolution of the OLED helps a lot. Text characters on the 5110 LCD are 3×6, while on the OLED they’re 5×7. This makes possible a more finely-detailed font that’s a nice improvement in legibility.

Text on the OLED is smaller, and at first I was concerned this would make it difficult to read. But with the awesome contrast and better font, my weak eyes find the OLED to be about equally easy to read as the larger text on the 5110 LCD. My wife declared the OLED more readable than the 5110 LCD. The OLED text is also larger than the text on my Backwoods Logger Mini (2011 flashback alert), and is about the same size as this CorelDRAW quick reference card I happened to have sitting out:

The OLED shows eight rows of text, compared to six rows on the 5110 LCD. This is a nice bonus when scrolling through a long list of filenames. With some extra development work and possible resulting display update slowness, future firmware might be able to trade fewer rows for larger text, but the OLED is designed around eight rows in hardware.

Fun with Fonts

I tried two different fonts. The first font has most letters being 5×6 pixels, with only the descenders of g, j, p, q, and y dropping below the baseline to make a 5×7 letter. Since each row is 8 pixels tall, the 5×6 letters provide two pixels of whitespace between rows. Here’s a sample:

The second font has most letters being 5×7 pixels. There are no true descenders, so g, j, p, q, and y sit on the same baseline as all the other letters. Because the letters are one pixel taller, this font is slightly more detailed and more readable than 5×6. But with only a single pixel of whitespace between rows, the text looks sort of cramped. I decided I didn’t like it, but maybe you’ll feel differently. Here’s a sample:

For comparison, here is the 3×5 font on the 5110 LCD:

Now What?

So it works. Now what? If I want to move forward with this OLED, there’s a lot of work to do. I need to find a supplier who can reliably provide hundreds of these displays. I need to get my updated PCB to my manufacturing partner. Because it’s a new design, I’ll have to pay them a bunch of money for one-time engineering fees. I’ll need to update the manufacturing instructions, and the test procedure, and the firmware that goes with it. And I’ll need to design a new case to fit the new board and OLED. It will all be a lot of work, and when it’s done my costs will have increased by $2 per unit. Is the pain worth it? Probably yes, but I’m still undecided.

I might do some experiments with another display I recently discovered, this COG 12864 LCD. It’s a little bigger than the OLED, which might be helpful, but it lacks the OLED’s excellent contrast and crispness. Its resolution is the same as the OLED, and it’s roughly the same price, and the manufacturing work needed to change displays would still be the same. I’m not sure there’s a compelling reason to choose the COG 12864 LCD over the OLED, but it’s a similar contender. Hmmm.

Of course the best option might still be to do nothing, and keep the 5110 LCD. Yes it’s a headache, but it’s a headache I’m familiar with and have dealt with successfully for four years. A new display would bring its own set of headaches through required manufacturing changes and case redesign, so I’m going to have headaches no matter what! But when I think about the best long-term solution, I’m drawn to the idea of a more reliable, better looking OLED.

Enjoy some gratuitous unnecessary zoom:

Read 14 comments and join the conversation 

Older Posts »