Lab 3 The Worm Game

-

 Lab 3 - 6502 Assembly: The Worm Game Adventure

For this lab, I decided to take a leap into creating a simple but super fun Worm Game in 6502 Assembly language. And let me tell you – this was by far the most fun lab I've worked on so far! Not only did I get to learn more about how Assembly interacts with both text and graphic screens, but I also had to dig into game mechanics like collision detection, random fruit generation, and managing user input, all with very low-level code.

The Game Plan

The goal was to create a basic version of the classic "Worm" game, which starts with a small worm moving around the screen. The player controls the worm with the keyboard (W, A, S, D to move up, left, down, and right) and tries to eat randomly appearing fruits, which makes the worm grow longer. The challenge? Avoiding crashing into walls or its own body!

Key Features:

  • Moving the Worm: Control the worm's movement using the keyboard (WASD keys).

  • Growing the Worm: Every time the worm eats a piece of fruit, it grows in size.

  • Avoiding Collisions: The worm must not crash into itself or the edges of the screen.

  • Random Fruit Placement: Fruits appear randomly on the screen, and the worm must eat them to grow.

  • Increasing Speed: As the worm grows, the game speed increases, making things more challenging.

Challenges and Fixes

One of the trickiest parts of this project was figuring out the direction reversal bug. Initially, when I tried to reverse direction (like moving right after moving left), the worm wouldn’t move at all. The problem was in the direction-checking logic. The code was designed to prevent moving directly opposite to the current direction, but this also meant the worm got stuck if I made a mistake.

Fix:

I made it so that when an invalid move was made (like trying to move right after left), the worm would continue in the last valid direction rather than freezing. This small tweak made a huge difference in gameplay!

Here's the code adjustment:

rightKey:

  lda #movingLeft

  bit movementDirection

  bne illegalMove


This change allowed the worm to continue moving in the previous direction on invalid inputs, rather than stopping completely.

Reflection: The Fun Factor

Designing the Worm game in Assembly was an absolute blast! It pushed my skills in managing memory, handling user input, and dealing with low-level graphics. I had to figure out how to update the worm’s position on the screen, deal with fruit placement, and even adjust the game speed as the worm grew longer. The interaction between the text and graphic screens was a great exercise in controlling multiple outputs in a limited environment.

Debugging Assembly was brutal at times — one wrong instruction and the whole game could break. I spent a lot of time isolating issues, checking memory addresses, and testing changes in the emulator. The process felt incredibly rewarding, especially when everything finally clicked, and the game worked as expected. A big part of this was learning to efficiently manage memory and how the game loop ties all of these small instructions together.

I can definitely say this was the most enjoyable lab yet, and I’m excited to continue exploring the world of low-level programming!

The Final Code:


define fruitLocationLow  $00 ; screen location of fruit, low byte
define fruitLocationHigh $01 ; screen location of fruit, high byte
define headPositionLow   $10 ; screen location of worm head, low byte
define headPositionHigh  $11 ; screen location of worm head, high byte
define bodyStart         $12 ; start of worm body byte pairs
define movementDirection $02 ; direction (possible values are below)
define wormSize          $03 ; worm length, in bytes
define fruitColor        $04 ;
define wormSegments      $0900 ;
define gameSpeedCycles   $05 ;

; page 0 (@ 0000) used for worm locations
; page 1 (@ 0100) used for stack
; page 2-5 screen
; page 6-? program opcodes.
; thus, use page @0900 -> page 9 for storing worm colors. Not using zero page incurs many cycles for drawing the worm at every loop.

; set worm body colors
lda #$00 
sta wormSegments ; trail color 
lda #$05
ldx #$02
sta wormSegments,x ; tail color

ldx #$20 ; set game speed. 
stx gameSpeedCycles ; 
; note: When gameSpeedCycles reaches 0, game cannot run any faster. Game starts to slow down at this point.

; Directions (each using a separate bit)
define movingUp    1
define movingRight 2
define movingDown  4
define movingLeft  8

; ASCII values of keys controlling the worm
define ASCII_w      $77
define ASCII_a      $61
define ASCII_s      $73
define ASCII_d      $64

; System variables
define sysRandom    $fe
define sysLastKey   $ff

  jsr initialize
  jsr gameLoop

initialize:
  jsr setupWorm
  jsr createFruitPosition
  rts

setupWorm:
  lda #movingRight  ;start direction
  sta movementDirection

  lda #4  ;start length (2 segments)
  sta wormSize
  
  lda #$11
  sta headPositionLow
  
  lda #$10
  sta bodyStart
  
  lda #$0f
  sta $14 ; body segment 1
  
  lda #$04
  sta headPositionHigh
  sta $13 ; body segment 1
  sta $15 ; body segment 2
  rts

createFruitPosition:
  ;load a new random byte into $00
  
  lda sysRandom
  and #$0f ; discard high bit
  cmp #$00 ; dissallow black
  beq addOne 
  cmp #$05 ; dissallow green
  beq addOne
  bne storeColor
  addOne:
    adc #$01
  storeColor:
  sta fruitColor

  lda sysRandom
  sta fruitLocationLow

  ;load a new random number from 2 to 5 into $01
  lda sysRandom
  and #$03 ;mask out lowest 2 bits
  clc
  adc #2
  sta fruitLocationHigh
 
  rts

gameLoop:
  jsr processInput
  jsr detectCollisions
  jsr updateWormPosition 
  jsr renderFruit  
  jsr renderWorm
  jsr controlGameSpeed
  jmp gameLoop

processInput:
  lda sysLastKey
  cmp #ASCII_w
  beq upKey
  cmp #ASCII_d
  beq rightKey
  cmp #ASCII_s
  beq downKey
  cmp #ASCII_a
  beq leftKey
  rts
upKey:
  lda #movingDown
  bit movementDirection
  bne illegalMove

  lda #movingUp
  sta movementDirection
  rts
rightKey:
  lda #movingLeft
  bit movementDirection
  bne illegalMove

  lda #movingRight
  sta movementDirection
  rts
downKey:
  lda #movingUp
  bit movementDirection
  bne illegalMove

  lda #movingDown
  sta movementDirection
  rts
leftKey:
  lda #movingRight
  bit movementDirection
  bne illegalMove

  lda #movingLeft
  sta movementDirection
  rts
illegalMove:
  rts

detectCollisions:
  jsr checkFruitCollision
  jsr checkWormCollision
  rts

checkFruitCollision:
  lda fruitLocationLow
  cmp headPositionLow
  bne doneCheckingFruitCollision
  lda fruitLocationHigh
  cmp headPositionHigh
  bne doneCheckingFruitCollision

  ;eat fruit
  lda gameSpeedCycles
  cmp #$00
  beq maxSpeedReached
  dec gameSpeedCycles ; remove ~24 wasted cycles
  maxSpeedReached: ; cannot decrease beyond 0
  ldy wormSize
  lda fruitColor
  sta wormSegments,Y
  inc wormSize
  inc wormSize ;increase length
  jsr createFruitPosition
doneCheckingFruitCollision:
  rts

checkWormCollision:
  ldx #2 ;start with second segment
wormCollisionLoop:
  lda headPositionLow,x
  cmp headPositionLow
  bne continueCollisionLoop

maybeCollided:
  lda headPositionHigh,x
  cmp headPositionHigh
  beq didCollide

continueCollisionLoop:
  inx
  inx
  cpx wormSize          ;got to last section with no collision
  beq didntCollide
  jmp wormCollisionLoop

didCollide:
  jmp gameOver
didntCollide:
  rts

updateWormPosition:
  ldx wormSize
  dex
  txa
updateloop:
  lda headPositionLow,x
  sta bodyStart,x
  dex
  bpl updateloop

  lda movementDirection
  lsr
  bcs up
  lsr
  bcs right
  lsr
  bcs down
  lsr
  bcs left
up:
  lda headPositionLow
  sec
  sbc #$20
  sta headPositionLow
  bcc upup
  rts
upup:
  dec headPositionHigh
  lda #$1
  cmp headPositionHigh
  beq collision
  rts
right:
  inc headPositionLow
  lda #$1f
  bit headPositionLow
  beq collision
  rts
down:
  lda headPositionLow
  clc
  adc #$20
  sta headPositionLow
  bcs downdown
  rts
downdown:
  inc headPositionHigh
  lda #$6
  cmp headPositionHigh
  beq collision
  rts
left:
  dec headPositionLow
  lda headPositionLow
  and #$1f
  cmp #$1f
  beq collision
  rts
collision:
  jmp gameOver

renderFruit:
  ldy #0
  lda fruitColor ; sysRandom
  sta (fruitLocationLow),y
  sta fruitColor
  rts

renderWorm:
  ldx #0
  lda #5 ; green
  sta (headPositionLow,x) ; paint head
	
  ;paint body and trail. 
  ldx wormSize  
  ldy #$00
  drawBelly:
   lda wormSegments,y ; 5 cycles
   sta (headPositionLow,x) ; 6 cycles
   dex ; 2 cycles
   dex ; ...
   iny ; ...
   iny ; ...
   cpx #$00 ; 2 cycles
   bne drawBelly ; 3 cycles
   ; -1 if branch fails
   ; $0766    d0 f3     BNE $075b -> no page crossing
   ; total ~24 cycles per segment   
  rts

controlGameSpeed:
  ldx gameSpeedCycles
  beq noSpin ; don't spin if gameSpeedCycles = 0.
  spinCycle:
    ldy #$02 
    spinloop:
      nop ; 
      nop ; 
      nop ;
      nop ; 2*4
      dey ; 2
      bne spinloop ; 3 first time , 2 on exit
      ;2*4*2+2*2+3+2 = 25 cycles.
  dex
  bne spinCycle
  noSpin:
  rts

gameOver:


Comments

Post a Comment

Popular posts from this blog

Project Stage 2.A

-
Project Stage 2 – Part A: Finding Cloned Functions For Stage 2 of my SPO600 project, I’m taking the basic GCC analysis pass I built in Stage 1 and evolving it into something a bit more interesting—analyzing cloned functions. The end goal? Build a Clone-Pruning Analysis Pass that checks if functions in a compiled program are just duplicates and, if they are, recommends pruning them to save space and avoid redundancy. But before we can make any pruning decisions, we first need to find these clones. That’s what this blog is all about: detecting cloned functions in the compiled code. What Is a Cloned Function? When GCC optimizes code, it often makes slightly modified copies of functions—these are called clones . You’ll see them with names like: scale_samples.constprop.0 scale_samples.Mrng scale_samples.resolver These cloned functions usually come from optimizations like constant propagation , inlining , or architecture-specific tuning . For example, if the compiler notices that a functio...
Read more

Project Stage 3

-
  Project Stage 3: Tidy & Wrap – Clone-Prune Analysis at Scale Welcome to the final part of my SPO600 project! In the previous stage, I built a GCC pass that could compare a cloned function to its original version by checking the number of basic blocks and the GIMPLE statements inside them. The pass would then decide whether the cloned function was identical and could be safely pruned. That version worked well when there was only one cloned function to analyze. But in this stage I wanted to scale things up. What’s New in Stage 3? The goal for Stage 3 was to make the Clone-Prune Analysis Pass more complete and scalable . Here's what I aimed to do: Handle multiple cloned functions , not just one. Automatically skip resolver functions , which are internal compiler helpers we don’t want to compare. Make the output more clear and architecture-independent (i.e., it works the same on both x86_64 and aarch64). Improve diagnostic logging to make testing and verification easier. This m...
Read more

Project Stage 2.C

-
  Project Stage 2 – Part C: Clone-Pruning in Action This is it the final part of my Clone-Pruning Analysis Pass series! So far, I’ve: Found cloned functions using name patterns and suffixes (Part A) Extracted and compared their GIMPLE to check for similarity (Part B) Now, in this post, I’ll show the analysis in action—specifically how my pass performs on two test cases provided in the course: clone-test-prune and clone-test-noprune . This is where all the logic from earlier pays off! Clone-Prune Test Files These test files contain three functions: scale_samples.default scale_samples.Mrng scale_samples.resolver My goal here: identify whether scale_samples.Mrng is identical to scale_samples.default —and if so, recommend pruning . Let’s look at them. scale_samples.default // Simplified view of instructions... vscale = 2; for (...) {     result[i] = input[i] * vscale; } scale_samples.Mrng // Basically the same logic, just cloned for target Mrng vscale = 2; for ...
Read more

Welcome to My SPO600 Journey

-
Welcome to My SPO600 Journey Hello and welcome to my first blog post! This space will document my journey through SPO600: Software Portability and Optimization ,  a course  taught by Chris Tyler   focused on understanding how software can be optimized for different hardware architectures. Throughout the course, I will be exploring low-level programming concepts, performance analysis techniques, and optimization strategies, starting with the 6502 microprocessor and advancing towards modern architectures like x86_64 and AArch64. About Me Hi everyone! My name is Haroon bajwa and I am currently studying Computer Programming and Analysis at Seneca College Newnham Campus, with a keen interest in system-level programming and performance optimization. This course presents an exciting opportunity to dive deep into assembly language and understand how code interacts with hardware. Through this blog, I aim to track my learning, share insights, and explore different optimization tech...
Read more

Lab1 6502 Assembly Language

-
  Optimizing Assembly: Insights from Lab 1 Introduction Lab 1 introduced me to the fundamentals of 6502 Assembly programming. It was my first real experience diving into low-level code, and honestly, it was a mix of confusion and excitement. The goal of the lab was to analyze an existing assembly program, understand how it works, and then try making changes to improve or modify what it does. This blog post walks through my personal journey with the lab—from running the original code to experimenting with new instructions—and what I learned along the way. Running the Bitmap Code We kicked things off with a basic assembly program designed to fill the emulator’s display with a single solid color. The code sets a pointer in memory to start writing pixel data and loops through, placing the same color on each pixel. Here’s a quick breakdown of what happens: The program sets up a pointer to location $0200 (the start of the bitmap). It sets the color to yellow with LDA #$07 . Then it uses...
Read more

Stage 1 Completed

-
Project Stage 1 Completed! For the first stage of my SPO600 project, I created a custom GCC pass that prints out the name of each function being compiled, along with the number of basic blocks and GIMPLE statements in that function. This gave me a deeper look into how the compiler breaks down high-level code during the compilation process. Setting Up My Environment I used the recommended three-directory setup: ~/git/gcc/         # GCC source directory ~/gcc-build-001/   # Build directory ~/gcc-test-001/    # Install/test directory I followed the official GCC documentation to configure the build: ../git/gcc/configure --prefix=$HOME/gcc-test-001 --enable-languages=c --disable-bootstrap --disable-multilib time make -j$(nproc) |& tee build.log The build process took a while at first, but using make for incremental rebuilds really saved time later. I made sure to always build inside a screen session so I wouldn't lose progress if my SSH connection dro...
Read more

Project Stage 2.B

-
Project Stage 2 – Part B: Comparing GIMPLE of Cloned Functions In the previous post , I wrote about how I detected cloned functions in the compiled program. I used naming conventions (like .constprop , .variant , and .resolver ) to group clones by their original function name. Now that I’ve found these cloned functions, it’s time to look inside them —into their GIMPLE representation —and figure out if they’re actually doing the same thing. This blog is all about how I accessed, compared, and analyzed the internal structure of these functions. Wait, What Is GIMPLE Again? GIMPLE is a simplified version of C/C++ code that GCC uses for optimization. It’s kind of like a low-level, easy-to-analyze form of your code, broken down into really basic steps (like x = y + 1 ). Each function is made up of: Basic Blocks : These are sequences of instructions with no jumps except at the end. GIMPLE Statements : Individual operations or assignments. In this part, I extracted GIMPLE from each clone and i...
Read more

Lab 4 Building GCC on My Linux VM

-
  Lab 4 Building GCC on My Linux VM (ft. My M2 MacBook Air) For this lab, I took a dive into the world of large software builds, specifically building the GCC compiler from source. The goal was to get hands-on experience using tools like make and autotools , since we’ll be working with GCC during our course project. Instead of using the SPO600 servers (x86-001 and aarch64-002), I decided to try something a little different and ran everything inside a Linux VM on my M2 MacBook Air (which is arm64 under the hood). Spoiler alert: it actually worked out great! Step 1: Cloning the Source Code First things first, I needed the latest development version of GCC. I SSH’d into my Linux VM and cloned the official GCC Git repo: git clone git://gcc.gnu.org/git/gcc.git gcc-source This gave me a folder full of source code, ready to be built. Step 2: Configuring the Build I’ve learned it's a bad idea to build inside the source directory, so I created a separate directory for building: mkdir gcc-b...
Read more

Lab 2 Adventures in 6502 Assembly

-
  Bouncing Pixels and Going Solo: Lab 2 Adventures in 6502 Assembly Introduction Lab 2 was originally meant to be a mob programming session, think pair programming, but with a full group, all sharing one screen and collaborating on every line of code. Unfortunately, I couldn’t make it to the in-class session, so I ended up taking on the lab solo. While I missed out on the live collaboration part, I still got a chance to dive deep into the code, experiment with the animation logic, and get creative with bouncing a graphic around the screen using 6502 Assembly. This post walks through my solo journey with Lab 2: animating a graphic diagonally, making it bounce off the edges of the screen, and exploring some fun optional challenges along the way. Setting Up the Animation We were given a base program that moves a 5×5 pixel graphic diagonally across the emulator screen. The starting point was a neat little subroutine called DRAW , which takes an image, its position, and then places it o...
Read more

Project Stage 1 Diving In!

-
  Project Stage 1 – Understanding GCC Passes and Setting things UP Alright, time to dive into the SPO600 course project! In Stage 1, our goal is to create a basic GCC pass that can analyze a program during compilation and print out some useful info. This is my first time working this closely with the GCC compiler, and let me just say, it’s a deep rabbit hole. But it’s also been really interesting figuring things out. In this post, I’ll talk about: What the project is about How I approached it Some of the issues I ran into and how I fixed them What’s This Project About? GCC processes code in multiple steps called passes . These passes can analyze and transform code at various intermediate stages before turning it into machine code. For this project, I had to: Iterate through each function being compiled Print the name of each function Count how many basic blocks are in each function Count how many GIMPLE statements are in each function These details come from GCC's internal repre...
Read more