First thing I wanted to get setup was at least get the basics of my build pipeline installed.  This is based on a blog post by Quinn Dunki, things have changed a bit and I wanted to verify the steps.

To get what we need, we will need to install the the following:

  1. cc65 – To compile the code
  2. AppleCommander – To put the compiled executable onto a floppy disk image
  3. Virtual ][ – To boot and test the image

Installing cc65

Installing cc65 on the Mac is pretty easy as there is a bottle under Homebrew to install it directly.  If you don’t have or have never used Homebrew, it’s a great way to install extra software in a way similar to MacPorts or Fink. Homebrew is easy to install, just follow the directions on their site.

Then to install cc65, simply do:

That’s it.  Pretty simple.  But, let’s try a simple test compile:

So far, so good.

Installing AppleCommander

For the build pipeline, we also need AppleCommander.  Luckily, we can also install this with Homebrew by using this Apple II homebrew repository.  First we need to “tap” the repository then we can install AppleCommander from there.

But, let’s make sure this part is working as well.  Let’s put the “helloworld” executable on a DOS 3.3 bootable disk and try it out.  You can get ”

Again, looks good so far.  Next!


  • The image created by -dos140 will not be bootable and, as you will see below, we will boot the DOS System Master 3.3 disk then run our image off the other disk.  In the final, I’ll INIT the test disk before hand and reuse it as needed to boot
  • When putting the executable on the disk, you’ll need to use -as (AppleSingle) flag when using AppleCommander.  This replaces the -cc65 flag mentioned in Quinn’s post.

Installing Virtual ][

So far, we’ve been able to ride the build pipeline for free, but here is where need need to get off that train and pay piper (See what I did there?).  To me, Virtual ][ is the go to emulator for the Mac and is worth every penny it costs.  It 44USD for the full license.  Like I said worth every penny. You can get Virtual ][ here.

Once you install it, you’ll need to get the correct ROM for the machine you want to run.  I run an Apple //e as my physical machine, so I also like to run a //e as my virtual testing environment.  You can find the ROM you need without a lot of digging, so I’ll leave that as a exercise for the reader.

The important part about using Virtual ][ that I’m not sure other emulators do, is that it has AppleScript support so it can be controlled from scripts.  This is important to the build pipeline so it can load and boot the disk image as part of the build.

To verify Virtual ][, let’s boot the “Apple_DOS_3.3_Master.dsk” (found on Archive.org) in drive 1 and the image we created above in drive 2.

Everything looks good.

Notes/updates compared to Quinn’s post (i.e. TL;DR)

  • cc65 can be installed via Homebrew.
  • AppleCommander can be installed via Homebrew after adding the Apple II homebrew repository.
    • The AppleCommand command line executable is “applecommander” not “ac”
    • The “-cc65” flag has been removed and you need to use “-as” or “-dos” as appropriate. In our case, it’s “-as”


Next, I’ll be looking to generate a CMakefile (which CLion uses) to do similar work and link these together.

In order to help motivate me to get some retro-computing work done, I signed up for RetroChallenge 2018/04.  If you don’t know what RetroChallenge is, well it’s an informal contest (that’s not really a contest) for doing retro-computing related projects.  Basically, it’s a way to help incentivize retro-computing enthusiasts to get off their butts and do something cool.

For my project, I have a main goal and some sub goals.  Mainly so I can feel like I accomplished something even if I don’t completely finish it in April.

Here is what I’m planning on doing for this challenge.   I’m planning on writing a game for the Apple ][ that is similar to an iPad game called CargoBot (iTunes link), which is a box sorting game that you need to program the crane to sort the boxes in the fewest amount of commands as possible.

Here are my goals as part of this project.  Mostly in order, but who knows. Feel free to keep score, if you like.

  1. Develop a build pipeline for use with the JetBrains tools (IntelliJ/CLion) similar to, and where I will borrow from, work reference by Quinn Dunki in this blog post.  As she mentions in the post, she is standing on the shoulders of (bald) giants, so I guess I will be standing on (the shoulders of giants)².  And, yes, I’m (mostly) bald, as well, so there is that.
  2. Build the core engine while comparing the tradeoffs for memory usage and performance by trying compact/verbose level formats.  Because, the geek in me wants to make it as small as possible but the gamer in me wants to to actually play it.
  3. Make the rendering of the game to modular so I can render it in any of the following modes:
    1. Text – Easiest way to vet out the engine.
    2. LoRes – Because I can.
    3. HiRes – Because I should.
    4. Double-HiRes – Because I shouldn’t, but I’m gonna anyways.

Some things you might see along the way, so don’t be frightened:

  1. Banging my head on my desk in frustration, because impact-maintenance is a real thing.
  2. Me pulling my hair out, which is a challenge in-and-of itself (see reference to being (mostly) bald above).
  3. Goofy graphics issues.  I’ve played with some HiRes stuff earlier and it’s “interesting” (Minnesota slang for “sucky”).  If you want to point and laugh early, you can look back and see the struggles I’m probably going to have to go through again.
  4. Swearing.  Well, only if you are nearby when this is all happening.  I’ll keep the blog family-friendly but I’ll make no such promises for real-life.

I encourage you to follow along.  We can laugh together (or you can laugh at me), we can cry together (as there may be tears) and hopefully we can play together (well, not together, but you know what I mean).

Let the challenge begin! (Well, tomorrow)