After several days of extensive testing with the latest Yellowstone prototype, and several years of development work on this universal Apple II disk controller concept, I’m here to say that Yellowstone v2.2 is looking good. Looking very good. It’s the bee’s knees, the cat’s pajamas, the whole package; it’s a humdinger, a totally gnarly wave; it’s crackerjack, boffo, hella good, chezzar, d’shiznit, on point, and just plain bombdiggity. I’ve thrown a dumpster-load of assorted drives and disks at it, and it’s all working nicely. Finally everything has fallen into place, and I’m excited for what comes next. Here are some feature highlights:

• Supports most Apple II and Macintosh disk drives, including 3.5 inch floppy, 5.25 inch floppy, Unidisk 3.5, and Smartport hard drives
• Compatible with Apple II+, Apple IIe, and Apple IIgs
• Maximum of 2 standard disk drives, or up to 5 drives when mixing smart and standard drives
• 20-pin ribbon cable or 19-pin D-SUB connectors
• Works in any slot
• Disk II compatibility mode for tricky copy-protected disks
• User-upgradeable for future feature enhancements

Yellowstone supports basically every disk drive ever made for the Apple II or Macintosh, whether external or internal. The only exception is the single-sided 400K 3.5 inch drive used in the original 1984 Macintosh. The list of drives includes:

• Standard 3.5 inch: Apple 3.5 Drive A9M0106, Mac 800K External M0131, Apple SuperDrive / FDHD Drive G7287 (as 800K drive), internal red-label and black-label 800K drives liberated from old Macs, internal auto-inject or manual-inject Superdrives (as 800K drive), and probably also third-party 3.5 inch drives from Laser, Chinon, AMR, Applied Engineering, and others.
• Standard 5.25 inch: Disk II A2M0003, Unidisk 5.25 A9M0104, AppleDisk 5.25 A9M0107, Disk IIc A2M4050, Duo Disk A9M0108
• Smart drives: BMOW Floppy Emu Smartport Hard Disk emulation mode, Unidisk 3.5 A2M2053
• Drive emulators: BMOW Floppy Emu, wDrive, etc.

With these latest test results, we’re almost at the point where other people can start to get their hands on Yellowstone cards. There are surely still some minor bugs, quirks, and annoyances yet to be discovered, and maybe some larger problems too. I need to get a few Yellowstone prototypes to beta testers, so they can try the cards with their equipment, and help find any remaining issues.

My priority now is to finish the automated tester that I’ve been developing. As I hand-assemble a few more prototype boards, I’ll test them in the automated tester, proving both the tester and the board at the same time. That means delivery of boards to beta testers will proceed more slowly than if I weren’t developing an automated tester, but I think this is necessary so that I can eventually scale up manufacturing for a general public release. I’m guessing there may be four to six weeks needed to finish off the automated tester and build it, but hopefully I can squeeze out at least a couple of hand-verified prototype boards much sooner than that.

The last piece of this puzzle will be securing a large enough supply of DB-19 female connectors, and designing a detachable Yellowstone adapter for them. I have a couple of DB-19F adapters that I’ve been using for testing, but DB-19F connectors are rare and hard to find. The ones I have now use a DB-19F with solder cups, but the type with PCB pins seems to be more common, if you can find them at all. I’ve stashed a modest supply of DB-19F connectors that’s enough for an initial Yellowstone production run, but the outlook is uncertain beyond that. I may have to commission 10000 new ones like I did with the DB-19 male.

These are exciting times! Thanks for following along this journey with me.

Hello! I’m Alice, the engineering intern here at Big Mess o’ Wires. I’m a math with computer science major at UC San Diego, and throughout the summer I’ve been working on some fixes and improvements for BMOW products. I started out on the ADB-USB Wombat, but most of my work has been on Floppy Emu development.

Today, I’m excited to finally share what I’ve been doing! Here is a collection of some of the new Floppy Emu improvements. They’re mostly related to Smartport and Unidisk 3.5 emulation for the Apple II, but there’s some other good stuff too.

Smartport Hard Disk and Unidisk 3.5 emulation:
– Control commands are now handled better. This resolves GS/OS freezes during shutdown or restart, and related problems with other software.
– A NAK/retry mechanism was added for cases where there’s a checksum failure on a Read or Status command. It will provide more robustness against signal noise.
– Status commands that request invalid or unsupported status types will now receive a proper error reply.

Unidisk 3.5 emulation:
– Emulation now continues to run even while displaying the disk selection menu. It will respond to commands as an empty drive, instead of not responding at all. This resolves some potential problems when booting from other disks and when swapping disks.
– Handling of disk ejection has been improved. Disks can now be ejected and replaced through the GS/OS Finder menu and other methods of software-controlled disk eject, as well as through the Floppy Emu menu interface.
– The disk icon that’s displayed in GS/OS has been updated to look like a 3.5 inch floppy disk.

General improvements:
– Occasional errors CHECK PIN CLKO-L and CHECK PIN RESET should no longer occur.
– Hidden system directories on the SD card will not be displayed in the disk selection menu, including Windows 10’s “System Volume Information” directory.
– OLED screen dimming behavior is now more consistent.

These improvements are available in firmware versions 0.2T-F30, 0.2S-F29-SPDC, 0.2S-F26, and 0.2H-F15 (depending on the Floppy Emu model and the type of computer it’s used with). You can download the new firmware files on the Floppy Emu page. Let us know if you run into any issues, and have fun!

Hello! If you haven’t met me already, I’m Alice, the BMOW engineering intern. (You might hear more about what I’ve been up to soon.) I’m excited to share that after several stages of redesign, cases for the Daisy Chainer are finally here! These clear acrylic enclosures will protect your Daisy Chainer and show it off with style. This is a plate style case similar to the ADB-USB Wombat with open sides and a logo-etched top. Available now on the store!

Yellowstone version 2.2 is up and running! If you don’t remember what’s changed in v2.2, well… that makes two of us. Luckily we can both go read this August 20 post for a reminder. Hand assembly took about two hours, and this was the first time any of the Yellowstone prototypes have worked straight away without needing any troubleshooting or fixes. The board has only been through one superficial test so far, confirming the ROM contents and booting a 5.25 inch disk, but I’m feeling optimistic it’s a winner.

After going through board v1.0, v2.0, v2.1, and v2.2, I’m sincerely hoping that this will be the final hardware version. The return of the DIP switch is the most visible change here – now the much-discussed -12V supply can be manually enabled or disabled. Leaving it enabled will almost always be OK, but there are a couple of polyfuses to protect the hardware just in case. There’s also a fix in v2.2 for a minor problem that prevented an Apple 3.5 Drive’s eject button from working if the drive was plugged into Yellowstone’s connector #2.

There are still some software issues to clean up, but (crossing my fingers) I think I can see the finish line now.

Just for fun, here’s a shot of the new Yellowstone board along with all of the disk drives I’ve amassed for testing. All of these will work with Yellowstone, and many others too.

And a bonus feature: here’s a peek at a 50 pin Apple peripheral card breakout board that I whipped up. It has all the signals labeled, because I don’t trust myself while debugging. With this breakout board, it’s possible to run a peripheral card on a breadboard instead of inside the Apple II. That’s exactly what I’m doing with the work-in-progress version of the Yellowstone tester shown here.

I’m still working on the design for an automated Yellowstone tester. The general idea is to use an STM32 microcontroller that’s connected to all the Yellowstone board’s I/O signals, then drive the inputs in various combinations and verify the outputs. This should catch a lot of potential problems, including open circuits, missing components, and many instances of defective components. But what about short circuits on the Yellowstone board that’s being tested? These aren’t so simple to detect, and they can potentially damage the tester.

The trouble with short circuits is that they can’t really be tested by working with digital signals alone – they force the whole problem into the analog domain. Depending on what’s shorted, and the effective resistance of the short, the behavior can vary greatly. A direct +5V to ground short might blow a fuse, or prevent the tester from even initializing if it shares a common supply. Other shorts might occur between a signal and any supply voltage (+5, -5, +12, -12), or between two supply voltages, or between two signals. The shorted signals might be driven from the tester, or from a chip on the Yellowstone board, or one of each. A short might cause immediate failure somewhere, or it might just cause a signal’s voltage to get pulled down or up. Depending on the change in voltage, it might not be enough to flip a bit and create a detectable error. Lots of components can also likely survive a short circuit for a while, but they’ll get hot, and will probably fail later. How can the tester detect these?

Assuming there’s a fuse, what type should it be? A replaceable fuse will be annoying if boards with shorts are at all common, since the fuse will need replacement often while testing a batch of boards. A poly fuse is resettable, but it can take about an hour to cool down enough to reset, rendering the tester unusable during that time. Neither option seems great.

If there’s a fuse, what should be fuse-protected? A fuse on the board’s 5V supply won’t do anything if there’s a short between an input signal and GND, because the current will be sourced by the tester and not by the Yellowstone board. Nor will it do anything for shorts on the other supply voltages. A short between signal and supply or between two signals may or may not be protected by a fuse, depending on where the current is ultimately sourced.

What max current rating is appropriate for a fuse? The “safe” current level could vary widely depending on what supply or signal is considered, and the current state of all the I/O signals. Then there’s there the 3.3V regulator on the Yellowstone board, which has its own overcurrent protection mechanism. If there’s a short between 3.3V signals, the regulator will limit the current, and a fuse or other mechanism on the tester may not even realize that a short circuit occurred.

My head is spinning just trying to map out the possible short circuit cases, and how to detect and prevent them. At the same time, I’m trying to design a tester that strikes a good compromise between complexity and thoroughness. Maybe I could design a tester with a dozen different fuses and current-monitoring ICs and IR thermal sensors, and it would be great at detecting short circuits, but it would be too much complexity and effort for a small-scale hobbyist product. My goals are to avoid damaging the tester, and to detect a large majority of common board failures including short circuits, while recognizing that it will never be 100 percent perfect.

Here’s a brief follow-up about the classic Macintosh game Dark Castle, which I mentioned a few weeks ago in connection with some possible disk emulation bugs. This game originally shipped on two 400K floppy disks. At the intro screen shown above, the player is given a choice of doors, and some of the doors will ask the player to insert disk 2. But when loading the 400K game disk with a Floppy Emu disk emulator, the disk swapping doesn’t work. Disk 1 doesn’t get ejected, and if disk 2 is inserted, it will be ignored. A few weeks ago I speculated that this may be caused by a Floppy Emu bug, but I was wrong.

After a bit of research, I found that the problem is just another example of Games That Only Work In Drive 1. This is pretty common in the Apple II world, but not so common for Macintosh games. When Dark Castle tries to eject disk 1, it specifically tells drive 1 (the internal drive) to eject, regardless of which drive contains the disk. Then it checks the same drive for disk 2. Since Floppy Emu is normally connected to classic Macs as the external drive (drive 2), this doesn’t work. To confirm this behavior, I disassembled an old Mac and connected a Floppy Emu internally, in place of the built-in floppy drive. With this configuration, Dark Castle 400K worked fine.

BMOW’s Vintage Apple Software Collection SD Card has an 800K version of Dark Castle, where the contents of both 400K disks have been copied onto a single 800K disk. This avoids the need for disk swapping, so the game can be played normally from a Floppy Emu or other external floppy drive, but it requires a Macintosh model that’s compatible with 800K drives. The oldest Macintosh models are only compatible with 400K drives. For those models, playing Dark Castle will require connecting the Floppy Emu internally as I did, or copying the disk images from the Floppy Emu onto real 400K disk media for use in the internal floppy drive.