Jon Thysell

Father. Engineer. Retro games. Ukuleles. Nerd.

Category: Howtos

Adventures in Macintosh restoration Part III: The Power Mac lives!

In Part II, I described my first purchase: a Power Macintosh 8600/200 in pretty good shape. But I left the most important question unanswered – does it work?

Replacing the PRAM battery

First step was to replace the PRAM battery – the little cell that keeps the clock in-time when the system is unplugged, and maintains a small list of basic settings like the screen resolution, which drive to boot, etc.

You’ll notice in the previous post’s photos that I’d already removed the original battery – in fact it was the very first thing I did when I opened the machine up.

December 1996. Seeing as this model was on the market in 1997, that’s probably the battery’s manufacture date, making it almost 24 years old!

I tested it with a multi-meter and it registered zero volts, confirming it was dead, well past its expected life of ~10 years. Thankfully, and most importantly, it failed gracefully – no leaks and no explosion. It’s a real risk too.

Thankfully, replacing the battery was smooth and simple.

Connecting a modern display

After replacing the battery, the next step was to get the machine set up and connected to a monitor. The only loose monitor I had available was a cheap LCD I’d bought a few years ago.

While many vintage macs could output VGA-compatible signals, Apple had their own unique video connectors. I had to pick up a cheap configurable VGA monitor adapter (FYI, the correct setting was 2, 3, 6, 7).

With that connected, it was time to start up the machine!

First proof of life

The machine started up with a satisfying startup sound:

It lives! The blinking “missing disk” icon is the exact behavior one expects without a boot disk present. Which means, the next step is to prepare a boot disk.

Breaking out the Floppy Emu

Without an already set-up hard drive, the two standard options I have for this machine are a boot floppy or a boot CD-ROM. I’d ordered the original system install CD, but it hasn’t arrived yet. (Side note, I’m behind in blogging all of this, but I ordered the CD August 17th, it wasn’t even shipped until September 4th, and it still hasn’t arrived as of this post).

Could I have burned a CD? It turns out yes, but I didn’t know that, or whether the CD-ROM drive even worked.

Could I use a floppy? Not right away – I do have blank floppy disks, but as far as I knew, no way to make a mac floppy on my PC, even if I had a floppy drive (which I didn’t). And again, no guarantee that the floppy drive in the mac works either.

So, time to bust out my first “modern” toy in this adventure: a Floppy Emu. I mentioned back in Part I that there are modern devices that emulate the older drive hardware and use SD cards, and the Floppy Emu is just that. It’s a little device that plugs into the internal floppy cable (or external floppy drive port) of these vintage machines, and lets you read from (and write to) floppy drive images on the SD card.

I put several boot floppy images onto an SD card, disconnected the real floppy drive, ran its cable out the front of the machine, and connected the Floppy Emu.

It took a few tries with different images (some threw up errors saying they wouldn’t work on this particular machine) but eventually the Mac OS 8 Disk Tools 8.1 PPC worked. Success!

Booting from floppy was slow, and this particular floppy image is really just to help you set up / troubleshoot your hard drives, but I was finally able to prove the machine wasn’t a lost cause.

About this computer

When getting a vintage mac up and running, it seems it’s tradition to take a photo of this screen, showing off how much RAM you have and that you’ve gotten this far. I myself was pleasantly surprised – I had counted the four RAM DIMMs and after a little research had concluded that they were 16MB each, for a total of 64MB RAM. Not amazing by today’s standards, but twice the standard 32MB this machine came with.

Turns out one of sticks was actually 32MB, so 80MB for me! Considering the price and availability of RAM for this machine (we’ll get into that in a later post) every little bit helps.

I think that’s enough for this time, stay tuned for Part IV!

/jon

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. 🙂

/jon

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

Automatically generating version numbers in Visual Studio

Having intelligible version numbers is one of the easiest ways for developers to keep track of their software in the wild. However, having to maintain version numbers manually across multiple projects can be an annoying, error-prone process, especially if you’re trying to build and release often.

So how can we automate this task away?

The Goal

I have a Visual Studio solution with multiple projects, that therefore generates multiple assemblies for my app. In no particular order, here’s what I want:

  1. Every assembly has the exact same version number
  2. The option to manually specify a version number (say for infrequent builds that I release to the general public)
  3. The option for VS to auto-generate a build number (say for frequent builds that are released to beta testers)

So, what are my options?

Sharing one version number

Let’s tackle the first requirement. By default, every code project in a Visual Studio solution has its own AssemblyInfo.cs, and each specifies their own version number that needs to be updated and maintained.

But there’s no reason we have to stick with that. A better idea is to:

  1. Remove the AssemblyVersion attribute from AssemblyInfo.cs in all of your projects
  2. Create a new file, say SharedInfo.cs in one of your projects (typically the one the builds first) and put the AssemblyVersion attribute there.
  3. For all of your other projects, simply add that SharedInfo.cs as a link. (In the “Add Existing Item…” dialog, click the arrow next to the “Add” button and choose “Add As Link”.)

Now you only have one file to update your version information in, making it much more manageable. Bonus, you can move all common assembly tags you want in your SharedInfo.cs, like Copyright, Product, etc.

Automatic versions

Being able to manually specify a version number is easy enough. Whether you keep the default Visual Studio AssemblyInfo.cs paradigm or the SharedInfo.cs method above, it’s just a matter of you picking and setting a new version number when you feel like it.

But now let’s see what we can do about having automatic versions.

Option 1: Use the built-in wildcards

The first option is given to us right in the default AssemblyInfo.cs, letting us know that we can simply set our version to Major.Minor.* and let Visual Studio auto-generate the Build and Release numbers.

Visual Studio then sets the Build based on the number of days that have passed since January 1st, 2000, and sets the Release to the number of two-second intervals that have elapsed since midnight. Sounds good so far, and of course you can always switch back to a manual version at any time. But there are a couple of caveats:

  1. This only works with AssemblyVersion, not AssemblyFileVersion. To make this work for both, you have to specify just the AssemblyVersion (comment out or delete the AssemblyFileVersion line) and then Visual Studio is smart enough to use the same value for AssemblyFileVersion.
  2. Both numbers are generated at the exact time the particular project was built. So if you have multiple projects in your solution and any one takes more than two seconds to build, you will end up with different versions for different assemblies.

Option 2: Use an extension

The next option, one I used for years, is to simply hand over the responsibility of generating versions to the VS extension Automatic Versions.

If features a very nice GUI and there are lots of styles of automatic versions you can specify for your projects. It resolves both of the issues with using the built-in wildcards, letting you specify AssemblyVersion and AssemblyFileVersion, and also making sure that every project has the same version number (whether you share a linked file or not).

Downsides?

  1. You might not find a version style that you like. While there are lot of version number patterns to choose from, if you have a specific format you need to adhere to (say to match existing releases), you might be out of luck.
  2. You’ve just added a dependency to your code. Are you sharing your code with other developers? Now they have to install the extension too.

Adding dependencies means adding risk. For over a year, the VS Performance Profiler simply would not work for me, throwing an error and crashing whenever I tried to analyze my applications. I thought maybe my VS 2013 install was simply borked, but the problem followed me to VS 2015.

Turns out Automatic Versions was the culprit. Now, to be fair, once I reported the bug the developer very quickly issued a fix and now the Profiler is fine. But I searched for a solution to that Profiler error for a year, and at no point did it occur to me that an extension might be causing the problem.

Option 3: Use a T4 text template

The last option I want to talk about, is using a T4 template. What are T4 templates? From Code Generation and T4 Text Templates on MSDN:

In Visual Studio, a T4 text template is a mixture of text blocks and control logic that can generate a text file.

I’ve you’ve ever made a website in ASP.NET or PHP, then you’ll have no problem with T4 text templates. Basically, you can create a template file with some in-line blocks of C# that will get run when you build your project to generate your actual file.

So, instead of creating a straight SharedInfo.cs like we did before, now we create a SharedInfo.tt and write a little bit of code to handle generating new version numbers.

Simply add a new T4 text template to your project paste in the following to get started:

<#@ template debug="false" hostspecific="false" language="C#" #>
<#@ output extension=".cs" #>
<#
    int major    = 1;
    int minor    = 0;
    int build    = 0;
    int revision = 0;

    // TODO: Write code here to automatically generate a version

    string version = String.Format("{0}.{1}.{2}.{3}",
                                   major,
                                   minor,
                                   build,
                                   revision);
#>
// This code was generated by a tool. Any changes made manually will be lost
// the next time this code is regenerated.

using System.Reflection;

[assembly: AssemblyVersion("<#= version #>")]
[assembly: AssemblyFileVersion("<#= version #>")]

Now, if you’re having trouble reading this, basically, the first couple lines are directives that the template is going to create a .cs file. The code in the <# #> blocks will be run when the project is built, and where you’re going to need to decide how you want to generate your build numbers. After that is the static template text of the output file, and you can see where you see <#= version #>, that’s where the value of the version string will be inserted.

As it stands, if you created a SharedInfo.tt with the above template, you’ll get a SharedInfo.cs with the following:

// This code was generated by a tool. Any changes made manually will be lost
// the next time this code is regenerated.

using System.Reflection;

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

And just like before, you can then add links to that SharedInfo.cs (not the .tt file!) into your other projects. So all you need to do is write the code that generates the automatic versions. What does that code look like? It’s up to you!

In my projects, I usually have a “manual” mode whereby the version numbers I entered are used for public production builds, and overwritten by something based on DateTime.UtcNow for private or test builds. If you want plain, auto-incrementing numbers, you might go with reading in your current SharedInfo.cs to parse out the previous version number, increment, and save it back out.

Well, there you have it, completely customizable automatic versioning in Visual Studio solutions. Like it? Have a different approach? Sound off in the comments!

/jon

P.S. If you want to see a “real-world” example of how I pick version numbers check out What the Chordious version numbers mean.

Consolidating the Sega Genesis, Sega CD, and Sega 32x power supplies

As I’ve mentioned before, the Sega Genesis was my first and favorite childhood gaming console, and though over the years I’ve come to rely on emulators, re-releases and clone systems to get my Sega nostalgia, I recently decided to set up some original hardware.

Whether you’re new to the system, or a long-time fan, the holy trinity is to get a Sega Genesis along with its two biggest add-ons, the Sega CD and the Sega 32X. Now, one of the major annoyances is that each has its own wall-wart power supply, which are a pain to use: they’re hard to get situated on power strips due to their size and they generate a lot of heat, even with nothing turned on.

I thought there had to be a way to have a single consolidated power supply that supports all three systems at once. And after a little research, I found two solutions:

  1. The Sega Trio, which is a commercial power supply made specifically to solve this problem at the reasonable cost of $28.99. Only problem seems to be the very limited availability.
  2. Follow what others have done (see this forum post), and build my own custom harness on top of a generic power supply.

So I decided to build my own, and document the build along the way.

The Investigation

The first step was to collect all of the relevant power requirements for each system (thanks to this page for a lot of it). For my own setup, I have a model 2 Genesis, model 2 Sega CD, and a 32X. Here’s what the original power supplies look like:

System Voltage Amperage Plug Type Polarity
Sega Genesis Model 2 10V 0.85A 1.7mm Pos. center
Sega CD Model 2 9V 1.2A 2.1mm Neg. center
Sega 32X 10V 0.85A 1.7mm Pos. center

Now the next step is to find a suitable generic power supply. It is important to note that none of these systems actually needs exactly 9 or 10 volts to operate. In fact, the rating on the label is more like the “average voltage” that adapters of that model produce. So a particular one of these power adapters may actually produce anywhere from 8 to 12V.

This is all fine because the first thing each system does is step down that input power to the steady 5 volts that the chips inside are designed to use.

Since it’s very easy to source 9V power supplies, I’ll go with 9V for my generic.

As for the amperage, I need to add up the ratings of each power supply to get a minimum safe value. Amperage ratings show the maximum amperage that the power supplies can safely provide, not the actual amount the systems will necessarily draw. To be safe, OEM manufacturers typically provide power supplies that can offer slightly more amps than they expect their product to draw at full intensity.

So in the original setup, 2.9A is probably safely above the maximum current I’d expect the three systems to draw at once. Round that up to 3A, and now I’m looking for a 9V, minimum 3A power supply, preferably one that isn’t a wall-wart.

The next consideration is how to get one power supply to have three plugs. So I’m going to need to make or buy some kind of harness to split or daisy-chain three separate plugs. As for the plugs themselves, I have couple of things to consider.

Generic power supplies typically come standard with barrel plugs with a 2.1mm diameter center hole with positive polarity. The Genesis Model 2 and 32X both use the more common positive polarity center. Unfortunately, they use the less common EIAJ-03 barrel plugs with a smaller 1.7mm diameter center hole. The Sega CD Model 2 uses the common 2.1mm center hole, but the less common negative polarity center.

So in both cases I’m going to need some adapters.

At this point I have a spectrum of options. On one end is to buy all raw parts and try to solder up a completely custom harness. More extreme, I could even build my own power supply from scratch. On the other end of the spectrum is to try and get away with buying off-the-shelf cables and adapters.

Building from scratch is fine if you have the time, skills and tools. To save money you’ll need to buy parts in bulk, which is great if you’re going to build a bunch, or might use the parts in other projects.

Anyone can buy off-the-shelf parts and just plug them all together. No special skills required. But you will pay a premium.

For this project, I thought it would be interesting to source off-the-shelf parts, just to prove that I could make it work with no soldering required. Yes it probably wouldn’t look as slick, but anyone could replicate it. Also I was feeling lazy. I can always play cable doctor later and transform the off-the-shelf parts into a slicker, more permanent solution.

Bill of Materials

Item Product Quantity Unit Price
9V 3A DC Power Supply Output 9V 3A AC/DC Power Supply Cord Charger IEC320 C8 Socket Adapter 1 $14.37
AC Power Cord SF Cable, 6ft 18 AWG 2-Slot Non-Polarized Power Cord (IEC320 C7 to NEMA 1-15P) 1 5.75
3-Way DC Power Cable Splitter 1:3 DC Power Splitter Cable Cord 1 Female to 3 Male 5.5×2.1mm Port Pigtals 12V 1 3.99
2.1mm to 1.7mm DC Power Adapter Cable 4.8mm x 1.7mm Male Plug to 5.5mm x 2.1mm female socket DC Power Adapter cable 2 3.59
2.1mm Power Jack Polarity Changer MODE 2.1MM JACK-PLUG POLARITY CHANGER BLACK 68-102-0 1 3.80
Subtotal $35.09
Shipping 4.49
Total $39.58

First off, I’ll say that I didn’t spend a ton of time sourcing the parts. Just a couple days casually browsing Amazon and Ebay. If I found something that looked like it’d work, I bought it. For $40, this is definitely not the cheapest way to do this, but it’s not much worse than buying three new power supplies at $9.99 each.

The nicest thing was finding out that the CCTV security camera market supports an industry of nice DC power cable splitters in a variety of configurations, which was the part I assumed I’d have to make myself.

The Build

Once I had the parts, it was a simply a matter of connecting everything. If it’s not straight-forward for you, it goes like this:

  1. Connect AC cord to the power supply.
  2. Connect the 3-way splitter to the power supply.
  3. Connect each of the two 2.1mm to 1.7mm adapter cables to a cable coming out of the 3-way splitter (one each for the Genesis and 32X).
  4. Connect the 2.1mm polarity changer to the remaining cable coming out of the 3-way splitter (for the Sega CD).

The end result should look something like this:

Since the plugs have different sizes, it shouldn’t be too hard to figure out which plug connects to each system. For the sake of simplicity, I put a bit of colored tape on each: red for Genesis, blue for CD, yellow for 32X, corresponding with the primary colors of the game boxes for each system.

The power supply works like a charm. I’m free from the three-wart tyranny!

Have questions or comments? Sound off below.

/jon