Jon Thysell

Father. Engineer. Retro games. Ukuleles. Nerd.

Tag: programming

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

Using a batch file to launch Gtk# apps on Windows with Mono instead of .NET

Mono is great for cross-platform development – maybe not so great for cross-platform deployment. In working on Chordious, a Gtk# app written entirely in MonoDevelop on an Ubuntu machine, there’s been no greater struggle than trying to find a simple “double-click” launch of Chordious on Windows.

Yes, if you stick with just the “standard” libraries and write your GUI with Windows.Forms, all an end-user has to do is double-click on your executable, and let .NET run it. But what if you don’t want that? What if your app needs to be launched by the Mono Runtime?

Realistically, the bigger hurdle is getting your end-users to install Mono in the first place – but even if you can get them past that – you’ll still need a double-click way to start your app. You’ll never convince them to start up a Mono command prompt and manually launch your app with mono.exe. And unfortunately for us, the Mono installer for Windows isn’t so nice as to add itself to the PATH, so you can’t just get away with a one-line batch file.

Enter StartMonoApp.cmd:

@echo off
setlocal

rem Script: StartMonoApp.cmd
rem Author: Jon Thysell <thysell@gmail.com>
rem Date: 7/15/2014

set _MonoApp=YourMonoApp.exe

rem Checking for 32/64bit machine

if exist "%SYSTEMROOT%\SysWOW64" (
    set WOW6432=\Wow6432Node
) else (
    set WOW6432=
)

rem Find default Mono version

set _MonoBase=HKEY_LOCAL_MACHINE\SOFTWARE%WOW6432%\Novell\Mono

echo Looking for Mono registry key %_MonoBase%

for /f "Tokens=2*" %%I in ('reg query "%_MonoBase%" /V "DefaultCLR" 2^>nul') do set _MonoVersion=%%J

if "%_MonoVersion%" equ "" (
    echo ERROR: DefaultCLR not found!
    goto nomono
)

echo Default Mono is %_MonoVersion%

rem Find the path to where that version of Mono is installed

for /f "Tokens=2*" %%I in ('reg query "%_MonoBase%\%_MonoVersion%" /V "SdkInstallRoot" 2^>nul') do set _MonoPath=%%J

if "%_MonoPath" neq "" (
    if not exist "%_MonoPath%" (
        echo ERROR: SdkInstallRoot not found!
        goto nomono
    )
)

echo Mono %_MonoVersion% installed at %_MonoPath%

rem Check for the mono.exe binary

if not exist "%_MonoPath%\bin\mono.exe" (
    echo ERROR: mono.exe not found!
    goto nomono
)

set PATH=%_MonoPath%\bin;%PATH%

rem Launch the app

pushd %~dp0

echo Launching %_MonoApp%

start mono.exe %_MonoApp% %*

popd

goto :quit

:nomono
echo ERROR: Unable to find Mono. Please install Mono and try again.
pause

:quit
endlocal

So let’s say you’ve got yourself a nice little Gtk# app named GreatMonoApp.exe. To make a double-click launcher that uses Mono, simply:

  1. Copy the contents (minus the line numbers) of the script above into Notepad.
  2. Update line 8 with the name of your executable (in this example, the line should read set _MonoApp=GreatMonoApp.exe).
  3. Save the file into the same directory as your executable. (You can name the file whatever you want, just make sure you save it as a .cmd, not .txt, file).

There you go! Double-click on that new batch file and your app should launch via Mono. You might see a flicker or two of command prompts, but otherwise works quite well. If something does go wrong, the command prompt will stay open with an (hopefully useful) error message for you to debug.

How does the script work? Essentially it looks for the registry keys that the Mono for Windows installer created, and uses them to find where the mono.exe binary is. Then it adds that folder to your PATH (temporarily) so it can use mono.exe to launch your app. And as mentioned before, if there’s anything wrong (can’t find the registry keys, can’t find the folder or binaries) the script will show an error.

I hope someone out there finds this as useful as I do – I’ve spent forever trying to solve this problem, with progressively more and more complicated scripts. I’ve verified that the script works on Windows XP, 7, 8, and 8.1, 32 and 64-bit.

Happy coding!

/jon

P.S. I have no reason to believe the script won’t work on Vista, I just don’t have access to a Vista machine to test it. Sorry true believers.

Rekindling a lost four-string love, Part II

My Ukuleles From Smallest to Largest

I first picked up an ukulele in the summer of 2002, but in ten years I hadn’t gotten beyond a half-dozen chords and one melody. By the time I’d moved to Washington State, my two ukes had become nothing more than decorations, empty hints that I was a musician (like guys who “accidentally” carry guitar picks in their loose change). If you haven’t yet, go read that story in Rekindling a lost four-string love, Part I.

Now, before I pick up my ukulele story in 2012, I first need backtrack a little to 2009, with my brief experience with another, inexpensive, “people’s instrument”. I’m talking about the tin whistle.

See, I like small, portable, entertainment. My favorite board games fit in a jacket pocket. I have packs of playing cards everywhere, in my bags, in drawers, even in my car. Now that I think of it, even back in college, when I was trying to learn the ukulele, I was also tried learning the harmonica. Harmonicas are legendary portable entertainment. The only problems were the breathing and all that tonguing. I could hardly keep my breath just being me, so playing wind instruments was just masochistic. Plus, I was trying to learn ukulele right? The harmonica quickly got lost in a drawer somewhere.

So, now it’s 2009, and I get the itch to learn an instrument again. I look at my ukes, but I think of my wrists, and I start shopping for alternatives. At the same time, I was also on a crazy personal mission to watch everything Star Trek, from beginning to end. Why you ask? Because I’ve been a self-claiming nerd for as long as I can remember, but when I really thought about it, I’d probably only seen a half-dozen episodes of The Next Generation as a child. So I set out to correct that.

Wait, what does this have to do with the tin whistle? Or learning the ukulele? Trekkies know the answer.

The Inner Light.

It’s one of the highest-rated Star Trek TNG episodes, and my absolute favorite. In it, Captain Picard, by virtue of a memory implant from an alien probe, experiences living an entire lifetime with a now extinct people. Most memorable is the titular song he learns to play on a little whistle. So now, sixty pounds lighter than I’d been in college, and with Captain Picard at my back, the idea of a wind instrument doesn’t terrify me anymore. I knew I’d found my new instrument.

Me and my Clarke Tin Whistle

Me and my Clarke Tin Whistle

I went online and bought myself a Clarke Tin Whistle, but much more importantly, I picked up The Clarke Tin Whistle Deluxe Edition by Bill Ochs. It was, by far, the best book on picking up a new instrument, any instrument, that I’d ever read. As I mentioned in Part I, I don’t have a musical background. And though I had a tall stack of ukulele books, most went straight into the grunt-work of learning an instrument, and just weren’t any fun. Frankly, I’d had enough of Mary and her damn little lamb.

But in Bill’s book, within a week, I had a half-dozen songs under my belt. Sure, Mary was in there, but so were others, longer, more interesting songs that sounded pretty even if I didn’t recognize them. Match that with the simplicity of playing the whistle itself, and I was having a blast. Presentation matters, especially for someone like me, with no musical background. And with the tin whistle, I had an extremely portable instrument that was fun to play, and with the book I felt like I was making real progress.

So why am I not writing about rekindling a lost six-hole love? Why did I put down that whistle?

Guilt mostly.

I felt like I should really be playing the uke. I mean I loved ukuleles. My grandmother had bought me one cause I said I was serious about learning it. I’d even bought an expensive one and dragged it around Africa with me. And so after a couple months, as I spent my time elsewhere, the little whistle went into the drawer along with the harmonica.

So why did it take another three years before I picked up the uke? Guess you’ll have to wait until Part III.

Update (02-APR-2013): Continue reading with Part III!

/jon

P.S. Though I set aside learning the whistle, I’d learned something else, something far more valuable. I’d learned that learning an instrument didn’t have to be all grunt work up front with all the fun at the end. That there was a logical progression to learning to play that didn’t need Mary and one chord over and over for hours. And in any area of study, it’s a powerful thing when you learn not just what you aim to learn, but the overall structure and progression for learning things of that category.

It just takes a good teacher. I learned my first programming language at age 8, but without any structure, any wisdom. I hadn’t internalized what it meant to program. It was through my high school computer science teacher that I got a grasp of how to learn a computer language. What to expect. What I needed to know to be able to use that language to solve the problems before me. That skill, learning how to learn a programming language, later became a cornerstone of my career as a software tester.

It’s the same thing with natural languages. When I learned French in high school, I didn’t really remember a thing later. Like most Americans, I had a scatter-shot of language education, especially grammar. Not that important if you’re a native speaker, as long as you’re surrounded by people who speak correctly, you’ll pick it up naturally. But for a foreign language, especially in my case, where immersion wasn’t possible or even encouraged, I was just parroting most of the time. I had no roadmap for turning my thoughts into words. But in college, I learned how to break a language down, to know what things I needed to learn, so that I could function in an immersive environment. By the time I was learning Swahili in Tanzania, I was driving my teacher crazy because I kept wanting to jump ahead of my classmates. I could see the bigger picture, and so knew ahead what I types of things I was going to need to know. But after ten weeks of training, when I was thrown in the deep end of completely on-my-own immersion, and I swam just fine.

Not to put too fine a point on it, but I ended up teaching computer science in Swahili. No way would I have been able to do that, if I didn’t understand how to learn programming, and how to learn a natural language. And computer science is hard enough to teach in your own language!