BMOW title
Floppy Emu banner

Yellowstone Future Forecast

BMOW’s new Yellowstone Universal Disk Controller for Apple II computers has been popular in its first month of release. At the time of its announcement, I warned that parts supply constraints might make this the one and only manufacturing run of Yellowstone cards. That forecast now looks increasingly likely.

Ignoring the burst of Yellowstone sales immediately after its release, and extrapolating from the average daily sales rate more recently, there’s enough stock on hand to last until August or September. Unfortunately the Lattice FPGA at the heart of Yellowstone is out of stock everywhere, due to the global semiconductor shortage that keeps getting worse. The estimated factory lead time on new Lattice FPGAs is an eye-watering 67 weeks. Ouch!

I thought long and hard about placing an order anyway. After all, the sooner I place an order, the sooner I can eventually get the parts. But 67 weeks is a very long time, and that’s just an estimate. I’m not confident that Lattice really has any clue when they’ll be able to resume shipping these parts. It could be never.

Ultimately I decided I’m just not comfortable extending my plans until almost 2024. Will the other required Yellowstone parts still be available then, at prices to make the product viable? Will the product even still make sense to produce, or will it have been obsoleted by something else? Will I still be interested in this line of business in 2024? I’ve already invested money and time securing parts for planned future manufacturing runs of the Floppy Emu disk emulator and the ADB/USB Wombat input converter, expected roughly six months in the future. This already makes me nervous. 67 weeks “estimated” for the Lattice parts is just too much. That would demand making business plans on a cloud and a prayer.

This means when the current Yellowstone stock runs out this summer or fall, there won’t be any more inventory for a long time. I’ll keep an eye on the lead times for Lattice FPGAs and the other required parts. If the situation begins to improve, and it becomes possible to manufacture more Yellowstones with under 30 weeks lead time, I’ll consider jumping back in.

Read 5 comments and join the conversation 

UPS International Shipping Redlining in South San Francisco

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 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, 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,’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.

Read 5 comments and join the conversation 

My First Amateur Ham Radio Contact Attempt

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.

Read 1 comment and join the conversation 

Now Available: Yellowstone Universal Disk Controller for Apple II

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.

Read 23 comments and join the conversation 

BMOW Tries Amateur Radio

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.

Read 7 comments and join the conversation 

First Look at the RP2040 – Raspberry Pi Microcontroller

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.


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.

Read 18 comments and join the conversation 

« Newer PostsOlder Posts »