Jon Thysell

Father. Engineer. Retro games. Ukuleles. Nerd.

Tag: software

Adventures in Macintosh restoration Part VII: System Experiments

In Part VI, I was able to install Mac OS 8.1 on my Power Macintosh 8600/200 using a SCSI2SD as the machine’s hard drive, and I was even able to get online. Now it’s time to play around with that setup.

The original plan

The plan for this machine has always been as a bridge machine between modern computers and older vintage Macs. It’s meant to give me some practice cleaning and restoring old parts, while also being as flexible and compatible as possible. It’s a utility machine.

In order to be the most compatible with the most software and the most hardware, I figured I’d need to install as many versions of Mac OS as possible. This machine officially supports System 7.5.5 through Mac OS 9.1, but rather than install the dozen of minor versions in-between, I thought one install per major version should be enough.

System 7

Let’s start with System 7. As far as I can remember, my childhood machines ran 7.0.1 or 7.1, older than what this new machine can handle. I remember the 7.5 series existing, and it’s possible that in the later years I ran it on the Centris 650 when I first got internet access.

System 7.5.5 is the earliest software this machine can run, and it’s the last version to support running 24-bit addressing (something the oldest programs need). The other contender for System 7 would be 7.6.1, which is considered mostly the same, except it’s got some PowerPC performance improvements that would apply to this machine.

In the end I actually chose 7.6.1 for this machine. It turns out the 24-bit support only applies to the 68k Macs, and this machine will never be able to run programs that need it. So 7.6.1 has the exact same compatibility as 7.5.5 but is just faster.

Beyond System 7

After System 7, we’re out of my personal experience. I may have used Mac OS 8 once or twice in high school, but I’ve never used Mac OS 9. I have no nostalgia for these systems, so the only requirement is to expand my access to software and hardware.

My initial plan was to pick just the latest in each line that I could run, Mac OS 8.6 and Mac OS 9.1. While I’m currently running 8.1, and having a little fun here and there playing some old games, as far as I can tell there’s no reason to run this version with newer ones available.

However, talking with people online, and it seems there are three camps when it comes to OS 8.

Camp one thinks System 7 was the pinnacle of Mac systems in terms of design and speed, and everything after that was bloat. They point out that the change from 7 to 8 was just to cut out the clone manufacturers, since they only had licenses to System 7. So 8 is really just a bunch of crap on top of 7.

Camp two thinks OS 8 is the pinnacle of Mac design, that 8 refined and filled in all of the gaps of 7. They say System 7 is too spartan for newer machines, and point out that 8 added better networking support and just as importantly, support for larger hard drives.

Camp three thinks OS 8 can be skipped entirely, thanks to Mac OS 9. Very little software lists OS 8 as a minimum, and even so, it’ll still run on OS 9. Same with hardware. Most things just work on 7 and above, or require 9, so unless you really like the style of 8, there’s no reason to use it if you can run 9.

I already planned on installing 9 as it gives me access to a variety of useful hardware upgrades on this machine such as USB and Firewire. So I decided to table the decision on OS 8 for now.

Let the experiments begin!

The first thing I did was backup the SD card with Mac OS 8.1. It doesn’t have anything particular that I care about, other than being a booting system. I re-setup the SCSI2SD with three virtual drives, then booted the 8.1 CD to use Drive Setup to format them.

I had already downloaded and burned CD images for a variety of versions: 7.5.5 and 7.6.1 specifically for this model, universal installs for 8.0, 8.5.1, and 8.6, and finally universal installs for 9.1 and 9.2.2.

I won’t go into all of the gory details here, but suffice it to say that I spent weeks installing and re-installing different OSes to the different virtual drives. I followed various suggestions online and took my own notes during the installation process of each. I ran benchmarks, browsed the web, and downloaded some apps and games to try out.

One win was getting an FTP server to run on the Mac, which meant I could more easily transfer files to it from a modern PC. That freed me up to download new software quickly on my PC, then upload the files to the Mac at my leisure. This gave me both an archive of downloads on the PC and saved me from having to browse the web on the Mac and deal with increased chance of download failures.

The other big win was installing Mac OS 9.2.2. Officially most machines can only run 9.1, because that was basically the last version of OS 9 meant to be run as an independent OS. By that point in time, Apple had switched over to OSX, but early versions still provided a “Classic Environment” compatibility layer that let those OSX users still run their old OS 9 apps.

Classic Environment still required a full copy of OS 9, and it got a few more stability and performance updates in the form of 9.2, 9.2.1, and 9.2.2. So installers exist for those versions, but of course they have protection measures in place to make sure you don’t just install them on older hardware.

However, thanks again to enterprising hackers, there’s a tool called os9helper that lets you trick the installer into working. And it worked!

The final plan

At the end of it all, I’d pretty much settled on a plan of only installing 7.6.1 and 9.2.2. I didn’t find any reason to keep 8 around, the installs sat dormant while I spent most of my time in 9.2.2. In fact, even keeping 7.6.1 around seemed to be “just-in-case”.

Anyway, this has been a pretty text-heavy post. I didn’t bother to take any pictures during all this software experimentation. Next time I’ll have more photos, as I dive into some hardware upgrades. So stay tuned for that in Part VIII!

/jon

Want to read from the beginning? Start at Part I.

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!

/jon

Making some retro games with LÖVE


I was in the mood to make some games this past week, when I discovered the wonderfully powerful yet lightweight LÖVE game framework.

After watching some videos on YouTube highlighting games others have made*, I set to work on one of my own. Within a couple of hours I had Pong running on my phone!

I decided I’d keep exploring the APIs by building a suite of simple retro games, the source of which I’ve uploaded to a new GitHub repo named RetroLove.

So far I have decent clones of Pong and Breakout. I’m thinking maybe Asteroids next. It’s so much fun, and the framework couldn’t be easier to use.

Check it out,

/jon

*: The story on how I found LÖVE is actually a little bit longer and shows the circuitous way by which I find myself doing these kinds of projects. I was working on another project, my first Universal Windows Platform app (that is, an app that runs on all Windows 10 devices). The project itself is something I’ve had on the back-burner for years, and I was primarily using it as an excuse to practice using XAML, which is the UI framework for UWP apps. (My day-job is on the XAML team at Microsoft, so using it myself only helps me to better understand our customers.)

Anyway, my app needed an embedded scripting language, and I wanted to use Lua, but I needed something that would work within a UWP app, which, because it needs to work on lots of different kinds of devices, meant I couldn’t use the native Lua libraries easily.

This led me to the very cool MoonSharp project, which is a Lua interpreter implemented entirely in C#. After I got that up and running, the app also needed a kind of visual editor, so I needed to do some 2D graphics work. It was then that I discovered the Win2D project, which makes it easier to do GPU-powered 2D graphics within XAML.

Then an idea hit me: what if I had a 2D game engine designed similar to retro consoles? Where the engine would be responsible for maintaining backgrounds, sprites, and drawing to the screen, and the game developer would provide the game in the form of a package of Lua code and game assets? I could make a UWP app that used MoonSharp to interpret the Lua and used Win2D to draw to the screen.

It had been some 15 years since the last time I’d made a game engine. In college I made a decent Mario-style platformer in Java; it had realistic physics, collision detection, music, sprite animations, scrolling, power-ups and enemies. I only ended up making one tech-demo of a level, but in the process I learned a ton about game engine design. (Though looking at that old code now… yikes.)

I spent a weekend trying to implement my idea for a sprite-based 2D game engine for Windows 10. It took me the two days to realize the true scope of such a project, and unfortunately I couldn’t get MoonSharp and Win2D to cooperate. Knowing that my idea probably wasn’t a unique one, I started searching online for other Lua-powered 2D game engines.

That’s how I found the free and open-source LÖVE. After seeing the size of its community, and how mature it was, I quickly abandoned my own broken code and started work on Pong.

SegaController v1.3.0 now available

I’ve released an updated version of the SegaController Arduino library. If you don’t know, SegaController enables your Arduino sketches to read Sega Genesis (Mega Drive) and now Master System (Mark III) controllers.

What’s new in v1.3.0?

  • Now supports Sega Master System (Mark III) controllers
  • Optimized code to reduce compiled binary size
  • Reduced read latency
  • Fixed issue with errant button reads when inserting/removing controller
  • Temporarily disables interrupts while reading to prevent misreads
  • Added DB9 pinout diagram to readme and examples

So if you’re interested in reading Sega controllers in your Arduino projects, check out  SegaController Arduino library on GitHub.

I’ve also updated How To Read Sega Controllers with information on reading Master System (Mark III) controllers.

Enjoy and happy hacking!

/jon

Introducing the AtariController Arduino library

After releasing my Arduino library to read Sega Controllers, I decided it might be fun to create a suite of such libraries for reading other retro controllers.

So today I’m introducing my new AtariController Arduino library on GitHub. This initial release only supports the classic Atari 2600 joystick, but I hope to add other controllers in the future.

The code is provided as a proper Arduino library, making it easy for Arduino enthusiasts to use in their own sketches. As with SegaController, I also include two examples, one which reports the button states via the serial port (good for testing) and one which sends Keyboard key presses (good for driving other software).

And of course, I’ve created some documentation of my own in the AtariController wiki at How To Read Atari Controllers.

Enjoy and happy hacking!

/jon