Category Archives: reviews

2018 Compilation and Review

2018 has come and gone, so it’s time for me to do a summary post and collection of my work on Bumbershoot over the year.


The various projects I did on this blog in 2018 are now collected for download in a single zip file. 2018 was marked more by a series of larger projects rather than a swarm of small programs. I had four sizable projects I worked through line by line and built from first principles:

In addition to those, there were a handful of smaller programs created along the way to test my build systems or my grasp of specific hardware techniques:


2018 was the most active year for the blog by a factor of about two; this is the first year I cracked 5,000 page views, 50 articles, and 100,000 words. The most popular articles this year were largely the same as last year, covering weird CGA modes and file formats and machine code linking on the ZX81. Sneaking into the top 5 was my article about the VSP Glitch on the C64, which seems to have rocketed above my other C64 articles thanks to a Reddit comment linking to it as an explanation for how Mayhem in Monsterland managed its high-speed scrolling.

The three articles I wrote this year that got the most views were the beginning and the end of my Atari 2600 project, and the post on the legacy sound chip on the Sega Genesis. All them seem to, again, have risen above the other articles due to links in forums. As usual, though, Bumbershoot Software mostly works as a standing reference, and search engines drive more traffic than everything else combined by an order of magnitude.

Other Stuff

Off of my usual topics, 2018 was also interesting in that it saw the release of five games that were very different from one another but also targeted quite narrowly at my current gameplay interests. I can’t really rank them against each other for a top five list, so here they are in alphabetical order:

  • Celeste. I played a lot of Thorson’s early work—most notably the Jumper series—and while those were occasionally a bit rough-hewn I consider them foundational to the “challenge platformer” subgenre, which also includes games like VVVVVV and Super Meat Boy, but which distinguishes itself from “masocore” games like I Wanna Be The Guy by always honestly presenting what the current challenge is. (This measure, which I discussed as part of what “perfect play” means across genres, does mean that Limbo also stands with I Wanna Be The Guy despite having much more forgiving platforming challenges.) Celeste is an extremely well-polished challenge platformer and quite possibly the best example of the subgenre now extant. It achieves this through excellent controls and map design but also through accessibility—while much has been made of Celeste’s Assist Mode, even a player whose training and reflexes are a match for the intended design will find that the most punishing or abstruse stages are hidden behind clearly optional unlocks. I have observed that Super Meat Boy is in part about testing the player to destruction, and that as a result its plot and ending cutscenes and such are all extremely perfunctory. Celeste actually wants to tell a story alongside its challenges and it puts the more generally-inaccessible stages in places where no story is being told. It’s a very effective combination.
  • EXAPUNKS. Zachtronics games are, in effect, a series of programming challenges. I like them, but I often have trouble sticking with them because it’s hard to motivate myself to write assembly language programs for pretend computers when I could instead be writing assembly language programs for real computers. The earlier Opus Magnum avoided this fate for me by not being as obviously a programming exercise even though it was one (you schedule motions of mechanical arms to assemble alchemical compounds), but EXAPUNKS seems to avoid it by having a sufficiently exotic programming model. Commanding cute little spider robots to run rampant through a pretend network seems to be far enough from the retrocoding projects I actually do to keep the challenges from interfering with each other in my motivation.
  • La-Mulana 2. The original La-Mulana was an homage to the MSX generally and Konami’s Knightmare II: Maze of Galious specifically. However, Maze of Galious was in my opinion an unplayable mess, while (with a few exceptions) La-Mulana managed to be crammed full of tricks and secrets and still mostly work. It did this by (apparently unconsciously, since they’re open about their inspirations and didn’t list this one) lifting a lot of design aesthetics from Myst—overwhelm the player with information and have all of it be relevant to something eventually. This is then layered on top of fairly-traditional action-adventure exploration gameplay. When that game was refined and modernized for the Wii, the parts that were problematic in the design were polished away and the combat was rebalanced and generally improved. At that point it stopped being a quirky obscure freeware game and started being an interesting genre-jam game that didn’t get imitated. The sequel is in some sense more of the same, but since the original hasn’t been imitated since its release more of the same was very welcome.
  • Return of the Obra Dinn. This is a first-person adventure game in the Myst mold, but manages to evolve the formula there in meaningful ways. Standard Mystlike games tend to involve using information in the environment to bypass obstacles, which in practice often reduces to replacing “find a key somewhere and use it to unlock a door somewhere else on the map” with “find a combination written on a wall somewhere and use it to open a combination lock somewhere else on the map.” Sometimes you’ll have to build the combination out of a lot of disparate pieces—Riven and the La-Mulana series both excelled at this—but Obra Dinn evolves the formula by requiring more aggressive deductive work on the part of the player to get the answers required. Despite being technically just a new, improved twist on a classic game design, it’s been long enough since Riven that this game was received like a bolt of lightning from a cloudless sky. It’s not that good but it is very, very good—and if you didn’t play the old Myst and La-Mulana games, you may indeed have never seen anything like this before.
  • Yoku’s Island Express. This is a super-cheerful action-adventure game built around pinball controls, starring a dung beetle turned postmaster drafted into a plan to save the island’s local gods. Despite all that it remains relentlessly cheerful all the way through (you have a dedicated button to blow a party horn and possibly throw confetti around—while there are in-game reasons to do this you are free to deploy it at any point) and I found the difficulty to stay well within reasonable bounds. I’m not very good at pinball, but I was able to work my way through the game without too much trouble, and it also neatly avoided what I think of as the biggest problem with high-level pinball play—the path to high scores usually involves finding some technique that’s reasonably high scoring and that one can perform with extreme consistency, and then doing that thing for as long as your endurance and precision can hold out. Here, because you have actual plot objectives to accomplish and a cap on “score”—where a normal pinball game would grant bonus points, you get bonus money instead, and there’s a cap on how much money you can carry at a time—you are always encouraged to attempt sequences of more varied skill shots to progress. It’s an interesting case study in how mixing another genre of gameplay into a game can address shortcomings in the original genre’s gameplay.

Bumbershoot Software in 2019

2018 saw me complete my ambition of doing a software release for every platform I grew up with. As such, I don’t have any big pressing projects bearing down on me this year as things I really want to attack going into the new year. That said, this was the state I was in for most of the year and I wrote more than I ever have, and got several releases out to go with them.

As such, I’ll be walking into 2019 with no firm plans for the blog but confident that something interesting will ultimately come up. Onward we go!


Looking Back on the Mac

Earlier this month, Ars Technica ran an article on attempting to use a Macintosh IIsi in the modern day to do actual work. I was never really part of the classical Mac world—even our school computer labs were either Apple IIgs machines or 32-bit x86 systems. (While I wasn’t really aware of it at the time, based on what I remember of the labs I think they were actually running DOS under Novell NetWare.)

What I found interesting was that this wasn’t the first time they’d done a stunt like this; four years or so ago they pulled the same stunt with a G3 PowerBook running System 9. This was interesting both because the author there had much more trouble dealing with System 9 than the newer author had with System 7, but also because it linked to Ars Technica’s comprehensive review of OS X 10.0 during its public beta period and initial release, and those initial reviews were unkind indeed.

The thing that jumped out the most at me from looking through these articles was the way classic Mac OS was presented as a system designed to be aggressively micromanaged and configured within an inch of its life. I first seriously entered the Mac world around 2008 when the transition to Intel architecture was just starting to get entrenched with consumers. By then, the common stereotype was that Apple systems were designed to make basically all design and interaction decisions for the user and personalization of one’s computing experience was generally considered a Bad Thing by the community. This stereotype very clearly had no basis until OS X, and in the runup to the OS X initial releases there was a palpable sense of panic from the writing that the System 9 faithful were going to be relegated to a niche market not worth serving in the new world.

In retrospect, I should have recognized some of this in advance. Around the time I was learning to develop in and for Mac OS X, I encountered Andrew Plotkin’s silly user-experience diary of installing and acclimating to Mac OS X 10.1. A lot of the trouble he had revolved around setting up his interaction model to let him work the way he wanted to. In rereading it now I’m struck by the way his “One True Way” of organizing applications in the Apple Menu matched the ways I organized my Start Menu back in the days when you organized your Start Menu rather than running a search engine over it.

I did not, and still don’t, have much interest in learning about the internals and idioms of classic Mac OS. Everything I have seen about it reminds me of what I consider the “awkward era” of personal computing, running from about 1995 through about 2005. We knew, more or less, what we wanted a personal computer to be, at this point, but the only machines that could actually do it were workstation-level systems that, while they weren’t exactly filling entire rooms, still ended up costing tens or even hundreds of thousands of dollars. After the home computer apocalypse of the early 1990s, Apple and Microsoft ended up evolving their systems towards an ideal obviously set by systems like SGI Unix workstations—but they needed to preserve the things that made their computers attractive to their users along the way. The story of Mac OS from System 7 through OS X 10.4 or so and the story of Windows from Windows 95 through Windows XP is one of that evolution, with the steps necessary to reach that endpoint taken in very different orders.

Unlike the Windows case, though, where XP was acknowledged as the NT line of business-level operating systems finally getting compatible enough with consumer hardware and Win9x-era software to let consumers use an NT kernel with all the benefits that was already known to have, it seems undeniable that in the Mac OS 9 to OS X transition, something real was lost.

Hamurabi for the C64

As 2016 draws to a close, I sweep up my old projects and finish and publish those that have been sitting around in a state of benign neglect. Today, that is a Commodore 64 port of the old management game Hamurabi.

This hadn’t really been intended for publication—I made this port to test a floating-point library I was building for my Ophis assembler. This library was a bunch of macros that called routines in the BASIC ROM. Hamurabi was a fairly short game that also used a lot of floating point, so my plan was to implement it with the library to put the library through its paces.

This resulted in a straightforward but perhaps overly macro-heavy translation of the BASIC original—I also took advantage of the C64’s longer filename length to give Hammurabi a properly-spelled name. I’ve extended it so that it does not depend on the Ophis libraries.

So, why is this interesting? Well, it was interesting to me because it turned out that some of my assumptions were too generous. The subtraction and division operations require certain preconditions to hold, and while there are a great many routines that load the floating point accumulators, exactly one does so while also making those preconditions hold. (ld_fact2_mem, if you are following along the code.) Some of my macros weren’t prepared for that, so this did succeed in improving the system.

The other reason it’s fun is because in doing the translation I had to pay closer attention to the code than one would for a simple type-in program. That means that I can now write a strategy guide based on how the game works! This was the inspiration for the entire city builder genre, so it’s interesting to see how things have changed over time.

I’ve done game reviews before. Let’s overanalyze a game designed in 1968 and published for microcomputers in 1978!


Hammurabi Strategy Guide

In the uncertain economic times of Bronze Age Sumeria, bushels of grain are the only reliable store of value. As king, your job is to control the flow of grain to ensure the prosperity of your people. Here are the raw numbers:

  • Each citizen needs to eat 20 bushels of grain to survive the year.
  • Each citizen can farm 10 acres of land.
  • One bushel of grain can plant 2 acres of land.
  • Each year, your land will yield up 1-5 bushels of grain per acre planted, with a 20% chance of each. (In any given year, each acre will have the same yield as each other one.)
  • After feeding and planting, but before harvesting, there is a 40% chance that rats will get into your grain silos. If they do, there’s a 50% chance that they’ll eat a quarter of your remaining grain, and a 50% chance that they’ll eat half of it.
  • There is a 15% chance each year of a devastating plague that kills half your population.
  • Each year, land can be traded between you and your neighbors for 17-26 bushels of grain per acre (10% chance of each price).
  • Immigration is random, but goes up the more land you have and the more spare grain you have.
  • If you starve 45% or more of your population in one year, you immediately lose the game.
  • Otherwise, at the end of 10 years, you are graded based on how much of your population starved over the years and the amount of land available to your population per-capita.

Adding this up, the goal of the game is to not starve your population, and that means not eating your seed corn and having a few good harvests. Speculation in real estate can help but it’s a temporary solution at best. Selling land to feed the populace and not buying it back before the end will also hurt your score.

You don’t need much luck. Sumeria is fairly sustainable as it is. Each citizen needs 25 bushels of grain each year to be fully productive and healthy; 20 to eat and 5 to plant the 10 acres they work. The average harvest per acre is 3 bushels, so each fully productive citizen is, on average, a net +5 bushels of grain to your stores. That can help weather bad harvest years or can purchase more land for immigrants to work. Turning spare grain into land is also useful because unlike spare grain, spare land cannot be eaten by rats.

Spare land also, in principle, improves your end score, but in practice, spare land has nothing to do with your skill in bronze age real estate speculation and everything to do with horrific plagues. Plagues, you will recall, halve your population, but leave your grain stores and land holdings completely intact. You also aren’t blamed for plagues the way you are for people starving. Horrific plagues, for you, are basically pure upside. Per-capita land doubles, and your remaining grain stores go twice as far, and the survivors are happier than they were before.

So it seems like the only thing that can really ruin you is a run of bad luck (1-bushel harvests, unhelpful land prices, good health). As written, really, the main challenge of the game comes from the interface encouraging fatal errors. You are asked to cmmit resources in increasing order of importance to your long-term survival. First you buy or sell land, then you eat, then you plant. You’ll need to work out each year’s moves in advance with a calculator to be sure you sell enough land to feed your people without also eating the seed corn. You basically cannot survive failing to plant enough grain—and this is the last question asked, where it is too late to alter anything else.

And this really is the whole challenge, once you know the mechanics. One could imagine a modern GUI interface to Hammurabi, where you would tweak sliders for for land, food, and seed, with each set to sensible defaults, and such a version would basically play itself. I suspect this is a major factor in why later, similar games (such as King, from the same series of type-in BASIC programs) put you in charge of a rapidly deteriorating death spiral. There, the challenge is to evade total disaster long enough to run out the clock and walk away from a smoking ruin before too much blame accrues to you. Here, though, the task is simply to not mess up too badly.

A Tour of 6502 Cross-Assemblers

Recently, I decided to revisit one of my projects from over ten years ago; a tiny game for the NES that I’d written with a very early version of my assembler. I’d actually developed that assembler in the first place because the options I had available at the time didn’t work the way I wanted them to, or were excessively finicky or underpowered, or weren’t freely available, or didn’t run on my system.

The world’s gotten better since, both because I’ve been part of more communities and seen more things, and also because tools have been better developed and disseminated. I can say with some confidence that had I known about the ACME assembler back in 2002 I would never have written Ophis.

As I was restructuring and bugfixing that old project—which also involved porting it over to ACME—the Habitat project of the Museum of Art and Digital Entertainment released Chip Morningstar’s Macross and Slinky, a structured assembler/linker system. I spent a weekend helping to bash that into a shape that runs on modern systems.

So this is all quite interesting because there are a great many assemblers out there for the 6502 series of chips, and all of them have subtly different features and semantics. I seem to have moved from a world where I couldn’t get an assembler that worked the way I wanted to needing to figure out how to differentiate a plethora of slightly incompatible options.

In working a bit with various assemblers, these are the things I think are important when picking an cross-assembler for your project.

Dramatis Personae

I’ll be comparing the following assemblers:

  • Ophis. This is the assembler I wrote back in 2001 to teach myself Python and have developed on and off over fifteen years, since I’d never found anything that let me easily target the platforms I wanted to target. It’s what I’ve used for pretty much all my examples on this blog.
  • xa65. One of the only 6502 cross-assemblers you can reliably find in Linux repositories.
  • CA65. This is the assembler for the CC65 development suite. It is now the assembler recommended for use by the NES development community.
  • ACME, aka ACME Cross-Assembler for Multiple Environments. Has a pretty strong Commodore/Apple bias, but also is one of the few 6502 assembler syntaxes to be represented on Pastebin.
  • 64tass. Designed to mimic Turbo Assembler. This is a favorite amongst many of the folks I talk Commodore with.
  • Kick Assembler. Another common one for sample code; The C64 codebase wiki seems to like this one.
  • Macross. The development system for LucasArts’s 6502 and 68000 products. In one sense, the oldest tool here, but in another, the newest kid on the block. Its ideas of code organization make it a very low-level high-level language more than anything else, so its idea of what features are important are thus very different.

Continue reading

Problem Attic and the Rhetoric of Platformers

A couple weeks ago Emily Short did a post about Liz Ryerson’s 2013 puzzle platformer Problem Attic. This came up in a context about having little but nonzero influence over a situation, compared to more traditional extremes of power fantasies or games where lasting accomplishment is strictly impossible (The original context was for games explicitly about helplessness, but I would include almost every classic arcade game there too. Asteroids invariably ends in shipwreck; Missile Command in your nation a radioactive wasteland. The closest the player can get to success is to stave off the inevitable just a little while longer.) Problem Attic was brought up as a game that did this via platforming mechanics.

That made this a must-play for me and I also decided to do it without reading much about it. I’m holding to that decision; mechanics are in some sense mute but in another sense they speak entirely for themselves. Short had mentioned that she was “relying on the expertise of other players both for the experience of gameplay in this case and for the rhetoric of platformers in general” due to the game being inaccessible to those lacking the appropriate skills. That’s generally not a problem for me—platformers are one of my “native” game genres—so I tried to play it blind and did ultimately succeed in completing it.

I don’t think I can honestly recommend Problem Attic, for a variety of reasons:

  • The game is intentionally unpleasant to play. It’s using a glitchy aesthetic, dissonant sounds, and wonky controls. The first piece of undistorted text is “press R to restart”, but the second is “GO FUCK YOURSELF”, and while people often say that games that are difficult to interact with should be played for the message, I do not particularly feel that my readers need to be told to go fuck themselves.
  • The implementation is a bit glitchy in ways that are not part of the glitchy aesthetic. I managed to soft-lock the game three different ways, and one of them actually did not let me restore the game to a playable state via pressing R. That’s always a bad thing to have happen in normal play, but I feel it is much harder to forgive in a game that deliberately blurs the line between intended actions to progress and forcing the game world into impossible states.
  • It’s firmly in the “masocore” subgenre of platformers, in which correct action is intentionally unclear. It doesn’t do anything particularly amazing with this subgenre; it’s just a fact of life. While this is not universally considered a flaw, a large enough group of players considers this something they must forgive in order to consider the game worth their time that I will list it here. (I am in that group, as it happens, but I did ultimately forgive it.)

So, that’s why not to play it. If you can get past all those things, it’s pretty short and (time lost to replaying after crashes aside) not disrespectful of the player’s time. Also, when it comes to telling a story through mechanical progression, it does in fact do a great many things right.

So let’s talk about Problem Attic and how it uses mechanics to express things. I will, of course, be spoiling the heck out of lots of stuff, and if you’re going to play this at all, you should really play it cold.

Continue reading