Very cool read over-all. Finding a bug in a game that is over four decades old is hilarious.
> What was amazing though is that all throughout all the code that handles scrolling and clipping, vertical parameters are supported.
Possibly the vertical parameters were either 1) part of the "library" the author had created but not needed for Choplifter, 2) to allow for offsetting the world on other (6502-based) platforms or 3) maybe intended for "bumping" the display when the chopper crashed?
Sounds both tedious and fun (the way solving a logic puzzle is "fun").
(A little surprised to find that Quinn does more than just work on steam engines as I have watched her YouTube channel for some time now — watching her building on her metal lathe and mill.)
> (A little surprised to find that Quinn does more than just work on steam engines as I have watched her YouTube channel for some time now — watching her building on her metal lathe and mill.)
Same! Her Youtube channel is the best resource I know for the hobbyist machinist. What a breadth of knowledge. I don't know how old she is, but would guess she probably wasn't even born when this game came out, so I'm astounded to learn she has decades of experience with Apple II dev.
--
Tangent, but curious if anyone knows why I'm seeing a handful of ' ' / U+FFFC OBJECT REPLACEMENT CHARACTERs peppered throughout the post on Linux FF? From their position at the end of sentences I figured they were emojis my system is missing, but I pulled it up on my phone and there's nothing there - or more accurately, it seems iOS Webkit just renders U+FFFC as a blank space. Emojis that got garbled by her CMS perhaps?
I wasn't aware she did steam engines - I knew about her from her "Veronica 6502" computer, which she designed and built. And lots of other computer hacks. She's certainly versatile.
I love doing this kind of stuff - it's endlessly engrossing to me. Lately I've been trying to find previously undiscovered cheat codes in 1990s console games - there are lots that never made it into the magazines! (Findings are on 32bits.substack.com).
The availability of the Ghidra reverse engineering tool suite, has made this a very accessible hobby if you have any sort of knowledge of low level languages.
One technique that this doesn’t mention is comparing state of the system across time.
If you frequently snapshot memory during normal gameplay and then, for every byte of memory, check whether it gets modified at all, you’ll probably spot many of those inline parameters to subroutines fairly easily, as small areas of memory that see updates inside a sea of static code, likely preceded by a RTS.
If, in addition to looking whether things get modified, you look at what values they take and how they get modified, you likely can spot things such as the score (it’s a fairly safe bet that is stored as a multi-byte number in contiguous memory, either as BCD or binary) or number of lives left (gets decreased during gameplay)
On current hardware, you probably can also add code that hunts for correlations between what happens on screen and what’s in memory. Those might help you to find a correlation between a memory location and the flight height of the chopper, for example.
It likely also is possible to detect, say, the code for shooting by frequently sampling the program counter, comparing a set of samples from flying around without ever shooting with one of flying around while shooting constantly.
Given today’s powerful hardware, there’s a lot of automaton that can be done on this.
I can even envision using modern AI (“there’s a helicopter on screen. What memory locations seem to store its height and orientation?”) for reverse engineering 8-bit games.
Tom7 implemented some of this with his Learnfun and Playfun (https://www.youtube.com/watch?v=xOCurBYI_gY) -
It looks for lexicographical changes to bytes in memory (i.e., one byte seems to almost always increase, and then when it suddenly decrements, a neighboring byte is incremented) as a way of calculating memory location for increasing values (score, x-position), and similarly detects bytes that generally seem to decrease (lives).
It then tries to play the game, choosing inputs that increase the values that should be increasing (move right, gain lives), or tries not to decrease the values that are decreasing (don't die).
This refers to the 1982 Apple II original version of Choplifter [0], not to the 1985 Sega arcade port [1]. Hence I couldn't at first understand claims like "There’s only one level, only three enemies, and you can play it to completion in a few minutes."; the 1985 version has much more.
I remember seeing choplifter in action at a nearby computer store. The salesman showed us the game while demoing an Apple ][ then boasted over the fact that he could also just switch the TV serving as a monitor over to a broadcast channel to watch soap operas.
Choplifter, not to be confused with Rescue Raiders[1,2], except in my memory, along with its cheat code: zippybobbypin (turns out it was actually zippy or bobbypin depending upon which cracked copy you had)[3].
Speaking of games which load fully into memory, there was a peripheral card called the Wildcard[4] which would snapshot memory to disk, making it trivial to make "backup" copies of such games. A handful of in-memory games would thus check periodically that the original disk was still present.
I'm sad that Rescue Raiders doesn't get the credit it deserves. I'm not going to argue that it's the original Real Time Strategy game because people are vehement that it's NOT an RTS. But I think it is and it's amazing that it came out in 1984.
I m a bit surprised by TFA: most C64 games, by very far, would also run entirely in memory. Some would load mid-game or even use several disks (like Ultima) but these were the exception.
I don't understand your surprise, because TFA says the same thing about C64 games:
"However the Apple II disk drive is very fast, so unlike the Commodore 64, single-load games went away quickly. C64 games did a lot of work to stay single-load since the C64 drive is so slow, but on the Apple II, running back to the disk to load your title screen, menu system, or new levels was no big deal."
That was out of necessity. The C=64 floppy drive was so painfully slow that using it for gameplay without causing stalls would be close to impossible. The few games that tried (there was an Elvira RPG for example) were plagued by long loading screens. The C=64 was also gifted with a higher than average amount of RAM for the era, making it practical to fit entire games in memory.
The article says "C64 games did a lot of work to stay single-load since the C64 drive is so slow" - what are you surprised by, since you seem to be in agreement?
> Choplifter was written by Dan Gorlin in 1982, and published by Brøderbund. That date, 1982, is especially noteworthy. The game came out just a few years after the original Apple II did, and it remained one of the best games on the platform for sixteen years.
> However in terms of pure fun, Choplifter remained hard to beat for sixteen years...
I want to know what happened in 1998 that made Choplifter stop being one of the best Apple II games.
Probably refers to the Apple II having a sixteen year production run but since Choplifter came out five years after the computer did, it's at best a clumsy statement.
Semi related, but far later is the work that Crash Bandicoot took in order to work well with CD based loading, they optimized the disk positions of content, etc in order to make it look seamless.
Would this have been written in C, asm, or something else? I suppose with Atari & Mac II both being Motorola processors the assembly would have been a direct lift except for any Apple-specific UI.
My favorite part of the story was the latent assertions looking for the bug. Any new code I write is peppered with these, though only active in debug builds. I've never learned to enjoy stepping through a debugger.
Most of the classic games from this era were written in 6502 assembly language. There were a number of popular macro assemblers available, C compilers were a bit more exotic. Given that the entire executable fit in 48K, there was no runtime library here.
There's an urban legend that Nasir Gebelli wrote his most popular games with the tiny mini-assembler in the Apple ][ ROM, opcode by opcode.
That's highly unlikely, given the gender of the writer.
As someone who spent too much time in junior high playing with Apple II+ computers, I have a lot of respect for the level of fanaticism that went into this disassembly work.
> What was amazing though is that all throughout all the code that handles scrolling and clipping, vertical parameters are supported.
Possibly the vertical parameters were either 1) part of the "library" the author had created but not needed for Choplifter, 2) to allow for offsetting the world on other (6502-based) platforms or 3) maybe intended for "bumping" the display when the chopper crashed?
Sounds both tedious and fun (the way solving a logic puzzle is "fun").
(A little surprised to find that Quinn does more than just work on steam engines as I have watched her YouTube channel for some time now — watching her building on her metal lathe and mill.)