Dear readers, I need your advice on web hosting. For 22 years (yikes) I’ve lived on DreamHost’s Shared Unlimited plan, for which I currently pay $15.99 per month. DreamHost no longer offers Shared Unlimited to new customers, but legacy customers like me can keep it. True to its name, it really is unlimited: no limits on disk space, bandwidth, websites, databases, email accounts, or anything else countable. But it’s a no-frills service with a basic level of server performance.

After my recent server overhaul, I’ve been wondering if it’s time to change plans. I’m not interested in switching hosts, but DreamHost now offers a whole array of plans with names like Launch, Growth, DreamPress, Stack, and Managed VPS, and I’m confused about how they really differ. The product pages are full of bullet points like “40k Monthly Visits” and “WordPress-tuned server” that sound nice but don’t tell me anything concrete. How much server resources do I actually get? What happens when a bunch of people visit at once?

So I dug through DreamHost’s plan pages and help articles, trying to get past the marketing speak to a technical understanding of each plan. Here’s what I found.

My priorities, in order:

1. Easy server management. I don’t want to configure the server, patch it, or wonder whether it’s up to date. I’ve been burned by this before, and spent days digging myself out of the hole.
2. Performance. The site should be fast, and stay fast when a popular post gets linked from somewhere like Hacker News. Today’s performance is adequate from here in California, but it could be better, and I don’t know how it feels for readers in more distant places like the UK, Japan, or Australia.
3. Price. None of these plans are expensive compared to my other business costs, so price matters, but it’s third.

What “Shared” Actually Means

Shared hosting means my site lives on a single physical Linux server alongside hundreds of other customers’ sites, all drawing from the same pool of CPU, RAM, and disk I/O. To keep one customer from hogging the machine, a process monitor watches each user’s combined CPU and memory usage, and kills processes when it’s too high. That means a burst of simultaneous page requests can trip the limit even if each individual process is lightweight, and visitors will see a slow page or an error. DreamHost doesn’t publish the actual CPU and memory limits, but the Legacy Unlimited Policy is clear that these resources are capped.

This brings us to what may be the most important concept for understanding these plans: the difference between a limit and a guarantee.

• A limit is a ceiling: the most resources you can use before something stops you.
• A guarantee is a floor: the minimum resources always available to you, no matter what anyone else is doing.

Shared hosting has a limit, but no guarantee. In practice, this hasn’t caused me major problems, but I have seen occasional unexplained sluggishness and downtime.

Web Hosting Launch, Growth, Scale

These are DreamHost’s current shared hosting plans, which replaced Shared Unlimited. Prices are renewal rates for annual billing:

All three include unlimited bandwidth. Email is a paid add-on starting at $1.67/mo per mailbox.

There’s nothing in that table about CPU or RAM. Reading DreamHost’s Resource Allocation Policy, it sounds like these plans run on the same shared infrastructure as Shared Unlimited: a limit, no guarantee. So what do the monthly visits numbers mean? Does Scale get a higher CPU/RAM ceiling than Launch? Or is the visits number only used to decide who gets asked to upgrade? And do these plans provide better or worse performance than my current plan, which says nothing about visits? If anybody knows, I’d love to hear it.

As far as I can see, these plans are Shared Unlimited with limits added. They’re a bit cheaper, but won’t make server management any easier or the site any faster.

Do I Actually Need Unlimited?

Probably not. My DreamHost account hosts four websites:

• bigmessowires.com – this site, the big one.
• mactoberfestmeetup.org – a simple two-page WordPress site for the Mactoberfest Meetup classic Macintosh event, which I’m helping to host next month.
• runworks.com and stevechamberlin.com – old static content, nothing interactive.

Altogether that’s 4 websites, 1 subdomain, 4 databases, and 9 GB of disk space, nowhere near the limits of even the smallest Launch plan. Email is the only wrinkle, but only runworks.com uses DreamHost email, and very rarely. I could pay $1.67 a month to keep it, or live without it.

So the countable limits in the Web Hosting plans aren’t a problem for me. What I care about is performance, which the tables don’t spell out.

What Does “40,000 Monthly Visits” Actually Mean?

DreamHost’s resource policy defines monthly visits as “the number of unique visitors your site may receive per calendar month,” excluding bots and crawlers. The pricing page calls it an estimate of what your site can comfortably handle, and says they won’t cut you off if you go over. But elsewhere they say that if you consistently exceed it, you “may be required to upgrade to a higher tier.” It sounds like a soft limit enforced by a sales email.

Is 40,000 a lot? It’s about 1,300 visitors per day, or one per minute on average. Any modern server should handle that without breaking a sweat.

The problem is that traffic is spiky. What matters for performance is how many requests arrive at the same moment, like when 500 people click a link to a popular post within a few minutes. A monthly count tells you almost nothing about that. Both Web Hosting Launch and the much pricier DreamPress 1 are rated for 40K monthly visits, despite running on very different infrastructure. I conclude that “monthly visits” is a marketing label rather than a technical measurement, which still leaves me wondering how to choose a plan that’s sized for my needs.

So How Many Visitors Do I Have?

Even if it’s mostly marketing, the monthly visitor number decides which tier DreamHost thinks I belong in. I assumed BMOW was comfortably under 40K. It turns out I really have no idea.

DreamHost’s traffic stats reported 657,000 requests and 137,000 “unique requests” last month. Neither is a visitor count. I couldn’t find anywhere in the traffic data that shows the number that DreamHost would actually use to decide if I’m over my plan’s limit.

I went to the raw server logs for the last week and counted unique IP addresses, excluding anything that identified itself as a bot or feed reader. A typical day has about 4000. But I need to account for factors like regular visitors who access the site many times per month, devices that appear with multiple IP addresses, and bots that pretend to be ordinary browsers. My best guess is somewhere between 40K and 100K unique human visitors per month, attempting to follow DreamHost’s methodology, but I can’t measure it exactly how they do.

The logs also show why focusing on a monthly visitor number misses the point. After my server update post last week, traffic spiked to about six times normal for a day, which is over half of a 40K plan’s monthly allowance in one day. What I care about is whether the server keeps up on a day like that.

Virtual Private Servers: I’m Too Lazy for This

I looked briefly at DreamHost’s self-managed VPS plans. They probably win on performance per dollar, with guaranteed CPU and RAM for about what I pay now. But I’d be the sysadmin, responsible for OS updates, security patches, and server configuration. That’s exactly what I’m trying to avoid.

Managed VPS: An Interesting Middle Ground

Managed VPS is a VPS where DreamHost does the system administration. Prices are renewal rates after the initial promo period:

Here DreamHost would manage “security patches, Ubuntu OS updates, and PHP releases,” and I’d manage my site content. I’d get SSH but no root access. Websites, email, and bandwidth are unlimited with these plans, so all four of my sites could live on one Business plan. An Auto-Boost feature temporarily adds RAM during memory spikes. Server-side caching uses OPcache. I might need a WordPress page caching plugin.

This is the first plan with a published resource guarantee: 2 GB of RAM and 2 cores that are all mine at the lowest tier. So how much RAM and cores does my site actually need? Ummm… I don’t know.

One important footnote: Reading the fine print, with Managed VPS plans your MySQL databases still live on DreamHost’s shared database servers. Since WordPress is heavily database-driven, part of every page load would still depend on shared infrastructure with no guarantee.

DreamPress: Managed WordPress

DreamPress is DreamHost’s “managed WordPress” product. Prices are renewal rates for annual billing:

DreamPress’s limits may look stingy, but it has the richest set of extras: NGINX page caching, Redis object caching, and OPcache all preconfigured, plus a free CDN tier with 10 locations, one-click staging, daily and on-demand backups, SSH and WP-CLI, and WordPress-specialist support.

The one-click staging would have saved me a lot of grief during my recent site update, when I built the new site on a subdomain and copied database tables and swapped directories to cut over. Yes I know I could roll my own staging solution, but it’s more friction.

The caching could make a big difference for performance. With NGINX serving cached pages to anonymous visitors (nearly everybody), most requests would never touch PHP or MySQL. 500 people arriving in three minutes would become much less scary. I’m not sure how NGINX caching would compare to a WordPress caching plugin, but I have to believe it would be faster. And the CDN would also help those readers in the UK, Japan, and Australia.

As for resources, DreamHost’s policy says DreamPress runs on “an isolated, dedicated allocation of resources,” and the process monitor doesn’t apply. That sounds like a guarantee, but unlike Managed VPS, they don’t say exactly how much CPU or RAM it is for any tier. It’s a guarantee of… something.

There are a few drawbacks. DreamPress is WordPress-only, so my two static sites would have to live somewhere else. And in the DreamPress plan tiers, the number of sites rises in lockstep with the visitor estimate, so there’s no way to buy more visitor capacity without also buying more site slots. If I ended up needing DreamPress 2 or 3 for performance reasons, I’d be paying for extra site slots I didn’t really need.

Seekrit Hidden Information in the Pricing Page

But wait! Maybe those DreamPress performance guarantees aren’t unknown after all. As of today, if you view DreamHost’s Pricing & Plans Page, there’s a plan details data table hidden inside a script in the HTML. The data is never displayed on the page, but it’s there. To see it yourself, open the page, choose View Page Source, and search for “ramGb”. Here’s the relevant part of the table:

The table rows for Web Hosting Launch, Growth and Scale have no RAM or CPU fields at all.

What does this all mean? It’s very unlikely each DreamPress customer gets 16 GB and 12 cores. DreamPress 1 costs $19.99, while Managed VPS Premier costs $114.99 for 12 GB and 6 cores. Possibly 16/12 describes the server or container that DreamPress sites run on, not the slice dedicated specifically to you. Or maybe those values are just placeholders that nobody filled in properly.

Summary

2000 words later, here’s my attempt to compare the most likely choices:

All four meet my top priority, since DreamHost handles OS and security updates for each plan. The differences are performance guarantees, convenience extras, and price. Shared Unlimited and Growth are basically the same, with Growth slightly cheaper but arguably worse. Managed VPS gives hard CPU and RAM numbers and holds all four sites, but has few conveniences and a shared database. DreamPress has all the bells and whistles and a vague promise of dedicated resources, but only for WordPress.

The Leading Candidate: Divide It Up

I’m leaning towards dividing my account: bigmessowires.com on DreamPress, and the other three small sites on Web Hosting Launch. BMOW would get caching, CDN, staging, and dedicated resources. The small sites would sit on the cheapest plan, which is plenty for them. If my traffic requires DreamPress 2 or 3 anyway, mactoberfestmeetup.org could use one of the spare WordPress slots, leaving only the static sites on Launch.

The downside is cost. Here are the whole-account options, at renewal prices:

Depending on the DreamPress tier, splitting would increase my current bill by roughly 2x or more. That might be worth it for the performance and convenience, but I’d like to be sure I’m getting something meaningful for it. In particular, with my low-ish traffic site (if I’m reading the data correctly), I have a nagging worry that DreamPress might not provide any obvious performance difference over Shared Unlimited. Or could even be worse, in some cases.

What Would You Do?

If you were running these web sites, which plan would you pick? To review, I’m estimating the BMOW site gets 40,000 to 100,000 visitors per month, with spiky traffic patterns. It’s a WordPress blog with about a thousand posts and many thousands of images. The other sites receive negligible traffic. Total disk usage across all four sites is 9 GB. The BMOW store is hosted separately on Shopify, so there’s no e-commerce to worry about here.

Some specific questions I’m hoping someone can answer:

• How are this site’s page load speeds for you? Is it snappy, sluggish, or somewhere in between?
• Does DreamPress for BMOW plus Web Hosting Launch for everything else make sense? Or would Managed VPS Business be a better choice, with all four sites on one plan and a caching plugin?
• How can I estimate my monthly visitors the way DreamHost counts them? Given my numbers, is a 40K plan out of the question?
• Do the Web Hosting Launch/Growth/Scale plans get different CPU/RAM ceilings, or is it the same shared server with different disk quotas?
• What CPU and RAM resources does DreamPress actually provide? Is there even a fixed number, or does it not work that way?
• For a largely read-only blog like this, is DreamPress’s page cache what really matters, more than guaranteed resources? Could I get 90% of the benefit by staying on shared hosting with a caching plugin and a CDN like Cloudflare?
• Should my two static sites even be on DreamHost? Is it worth the hassles to move them to a static hosting service like GitHub Pages or Cloudflare Pages?
• Is there any other reason to keep a grandfathered “truly unlimited” plan, or will I regret giving it up?

Leave a comment below and let me know what you think!

The Big Mess o’ Wires website has a new foundation and updated look for 2026, cleaning out the cruft and junk. It’s a familiar story. Over the years, the site accumulated loads of customizations that tended to complicate updates. One day in 2016 an update broke the site. Lacking the energy to troubleshoot the problem, I simply turned off updates and never turned them back on. Eventually the version of PHP that I was using reached end of life, but it couldn’t be updated without causing breakages either. For the past four years, I’ve paid a monthly fee for extended maintenance of my obsolete configuration.

Being frozen in time with a 10-year-old technology stack would be bad enough, but it was actually worse than that. The theme I was using, which determines the visual appearance of the site, was 21 years old! I could never update it, because I’d directly edited many of its files for reasons I’m sure were excellent but which I could never remember later. It was a similar story with several other key plugins. So there I was, stuck with a 2005-2007 infrastructure that wasn’t surviving very well in 2026.

I finally decided it was time to take action, backing up the whole site to my laptop and getting it running locally in a 5 GB container. This afforded me the time and space I needed to upgrade pieces of the infrastructure and break things temporarily while I worked. The trickiest part was getting it all back onto the server again, and cutting over quickly and cleanly from the old version to the new one. The whole process took me about 10 days of on-and-off work.

Core Platform

• Updated from WordPress 4.7.22 to 7.1.3, and PHP 7.4 to 8.4. Paid legacy-PHP support is no longer needed!
• Lots of code that would crash under WordPress 7 or PHP 8 was removed or replaced.
• The database also moved to InnoDB, MySQL’s newer table format.
• Everything is https across the board now. Http redirects to https.

Database Character Set

• Somehow the old database contained latin1 tables that actually held UTF-8 text, which caused a number of odd problems I’ve written about before. Depending on the age of the data, some text was doubly-encoded.
• I used a script to examine and fix all of the database text as individually needed, instead of a blanket conversion.
• Characters outside latin1 now work consistently. Posts and comments can contain äcçéntêd letters, Japanese 日本語のテキスト text, even 😆💩🦋emojis.
• I also fixed over 1000 instances where the HTML non-breaking space entity   had been converted into Unicode character C2A0 (non-breaking space) and stored that way in the database, causing confusion and layout problems.

Plugins

• Removed a cacheing plugin that was disabled anyway, a backup plugin that had silently stopped working five years prior, a security plugin of questionable value, a plugin that was supposed to magically turn my desktop theme into a mobile theme, and many others.
• Found and configured new plugins for anti-spam, comment subscriptions, image format conversion, and link redirection.
• Created a few small plugins to modify my new theme’s behavior, instead of modifying any theme files directly. These were mostly related to the appearance and behavior of the comment sections, but also the “Most Discussed” sidebar widget you see here.

Cleanup

• Large amounts of spam and trash comments and leftover junk was deleted from the database, shrinking it by a third.
• Deleted more than 50 installed but unused themes.
• Removed old backups and other files accidentally left on the server years ago.
• Removed all remaining traces of the old WooCommerce store at bigmessowires.com/shop. Since 2021, the store has been powered by Shopify and lives at shop.bigmessowires.com.
• Removed some unused jQuery and Google Analytics code that was appearing on many pages.

Things That Were Broken On The Old Site

• Fixed several dozen photos in old posts that were appearing sideways or upside down, due to changes over the years in the way browsers handle rotation metadata in images.
• Repaired large numbers of embedded YouTube videos that weren’t working because of http vs https issues in the YouTube link.
• Fixed many links that were typos or that didn’t work due to capitalization differences.
• Reviewed about 100 dead links, replacing many of them with links to the Internet Archive.

Content, Look, and Speed

• All images in posts and pages now have width and height attributes, so pages no longer jump around while loading.
• Set featured images for most posts going back to 2007, used for the cards on the home page.
• Changed the Archives widget to only show links for each year, instead of a separate link for each of the ~240 months in the blog’s history.
• Addressed issues with past comments, like commenter names that were a space character rather than an empty string, and replies to comments that no longer existed.
• Adopted a new modern and responsive theme, but with fSpring’s colors and feel. New home page card design, a new top banner, reworked sidebar, new numbered page UI for post listings and pages with over 50 comments.
• The mobile version of the site now looks completely different than before, and more like the desktop version.
• Implemented many page loading speedups: WebP images, lazy loading of images, delayed loading of the YouTube player until it’s actually clicked, fewer scripts. To view a typical page, it now requires only about a third of the data download that it used to.

Accessibility

• This was an important one! For the last several years, a few unscrupulous law firms have been filing thousands of nuisance lawsuits related to ADA accessibility issues against small web site operators.
• Rather than a genuine problem report from a site visitor looking for help, these are straight-up cash grabs where the law firms hope the site operators will agree to pay a 5 or 6-figure settlement rather than take a risk in court, since fixing issues after the fact doesn’t necessarily absolve liability.
• Prior to the server update, a popular accessibility checker tool crawled the BMOW site and flagged thousands of issues. With the updated site, it finds zero.
• Meaningful “alt” tag text was added to over 1500 images, for use by screen-reader software.
• All tables now have properly-tagged headers.
• All content headings such as “Accessibility” above now use structural tags like <h2> and <h3> rather than relying solely on font size and weight to convey their purpose.
• Closely-spaced links and buttons are now spaced further apart, as WCAG rules require.
• UI colors were adjusted to maintain a minimum contrast level between text and background.
• The site can be navigated with the keyboard and tab items.
• Hidden labels and names that are only used by screen readers were added to many UI items.
• Added an Accessibility statement page.

Preventing Mistakes

• To avoid the risk of breaking something subtle that wouldn’t be noticed until later, the entire site was crawled and logged before beginning work. After making changes, the work-in-progress site was then crawled again to confirm that the only changes were the intended ones.
• Rather than making ad-hoc edits to the server data and files, the update was constructed as a series of about 50 scripts that operated on a local copy of files, each script responsible for applying one specific update or change. The scripts could be re-run from the original server dump at any time.
• Because my web host lacks any real sandboxing or versioning capability, the finished site was deployed to a subdomain for live testing. The cut-over was achieved by renaming and swapping the server root directories of the subdomain and main domain.

For three years, the ADB-USB Wombat firmware sat quietly at version 0.3.9. Everything worked well for most people, most of the time, but the key word in that sentence is “most”. My customer support inbox had many stories describing specific models of keyboards that didn’t type, mice that didn’t move, and KVMs that didn’t cooperate. Too many of those stories ended with an unsatisfying “sorry, that device isn’t compatible.” Most of it seemed to be due to limitations of Microchip’s USB stack code, which I didn’t write and don’t understand well.

This fall, with the help of fancy new AI coding tools, I decided to work through that whole list of issues. Between late September and early October, the firmware went through eleven releases, from 0.3.11 to 3.21. Most of them never received any public announcement or release, so everything in 0.3.11 to 3.21 is effectively one giant update. If you have a Wombat, it’s time to update your firmware!

About the version numbers: Yes, it jumped from 0.3.16 to 3.17. I decided to ditch the leading zero, which served no practical purpose.

Greatly Improved USB Device Compatibility

This was the biggest problem, and it had many causes. The first one was a basic byte/word size discrepancy in the USB stack code. When the Wombat fetched a USB device’s HID report descriptor, the code stored the length of the descriptor in an 8-bit variable. Later it checked that value against the expected length, a 16-bit variable. Any descriptor longer than 255 bytes got its length truncated, the length check failed, and device enumeration silently stopped. No keyboard, no mouse, nothing. Simple USB devices have small descriptors, but anything with complex features or lots of buttons can easily exceed 255 bytes. The Logitech Bolt receiver’s touchpad interface alone has a 429-byte descriptor. After fixing this bug, a huge number of devices that had never worked with the Wombat suddenly did.

To fix more compatibility bugs, I realized that my biggest limitation was testing. I could go broke buying hundreds of keyboards and mice and plugging them into the Wombat to see how they were handled. Then I realized that compatibility issues were almost always related to the USB report descriptor, and if I had the descriptor, I could “virtually” test a device against the Wombat without having a physical sample. So I put together a corpus of descriptors from about 200 devices, common ones and weird ones, harvested from forums and bug trackers all over the web. I created a simulator to test how the Wombat handled enumerating and processing sample reports from each device. This proved to be super useful and revealed all sorts of additional Wombat issues.

One big issue uncovered by the corpus testing was keyboards that report their keys as a bitmap instead of as a traditional array of pressed keys. This is common on gaming keyboards that support N-key rollover. The old firmware decoded those bitmaps as if they were key arrays, with entertaining results: on one keyboard tested, pressing the space bar consistently typed the letter “m”. Bitmap keyboards are now fully supported, including keyboards that send both formats on the same interface.

Then there were keyboards running QMK, VIA, Keychron, and Keyboardio firmware, which need to be explicitly asked to switch to the simpler “boot protocol” mode, gaming keyboards that split their keys across several separate USB interfaces (Logitech G810 and some Razer models), gaming mice and KVM switches whose buttons and scroll wheels were ignored by the Wombat, devices that combine a keyboard and mouse in one, and the Apple Magic Keyboard, which misbehaved after pressing Caps Lock because of a bug in how the Wombat sent keyboard LED updates.

Multiple Simultaneous Keyboards and Mice

A notable limitation of the old firmware was that it managed exactly one keyboard and one mouse. If you plugged in more, all but one of them would be ignored, and it wasn’t easy to predict which one would actually work. That caused a lot of confusion, especially because some gaming mice also pretend to be keyboards for their macro buttons, and some keyboards also pretend to be mice. This meant that a real keyboard could end up being ignored because the Wombat was managing the mouse’s macro button keyboard instead.

Now every attached USB keyboard and mouse works at the same time. Keys from all keyboards are combined, mouse movements are added together, and buttons from all mice are merged. It all just works.

To accomplish this, it required more than just code changes to poll additional USB devices and combine their reports. The PIC microcontroller struggled to manage polling and processing of up to 8 USB devices at once while also responding to ADB commands fast enough to meet the timing requirements. I created a special measurement build of the Wombat firmware to capture timing and profiling data, testing it on an Apple IIgs and all of my Macs to find the most challenging environment. The most demanding was the Mac IIci, which fires about 244 ADB commands per second in bursts during startup, with only about 500 microseconds between them. After optimizing the code and carefully reviewing interrupt priorities, the Wombat is now able to handle the heavier USB load while simultaneously processing high-frequency ADB commands, no matter how many devices are attached.

In ADB-to-USB mode, the Wombat now supports up to two ADB keyboards and two ADB mice at the same time, like an Apple Extended Keyboard plus a separate numeric keypad, or a keyboard, a trackball, and a mouse in one daisy chain. ADB devices can also now be plugged in and unplugged while the Wombat is running.

A Real Preferences Menu

The Wombat has no display screen and no buttons except a power key, so how do you configure its settings? Previously the answer was a collection of ugly tricks. Depending on the setting, you might short-click or long-click the mouse wheel, press a magic key combination, or change an option that was incongruously included in the key mapping table. Nobody remembered any of these methods, including me. Only one of these settings was actually preserved when power was turned off, so the rest had to be reconfigured every time.

Now the Wombat has a real preferences menu! Open a text editor or go to the BASIC prompt, press Control-Shift-Capslock-P, and the Wombat “types” a menu into your document:

BMOW Wombat ver 3.21 preferences
1 Keyboard layout is US
2 Mouse speed is 3 of 6
3 Right button is CTRL LEFT CLICK
4 Scroll wheel arrow keys are ON
0 Restore defaults
1234 change, RETURN save, ESC cancel

Press a number key to change a setting. Settings are saved in the Wombat’s flash memory, and survive power-off and firmware updates.

To correctly support this method of virtual typing for menus, the Apple IIgs needed some special love. In GS/OS, the IIgs couldn’t keep up with the speed of the Wombat’s virtual typing. Longer messages apparently overflowed a keyboard buffer in the OS and came out garbled. I didn’t want to slow down the text output for everybody, though, so I developed a way to fingerprint the host computer and detect when it’s a IIgs running GS/OS, based upon the rate of ADB commands received and the mix of commands. That enabled me to slow down the text for GS/OS only.

At the IIgs BASIC prompt, every line of menu text ended in a Return keypress, so BASIC tried to interpret it as a code statement and replied with ?SYNTAX ERROR to each line. That was super annoying, so I developed another fingerprinting technique to detect when the host computer is a IIgs running BASIC. When in BASIC, the Wombat now ends each line of text with Control-X instead of Return, which cancels the line instead of running it.

No Stone Left Unturned

Beyond those three big changes, there was a long list of other fixes and improvements:

• Stuck and lost keys – Several bugs that caused keys to get stuck down, go missing, or arrive in the wrong order are fixed, in both directions.
• Caps Lock – At least half a dozen separate bugs caused the Wombat, the keyboard, and the computer to disagree about whether Caps Lock was on. Caps Lock is now in sync everywhere, including the latching Caps Lock key on Apple Extended Keyboards.
• Startup key combinations – Combinations held down during startup or reset now work reliably: Control-Apple-Reset and the self-test on the Apple IIgs, Command-Option-P-R to reset a Mac’s PRAM, Command-Option-O-F for Open Firmware, and others.
• Screensavers and sleep – In ADB-to-USB mode on a modern computer, the Wombat no longer prevents the computer from going to sleep or starting its screensaver.
• Boot prompts – The Wombat now works correctly in environments that poll the keyboard but never poll the mouse, like the Linux disk encryption password prompt and some BIOS screens.
• ADB devices – Kensington Turbo Mouse 4.0 and 5.0 trackballs work better, and the right button of MacAlly 2-button mice now works.
• USB hubs – The Wombat supports up to 8 hub ports in total, and older firmware crashed if you exceeded that. It now ignores the extra ports, and the -I help command tells you how many were ignored.

Weird Bugs

A few of the bugs that I found were especially interesting.

The hourly screw-up – A few customers had reported problems that occurred regularly after about an hour of Wombat use. One person even told me that after 30-60 minutes of use, their mouse started typing keys on their Mac. I must admit I didn’t give these reports much weight, and thought it must be a coincidence or caused by something else. Ha ha. The actual cause was the Wombat’s microsecond timer, a 32-bit counter. 2^32 microseconds sounds like a long time, but it’s actually only about 72 minutes. When the counter wrapped around, a time comparison in the firmware went wrong and the Wombat thought the Mac had sent an ADB reset. This reset all the ADB devices and a bunch of related state data, without properly reinitializing it again. Chaos ensued.

Intermittent failures – In one of my tests, the USB keyboard occasionally didn’t work after power-up, but I couldn’t figure out why. After much digging, the cause turned out to be the Microchip USB stack’s internal event queue. It held only four events, and when it was full, it silently threw away new events. Because nobody will ever experience more than four USB events before they can respond to them, right? If an event related to enumerating a newly-attached device was lost, that device got stuck waiting forever. A deeper queue plus a timeout fixed this.

Microchip Tools and Automated Testing

Years back when I originally selected the PIC32 for the Wombat, a BMOW reader warned me against it. Not for any hardware reason, but because he said the Microchip tools made him angry. I can now appreciate why.

Virtually every time I return to Wombat development after an extended break, I find that some Windows update or who-knows-what has caused my PICkit 3 programmer to stop working. Again, and again. This time was no exception. Was it a Windows 11 thing? Java update? A USB driver issue? It didn’t help that Microchip themselves discouraged people from buying the PICkit even when it was an active product, and it’s since been discontinued.

I’d been carefully avoiding updating MPLAB X, the Microchip IDE, because it had been such a pain to get configured the first time. But in an attempt to solve my PICkit woes, I finally bit the bullet and updated my 2017 installation of MPLAB X 3.61 to a shiny new MPLAB X 6.20, the most recent version still with PICkit support. I was pleasantly surprised to discover that I could use the 6.20 GUI and debugging tools, but keep the compiler and toolchain from 3.61, so a painful project reconfiguration wasn’t needed. That mostly resolved my PICkit issues, although I’ve still had some mysterious failure episodes where I needed to unplug everything and plug it in again.

Once I had the PICkit mostly working, and attached a serial cable to read the Wombat’s debug output, it opened up some very cool opportunities for automated testing. My AI coding tool created scripts that would flash a new firmware version to the Wombat, run it, look at the serial log output to collect data on timing and USB events, then apply fixes to the firmware based upon the collected data, compile and flash the new firmware, and try again. It modified, tested, and fixed itself in a repeating dev cycle while I sat there drinking beer and watching it work, nodding my head. Impressive stuff.

The Wombat is great for adapting USB keyboards and mice to classic ADB Macintoshes, and ADB keyboards and mice to modern USB computers. But what about game controllers? They’re not supported. It’s an often-requested feature, but one that’s not as easy to implement as it might seem. The main problem is that unlike keyboards and mice, there doesn’t exist any uniform standard for communicating with game controllers: neither for ADB nor for USB.

In the past when people have asked about game controller support, it’s not always clear if they’re asking to use USB game controllers via the Wombat on a vintage Mac, or if they’re asking to use classic ADB game controllers like those from Gravis via the Wombat on a modern PC. From reviewing the comments and emails I’ve received, I think interest is roughly evenly split between USB-to-ADB and ADB-to-USB game controller support.

I’m using the term “game controller” here to include both joysticks (typically analog) as well as gamepads (typically a collection of buttons with digital on/off status). The challenges involved in both are similar, but the details differ.

USB-to-ADB Game Controller Implementation

Of the two possible directions for adapting game controller communications, this is probably the easier one: connecting USB game controllers via the Wombat to play classic games on a vintage Macintosh. For the moment, let’s limit our thinking to just gamepads with digital buttons. A simple way to implement basic support might be to program the Wombat to make gamepads appear like a keyboard to the Mac, with a fixed key map. For example the D-pad buttons could send arrow key press events, ABXY could literally type A, B, X and Y, and the Select button, Start, and shoulder buttons would send other keyboard key events.

This may be doable, but there are some difficulties. The main issue is that as far as I understand, there’s no true standard way for USB game controllers to communicate their state to a USB host. Some use DirectInput, some use XInput, some use regular USB HID as if they were a standard keyboard or mouse. The Wombat would probably need to support all of these methods, and somehow determine which one to use. DirectInput and XInput differ from regular USB HID, and supporting those input methods would require developing a new feature for the Wombat firmware.

The other big challenge is that apparently there’s no standard order in which USB game controllers report the state of their buttons. One might report its D-pad as buttons 0 through 3, another as buttons 2-5, another as buttons 6-9. That would seem to prevent the Wombat from using any kind of fixed button-to-key mapping, like automatically treating the D-pad buttons as arrow keys, because it wouldn’t know which are the D-pad buttons.

Maybe the games themselves could be configured in their preference settings to expect directional movement input from a weird key combination like X/1/B/A, but I don’t know if all games are that flexible. Probably some are hard-coded to expect arrow keys for movement and space bar to jump or shoot. Users would also probably be confused or frustrated if the behavior and default button-to-key mapping were different depending on the exact brand of USB gamepad they used, seeing different behavior from nearly identical-looking gamepads.

It would be better to include a configuration / mapping layer somewhere, but where? The Wombat lacks any UI of its own, and isn’t suited to that task. Maybe a text configuration file could be loaded from a USB thumb drive. It seems clunky, though.

The USB gamepad wouldn’t necessarily need to appear as a standard keyboard to the ADB Macintosh. Another option could be to make it appear as if a Gravis gamepad were present. This would also require installing the Gravis control panel on the Mac. Fortunately the Gravis ADB protocols have been documented by Tashtari, so it is technically possible, but I’m not sure it would really solve any problems. If the Wombat doesn’t know whether USB gamepad button 1 is D-pad right or the Start button, then it can’t do a sensible job of emulating a Gravis gamepad, no matter how the Gravis control panel is set up. Ultimately I’m not sure that emulating a Gravis device would provide any clear benefit over emulating a keyboard and/or mouse.

Maybe the situation isn’t as bad as I fear, and in practice USB game controllers are more consistent than I think? I could buy a sample set of the 5 or 10 most common or most popular USB game controllers, and analyze how they work. But that could be expensive and time-consuming.

As for joysticks, I know a lot less about how they work, both on the ADB and USB side. According to one report, typical ADB joysticks behave like a mouse+keyboard to the Macintosh, where the “cursor” snaps back the same distance it traveled in the axis when pressure is no longer applied to the stick, and the buttons get mapped to keyboard buttons. I’d probably need to purchase some ADB joysticks to experiment with, to confirm their behaviors and see if there are differences across models and brands.

ADB-to-USB Game Controller Implementation

I’ve thought much less about this direction. To me, it seems the less compelling of the two. There are real reasons to want USB-to-ADB game controller support: you want to play a classic game on your classic Mac, but classic ADB game controllers are very hard to find. A USB game controller plus the Wombat could then serve as a substitute. The purpose of ADB-to-USB game controller support would be more for nostalgia or for laughs maybe. Yeah you could use your ADB Gravis Mousestick II to play a modern game on your Windows machine, but it’s a little silly when you probably already have a perfectly good USB joystick, or can purchase one for a few dollars.

Putting aside the question of rationale, Gravis protocol support would be a must for ADB-to-USB game controller support. All of the most popular ADB game controllers were made by Gravis, so the Wombat definitely would need to know how to talk to them. Translating the input from the Gravis controller and emulating a USB game controller or joystick might be simpler than the reverse task, because I could probably just choose one of the three common interfaces (DirectInput, XInput, USB HID) instead of needing to support all three. And I wouldn’t need to worry about non-standard button mappings, since I’d only need one mapping, and could just copy the mapping from any popular USB game controller. I think.

As you can see, this is all about as clear as mud, and maybe it gives you more appreciation for why game controllers have remained unsupported by the Wombat. It’s just not a straightforward task, and there’s no obvious “best” solution. I’m sharing my thoughts here and looking for your feedback on all of this. Which direction of game controller emulation would be most valuable to you? How would you imagine it working, exactly? Have I overlooked or misunderstood anything important about the implementation details? Do you have any experience with USB game controllers and how they typically work, how they select between the various communication protocols and so on? If you all can help me sketch out a plan that makes sense here, I’ll try to implement it.

Mea culpa time here. Since the beginnings of the Wombat there have been reports that certain USB keyboards and mice weren’t recognized by the device. Nothing happened when typing or moving the mouse, and the Wombat’s activity LED didn’t blink. The affected devices were usually fancier keyboards and mice with lots of buttons and features, as opposed to plain vanilla $8 two-button mice and generic 101-key keyboards. I had always chalked this up to some unknown issue in the Microchip USB stack code for handling of peripherals with multiple USB interfaces or a single interface with multiple types of data. It was something in the bowels of that code, which I didn’t write and didn’t understand too well, so I treated it as a regrettable known incompatibility.

Recently a few Wombat customers reported more problems like these related to the Logitech Bolt USB receiver, and I decided to take another look. One helpful customer sent me a dump of the Bolt’s USB HID report descriptor as reported by Linux. I dug through the code with the help of AI, attempting to analyze how the USB stack would handle this report descriptor. It looked hopeless, until…

After wading through thousands of lines of mind-numbing USB goo, I found the smoking gun. Upon completing a USB transfer, the code was storing the number of bytes transferred in an 8-bit local variable and then comparing it to the 16-bit expected transfer size. The result was that any transfer larger than 255 bytes would always fail! Please queue the laugh track and sad trombone sound effects.

What does this have to do with composite USB devices? Nothing, except that composite USB devices have more interfaces with more data to report, resulting in larger report descriptors that are more likely to exceed 255 bytes.

Firmware 0.3.11 was released yesterday to fix this bug. It’s not just something relevant to the Logitech Bolt. If you’ve been using the Wombat in USB-to-ADB mode and encountered certain keyboards or mice that just mysteriously didn’t work with the Wombat, please try the new firmware. There’s a good chance that this will fix it.

Nobody enjoys troubleshooting non-working hardware, and I’m no exception. Every time I ask a contract manufacturer to assemble a batch of more Floppy Emus, there are always a few that don’t pass QA testing. What happens with those? For several years the accumulating QA failures have been sitting in a pile in the corner of my office, along with a few customer returns, all waiting for the day when I would dedicate time to their investigation. It was a long time coming, but “Failure Analysis Day” finally arrived, or more like Failure Analysis Month, and the results were pretty interesting.

Here’s a breakdown of the unique causes of failure that I identified, and the number of boards affected by each cause.

 
Clock Crystal

This was a strange failure that required a lot of time to track down initially, but once I learned to recognize the symptoms, I realized that most of my QA failures were due to this problem. I wrote about the clock crystal mysteries in more detail in a separate post last month. The short story is that during my most recent manufacturing batch, my normal supplier of clock crystals was out of stock. The contract manufacturer, with my approval, substituted a different crystal with the same specs. It shouldn’t have affected anything. But somehow it did.

26 of the QA failures appeared to have no functioning clock at all. The board utterly failed to do anything when the microcontroller clock source was changed to the external crystal. A further 16 displayed some level of function, but with erratic behavior or failures at higher clock speeds. Initially I wasn’t sure whether this was due to the newer crystals exposing some defect or fragility in the Floppy Emu design, or whether it was simply caused by defective or damaged crystals. Eventually I came to the opinion that the crystals were damaged by rough handling or overheating during assembly. Replacing the crystals and reprogramming the boards resolved all the issues.

 
CPLD Chip

The Xilinx CPLD chip on the Floppy Emu is a delicate flower that has long been a source of challenges. Prior to this year’s crystal-gate debacle, the CPLD was the single biggest source of failures that I’d observed. As the chip that’s directly connected to the Floppy Emu’s external interface, it bares the brunt of any static discharge or electrical stress. It’s a 5V-tolerant 3.3V part, but its 5V tolerance has sometimes seemed a bit questionable, at least in the way it’s used here.

Symptoms of a failed or bad CPLD can include disk emulation failures, overheating, or erratic behavior. Usually the device will still be functional and text appears on its display, but the disk features no longer work. In extreme cases the failed CPLD acts as a hard short-circuit from power to ground, and then nothing works. Replacing and reprogramming the CPLD resolved all of the problems with these boards.

 
Microcontroller not programmed

Amusingly, or depressingly depending on your perspective, the third leading cause of QA failures was that the microcontroller simply wasn’t programmed. Somebody fell asleep at the switch at the contract manufacturer, lost track of what they were doing, put a PCB in the wrong pile, or whatever. A board with an unprogrammed microcontroller will appear completely dead at first glance, but it still responds in the debugger and it only takes a few seconds to flash the chip and get everything working.

 
Soldering problems

Every component must be electrically bonded to the PCB with solder. Soldering problems can be tough to spot with the naked eye, but usually jump out under magnification, so one of my first troubleshooting steps is usually to look at a problematic board at 10x. I really should get a cool desktop microscope, but for the moment I’m using a cheap 10x jeweler’s loupe which works well enough.

A couple of boards had too much solder in places, resulting in a solder bridge that unintentionally connected two adjacent IC pins. But it was more common to find joints with insufficient solder or poor solder joints, where an IC pin was sort of resting on the PCB pad without actually bonding to it. Fortunately both problems were easy to fix with a soldering iron and a bit of flux.

 
Bad microcontroller chip

The onboard microcontroller trip is another potential source of failure. In my experience, these microcontrollers are pretty robust, and the only failures I have seen are caused in the field when customers accidentally connect the Floppy Emu cable backwards to their Apple II Disk II controller. This is distressingly easy to do, since the Disk II controller has bare pin connectors instead of a shrouded and keyed header. A backwards connection results in +12 and -12 volts applied to the mcu’s pins, killing it.

Unfortunately the symptoms of a bad microcontroller are nearly identical to the symptoms of a bad clock crystal: a completely unresponsive board, with no debugger activity. I had to review each non-responsive board’s history in order to guess which issue was at fault. In some cases I guessed wrong, and I ended up replacing the microcontroller, and then when that didn’t help, also replacing the clock crystal.

 
Other

The remaining issues were all one-offs. One board’s display header was physically broken and missing a pin, resulting in a blank display. Another board failed QA because the LED didn’t illuminate, except there was no LED! There was only a blank pad on the PCB. I also encountered a failure due to a PCB that was physically cracked, a long line running down the breadth of the PCB that could only be seen clearly under light from a specific angle. Two more boards defied my efforts to pinpoint the cause of their failures, and after spending too much time on them, I threw them into the scrap bin.

The very last board that I examined turned out to have no problems at all. I tested it extensively and it worked perfectly. This might have failed QA due to something external like a bad power supply or cable, or maybe it was simply miscategorized.

 
Final results

Of 68 Floppy Emus in the failure analysis heap, I managed to resuscitate 65 of them. That’s a pretty solid percentage! I learned to recognize the symptoms of certain failure causes, so I can address them faster if I see them again. More importantly, the failure analysis learnings (especially about clock crystals) will also help guide me in making design and assembly process changes, so I can reduce the number of future QA failures. Knowledge is power, as they say, and now I have lots of power.