UPDATE: See newer Mactoberfest info here. It even has a fancy logo now.

Somebody stop me! On Saturday October 14 from 11am to 5pm, Big Mess o’ Wires invites you to the 1st Annual Mactoberfest San Francisco Bay Area Classic Macintosh Meetup / Mini-Expo / Repair Clinic / Swap Meet / Open House / LAN Party / Hangout. Bring your classic Macintosh collection, your tools, your extension cords, your Localtalk cables, and all your best nerd toys. If you want to bring some Apple II or other vintage computers too, I won’t stop you. I’ve rented a room for 50-ish people, furnished with tables and chairs, and the rest is up to you:

• Mingle and chat. Stump the crowd with Macintosh trivia. How many of the signatures on the inside of the Mac 128K’s case can you name?
• Hardware showcase. Demo your interesting computers, peripherals, software, and vintage tech. I heard a rumor that some never-released classic Apple prototypes might be there.
• Repair broken equipment. Bring your soldering iron, multimeter, or scope. We’ll crowd-source some fixes.
• Beam some notes to other Newton users with IR. When else will you have a chance to do that?
• Play classic networked games like Bolo and Spaceword Ho!
• Buy, sell, trade, or donate vintage equipment. Find that one weird part you’ve searched for since 2008.
• Stock-up on BMOW’s vintage computer products. Yeah I’ll have stuff available for sale, but that’s not the point of this event.
• Debate whether the Newton was just ahead of its time, or was actually hot garbage.

This will be fun, but set your organizational expectations low. It’s a large rented room with lots of tables and chairs, hosted by Big Mess o’ Wires. The rest is up to you. The photo above is from a computer festival in Europe, and is much better coordinated than the chaos we’ll probably have. Don’t expect a highly-polished and curated event with fancy exhibits, a speaker series, and mad prizes. Don’t expect to wander through museum displays without talking to anybody. This is a low-key participatory event built on your own involvement and whatever goodies we collectively bring to play with.

Where
 
I’ve rented a large room near my home in Belmont California, in the middle of the San Francisco peninsula. Belmont is near Highway 92 and is roughly equidistant from San Jose and the South Bay, San Francisco and points north, and Oakland, Berkeley and the East Bay. If these words mean nothing to you, then you’re not in California and you’re too far away, sorry.

What to Bring
 
Please don’t forget to bring your electric extension cords! I’m not the AV department and I won’t be providing any electric cords. The room will have plenty of 6 x 3 foot tables and chairs, and copious electric outlets, but the closest outlet might not be near your table. There’s a hardware store half a mile away, if you need more extension cords on the day of the event. Also bring your classic Macintosh and other vintage computers, items to sell or trade or repair, tools for making repairs, and networking equipment if you want to LAN play. Don’t forget to put your name on your power cords and all your equipment, so it doesn’t get confused with somebody else’s stuff.

Attendance
 
I expect to have between 30 and 100 people. If we have more than 50 who are interested, I’ll need to start making table assignments. If this event goes viral and 500 classic Macintosh fanatics show up, plus Tim Cook and all the members of the original Macintosh dev team, we’ll have a problem because there’s a hard maximum of 100 people for the room.

RSVP here (in the Google Form) if you’re maybe, probably, or definitely planning to attend. This will help me keep track of who’s bringing what hardware, and the likely overall attendance level. The street address within Belmont is on the RSVP form.

If it looks like we may exceed 100 people then I’ll close the RSVP. Don’t be that sad person who’s turned away at the door (although you might start a Classic Macintosh tailgate party in the parking lot).

 
1st Annual Bay Area Classic Macintosh Meetup / Expo / Clinic / Swap-Meet
Hosted by Big Mess o’ Wires
Saturday October 14, 11:00am to 5:00pm
Belmont, California
in the “Fireplace Room”
(event address is on the RSVP form)

See you there, and don’t forget to RSVP!

RSVP here for the Classic Macintosh Event

The BMOW Wombat enables the use of USB mice with ADB computers, such as classic Macintosh and Apple IIgs systems. It’s a great feature, but sometimes the mouse tracking speed appears too fast or too slow for convenient use, even after making adjustments in the host OS’s mouse control panel. Firmware version 0.3.9 introduces a new Wombat feature to help: hardware mouse scaling.

With each long-press of the USB mouse wheel button (longer than half a second), the Wombat increases the mouse tracking hardware scale by a factor of 2. This scale is in addition to any mouse scaling that’s applied in the host OS’s control panel. The available scaling factors are 1/2/4/8/16x. For the Razer Basilisk v2 mouse shown in the video, I found that 8x scaling felt about right, but your tastes may be different.

Firmware 0.3.9 also disables an error-checking feature in the Wombat’s parser for USB HID report descriptors, because some USB devices have a minor error in their report descriptor, including this Basilisk mouse. The descriptor uses a sort of universal grammar for HID devices to describe what they do and what kind of data they can send and receive. The Basilisk has an error in its report descriptor where it specifies a maximum possible value of 572 for a report item that’s only 8 bits in size. The Wombat report parser was seeing this error and rejecting the whole device. Disabling the error check enables the Basilisk to work with no ill effects. This change may also “fix” some other USB mice and keyboards that previously weren’t recognized by the Wombat.

Download the latest Wombat firmware now, and let me know how it works for you.

Paul C. Pratt is the man behind the Gryphel Project, an ambitious software and documentation effort to preserve and extend classic 68000-based Macintosh computers. He’s the author of the wildly-popular Mini vMac emulator, as well as other great tools like disassemblers and ROM utilities. Paul’s been a pillar of the classic Macintosh community for decades. Although I’ve never met him, I’ve exchanged many emails with Paul over the years, and he’s always been helpful.

Paul has gone missing. Not missing in the sense of a family emergency and police search, but missing for over two years from the classic Macintosh community where he’s been an active member for so long. His Gryphel Project site is still up, but there have been no new posts there since April 2021. He hasn’t appeared anywhere else online either, and he’s not responding to emails, nor to messages sent through community forums where he’s a member. Paul doesn’t have much social media presence, and nobody’s sure of his real-world address or phone number.

Maybe some family emergency or health crisis has demanded Paul’s attention since 2021? Maybe he simply got burned out on classic Macintosh topics, and decided to abandon his online identity and walk away from it all? For the past year, concerned members of the community have attempted to get in touch with Paul through various ways online and real-world to confirm he’s OK, or to ascertain what might have happened to him. They’ve not been successful, which is frustrating and sad.

I sincerely hope that Paul’s sitting in a sunny meadow somewhere, enjoying a lovely day and not giving any thought to crusty old Macintosh computers. But with every passing day that he’s not heard from, we all fear the worst. If he’s died, it’s entirely possible that Paul’s heirs might not think or care to tell anybody outside of his immediate family and friends. From his bio we know that Paul was born in 1969 or 1970, which makes him about 52, and the same age as me. That’s not old, but it’s a cautionary reminder that none of us live forever.

Hearing Paul’s story has motivated me to draft a continuity plan for BMOW, in case of my sudden unexpected disability or death. I’ve made arrangements to ensure the blog and the store would be gracefully wound down, and product designs would be transferred to responsible hands to make sure that nothing important is lost.

31 years ago Tetris Max for the Macintosh was born, an improved clone of tetris, and it became an insanely popular Mac game during the 1990s. I may or may not have had some involvement in its development. (See lots more Tetris Max history.) Macintosh System 6 was the current OS version at the time of the game’s release, but System 7 was introduced shortly afterwards. It’s recently come to my attention that the final version of Tetris Max (v2.9.1) may not work when running System 6 on certain Mac hardware, even though the game was advertised as System 6 compatible. I haven’t yet been able to fully verify this myself, but there’s a Macintosh Garden bug report from ironboy36 in 2022, and more recently a detailed bug report complete with video (thank you James!) Obviously I need to fix this stuff ASAP – 31-year-old bug be damned. And I need your help! Consider this a group debugging effort.

Both bug reports mention an “Unimplemented Trap” error message, which probably means Tetris Max tried to call a Toolbox function that’s only available in System 7 or later, and isn’t available from System 6. I suspect this bug only applies to color-capable 68K Macintosh models running System 6, because Tetris Max 2.9 works OK under System 6.0.8 on my B&W-only Macintosh SE. That limits the range of Mac models where this problem might appear to the Macintosh II family (including the Mac SE/30), because later Mac models can’t run System 6 anyway, and earlier models (like the Mac Plus and original SE) aren’t color-capable.

James’ test was performed on a Mac SE/30 with the built-in black-and-white screen, running System 6.0.8 loaded from a BMOW Floppy Emu disk emulator. I think he was also using a Mac ROM-inator II replacement ROM during this test. Ironboy36 didn’t mention what hardware was used, so we can only guess.

 
Reproduction

Challenge #1 is simply reproducing the bug. Unfortunately I think this needs to be done on real hardware, and not under emulation, because I’m not aware of any software that can emulate a color-capable 68K Macintosh running System 6. Mini vMac only emulates non-color Macs like the Plus and SE. Basilisk II can’t handle 24-bit addressing or System 6, and Sheepshaver is PowerPC-only emulation. There’s MESS, but I’m not sure about its capabilities, and setting it up is daunting. [Note: I learned there’s a Macintosh II version of Mini vMac that can handle System 6, but I found it to be slightly unstable and not a reliable testing platform.]

Working on real hardware is OK, even if it’ll be more difficult, but I don’t have easy access to any appropriate machines. My SE/30 needs to be recapped and currently doesn’t boot. I also have a Mac IIci and a Mac IIsi, but one is missing the power supply and the other has an unknown motherboard problem. I can probably get one of those machines working again, but at least for now I need to rely on other people to run Tetris Max with System 6 on systems like these, and send me reports.

 
Other Complications and Possible Causes

I don’t remember intentionally dropping System 6 support in later versions of Tetris Max, but it’s possible. After 31 years, with no source control and no release notes, I couldn’t tell you exactly what changed between the last few versions of Tetris Max. Version 2.9.1 was the last public release from the 1990s, but the game was later patched to create a 2.9.2x version which supported running directly from a locked disk like the ROM disk provided by the Mac ROM-inator II. And before 2.9.1, there was straight version 2.9, which is the most common version found in archives today. For the purposes of troubleshooting this bug, I think all three versions behave identically.

It’s possible this is actually a Mac ROM-inator II problem, since that’s what James used and possibly ironboy36 too. It would help to try running Tetris Max on the same computer, with the same System version, with the Mac ROM-inator and then again with the stock Apple ROM. Maybe the game is confused into thinking the SE/30 is a IIsi, and then tries to call some System routines that aren’t available in the SE/30? Just a guess.

Another possibility is that the version of 6.0.8 that’s on the Floppy Emu’s SD card is missing some data that’s supposed to be in the System file, and which is actually the source of the problem. For example, I know it’s missing some of the standard bitmap font sizes, though this shouldn’t cause an Unimplemented Trap error. I suspect this particular 6.0.8 System file was borrowed from a Disk Tools floppy rather than being the result of running the full 6.0.8 installer. It would help to try Tetris Max on a Macintosh II series machine with either System 6.0.7, or a fresh install of 6.0.8 from the installer floppies.

 
Debugging

I was able to dig through many layers of dusty old backups, and get Tetris Max rebuilt and running in the debugger with Codewarrior Pro, on an emulated System 9.0 PowerPC Macintosh with Sheepshaver. I stepped through all the code that runs between application launch and when the game window appears, and didn’t see anything that’s obviously System 7-only, but there’s a lot of code and I don’t have a good sense of which OS calls might be to blame. If you’re a developer, you can find the source code at Macintosh Garden.

Ideally I would run Tetris Max in the debugger on a color-capable 68K Mac with System 6.0.8, and go step-by-step until the game crashes, but there are a couple of problems with that approach. The version of Codewarrior Pro that Tetris Max is built with probably doesn’t work under System 6, or on Mac systems as old as the Macintosh II series. Even if it does, I don’t currently have working hardware to do it.

Macintosh Garden also has older versions of Tetris Max, including 2.8, 2.3.1, and older. If I can get the game running on real hardware, or somebody else can try it and report their results, I could find out what version broke the System 6 compatibility. That could provide more clues.

If my ancient memories are correct, someone could also install MacsBug on their Mac, and then they’d get more debugging info when the error occurs, instead of a mostly-useless “unimplemented trap” message. I think MacsBug would report which Toolbox trap the game tried to call, which would be very useful to know.

For the moment, the only viable debugging approach I can think of is to create a series of instrumented builds of Tetris Max, which beep or log their progress to a file during startup, and share these builds with people who can help test. That could eventually narrow down the point of the crash until the offending Toolbox call is identified. From there I could hopefully implement a work-around. But this approach is barely better than inserting PRINT statements into a 1979 BASIC program to aid with debugging, and I don’t like it very much. 30 years later, shouldn’t there be an easier method of debugging?

Here’s a new firmware update for the BMOW Floppy Emu disk emulator! This update has several small improvements and fixes for the Emu’s Apple II disk drive emulation modes.

 
Overrun Errors in GS/OS

The new firmware resolves a problem that could cause a “Fatal Error: Overrun” on the Apple IIGS with GS/OS. This error would appear when using Smartport hard disk emulation mode, with more than one hard disk image mounted, if you repeatedly exited and re-entered GS/OS (by exiting to BASIC or another ProDOS8 application).

I call the issue “resolved” rather than fixed, because the root cause is still not clear. What I found is that when exiting GS/OS for the second time, the computer sends a Control packet to the second hard drive (the non-boot drive) with a control code of $40. I haven’t found any documentation about this particular control code or what it’s intended to do. Other control codes are used for functions like ejecting removable media or resetting the disk drive. This particular Control packet has a very large data payload attached – about 1500 encoded bytes or 1300 real data bytes – which was overflowing the Floppy Emu’s receive buffer. Anyone have a guess what the control code $40 might mean?

 
Dual 5.25 Inch Drive Automount

In Dual 5.25 Inch Floppy emulation mode, automount of the most-recently-used disk now works for both drive 1 and drive 2. Previously only drive 1 supported automount.

 
Directories with Hundreds of Files

This firmware also fixes a UI problem that would occur if the current directory on the SD card had more than 212 files. Very large directories would exceed the memory capacity of the Floppy Emu, causing incorrect UI behavior. The new firmware will warn you if there are too many files and then limit the directory listing to the first 212. To avoid this, it’s recommended to use a hierarchical directory structure instead of flat directories containing hundreds of files each.

 
Get the New Firmware

You can download the latest Floppy Emu firmware from here. As always, I appreciate your feedback on firmware updates, whether it’s a problem report or just a “works great for me” confirmation. Enjoy!

After three very difficult years, BMOW’s experience with the global semiconductor shortage is finally starting to improve. During most of 2020-2023, even common chips like voltage regulators were hard to get, and a few essential chips that are required for Floppy Emu and Yellowstone were completely unavailable for periods of months or even years. I previously wrote about the business difficulties this created in Global Chip Shortage Hits Home, Semiconductor Shortage and Business Threat, and Yellowstone Future Forecast Update. It’s been rough.

I’m happy to report that this storm is beginning to wind down, and the skies are clearing. Last week I received a long-awaited shipment of Xilinx XC9572XL chips for Floppy Emu that I’d ordered nine months ago, and today I received word from Digikey that the Lattice LCMXO2-1200 for Yellowstone is back in stock again after being completely unavailable everywhere for 1.5 years. The Atmel ATMEGA1284p for Floppy Emu isn’t generally in stock, but supplies are available directly from Microchip with “only” a few months’ delay on back-orders. It’s not a perfect situation, but it’s a huge improvement on a year ago.

The downside is that chip prices have increased substantially, especially for some of the older chips that I use. For that Xilinx chip specifically, the XC9572XL used to be around $2 each when purchased in large quantities, and now it’s $9.66 each with no quantity discounts available. Ouch!