I’m squeezing in one more big firmware update for the BMOW Floppy Emu disk emulator before the Thanksgiving break. This update brings a major improvement for Smartport hard disk selection and management, as well as a new settings menu that combines all of the Floppy Emu’s various user preferences. Based on the suggestions and questions I’ve received in the past, I think this update is going to make a lot of people happy.

 
Disk Image Selection UI for Smartport Hard Disks

For Apple II computers, Floppy Emu offers a Smartport hard disk emulation mode, providing up to four simultaneously-available hard disks to your computer. Today’s firmware update introduces a new UI for dynamically managing and selecting the desired disk images, entirely within the Floppy Emu menus, and without needing to rename any files on the SD card. After pressing a button to pause the Smartport disk emulation, a setup screen appears. For each of the four hard disk slots, you can view or change the associated disk image, or remove the disk image and leave the slot empty. Disk images are selected through the the same file browser menus as in other emulation modes.

It sounds simple, it was a bit of a bear to implement, but it was worth it. The new interface is a much more flexible and intuitive way of configuring Smartport hard disks, and it’s no longer necessary to name or rename the disk images using a fixed naming convention like smart0-gsos-6.0.2.po.

 
System Settings Menu

This update also introduces a new system settings menu for all Macintosh, Lisa, and Apple II firmware versions. Press SELECT when prompted during Floppy Emu’s startup, and you’ll arrive at this new top-level menu. From here you can change the current emulation mode, adjust the display type and brightness, view software version information, and more. This menu replaces the scattered settings interfaces that existed before, each requiring a different hard-to-remember button combination to reach.

The Jumbo OLED option that appears in the settings menu is for a 2.4 inch display that was previously discussed in 2019. A few people have since built custom Floppy Emu enclosures using this OLED, but the standard firmware doesn’t work quite right with it: text and images appear shifted two pixels out of position. Beginning today, the jumbo OLED is graduating from a fun experiment into an officially-supported option, and changing the display type to jumbo adjusts the image position as need.

 
Update Now

Download the latest Floppy Emu firmware from the project page, or buy a new Floppy Emu Model C at the BMOW Store.

I’ve also prepared this video demo of the new one-step process for firmware updates, which was introduced last week.

Please enjoy this new update for the BMOW Floppy Emu disk emulator as we head into the Thanksgiving holiday week. The new firmware brings a UI refresh, scrolling of long filenames, bug fixes, performance tweaks, a couple of new disk formats, and a simplified naming scheme and update process. I think you’re going to like it. Here’s a look at what’s changed.

 
UI Graphics Galore

For the Floppy Emu Model C, the user interface has been overhauled to take better advantage of the extra display resolution (compared to the previous generation of hardware). There’s a new start-up screen to replace the old smiley-face, and improvements to how the current emulation mode is displayed. I sometimes hear from customers who are confused about which disk emulation mode they’ve chosen, or how to change the emulation mode, and this UI should help with both. The active emulation mode is now displayed in both text and graphics during startup, along with a prompt “press SELECT to open emulation mode menu”. If you can’t remember that you chose Lisa 3.5 inch floppy disk emulation, now you’ll see a bitmapped Lisa logo and a 3.5 inch disk icon. All of the references to the PREV, SELECT, and NEXT buttons have also been enhanced with triangle and square icons to match the legend on the Emu’s acrylic case. It looks slick.

The new UI extends to the main disk emulation display as well. You’ll see one or two icons depicting the types of disks that Floppy Emu is currently emulating. Read-only disks are displayed with a padlocked icon, and in Dual 5.25 Inch Floppy mode the icons are also numbered for Drive 1 and Drive 2. It may be eye candy, but it’s so much better than boring text.

 
Long Filename Scrolling and Size Display

Do you have a file or directory name that’s too long to fit the Floppy Emu’s display? The new firmware also implements filename scrolling in the menus and disk emulation screens. It’s hard to capture in a photo, but it’s a smooth pixel-by-pixel scrolling and it looks great. This features was suggested several times in the past, but I used to believe it wasn’t necessary. The firmware truncates long filenames by omitting the middle section, rather than the end, so “Welcome Aboard – Disk 1, Size A.woz” becomes “Welcome Aboard ..de A”. That’s enough to tell apart side A, B, and C, but now that I’ve seen filename scrolling in action, I have to admit it’s much nicer. The original method is still used when you’re quickly scrolling through a menu listing, but if you pause for a second, the highlighted menu entry begins to scroll and reveal the full name of the file or directory.

For technical reasons, long filename scrolling isn’t available for Unidisk 3.5 disk emulation. Whomp whomp.

Filename scrolling also creates an opportunity to show more information about the highlighted item in disk selection menus. If Floppy Emu recognizes the disk image as a supported type, it’ll show the size/type as a suffix on the filename, right in the menu! Imagine you’ve got your Floppy Emu connected to a Macintosh Plus, which supports 400K and 800K floppies only. If you scroll through a directory listing and see “Stuffit Expander 5.5.dsk 1440K” then you’ll immediately know the Mac Plus can’t read it. With the earlier firmware, you had to guess at this, and try inserting the disk before you could learn its size and type.

 
Bug Fixes and Enhancements

The new Apple II firmware fixes a rare bug that occurred when Dual 5.25 Floppy mode was used with a Yellowstone universal disk controller card, and Drive 2 was empty. Why would you run Dual 5.25 Floppy mode but leave one of the drives empty? I don’t know, but it’s fixed now.

For Macintosh/Lisa users, menu scrolling and alphabetic sorting have been sped up to match the behavior of the Apple II firmware. There are also three new floppy disk type variations, which I’m calling Small 400K, Small 800K, and Small 1440K. These are standard raw floppy disk images, except instead of filling empty sectors with zeros at the end of the disk image, the image file is simply truncated. You might recognize these as a disk image like “Tools.dsk” that’s 717K instead of 800K. It’s rare, but I’ve run across a few examples.

 
New Firmware System

The final change is the one I’m most excited about: an all-new system for naming and applying firmware updates. Before now the firmware versions had complex names like “Mac-Lisa-0.8H-F15”, which made sense to me but confused everybody else. The firmware was also distributed as two separate data files, one for the AVR microcontroller chip and another for the CPLD logic chip, and both parts needed to be installed separately.

No more. Beginning with this version, I’m moving to a simplified naming scheme using the date in YYMMDD format, with an A or M suffix to indicate the Apple II or Macintosh/Lisa version of the firmware. I’ve also merged the two data files into a single unified file, requiring only a single step to perform the update. If you’re familiar with the old update process, make sure to view the README file since the process has changed. Behind the scenes the AVR can now detect when it’s just been updated, and it automatically unpacks and applies the CPLD update too. I should have done this years ago.

Download the latest Floppy Emu firmware from the project page, or buy a new Floppy Emu Model C at the BMOW Store.

The Noisy Disk is back in stock at the BMOW store, after a manufacturing delay. Do you miss the iconic sounds of mechanical click-clacking from original Apple II floppy drives? Does the familiar rattling of a boot floppy bring a smile to your face? This board uses a mechanical relay to create authentic-sounding disk head movements for the BMOW Floppy Emu disk emulator. Sure it’s useless, but it’s useless fun.

The Noisy Disk board attaches inline with your existing Floppy Emu cable. When Floppy Emu is configured to emulate a 5.25 inch Apple II floppy drive, the Noisy Disk onboard relay snaps open and shut whenever the emulated disk steps from one track to the next. It creates a symphony of disk noise that will bring back memories of 1979.

Noisy Disk is available now at the BMOW Store.

There’s a new Apple II firmware update for the BMOW Floppy Emu Disk Emulator. This update makes a small but important change to the emulated drive behavior after a disk is ejected. The current track number and other drive state is now maintained even after a disk is ejected, and is applied to the next disk that’s inserted, instead of resetting the state to defaults. A few multi-disk Apple II games appear to rely on this behavior, including Captain Goodnight, which otherwise would fail after the insertion of side B. The new firmware is version 0.2W-F33 and 0.2W-F34. You can download the latest Floppy Emu firmware from the project home page.

Firmware version 221024 is now available for the Yellowstone Universal Disk Controller for Apple II. This is the first new firmware since Yellowstone was released, and it fixes two unrelated problems with reset handling and with the NMOS version of the 6502 CPU. The reset handling issue could cause disk I/O to stop working after pressing Control-Reset (not Control-Apple-Reset like is frequently used to reboot an Apple II). The Total Replay collection of games also exposed a subtle problem with Yellowstone on the NMOS 6502, which is used in the unenhanced Apple IIe and the Apple II+, causing Total Replay to freeze during startup on these computers. Firmware 221024 resolves both issues. You can download the latest Yellowstone firmware from the project home page.

Yellowstone is a universal disk controller card for Apple II computers. It supports nearly 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. Yellowstone combines the power of an Apple 3.5 Disk Controller Card, a standard 5.25 inch (Disk II) controller card, the Apple Liron controller, and more, all in a single card. Get yours now from the BMOW Store.

History repeats itself. I’ve been bitten by an obscure Yellowstone bug related to 6502 phantom reads, and it’s exactly the same problem that I struggled with 13 years ago during the design of my BMOW 1 homebrew wire-wrapped CPU. In both cases, I designed some hardware where CPU reads from a specific address would have side-effects that changed the machine state. And in both cases, I later encountered baffling bugs where the CPU would perform unintentional reads from those special addresses, thanks to the CPU’s implementation details, even though the program instructions never specified a read there. It’s an especially sneaky bug when examining the source code listing reveals nothing, and you need to break the abstraction barrier and look at how the CPU actually implements each instruction.

Back in 2009 the problem was BMOW 1’s audio system, and this time it was the Yellowstone Apple II disk controller‘s Smartport hard disk I/O.

 
$CFF8: A Special-Purpose Disk Read Register

With a traditional Apple II disk controller, in order to read the data bitstream from the disk, the program must continuously poll a shift register and check if the MSB is 1. This checking and polling loop eats CPU time, creating an upper bound on the fastest bit rate that a 1 MHz Apple II can process reliably. Yellowstone takes a different approach. When the program reads from the special address $CFF8, the Yellowstone hardware halts the CPU by deasserting the 6502 RDY signal until the shift register is filled. When the CPU resumes and the program reaches the next instruction, it’s guaranteed to have a good value with an MSB of 1, so checking the value isn’t needed. This provides just enough time savings in the inner loop for a 1 MHz Apple II to handle the faster bit rate of 3.5 inch disks, which is twice as fast as 5.25 inch disks. Pretty neat!

If the program code ever accidentally read from $CFF8 when it didn’t intend to fetch disk data, that would create a big problem by halting the CPU and desynchronizing the disk bitstream. But accidental reads should be trivial to avoid – just don’t use $CFF8 for any other purpose. If the code doesn’t reference $CFF8, then $CFF8 won’t be read… right? RIGHT? Wrong. It turns out that was a safe assumption for the 65C02, the second-generation version of the CPU that included various improvements and new instructions, and that’s present in the enhanced Apple IIe and Apple IIc. But for the original NMOS 6502, as found in the Apple II+ and unenhanced Apple IIe, it’s a different story.

 
Total Replay, Yellowstone, and the Unenhanced IIe

I first became aware of a possible problem after a few Yellowstone owners reported that Total Replay was freezing during startup, before ever reaching the main menu. Putting all the reports together, it emerged that everyone with this problem was running on an unenhanced Apple IIe system. For quite a while I assumed this was probably a Total Replay bug. Maybe it used one of the instructions only available on the 65C02, or relied on some ROM code only present in the enhanced IIe ROM.

Recently with the help of Peter Ferrie, I began digging into the mystery in more detail. Peter shared that Total Replay was running without trouble on unenhanced IIe systems with other disk controllers, so this was apparently a Yellowstone-specific problem. Where could I begin troubleshooting? I don’t own an unenhanced IIe, but I have an enhanced Apple IIe and some ROMs and a spare NMOS 6502, so I could make an unenhnaced IIe. I could even create a Frankenstein hybrid system with a 65C02 but the unenhanced ROMs, or a plain 6502 and the enhanced ROMs. My experiments found that the problem was caused by the NMOS 6502 CPU, not by any difference in the ROM. But why?

 
STA (indirect),Y

Deep in the Yellowstone firmware for Smartport hard disk reads, you’ll find the instruction STA ($4B),Y. This instruction stores one byte from the disk into a user-supplied buffer, using a 16-bit buffer pointer stored at $4B-$4C plus an 8-bit offset from the Y register. For reasons of program efficiency, and using the Y register for two purposes at once, the code subtracts a fixed value from the $4B-$4C pointer and adds the same value to Y in order to compensate. For example if the buffer begins at $D000, then to store a byte at $D0F1, the code might use a Y value of $F9 and a $4B-$4C value of $CFF8. Queue the spooky foreboding music here.

On the 65C02, STA (indirect),Y requires five clock cycles to execute: two cycles to fetch the opcode and operand, two cycles to read two bytes in the 16-bit pointer, and one cycle to perform the write to the calculated address including the Y offset. All good. But for the NMOS 6502 the same instruction requires six clock cycles. During the extra clock cycle, which occurs after reading the 16-bit pointer but before doing the write, the CPU performs a useless and supposedly-harmless read from the unadjusted pointer address: $CFF8. This is simply a side-effect of how the CPU works, an implementation detail footnote, because this older version of the 6502 can’t read the pointer and apply the Y offset all in a single clock cycle. But it means that when Yellowstone reads a Smartport disk block into address $D000 using an NMOS 6502, it triggers a phantom read from $CFF8 and halts the CPU. That’s what was happening to Total Replay on the unenhanced Apple IIe.

 
Now What?

Peter suggested it would be possible to modify Total Replay to avoid loading blocks directly to $D000. I hope to save him that effort, and fix the root problem in the Yellowstone firmware instead, because other software may have the same problem when running on the NMOS 6502. I haven’t found another example yet, and standard software like DOS 3.3 and ProDOS appear to work OK. But there are probably other examples lurking out there somewhere.

How can the Yellowstone hardware tell the difference between an intentional read of $CFF8 and a phantom read? It can’t, not really. It just sees that $CFF8 appears on the address bus, the proper address decoding signals are asserted, and that’s the end of the story.

Fortunately Yellowstone is built around an FPGA, which creates the possibility for more complex address decoding behavior than would be possible with just a couple of discrete logic chips. My plan is to save information about what happened on the preceding bus cycles, and when $CFF8 appears on the address bus, use that extra information to help decide whether it was an intentional read. The details may be tricky but I think this approach should work. Meanwhile I’ll have more respect for the unintended consequences of phantom reads, and hopefully avoid making the same mistake again 13 years from now. Check back in 2035.