Auction of ESP32 and Pi Pico Kits, iFixit Gear, Computer History Museum Private Tour, and More Mactoberfest Meetup 2026 is almost upon us! Our sponsors iFixit and Elecrow have donated some cool items that we’re auctioning to help pay for the costs of running this event: electronics and hardware toolkits from iFixit a private guided tour of the Computer History Museum Raspberry Pi Pico and ESP32 and Lego project kits You can likely get this stuff for cheap. The bidding is open now, and will continue through the end of the meetup on Saturday, so winners can pick up their items on-site at the conclusion of the event. Check out the available items or place a bid at the auction web site. Mactoberfest Meetup is a friendly and collaborative convention for classic Macintosh enthusiasts, happening November 7 in Belmont, California. We’re planning to welcome 30 exhibitors and over 100 total guests on Saturday. I hope to see you there! https://www.bigmessowires.com/2026/11/03/auction-of-esp32-and-pi-pico-kits-ifixit-gear-computer-history-museum-private-tour-and-more/ #rss #feeds #linksharing #qwibbit

Wombat Game Controller Beta – Call for Testers ADB-USB Wombat firmware 3.22 beta 2 introduces preliminary support for USB game controllers. Please give it a try and let me know: Does this make sense? Does it feel good? I’m especially interested in feedback on the way the firmware controls the mouse with the game controller’s stick. In this beta version, USB game controller buttons and sticks are converted into ADB keyboard keys and mouse movements. Three fixed controller profiles are provided: ARROWS, WASD, and FLIGHT. ARROWSWASDFLIGHTShortcutBack + D-pad upBack + D-pad rightBack + D-pad downD-pad upUp arrowW=D-pad downDown arrowS–D-pad leftLeft arrowAShift-ZD-pad rightRight arrowDShift-XLeft sticksame as D-padsame as D-padsame as D-padRight stickrelative pointerrelative pointerauto-center pointerR3 (stick click)switch pointer modeswitch pointer modeswitch pointer modeASpaceSpaceSpaceBShiftShiftShiftXWEFYRQGLBmouse clickmouse clickmouse clickRBCommandCommandALTslow pointer movementslow pointer movementslow pointer movementRTTabTabTabStartEscEscEsc With this firmware, you need to choose the profile whose mappings are most similar to the game you want to play, and then change the game’s control preferences to match the keys that the profile uses. The existing profiles map directly to Prince of Persia, Dark Castle, and Hellcats Over the Pacific, but other games can be adapted to match them too. In later firmware versions I hope to add a custom profile, with a learning mode where you can choose the mapping between each controller button and keyboard keys. Even later, I may add support for Gravis Gamepad and MouseStick II emulation so that this configuration step can be done in the Gravis control panel instead of the Wombat. What USB Game Controllers are Supported? In theory any USB game controller should work, in either X-Input or Direct Input mode. However, the only game controller that I’ve directly tested is the Logitech F310. If one of your USB game controllers doesn’t play nicely with this firmware, fear not. I have created a special web page for collecting technical information on your game controllers. Please plug the offending controller into your PC or Mac, launch Chrome or Edge (Firefox and Safari won’t work for this), and visit the web page https://www.bigmessowires.com/rusb/wombat-controller-test.html. Follow the instructions on the page to capture some controller data and generate a log file that you can send to me. How do you Control a Mouse with a Game Stick? Each of the three profiles supports some type of mouse control via the game controller’s right stick. It may seem obvious and simple to convert stick inputs into mouse movements, but it definitely is not. The stick is an absolute positioning device whereas a mouse provides only relative movement data. The stick also has a tiny range of movement, compared to a mouse which can range over the whole surface of your deck. One common approach is to use the stick to push the mouse pointer around the screen. If the stick is moved slightly to the left of center and held there, the mouse pointer will begin to move left, and will continue moving left for as long as the stick is maintained in the same position. Pushing the stick further to the left increases the movement speed. Holding the left trigger will slow down the mouse movement, making it easier to execute small precise motions. Releasing the stick and letting it return to its center position will cause the pointer to stop moving, remaining in whatever part of the screen where it landed. The Wombat docs call this relative pointer mode, and it works well for most games. But the details are complex. Is there a dead zone? Is there a linear relationship between stick displacement and mouse speed, or is it a curve? What kind of curve? What are the minimum and maximum speeds? I spent a long time tuning this in a handful of classic Mac games. The subjective feel of it will depend on the Mac’s Mouse control panel settings, as well as the pointer speed setting in the Wombat preferences menu. Another approach is to set the mouse pointer location on screen to match the stick position. Push the stick left, and the pointer jumps to the left of the screen. Maintain the stick in the same position, and the pointer does not move further. Releasing the stick and letting it return to its center position will cause the pointer to jump back to the middle of the screen. The Wombat docs call this auto-center pointer mode, and it works well for flight simulators and games that use the mouse for aiming. But because the Mac doesn’t natively support absolute pointing devices, auto-center pointer mode is inherently fragile. It requires the Mac’s Mouse control panel speed to be set to Tablet / Slowest. It also depends on the initial mouse pointer location and your screen resolution, because if the mouse hits the edge of the screen, the auto-centering can’t work correctly. The current implementation is tuned for a 640×480 screen. In any profile, you can press R3 to toggle between relative pointer and auto-center pointer modes. Auto-center is the default for the FLIGHT profile, and the others default to relative mode. https://www.bigmessowires.com/2026/10/22/wombat-game-controller-beta-call-for-testers/ #rss #feeds #linksharing #qwibbit

Help Me Choose a Web Hosting Plan: Decoding the Marketing Speak 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: 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. 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. 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: Launch Growth Scale Price/mo $10.99 $12.99 $25.99 Websites 25 50 100 Storage 25 GB 50 GB 100 GB MySQL databases 25 50 300 Monthly visits 40K 200K 400K 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: Business Professional Enterprise Premier Price/mo $24.99 $46.99 $92.99 $114.99 CPU cores 2 2 4 6 RAM 2 GB 4 GB 8 GB 12 GB Storage 60 GB 120 GB 240 GB 360 GB 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 1 DreamPress 2 DreamPress 3 DreamPress 5 Price/mo $19.99 $24.99 $28.99 $40.99 Websites 1 2 3 5 Storage 15 GB 25 GB 30 GB 50 GB Monthly visits 40K 80K 125K 175K Backup retention 14 days 14 days 14 days 30 days 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: Plan RAM (GB) CPU cores Storage (GB) Monthly visits Websites DreamPress 1 16 12 15 40K 1 DreamPress 2 16 12 25 80K 2 DreamPress 3 16 12 30 125K 3 DreamPress 5 16 12 50 175K 5 DreamPress 10 16 12 100 350K 10 DreamPress 20 16 12 200 700K 20 Managed VPS Business 2 2 60 — — Managed VPS Premier 12 6 360 — — 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: Shared Unlimited (current) Web Hosting Growth Managed VPS Business DreamPress Price/mo (renewal) $15.99 $12.99 $24.99 $19.99 – $28.99 Storage Unlimited 50 GB 60 GB 15 – 30 GB Monthly visitors N/A 200K N/A 40K – 125K CPU/RAM guarantee None None 2 cores, 2 GB Yes, size unknown CPU/RAM limit Undisclosed Undisclosed Plan size + Auto-Boost Unknown Server-side caching None built-in None built-in OPcache only NGINX + Redis + OPcache CDN No No No Bunny CDN included Staging No No No One-click Backups 3 file snapshots, 9 daily DB backups Daily Daily Daily, 14-day retention Email Unlimited Paid add-on Unlimited Unlimited Non-WordPress sites Yes Yes Yes No 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: Option Price/mo Stay on Shared Unlimited $15.99 Everything on Web Hosting Growth $12.99 Everything on Managed VPS Business $24.99 DreamPress 1 + Web Hosting Launch $30.98 DreamPress 2 + Web Hosting Launch $35.98 DreamPress 3 + Web Hosting Launch $39.98 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 host https://www.bigmessowires.com/2026/10/15/help-me-choose-a-web-hosting-plan-decoding-the-marketing-speak/ #marketingspeak #webhosting #sharedunlimited #plan #dreamhost #cpu #means #managedvps #performance #legacy #rss #feeds #linksharing #qwibbit

The Mother of All USB Wombat Firmware Updates 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. https://www.bigmessowires.com/2026/10/10/the-mother-of-all-usb-wombat-firmware-updates/

Applying 10 Years of Server Updates in One Shot 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

and

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. https://www.bigmessowires.com/2026/10/12/applying-10-years-of-server-updates-in-one-shot/