Tag: 6502 assembly

Hacking Alternative Maps into Superman (1979, Atari 2600)

My research on Superman has lead me to a deep understanding of the map topography, and I have come to regard it as an inspired design. But whenever I hear people talk about Superman, I feel like I must be in the minority. People who like the game tend to agree with me, while people who don’t, don’t.

Often I’ll hear players who do not have the appreciation for the game that I have complain that the map is a weakness in the design. I always rebut this by saying that yes, it’s confusing at first but once you learn it, it’s actually a strength. I can point to all the shortcuts that are made possible by the map topology, its utility in weighting the randomness of the AI movement, and argue that it’s actually beneficial that the map is confusing, because it makes the overworld seem bigger than it really is, and adds to the challenge of the game.

But I think it would be even more convincing to demonstrate alternative maps, and let players experience them and decide for themselves.

It’s fairly likely that I’m the only one in the world who cares about this, and I’m almost certainly the only one who cares about it as much as I do. But what the hey.

I decided to see if I could could learn how to hack the ROM for Superman, and change the map navigation in order to rearrange the map screens. This would be preferable for authenticity, but it might also be limiting, in terms of what’s actually possible.

If that doesn’t work, or if I have ideas for expanding on Superman‘s design that aren’t feasible in a romhack, the other option would be to remake Superman in GameMaker, keeping it as faithful to the Atari version as possible, and experiment with the map that way.

Alternative Maps

The easiest Map design to implement would be to make the vertical and horizontal sequences identical, and to make up/right be “forward” and left/down be “backward”. The subway system could be left unchanged, up to go to the next station, and any other direction to exit back to the overworld, keeping the exit screens the same as in the original. At the end of the list of overworld, we can loop back to the beginning.

The biggest problem with this redesign idea is that there are no overworld shortcuts, other than to take the subway. To get to/from anywhere, it is always a straight line. This is slow, tedious, and to me, it seems like it would be boring. Subway travel helps somewhat to speed up travel, and becomes more important. But a bigger problem is that the gangsters can’t really spread out deep into the map by randomly moving in one of four possible directions. Their possibilities have been halved; they can only go forward or backward to the next screen, and so they will all be found in the first few screens, and rarely if ever would they make it to the end of the map.

But on the plus side, this map is extremely easy to navigate, much harder to get lost in. Gone are the one-way vertical transitions from the Phone Booth and Bridge screens, and the confusion they created. This might make it an ideal variation for a very young player, or for someone who is very inexperienced with Superman.

The other easy to understand map would be a cartesian grid. We have a problem in that 21 overworld screens do not map neatly to a regular grid of equal rows/columns. We can take a 5×4 grid to get 20 of the rooms in, with one room left over. We could truncate the overworld to simply remove this screen, which is the easiest solution. At the end of each row or column, we can either have a hard edge, where you cannot proceed beyond, or we can wrap around to the start of the row or column, or we can increment the row/column and move to the start of the next row or column. I’m not sure how to make a hard edge work, though. The easiest way would be to make these edges refer back to the same room, but doing it this way, Superman would still warp to the other side of the same room, which would be weird. Still, as a proof of concept, it’s quick and easy to do.

The advantage of this map is that it would be still be easier to understand and learn. The disadvantage is that, at least using the first two traversal approaches, you can no longer go through the entire overworld by going in one direction. When the world loops, it will only take you to the beginning of the the current row or column.

The ROM Hack

I looked into it and discovered that the ROM hack path would be much easier than I had anticipated. So much of the work had already been done for me by others.

  • I searched the web and found decompiled assembly source code for Superman, which had been nicely annotated.
  • I learned that sometime in the recent past, someone named chunkypixel had released a Visual Studio Code extension called Atari Dev Studio.

This saves me a ton of time. I don’t have to learn how to disassemble the rom myself, and I don’t have to learn 6502 Assembly well enough to be able to make sense of the disassembled code to figure out what’s going on.

So, literally, all I had to do to get started was:

  1. Install Visual Studio Code
  2. Install Atari Dev Studio plugin
  3. Open the decompiled superman.asm
  4. Edit it
  5. Compile it
  6. Test it in Stella

I’m astounded that it’s this easy. The annotated source code is documented well enough that I can tell where I need to make my edits, and what the changes I need to make are. Hats off to the homebrew community for developing these tools and making the information generally available!

First, I did a test compile to make sure that the decompiled assembly that I had was viable. It compiled right away without any problems. I fired up Stella and ran it, and it ran, and seemed to play exactly like Superman. Success!

To make the edits, I read through the source .asm file and tried to understand what I could. Fortunately, the file is reasonably well documented. Without actually knowing 6502 ASM, I can’t say I understand everything I’d like to, but I can see enough that I should be able to make edits by trial and error, and make progress.

The section I’m interested starts off like this:

Screen00: ;unused??
;Screen Info: 8 bytes per screen
;Offset 0 = GFX bitmap low byte
;Offset 1 = GFX bitmap high byte
;Offset 2 = Foreground color
;Offset 3 = Background color
;Offset 4 = screen above
;Offset 5 = screen right
;Offset 6 = screen below
;Offset 7 = screen left
    .word IF2AC ; $F000
IF PAL
    .byte $46 ;red $F002
    .byte $08 ;grey $F003
ELSE
    .byte $36 ;red $F002
    .byte $08 ;grey $F003
ENDIF
    .byte <Screen00 ;$F004
    .byte <Screen00 ;$F005
    .byte <Screen00 ;$F006
    .byte <Screen00 ;$F007

From reading through the code, I infer that the stuff after a semi-colon is a comment, so the different comments explaining the Offsets help me to understand that Offsets 4 through 7 have to do with the connections between the different screens in the map. All I should need to do is update them with different addresses, and the map will change! Easy!

In my next update, I’ll present my modded Superman maps and do a little analysis of them.