I’ve stumbled across a puzzling mystery. If you live in the southern part of the city of San Francisco, or in a large area further south into San Mateo County, UPS will not sell you international shipping labels. But change your Ship From zip code to a different city just a few miles away, and UPS will be happy to quote you for international shipping. I reached this conclusion after spending many hours pricing dummy international shipments with different Ship From and Ship To addresses, package sizes and weights, and content types. Only the Ship From address seems relevant. A UPS agent confirmed this behavior but couldn’t offer any explanation or solution.

I first discovered this problem on April 4, while using the third-party shipping service Pirate Ship to generate some UPS international shipping labels. For all my packages, Pirate Ship offered US Post Office shipping options, but nothing from UPS. After several hours working with Pirate Ship’s tech support, they concluded UPS was declining international shipping service to this region for some unknown reason. They told me to take up the issue with UPS.

Initially I didn’t believe Pirate Ship’s explanation, but then I discovered I could reproduce the same problem directly at the UPS.com page for international shipping quotes. You can try this too. Go to the UPS international shipment cost calculator page, as a guest (not logged in). Enter these package details:

Ship From: United States, Redwood City, zip code 94065. Or mostly anywhere else in the United States, except one of the redlined areas listed below.
Ship To: France, postal code 75008, Paris. Or try any another major city in Europe, Asia, wherever, it doesn’t matter.
Customs Value: 119
Package Details: My packaging, 11 x 9 x 2 inches, 0.8 pounds, 119 dollar value

You’ll see a list of available UPS shipping methods with specific price quotes. For example, UPS Worldwide Expedited service costs $154.44 to Paris. You’ll get the same behavior with Ship From addresses in most parts of California or elsewhere in the United States.

Now try the same experiment again, but for the Ship From location, choose one of the following cities and zip codes. These cities are a contiguous geographic region just south of San Francisco, centered around the San Francisco airport. The total population is about 1 million people.

94002 Belmont
94403 San Mateo
94402 San Mateo
94401 San Mateo
94404 Foster City
94010 Burlingame
94030 Millbrae
94128 San Francisco
94112 San Francisco
94132 San Francisco
94066 San Bruno
94080 South San Francisco
94019 Half Moon Bay
94044 Pacifica
94015 Daly City
94005 Brisbane

When you repeat the test using one of these Ship From addresses, UPS.com complains:

The shipment descriptions you have indicated may require special assistance. Please check the accuracy of your request or contact your local UPS office for assistance.

This is consistent with the apparent UPS international shipping redlining that I observed when using Pirate Ship. I spoke with the staff at the local UPS Store, but they’d never heard of this problem, and said their outgoing international shipments were working just fine. Through trial and error, I discovered that Shopify Shipping isn’t affected by this problem either, so it may have something to do with the class of UPS shipping account used to buy shipping labels. The problem definitely affects Pirate Ship, UPS.com’s own shipping quote system, and probably others too.

I then spent a long time on the phone with other UPS support agents who told me I was wrong, and that the Ship From zip code didn’t matter for determining international shipping service availability. On the third try, I was finally able to demonstrate the problem to a UPS agent, but she could only say “I don’t know why it’s doing that”. She couldn’t offer any explanation or solution. That was several days ago, and the problem is still happening today.

My new interest in amateur radio is taking off. After a couple of weeks studying, I took the ham Tech and General license exams on Saturday, and passed them both. Today the FCC updated their license database and created a new call sign for me, which means I can now legally transmit on the amateur radio bands. With my freshly-awarded operator’s license and a new radio, I tried getting on the air for the first time. It didn’t go exactly according to plan.

It’s finally here! After more than four years in development, I’m pleased to announce that BMOW’s Yellowstone Universal Disk Drive Controller for Apple II is available and shipping now. Yellowstone combines the power of an Apple 3.5 Disk Controller Card, a standard 5.25 inch (Disk II) controller card, the Apple Liron disk controller, and more, all in a single card. It supports virtually every type of Apple disk drive ever made, including standard 3.5 inch drives, 5.25 inch drives, smart drives like the Unidisk 3.5 and the BMOW Floppy Emu’s smartport hard disk, and even Macintosh 3.5 inch drives. Yes, pull the internal 3.5 inch drive from an old Mac and use it directly with your Apple II!

Yellowstone Features

• Add 3.5 inch drive and smartport hard disk support to your Apple IIe or II/II+
• Provide more disk connectivity options for your Apple IIgs
• Bring Macintosh 3.5 and naked Apple 3.5 inch drive mechanisms to the Apple II
• Drop-in replacement for an Apple Liron controller card (with optional DB-19F adapter)
• Drop-in replacement for a standard 5.25 inch or Disk II controller card
• Run two drives of different types on twin independent disk connectors
• Disk II controller emulation mode for tricky copy-protected disks
• Works with DOS 3.3, ProDOS, GS/OS, and more
• User-upgradable firmware for future feature enhancements
• 20-pin ribbon cable connectors or optional 19-pin D-SUB connectors

Yellowstone includes two independent disk drive connectors on the card, and supports drives with rectangular ribbon connectors as well as drives with D-shaped 19-pin DB-19 connectors. The standard Yellowstone card includes two rectangular connectors built-in on-board, and DB-19 female adapters are available separately if needed for use with 19-pin drives. There’s also a Yellowstone Everything Bundle that packs the Yellowstone card with two DB-19 female adapters into a single combined package.

The Yellowstone hardware is powered by an FPGA – a programmable logic device that replicates the behavior of the IWM chip and various support chips normally found on other disk controller cards. This gives Yellowstone unparalleled flexibility and control over every aspect of disk I/O, and the ability to change its behavior through firmware updates.

 
Limited Availability

If you’re interested in getting a Yellowstone card, don’t wait too long. At the risk of sounding like a late-night infomercial, “supplies won’t last”. The global chip shortage has created major problems for parts availability, and the FPGA chip at the heart of Yellowstone is no longer available anywhere, with estimated factory lead times of more than a year for new parts. If anyone has a lead on some Lattice LCMXO2-1200HC-4TG100 chips that could be delivered before 2023, let me know! The DB-19 female connectors have also become unobtanium. These aren’t manufactured anymore, and the only available sources are dusty new-old-stock from the 1990s. Once the supply of DB-19 females is gone, they’re gone and that’s the end. BMOW has enough Yellowstone hardware in stock to meet a few months’ worth of estimated sales, but beyond that the outlook is uncertain, and it may be 2023 or later before a resupply is possible. Lucky for you, there are plenty of them in stock right now.

 
Universal Drive Support

Need to attach a disk drive to your Apple II? Yellowstone has got you covered. Yellowstone is compatible with all the disk drives shown in this stack, plus many more. See the instruction manual for complete details.

 
Final Testing, One Last Moment of Panic

These Yellowstone boards were all tested by the contract manufacturer, using the automated Yellowstone test rig that I’ve described previously. But of course for this first batch, I’m going to spot test some boards at home before I put them in the store. So I grabbed a few from the shipping box, popped one into my Apple IIe, and… it didn’t work. After 10 minutes of troubleshooting I couldn’t figure out what was wrong, and I nearly had a heart attack imagining that the whole lot of Yellowstone boards had some systemic design error. Then I noticed the ribbon cable that I’d grabbed off my desk for testing:

Notice anything strange about this cable, like a giant hole in one of the conductors? Why, Steve, why?! I don’t remember why I originally made this hacked cable, but I curse myself now for leaving it on my desk where I’d accidentally pick it up six months later.

 
Available Now

If you own an Apple IIe, Apple IIgs, Apple II+, Apple II, or Apple II clone with expansion slots, Yellowstone is the disk controller card you’ve been waiting for! Check out the complete details in the Yellowstone instruction manual, or buy one now at the BMOW Store.

How do older electronics nerds have fun? With an amateur radio license, of course! Some recent conversations with friends spurred me to learn more about ham radio operation, and I threw myself into studying. I’m now scheduled to take the technician and general class license exams back-to-back on March 19, and if I pass I’ll receive a call sign and can get on the air. Watch out, world.

What exactly do amateur radio operators do? Until recently, I only knew what I’d seen in movies, where hams working at night try to make voice contact with other radio operators on the opposite side of the planet, using huge antennas. This is called DXing and it’s certainly a big part of the hobby, but now I’ve learned there’s much more. Many hams begin with simple handheld radios operating on VHF and UHF frequencies, where they can talk to others in their local area. Most cities have repeaters on hilltops and tall buildings that can rebroadcast these low-power transmissions, effectively increasing the coverage area. Where I live in California’s San Mateo County, there are over 50 such repeaters available for amateur radio use!

Other fun things to try: talking to the International Space Station, bouncing signals off the moon, and patching communications through amateur radio satellites. There are also radio-internet gateways that can stream radio traffic across the internet for part of its journey. And beyond voice communications, there’s all manner of digital radio communication too. Packet radio, RTTY, image and video transmission, you name it.

Much of the hobby revolves around building and tinkering with the radio equipment and antennas, in order to get the best performance. For people who enjoy experimenting with electronics, this is a good challenge.

To broadcast on an amateur radio frequency, you must be licensed. This theoretically prevents inexperienced people from accidentally screwing-up the EM spectrum for everybody else through improper operation of their radio. There are currently three levels of license, from the beginner-level technician license, to the general license, and the top-tier amateur extra license. Your license class determines what frequency bands you’re permitted to broadcast on, and the maximum permitted power level. Technicians are mostly restricted to VHF and UHF frequencies (with a few exceptions), while the general license opens up more lower frequency bands that propagate further and are better suited for chatting with people 10 time zones away. Amateur extra licensees can broadcast in any amateur band and are also eligible to get shorter, more-memorable call signs.

Before I knew anything, I assumed the amateur radio license exams would be quite difficult. “Difficult” is a relative idea, but now that I’m familiar with the tests, I’d say practically anyone could pass the technician exam with about 5-10 hours of study. If you already have some background in basic electronics and physics, like most readers of the BMOW blog likely do, then you’ll find it easier. The technician exam is roughly one-third electronics and radio theory basics, one-third practical radio operation skills, and one-third FCC regulations. The general exam goes deeper into the theory, but it’s nothing too scary. All the tests are multiple choice, and knowledge of Morse Code isn’t needed.

Initially I’d planned to study for the technician license, but after I realized I already knew about half the material on the general license exam, I decided to double-up and do them both at once. This seems to be a fairly common path for people who already have some electronics and physics background.

See you on the airwaves! If you’re in the SF Bay Area, hit me up after the 19th if you’d like to try some on-air conversation.

In response to my last post, a few readers suggested looking at the Raspberry Pi Foundation’s RP2040 microcontroller for possible use in a future Floppy Emu hardware refresh. The RP2040 was announced in January 2021, first as part of the Raspberry Pi Pico development board, and later as a stand-alone chip. While Raspberry Pi’s other offerings are essentially full-fledged computers, the RP2040 is a traditional microcontroller that will compete directly with familiar products from Microchip, ST, Espressif, and NXP. So what does it offer that might set it apart from the competition? Is it worth a look? Here’s my take.

 
Strong Points

RP2040 is a 133 MHz dual-core ARM Cortex M0+ microcontroller, with 264 KB of RAM, and a unit price of $1 USD. Right off the bat, that looks appealing. I don’t know of any other microcontroller from a major vendor that offer a better ratio of hardware specs per dollar. 133 MHz is quite zippy, and 264 KB of RAM is substantially more than any of the alternative parts I’ve been considering. Dual core is just icing on the cake.

The hardware also includes two programmable I/O (PIO) blocks with interesting potential. These are hard to describe in a single paragraph, but they’re like high-speed specialized coprocessors that could replace much of the software-based bit-banging that’s often needed in microcontroller applications. They’re a good fit for high-speed bit twiddling, independent of the main cores. For the Floppy Emu, PIO blocks could probably be used to replace some of the specialized logic that’s currently handled by a CPLD programmable logic chip.

The documentation looks well-written. So far I’ve reviewed the chip datasheet, hardware design guide, the C/C++ SDK documentation, and the Getting Started Guide.

The RP2040 is available and shipping in large quantities right now, which is quite an accomplishment given the current shortages everywhere else in the industry. DigiKey has over 50000 in stock. You can also order the chips directly from Raspberry Pi.

 
Weak Points

There’s zero flash or non-volatile memory for program storage on the RP2040. All the application code and data must be stored in an external flash chip. Six dedicated pins are used to communicate with a separate QSPI flash, using execute-in-place (XIP) technology to run code directly from flash without needing to copy it to RAM first. A 16 KB XIP cache helps speed up this process. Relying entirely on external flash helps keep the RP2040 price down, and lets the user choose a flash chip whose storage size matches their needs, but it also has some serious drawbacks for my purposes.

The biggest worry is code execution speed. If most of the code fits into the 16 KB cache, then the code should run as fast as any other CM0+ microcontroller with similar specs. But for uncached code, and especially for application startup code when nothing is yet cached, I fear it will be slooooow, slower even than 8-bit AVRs with much lower system clock speeds. I used section 2.3 of this Atmel document to understand what XIP traffic looks like for a QSPI interface. Fetching a 32-bit value requires 20 SPI clocks, which is 80 system clocks using the RP2040’s default settings. A 32-bit value can hold two 16-bit Thumb instructions, so it looks like 40 system clocks per instruction, or 3.3 MIPS at 133 MHz. Slow.

For many time-critical routines, code can be pre-loaded into RAM with some extra effort, where it will run much faster. But for application startup code there’s really no way around this bottleneck. I’m not sure if this would be a serious problem, or if I’m worrying over nothing.

There’s no easy place to store settings information, like the EEPROM on an AVR. Presumably settings would need to be stored in the same external flash as the program code. This would require copying some section of code to RAM and executing it, which would deactivate the XIP interface and use standard SPI flash commands to update a few bytes, before re-enabling XIP and resuming the program.

The RP2040 bootloader could be considered both a strong point and a weak one. There’s a built-in USB bootloader in mask ROM, which is activated if the external flash is missing or deactivated. To the computer it appears as a USB mass storage device, so you can update the firmware with a simple drag-and-drop. This is great if your product already has a USB device (USB-B) connector on it, but the Floppy Emu doesn’t and doesn’t need one. I could roll my own pseudo-bootloader as part of the main application code, to load firmware updates from the SD card, but it wouldn’t be in protected memory like a real bootloader. If something went wrong during the update, it might corrupt the pseudo-bootloader and effectively brick the device.

While I admit I haven’t tried it, the C/C++ development toolchain doesn’t look great. Ideally I’d hope to see an IDE like Atmel Studio or STM32 Cube, with hardware-specific tools to help configure the peripherals, GUI settings for all the build options, an integrated simulator and debugger, and so on. But the reality is more like a pile of libraries, header files, and build scripts. Changing any kind of build settings relies heavily on editing CMake files and adding new defines whose existence you may not have known about. Sure you can use the VSCode IDE, but it doesn’t seem to do much more than function as a text editor, and you’ll still be tearing your hair out struggling with CMake. The build environment is also clearly geared towards Linux, and while setup is possible under Windows, it appears to be cumbersome.

My last worry is over the RP2040 development community, or really the lack of a community. If you’re developing for an AVR, or Atmel SAM, or STM32, you’ll find thousands of helpful resources on the web with example code, discussion forums, and sample projects. There’s very little of this for RP2040, and most of what does exist is geared towards Micro Python and Circuit Python, rather than bare metal C/C++ development. The only discussion forum I’ve found is a small subsection of the main Rasperry Pi forums. This doesn’t make it impossible to develop – the documentation seems thorough and there is some help on the web. But it’s a far cry from working “in the herd” and developing for a more popular microcontroller family.

 
Conclusions

So is the RP2040 the future of the Floppy Emu? It’s hard to say, but I think probably not. It may help to compare it against some other possibilities, like the Atmel SAMD21 (48 MHz CM0+ with 32 KB RAM) or SAMD51 (120 MHz CM4 with 128 KB RAM), which cost around $4 each in large quantities. Compare these to an RP2040 plus an external flash chip, with a combined cost of about $2. The RP2040 solution is half the price, but both alternatives are cheap enough, and I would choose whatever solution will make development easiest.

The extra RAM of the RP2040 is welcome, but I’m unsure what I’d do with it. 32 KB is more than enough to buffer a disk track plus other application data, and unless I had 1MB or more to buffer a whole disk, additional RAM might not be immediately useful.

133 MHz is greater than 48 MHz, so maybe the RP2040 is much faster than the SAMD21? Or maybe not, given the overhead of XIP code execution?

All these differences in favor of the RP2040 look interesting, but if they aren’t critical for my specific application, then are they worth the trade-offs of the build environment, development community, and concerns about external flash?

For the specific case of the Floppy Emu, I think the best argument in favor of the RP2040 is the PIO blocks. If those could replace all of the logic that’s currently handled by a CPLD programmable logic chip, then I could eliminate the CPLD entirely, and greatly simplify the whole design. But if the PIO blocks can only replace some of the logic, then I still need a CPLD or something similar, and the advantage of the RP2040 is much less. But that’s a difficult question to answer by just reading the docs, and I’d need to really dig in and try building it.

It’s been a while since I last shared any business updates for BMOW. The past few years have been an exciting trip, as my personal technology blog has grown into a side hustle and then into a bona fide business. Initially BMOW was something I did in my spare time away from my real job (video game development), then it was something I did while I was between jobs, and now for the past few years it has been my real job. The experience has been great, but now the global chip shortage has scrambled everything, and the future outlook is growing scary.

 
The Good

First the good news. The gradual transformation from blog to store began in 2014, when a few blog readers started asking to buy the Macintosh floppy disk emulator that I’d been writing about. I sold about $18000 of hardware that first year, doing all the assembly and fulfillment by hand. It didn’t leave a huge profit after subtracting all the cost of parts, tools, and other business expenses, but it was a thrill to be making something that people wanted.

In the time since then, sales have grown consistently every year. I’ve moved the assembly work to dedicated manufacturing partners, added many new products to the BMOW line-up, and even hired a part-time employee to help with order fulfillment and customer support. In 2021 I sold several thousand Floppy Emus, plus lots of other products too, which was amazing. Gross revenue was into the hundreds of thousands. My net income after all expenses is less than I could earn as a software developer here in Silicon Valley, but it’s still a respectable number, and being my own boss is fantastic. I couldn’t imagine going back to a regular full-time job now. Sure, I’m always complaining about the challenges of international shipping or payment processing disasters or something else, but that comes with the territory of running my own business.

 
The Bad

If there’s anything bad here, it’s the overall fragility of the business. A great business would have revenue from many diverse products, with reliable sources of supply, and a large and growing market. I have none of that. The market is owners of obsolete computers from 25+ years ago. There simply aren’t many of those, and the number is shrinking every year as some computers break and can’t be repaired. How many working Apple II and classic Macintosh systems even exist today? Ten thousand? Ten million? I really don’t know. I keep thinking that I must have saturated the market already, but it hasn’t happened yet.

Product diversity is another weak point. BMOW sells eighteen different products, but 80 percent of revenue comes from the Floppy Emu Disk Emulator. Everything else is basically just a distraction. If anything threatens the supply or sales of Floppy Emus, then the business is in big trouble.

 
The Scary

Friends, the global chip shortage is very bad. For over a year columnists keep predicting it will get better soon, but it only gets worse and worse. This won’t continue forever, but how much longer will we have to endure this crunch? Six months? A year? Two, or three? And what will the landscape look like then? Will semiconductor makers take this opportunity to discontinue some of their oldest and least-profitable chips, the chips that are needed for vintage computer hardware?

The Floppy Emu uses two primary chips: a microcontroller and a programmable logic device. The mcu is an Atmel ATMEGA1284 and the logic device is a Xilinx XC9572XL. Both are relatively old technology, like 15+ years old. Both have seen their prices double or triple in the past couple of years. And both now have very limited or zero stock everywhere, with little hope of getting more stock anytime soon. Maybe I can get more in six months, or a year? Maybe never?

The last time I did a Floppy Emu manufacturing run, it was very difficult to find parts, particularly the ATMEGA1284. I almost gave up. My manufacturing partner made a lot of calls, and eventually found a surplus parts broker who could fill the order for a nosebleed price. As of today, I have enough finished Floppy Emus to last until roughly September at my normal rate of sales. I don’t know what happens after that. If I can’t find the required parts, or redesign the board around new parts, then I’m basically out of business.

 
Strategizing

What would you do in this situation? I can’t decide, and I’m spinning my wheels trying to decide what to do, while the clock is ticking and time is running out.

One option is to redesign the Floppy Emu hardware around new parts with better availability. The existing parts are pretty old anyway, so a refresh would make sense. But what new parts should I choose? It’s not just the ATMEGA1284 that has supply problems – it’s virtually all microcontrollers from Microchip, ST, TI, everybody. And the options for programmable logic parts are even worse. There’s very scarce availability of any programmable logic parts, and the few that are available are actually less capable than the old Xilinx part, or cost five times as much. Sure, you can sometimes find parts with a few hundred at one supplier and 1000 at another, but it’s usually one specific oddball package or variant while the rest of the family is out of stock. That’s a fluke, not a reliable supply. To feel comfortable betting the farm on a new chip, I’d want to see all the members of its family with deep stock in the many thousands, at multiple suppliers.

If I redesign the Floppy Emu hardware, should I redesign around the best available parts options today, or around a blue-sky vision of the best-suited parts for the task regardless of current availability? A redesign will be a major time-consuming effort, and I can’t afford to get it wrong. It’s a gamble. If I redesign around the best available parts today, that greatly limits my choices. I could be locked into sub-optimal parts for a long time to come. That might make it much harder to add new features, or might create new supply problems in the future, or increase my costs. If I redesign around the parts I’d like to use in a perfect world, then I could have to wait a very long time before they become available again. The redesigned hardware might never see the light of day except for a few prototype units.

Given how much time any redesign would require, and the uncertain results, there’s another option I’m seriously considering: do nothing. Place some back-orders now for the ATMEGA1284 and XC9572XL, and then forget about it. Use the coming months to work on Yellowstone features or develop some cool new product, instead of redesigning the Floppy Emu. Hope that the parts become available before I need them, and if they don’t, it will be lean times at BMOW. I would still probably want to revisit the Floppy Emu hardware design in another year or two, to take advantage of the capabilities of newer parts, but I would do it after the chip shortage is over and there’s a clearer picture of what parts I can safely bet on.