Reversing Choplifter(blondihacks.com)
blondihacks.com
Reversing Choplifter
https://blondihacks.com/reversing-choplifter/
43 comments
Someone reverse-engineered Robotron and found bugs in that too [1].
[1] https://web.archive.org/web/20130714200334/http://www.robotr...
[1] https://web.archive.org/web/20130714200334/http://www.robotr...
> (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?
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.
She is also the one who made that one famous post about armorplating her cat feeder
https://blondihacks.com/furiosas-cat-feeder/
https://blondihacks.com/furiosas-cat-feeder/
In her free time she's also given me the gift of learning home machining via her wonderful YT channel: https://www.youtube.com/c/blondihacks
Quinn is a full-spectrum powerhouse.
Quinn is a full-spectrum powerhouse.
yahtzee! (me too)
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.
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.
The people who reverse engineered Colonel’s Bequest had me floored. Super impressed.
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.
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).
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.
[0]: https://en.wikipedia.org/wiki/Choplifter [1]: https://www.arcade-museum.com/Videogame/choplifter
[0]: https://en.wikipedia.org/wiki/Choplifter [1]: https://www.arcade-museum.com/Videogame/choplifter
(the 1985 Sega arcade port is the one you'll find on all the ROM sites. It's much better.)
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.
[1]: https://en.wikipedia.org/wiki/Rescue_Raiders
[2]: https://www.youtube.com/watch?v=F8_XsRYTO-0
[3]: https://groups.google.com/g/comp.emulators.apple2/c/JwoKZKYQ...
[4]: http://retro.co.za/ccc/apple2/Wildcard/
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.
[1]: https://en.wikipedia.org/wiki/Rescue_Raiders
[2]: https://www.youtube.com/watch?v=F8_XsRYTO-0
[3]: https://groups.google.com/g/comp.emulators.apple2/c/JwoKZKYQ...
[4]: http://retro.co.za/ccc/apple2/Wildcard/
Rescue Raiders was next level.
It needs to be on iOS, but in the meantime, for the web:
https://armor-alley.net
It needs to be on iOS, but in the meantime, for the web:
https://armor-alley.net
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."
"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?
So I knew Quinn did machining stuff to make model railroads and whatnot. I was not aware she also did software engineering
She sure did/does: https://www.mobygames.com/person/61954/quinn-dunki/
> 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.
> 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.
Loved this game on the Sega Master System. It was so addictive but frustrating at times.
I remember it on Atari 2600 more than Sega myself. All the same it was definitely a very fun game at the time.
Ah! I can definitely relate to that ;-) Still can hear the rescue sound of people entering the chopper !!!
bleep.
Quinn's machining videos are also a joy to watch: https://m.youtube.com/@Blondihacks/videos
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.
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.
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.
Not an urban legend, he confirmed it in an interview with John Romero (great interview BTW: https://www.youtube.com/watch?v=S3EmtTpoEa8 )
Some notable exceptions I'm aware of...
Ultima I was written in Applesoft BASIC with portions in assembly.
https://en.wikipedia.org/wiki/Ultima_I:_The_First_Age_of_Dar...
Wizardry was written in Apple Pascal.
https://en.wikipedia.org/wiki/Wizardry#Development
https://en.wikipedia.org/wiki/Apple_Pascal
Ultima I was written in Applesoft BASIC with portions in assembly.
https://en.wikipedia.org/wiki/Ultima_I:_The_First_Age_of_Dar...
Wizardry was written in Apple Pascal.
https://en.wikipedia.org/wiki/Wizardry#Development
https://en.wikipedia.org/wiki/Apple_Pascal
Great article! Quinn should get in touch with Dan to see if he remembers the answers to some of the questions she had.
For a brief moment, I thought it was the one about not being able to resize the bookmarks dialog since rewrite took place.
HN hug of death
Choplifters of the world unite and take over
A very difficult read for me… hard to get past all the auto fellatio.
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.
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.
Ah, should have guessed as much with all the patreon and YouTube links on that website. You got me.
> 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.)