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.

Version 0.3.1 firmware for the ADB-USB Wombat is now available. The Wombat is a bidirectional ADB-to-USB and USB-to-ADB converter for keyboards and mice. It enables the use of modern USB peripherals on vintage ADB-based Apple or NeXT computers, or ADB peripherals on modern machines equipped with USB. The Wombat is great for breathing new life into your vintage hardware collection.

Firmware 0.3.1 fixes a small but important bug that affected a small number of USB-equipped Macs that were built between 1998-2003, including some G3/G4 models of iMac, iBook, Powerbook, and Power Macintosh. ADB-to-USB conversion worked normally on these computers when running OS X, but they were unable to detect the keyboard when running MacOS 9. The reverse USB-to-ADB keyboard conversion worked normally under both MacOS 9 and OS X. If you weren’t affected by this bug, there’s no need to update your Wombat and you can safely stay with firmware version 0.3.0.

The Internal/External Drive Switcher for Apple IIc is once again available in the BMOW Store. The Switcher is a convenience option for Floppy Emu owners with a IIc, and makes everything easier when when emulating a 5.25 inch floppy disk drive. It provides a simple way to select whether the internal floppy drive or external Floppy Emu will appear as 5.25 inch Drive 1, which is the only bootable drive on the IIc. More details are here.

In preparation for Halloween this year, I built a large and colorful LED matrix. After programming it with monster-themed animations, it looked fantastic! Months passed, and when October 31st finally arrived, at dusk I hung the LED display outside by the street. It was to be the perfect lure for neighborhood kids.

But when I checked back an hour later, the LED display was dark and dead. Halloween passed in sad form, with no display of animated monsters. What happened?

 
LED Matrix ‘Hello World’

This all started last May, when I bought a generic 64 x 32 LED matrix from eBay. These matrix displays are designed to be controlled by an Arduino, Raspberry Pi, or other microcontroller or FPGA. The smallest displays are the simplest: the control unit selects one row of LEDs to illuminate, and then sends a stream of 0’s and 1’s to turn off or on the individual LEDs in that row. In effect, each row of the display is like a large shift register, with each bit corresponding to a separate LED. By cycling rapidly through all the rows, and providing different data for each row, the control unit can create the appearance of the whole LED matrix being lit. For larger displays, two rows can be illuminated at once, using two separate streams of bits, but otherwise the interface is the same.

A blog post from May describes my experiences with that first 64 x 32 LED matrix, using custom software I wrote for an Arduino. It worked well, and the matrix was impressively bright and colorful – the photos can’t do it justice. My custom software was limited to displaying static images, with only 8 colors, because the red, green, and blue LEDs were simply on or off with no in-between state.

 
Matrix Upgrade

If one matrix is good, two matrixes must be better! I bought a second identical matrix and connected it to the first. These matrixes are designed to be daisy-chained, with the shift-out from one matrix connected to the shift-in of the next. Logically this results in rows that are twice as long as before, creating a 128 x 32 matrix. But physically I arranged the displays to create a 64 x 64 matrix. As a result, the control software became more complicated with mappings between physical and logical lines.

I quickly abandoned my custom Arduino solution, and adopted the excellent rpi-rgb-led-matrix Raspberry Pi library by Henner Zeller. It’s incredibly rich, supporting many different physical to logical mappings, thousands of colors using PWM, video playback, and many other advanced features. Really, if you’re experimenting with one of these LED matrixes, this is the software you want.

For the Raspberry Pi, I selected a Zero W thanks to its built-in WiFi, small size, and rock-bottom price of $10. The OS is a default Raspbian image configured to run in terminal mode. It’s easy to connect to the Pi over WiFi using ssh, and then use rpi-rgb-led-matrix command-line utilities to display images on the LED matrix. It’s a powerful solution, and the only downsides compared to the Arduino are the few seconds required for the Pi to boot up, and the need to perform a clean shutdown instead of just pulling the power plug.

It’s possible to connect the LED matrix directly to the Pi’s GPIO pins, if you don’t mind a squid-like mass of wires. I chose an easier route and bought the Adafruit RGB Matrix Bonnet, which has the same footprint as the Pi Zero and makes the LED matrix connections a breeze. I performed a simple mod to the Adafruit bonnet in order enable hardware PWM to reduce flickering, as described further here. After that it was just plug and play, using the --led-gpio-mapping=adafruit-hat-pwm command-line switch for the rpi-rgb-led-matrix software.

Using the advanced search tools from Google Images, I looked for 64 x 64 animated GIFs with monster-related keywords. In short order I was able to locate several dozen. I was in business!

 
Building the Frame

To mount the two LED matrix panels together and create an eye-catching display, I built a custom frame. The design was loosely based on this Instructable by Al Linke. It uses several layers of laser-cut acrylic with a pile of carefully-sized spacers and machine screws. The frame took a substantial amount of work, but the end result looks great.

First the LED panels were mounted on a black acrylic piece, with pre-cut holes for mounting screws, wiring, and the Raspberry Pi. The rear of that piece was an ugly and bumpy tangle of cables that wouldn’t hang flat against the wall, so a second black acrylic piece was mounted behind the first to contain the mess. This piece also has integrated mounting holes for a wall hook or picture hanging wire. A third semi-frosted acrylic panel was then mounted on top, to give the LEDs a more diffused look. This is matter of taste, but I found that the LED images looked much nicer with the diffuser panel than without.

 
Powering the LEDs

In a 64 x 64 matrix, there are 4096 elements. Each element contains separate red, green, and blue LEDs, so the grand total is 12288 LEDs. Assuming that each LED draws 15 mA (a typical number for a single discrete LED), naive math calculates the total current as a whopping 184 amps! Ouch! But this calculation overlooks the fact that only a few rows are actually illuminated at the same time. This particular matrix uses 1:16 multiplexing, so the maximum current is a much more manageable 11.5 amps.

Armed with this information, I purchased the 5V 10A power supply shown here. Why only 10A instead of 11.5A or more? Enclosed “brick” supplies that can provide more than 10 amps are difficult to find, and I expected I’d never need 11.5 amps anyway for real-world images. 11.5A is a worst-case number for a solid white image where every LED is on. My halloween monster images are much darker, typically with many black pixels, so the required current should be much less.

 
Failure Analysis

When the LED display died on Halloween night, the Raspberry Pi was unresponsive to WiFi connections and the LEDs were dark. The power indicator on the Pi was blinking on and off. Later I noticed that the blue power indicator on the power supply brick was also blinking on and off. Strange.

I brought everything inside and plugged it back in, with the same result. Nothing worked, and the power indicators blinked. At first I thought there must be a short-circuit somewhere in the LED matrix or the Adafruit bonnet, which was repeatedly tripping some protection circuitry in the power supply. But when I disconnected the Pi and the LED matrix, and tried the power supply alone, I observed the same blinking power indicator. The problem was clearly with the power supply itself. Did I exceed its maximum current rating and kill it?

Confused, I left the hardware unplugged for a few days. Later, when I plugged it in again to begin more troubleshooting, I was surprised that it worked! I reconnected the LED display, and everything was great for about an hour. Then it died a second time, with the same blinking power indicator symptom. Uplugging and replugging didn’t help. But if I left it unplugged for a few hours, it would work again the next time it was plugged in.

By this point I was fairly sure I must be over-taxing the power supply and drawing too much current. I guessed that the supply must contain a thermal fuse, and it was overheating and shutting down. Only after a few hours of cooling would it work again, for a short while. 10 amps was simply not enough, it seemed.

To solve my power needs I purchased this 5V 30A “cage” type supply. I was reluctant, because this type of supply isn’t meant for outdoor use, and because it requires wiring to screw terminals instead of using standard power plugs. I’m a reasonably careful person, but I still get nervous playing with bare wires that carry mains voltages. Unfortunately I didn’t see a good alternative.

Before connecting the 30A supply, I decided to do one more test to see how much current the 10A supply was really using. I don’t have an easy way to directly measure the DC current, so I used a Kill-a-Watt meter to measure the power delivered from the wall outlet to the supply. I cycled the LED matrix through its collection of monster images several times, and the highest power measured by the Kill-a-Watt was 19 watts. Hmmm. If I assume the power supply is 80% efficient, then that means it was supplying about 15 watts to the LED matrix. It’s a 5V supply, so that’s a current of only 3 amps maximum – far below the supply’s claimed max of 10 amps. So why did the supply keep shutting off after an hour of use?

While still connected to the Kill-a-Watt, I let the hardware run for a while. This time it took several hours before it shut down, but the end result was the same as before, with dark LEDs and a blinking power indicator. The Kill-a-Watt showed 1 watt. The power supply didn’t feel hot to the touch, but was only slightly warm. This seemed to rule out my “overheating” theory, but didn’t suggest anything else.

Because I’d measured the max current at only about 3 watts, I decided to try a new approach. I pulled out another brick-type power supply from a different project, this one rated at 5 volts and 4 amps max. I connected it to the LED display, and started everything running. It worked just fine, and 18 hours later it’s still running smoothly. Success! At least for this series of Halloween images, it’s all I need.

I’m still curious what caused the first power supply to fail the way it did. Clearly it’s defective or broken somehow, but I’d like to understand more. A 10 amp power supply shouldn’t have any trouble delivering 3 amps continuously. And if it were actually something like a 2 amp power supply, mislabeled as 10 amp, I would expect it to get obviously hot after extended use. But it was never more than slightly warm. Could there be another explanation?

How quickly can a microcontroller detect and respond to changing inputs? Fast enough to replace a dedicated combinatorial logic chip, like a mux? I finally have some test results to begin answering this question.

My goal here is a potential redesign of the Floppy Emu disk emulator. The current design uses a microcontroller for the high-level logic, and a CPLD for the timing-critical stuff. But if a new microcontroller were fast enough to handle the high-level logic and the timing-critical stuff, I could simplify the design and eliminate the CPLD.

This is the fourth post in a series:

1. Thoughts on Floppy Emu Redesign
2. Thoughts on Low Latency Interrupt Handling
3. More on Fast Interrupt Handling with Cortex M4

 
Background

Let’s consider a mux-like function performed by Floppy Emu’s CPLD, as part of some disk emulation modes. It behaves like a 16-to-1 mux: 16 data inputs, 4 address inputs, and 1 data output. In order to properly emulate a disk drive, the mux must respond to changing address or data inputs within 500 nanoseconds. For my tests, I used an ARM Cortex M4 running at 120 MHz: specifically the Atmel SAMD51 on an Adafruit Metro M4 Express board.

At 120 MHz, 500 nanoseconds is 60 clock cycles: that’s how much time is available between an input’s rising/falling edge and the updated data output. The previous posts in this series examined the datasheets and performed some static code analysis, attempting to decide whether this was realistically possible in 60 clock cycles. The answer was “maybe”, awaiting some real-world timing experiments.

 
Timing It

Here’s a very simple interrupt handler. It doesn’t even attempt to perform the 16-to-1 mux function yet. It sets an output pin high when the handler begins running, and low when it finishes running, so I can monitor the timing with a logic analyzer. The body of the interrupt handler clears the interrupt flags for external interrupts 1, 2, 3, and 6 (where I connected the address inputs). This establishes a lower bound on how fast the real interrupt handler could possibly be, once I’ve added the 16-to-1 mux functionality and many other related pieces of logic.

void EIC_1236_Handler(void) 
{
	PORT->Group[GPIO_PORTA].OUTSET.reg = 1 << 2; // PA2 on

	uint32_t flagsSet = EIC->INTFLAG.reg; // which EIC interrupt flags are set?
	flagsSet &= 0x4E;  // we only act on EIC 6, 3, 2, and 1
	EIC->INTFLAG.reg = flagsSet; // writing a 1 bit clears the interrupt flags.
	
	// now do something, based on which flags were set. More flags may get set in the meantime...

	PORT->Group[GPIO_PORTA].OUTCLR.reg = 1 << 2; // PA2 off
}

Here are the results from the logic analyzer. The inputs PH2, PH1, PH0, and SEL are from a Macintosh Plus querying to test whether a disk drive is present. ISR is the timing output signal from my interrupt handler.

Every time there's an edge on one of the input signals, there's a brief spike on ISR. Looks good. Let's zoom in:

For the highlighted input edge, the delay between a rising edge of PH1 and the start of the interrupt handler is 175 nanoseconds (0.175 µs). Other edges are similar, but not identical. For this sample, the delays ranged between 175 and 250 ns. The width of the ISR pulse (the duration of the interrupt handler) was either 50 or 75 ns. So the total time needed to detect an input edge and run a minimal interrupt handler function is about 225 to 325 ns. That only leaves a few hundred nanoseconds to do the actual work of the interrupt handler, which doesn't seem promising. (The precision of the timing measurements was 25 ns.)

Test conditions:

• NVRAM line cache was enabled
• NVRAM wait states set to "auto"
• L1 instruction/data cache was enabled (it's about 1.6x slower when disabled)
• edge detection filtering and debouncing were off (these add latency)
• edge detection was configured for asynchronous (fastest)
• the main loop never disables interrupts
• SAMD51 main clock was definitely 120 MHz (confirmed with a scope)

This result is moderately worse than predicted by my static analysis of code and datasheets. Through further tests, I also found that code in my interrupt handler averaged close to 2 clocks per instruction, not the 1 clock per instruction that I'd hoped. That makes sense, because apparently any Cortex M4 instruction that references memory requires a minimum of two clock cycles. When I began writing the 16-to-1 mux code, the duration of the interrupt handler quickly approached 500 ns all by itself, without even considering the delay from input edge to start of the interrupt handler.

 
What Next?

Given these results, I'm almost ready to give up on this idea, and return to the tried-and-true CPLD-based solution. I say "almost", because I haven't yet written the full 16-to-1 mux functionality and other related logic, and because there are still a few more tricks I could try:

• relocate the interrupt vector table from NVRAM to RAM
• relocate the interrupt handler itself from NVRAM to RAM
• overclock the SAMD51 or try a different microcontroller
• profile various Macs and Apple IIs, to see if there's any slack in the 500 ns nominal requirement

But at this point, my intuition says this is not the right path. The whole idea of moving timing-critical logic from a CPLD to the microcontroller was to simplify things. There's no reason I must do this - it's just an option. So is it really simplifying things if I need to throw every optimization trick in the book at this problem, just to barely maybe meet the 500 ns timing requirement with no room to spare? What happens when I discover some future bug or requirement that needs a few extra instructions in the interrupt handler, and now it's pushed over 500 ns? Is it really worth abandoning all the time I've spent getting familiar with Atmel's SAM hardware and tools, in order to try some other vendor's part that goes to 150 MHz or 180 MHz? Probably not.

Relying on both a CPLD and a microcontroller surely has some drawbacks: a two-part firmware design, larger board, and slightly higher cost. But it also has a huge benefit: it's a much surer path to getting something that works. I've already done it with the existing Floppy Emu design, and I could make incremental improvements by keeping the same basic approach, but replacing the current CPLD and microcontroller with newer alternatives. I'll stew on this for a while more, but that's where it feels like this is headed, and I'm OK with it.