Jon Thysell

Father. Engineer. Retro games. Ukuleles. Nerd.

Adventures in Macintosh restoration Part II: Getting a crossover machine

In Part I, I discussed my history with classic macs, my plans to restore a 30-year old compact mac, and some of the hurdles to getting started.

I decided that my first step would be to buy and restore a “crossover” machine. Basically, get a “newer” classic mac, one in-between the mac I want to restore and the modern PCS that I currently own.

It’s a staging ground

Despite the general availability of classic Mac software online, getting it off the internet and onto a pre-Internet, floppy-oriented device can be a bit of a pain if you only have modern equipment. Getting a crossover machine means more options than floppies: CD-ROMs, USB flash drives – even direct Internet-access itself.

It’s practice

I’m a fair hand at electronic repairs – I’m not worried about that aspect of a restoration. But there are other things I’ll need to do, cleaning and repair techniques I’ll need to learn too. Getting a crossover machine gives me a chance to test those skills out without worrying too much about ruining the final result.

Time to troll eBay

I’d been watching eBay for a while, but mostly I was looking for a good compact mac, or good prices on parts for an eventual compact mac. So I switched gears and started looking at newer macs. My requirements were pretty minimal – it needed to boot (at least enough to ask for a disk), have a floppy drive and some other way of accessing data – a CD-ROM drive, Ethernet card, USB, something.

I finally found a Power Macintosh 8600/200. It had no hard disk, but it included a keyboard and mouse, and there was a photo of it booting to the “insert disk” screen. Overall condition looked pretty good, but most importantly, it had a CD-ROM drive, built-in 10Base-T internet, and the option of adding PCI cards with USB. What sealed the deal, so to speak, was that I found the original manual and install CD online, which meant I could potentially get it up and running without having to resort to floppies at all.

So I bought it, and it arrived exactly as pictured – a little dirty, a little scuffed, but seemingly intact.

My Power Macintosh 8600/200 (Outside)

My Power Macintosh 8600/200 (Inside)

So, does it work?

Guess you’ll have to wait until Part III to find out. 🙂


Adventures in Macintosh restoration Part I

I have a lot of fond childhood memories with classic macs and after watching a variety of restoration videos on YouTube, playing around with some emulators, and needing a new project, I’ve decided that it might be fun to try and restore a classic mac on my own.

My history with Macintosh

Growing up in the 90’s, my family was an Apple family, and my first computer was a Macintosh IIfx with its Motorola 68030 processor and 20MB of RAM. When my father eventually made the switch to Windows for work, I inherited his Centris 650, which was my main computer for many years.

On that machine I learned to program in C with Metrowerks CodeWarrior and created my first web sites writing HTML in BBEdit. Before that, I bought a book on HyperTalk, and spent hours making black and white cartoons and little games in HyperCard to share with my friends.

While I never owned one of the classic B&W “compact” macs, I used them often enough at school. Even though I had a better System 7 machine at home, I still loved playing with those old System 6 machines, limitations and all.

Eventually I built my first Intel PC, jumping to Windows 98 instead of following Apple into PowerPC and Mac OS 8. That was in 1999, and I’ve never really looked back, in fact the only Apple product I’ve bought since then was a single iPod around maybe 2008.

Fascination with 68k

It wasn’t until I started getting back into retro games and consoles that realized that the Sega Genesis, my favorite childhood gaming console, ran on a Motorola 68000 processor – the same architecture as my old macs. It blew my mind that both systems, which couldn’t have been more different in my childhood mind, were more or less running the same CPU under the hood.

Wanting to try my hand at writing a Genesis game, I even started looking into programming in 68k assembly a few years ago, though I eventually abandoned the effort when I started costing out how long it would take me to actually make something, versus spending that time on my other hobbies. But the idea to do something with a 68k-based machine has gnawed at me ever since.

Emulators and disk format problems

Last year I started playing around with Mini vMac, an excellent classic mac emulator. Turns out there’s a lot of the old mac software still floating around online. Then I started thinking around buying and setting up some vintage hardware myself. I began researching and learned a lot about the various options for doing so, especially how to overcome the hurdle of actually getting files onto old hardware.

Getting bootstrapped isn’t easy. Basically, the primary option for getting data onto/off classic macs are floppy disks, and unfortunately, old mac floppies are just different. Even if you can get installers or disk images of all the old software online, you can’t just write them to a floppy from a PC. The disks are physically formatted differently, and you need an actual working classic mac with an original floppy drive to write them.

Once you have a classic mac up and running you can read PC-formatted disks with the right software, but the trick is getting the classic mac set up and working in the first place. A real chicken and egg problem.

The easiest thing to do is simply pay someone with a working classic mac to make a set of setup floppies for you, but even after that, you need to make sure the mac you’re using can read 1.4MB floppies (not just the older 400k/800k floppies) otherwise you still won’t be able to transfer data to/from a modern PC.

The crossover solution

The other (better?) option is to get a newer, but still old, classic mac as a “crossover” machine. Usually something from the PowerPC-era with a CD-ROM drive, Ethernet, even USB, with that special Apple floppy drive, as a staging ground for reading/writing old floppies. Then you transfer files from your modern PC to the crossover machine, then write floppies.

Now, and I’ll get into these later, there are also modern products that emulate floppy and hard drives that use SD cards, which you can read from / write to from any machine. But not only are they pricey, there are nuances to using them that don’t make it as simple as drag-and-drop.

Then there’s the question in any restoration: how original are you going to keep it? Every person, and every build is different, and the journey is just as important as the destination with a project like this. I mean, the emulators really are excellent – if I just want a quick rush of nostalgia, I can run all of this stuff in a window on my desktop.

Anyway, at the time I decided I didn’t want to invest either the time or the money to start such a project, and filed what I’d learned for later.

Now is later, looking for a new project

That’s where I left things last year: some emulator configs, setup disk images, and bookmarks saved off on my computer, in my perpetual project backlog.

Now it’s 2020, and while cleaning out a closet I found an old laptop I’d forgotten about. Not a powerful machine, but small and tough, and I thought “this would make a good emulator machine”. Now I’ve made my share of “emulator machines” and mini arcade-cabs, but I’d been watching a lot of videos on old 8-bit computers, and I thought, since the laptop is small and obviously has a keyboard, it might be fun to set it up as an old 8-bit computer emulator, specifically the Apple II and Commodore 64.

It was easy to set up, and I spent a few evenings exploring the old Apple II library. I never owned an Apple II, but like many 90’s kids I used them in elementary school, and it was fun to play through The Oregon Trail and Odell Lake again. But it was almost too easy to set up, and it only reminded me of the macs I used to have and all the research I did planning to restore one.

So I dug out my old notes and start trolling eBay. While it might be more “nostalgic” to try to rebuild my original IIfx or Centris, both are fairly large and would require an external monitor. I do have a home office now that I didn’t have last year, but there’s not a ton of space, and I don’t really want to add a big period-correct CRT onto my desk.

A laptop might work, but that’s a whole another layer of problems sourcing replacement hardware. And really, deep down, I want one of those classic compact macs. So I start working on a plan.

My goal is to take a 40-year old computer and give it a full overhaul – not just getting it up and running, but cleaning it inside and out, replacing components on the motherboard, fixing dead drives with new grease and gears, bleaching the case plastics back to the original color.

I don’t just want a working compact mac, I want to learn new skills, to get down and dirty in the hardware. Something that’s gonna take time and sweat to finish. Something that I can proudly display on my desk. Then, after all that, do what I always do with my hobbies, write some software for it. Finally scratch that itch to write something for a 68k machine.

Of course, I want to document my progress along the way. I’ve already gotten started, but this post is getting long in the tooth, so I’ll save that for Part II.

Stay tuned!


Introducing the HawKeys utility

Last year I started learning Hawaiian in an effort to improve my understanding of the music that I love. I found that I wasn’t satisfied with the available tools for typing the ʻokina and kahakōs used in the Hawaiian language.

At first I wrote a little AutoHotKey script to make it easier, and it works, but AutoHotKey is kind of a heavy tool for so simple a use case.

This year I set about writing a simple Windows app that gave the same result: global hotkeys to quickly type ʻokinas and kahakōs. It mean learning some old-school Windows coding around creating hot keys and simulating the keyboard, but the result is a simple .NET 2.0 WinForms app called HawKeys. It works great, and even better, HawKeys is my first app published on the Microsoft Store!

So if you’re on Windows 10, get HawKeys on the Microsoft Store. Otherwise. if you’re on Windows XP SP3 or greater, go to Latest HawKeys Release, download the zip file and run HawKeys.exe.

You can follow the development at HawKeys on GitHub.



State of Mzinga, November 2018

Mzinga is my open-source AI for the board game, Hive, and I last posted about it back in February 2018.

So what’s changed in the last nine months?

From an end user standpoint, the high-level highlights are:

  • The official expansion pieces (Mosquito, Ladybug, Pillbug) are now fully supported
  • Lots of Viewer updates, including:
    • Graphical bug pieces, rather than just the text names
    • Sound effects
    • Progress bars while the AI is thinking
    • Improved layout to maximize the playing area
    • Ability to “lift” pieces that are stacked to see underneath them
    • “BoardSpace” notation (the defacto way to record Hive games)
  • The Viewer now includes an “Internal” implementation of the Mzinga Engine, in case no engine executable is available
  • Engines can now expose their options to be set by the Viewer
  • There is now a “portable” release, ie. a simple zip file for users who can’t/won’t install
  • The “updater” now only checks for updates but doesn’t offer to download and install them (security issue)

From an engine / AI standpoint, the highlights are:

  • Switched to a Principal Variation Search, ie., assume that the best move from a previous, shallow search, is the best place to when starting a deeper search
  • Pre-sort moves to try moves with the most potential to upset the game first (ie moves that affect how surrounded the queens are)
  • Switched to tapered evaluation, ie. how you should play near the start of the game can be different than how you should play near the end of the game, so evaluate the board with different metric weights as the game progresses
  • Different metrics for different game types: one general set of metric weights for all game types (all the combinations of with/without expansions pieces) just isn’t effective, so the AI now has different specialized metric weights for each game type
  • Better usage of multi-threaded searches
  • Various perf improvements

I think the biggest upgrades for users are the inclusion of the expansion pieces, the much friendlier Viewer, and the fact that it’s now portable. Technically all you need to play Hive is the single Mzinga.Viewer.exe from the portable release. You can throw it on a flash drive and play Hive on any Windows (Vista or higher) computer.

On the research front, the biggest discovery for me was of the TreeStrap self-training algorithm. I won’t go into details here, (I talk about it a little in this BoardGameGeek post), but suffice it to say that it provided a more targeted way to improve Mzinga’s AI. Rather than rely solely on my evolution-based model (which, due to the limitations of my population sizes and my “rough” implementation of genetics, produced an often homogeneous pool of AIs) TreeStrap let me force an individual AI to self-train by playing games against itself and intelligently updating its own metric weights.

It was through using TreeStrap that I created a decent AI for playing games with both the Mosquito and Ladybug expansion pieces. However, it was only in testing that AI against my existing pool of evolved AIs that I learned that it only excelled in that game type. In fact that AI did horribly in other game types, which lead me to believe that it might not be possible to create one set of weights that works in all game types. This propelled me to finally expand Mzinga to support specialized weights for each game type.

But now I have a pretty robust “pipeline” for improving Mzinga’s AI. First, I have eight special AIs, each self-training against for one particular game type. Then I push those AIs into my pool of other AIs and have them all fight each other (no more evolution, just the fighting) to evaluate their strength. Then I take the top AIs for each game type (usually, but not always, the self-trained AIs) and inject their weights into Mzinga’s Engine.

In theory, if I keep repeating that loop then Mzinga’s AI should get stronger and stronger. Also I can keep “snapshot” the AI every time I release a new version and keep it in the AI pool, so I can track that the newer AIs are objectively stronger than the older ones.

As this self-improvement loop is already starting to pan out, I’ve begun spreading the load across multiple computers. I can now have one set of computers that continuously run the self-training algorithm on the special AIs and push the results to OneDrive, while another computer regularly grabs those AIs and tests them in combat.



September in the Rain on Ukulele

While at the Port Townsend Ukulele Festival last weekend, I took a wonderful class by Danielle Ate The Sandwich on tips for recording for YouTube.

All of her advice was good and straight-forward and just what I needed. The process I’d developed for recording myself was certainly quite an affair and at sometimes a slog that would leave me exhausted and frustrated at the end. Seeing how easy it was to make decent video with even just a phone inspired me to find an open spot on the Fort Worden campus and make a video.

It’s the first piece I ever learned, over a decade ago. I’m pretty pleased with the result, and I look forward to making some more impromptu videos.


For those who’ve asked for it, here’s the tab: September in the Rain (Ukulele Tab). It’s not my arrangement – it’s based on the intro to the full song that I played in a group a long time ago that I reconstructed from memory.