he next step in this series was my interest in the JMP (jump) statement located in memory location $6C89 to see if it was jumping back to the main loop of the game. This is actually how I discovered the starting address to many other C64 games, is by trial and error.  I arrived at this guess by starting with the joystick saved registers and tracking where the flags were set in locations $7576, $7575, and $7574. After some analysis I landed at register $6CF6 in hopes this may be my guiding light. The screenshot depicts my discovery here. Suddenly my boyish, squeaky voice was re birthed as I claimed “This is probably the main routine.” The point being here is not how I sounded, but rather a deeper passion for new discovery when searching through an assembly language listing as profound as this.

Continuing my analysis, I later arrived at memory location $6D04. The code showed LDA $DC00 STA $7573 AND #$10 BNE L_BRS_($6D13)_($6D0C).  Also during this time, I was communicating live with other stream observers that landed on my Twitch.tv channel to see what their thought process was in my evaluation of the code samples I was presenting. Then I heard someone chime in after I asked the question via chat and I saw they mentioned that the AND #$10 against the joystick port was checking for the fire button pressed down.

After this my mind started to speculate what else could be going on in the main loop in hopes of digging deeper to the true main loop location. Things  such as animation, spawning bad guys, enemies pursuing your player, enemies able to walk up/down ladders,  and the animation of the child hostage in their cells to name a few. A lot of interaction is taking place in a game loop. This is an important element to put into scope since it can help you when you start analyzing assembly language listings while keeping the game’s action components in mind.

My faithful audience pitched in again and I saw that someone mentioned the value of setting a break point in the VICE C64 Monitor to see if it halts at that location while interacting with the game. So pausing the game, I opened up the Monitor, clicked to set a break point (marked by a red line), and then returned to the game in progress, but discovered it crashed instead.

To probe a little further in my understanding of how the Monitor works, I loaded up the Help screen to see all of the commands available at my disposal. I discovered by just typing the letter r, that I suddenly could see the status registers of the game. This is importance since I could learn what the accumulator, x, y, zero flag, and other registers were now showing in memory.  A screenshot is visible here for clarity. The goal was to get the game running again. So opening up the memory window, I finally scrolled through memory until I saw a green line as advised by my viewers. Right clicking on it, I found the option to ‘unset a break point’. Then the game was able to run again.

An idea surfaced  much later that I could try to port the game into the CBM Prg Studio tool. The game was saved in Infiltrator as a snapshot. In chat, somebody mentioned to save the game in Regenerator as a tas file (Turbo Assembler) to see if I could load it into the CBM Prg Studio editor. When I finally got it loaded, to my surprise, I discovered that the format was not going to work. This is because the file is recognized to be read by the Turbo Assembler. So next I tried my luck at compiling it, but was disappointed to learn that a ton of errors were resident. It was still interesting to learn at that time that a TAS file could be loaded into CBM Prg Studio for the Commodore 64. However, it would be best to utilize a different editor (none other than the Turbo Assembler) to stay consistent with the format in order to see it have a successful execution.

Toward the conclusion of the video, I returned to Regenerator again. I explained how I prefer this tool since it highlights a lot of the memory locations, includes built in comments for central memory locations (VIC, SID, CIA), and also allows you to embed your own comments. This led me to searching through the code routines again until I came to register $41A6 which was the home of raster subroutine. Rasters are used to run interrupts in the background of a game to save on the game cycles. Often these can run “uninterrupted” by the game, producing a much smoother game. This is necessary especially when you have game characters running around, chase your sprite, and won’t detract from the timing of the joystick movement.

The video cut out when a chat member by the name of RetroCoder mentioned that this loop may be the location of the bottom panel of the game. Unfortunately I have to end this session since twitch.tv trashed the rest of the videos for this series. It taught me a grave lesson above saving all my work. However, stay tuned to more sessions to come.  Remember, this is just an exploration of discovery. It is in no means perfect, but rather a path to learning more from other games that were popular back when the Commodore 64 was king of the world.