Lab 1

 

6502 Assembly Language Lab


In this lab, I explored the 6502 Emulator to manipulate the bitmapped display using assembly language. The goal was to fill the screen with colors, experiment with random pixel values, and optimize execution time.


Task 1: Filling the Screen with Yellow

The initial code filled the screen with a solid yellow color. Here's the snippet:


lda #$00       ; Set a pointer in memory location $40 to point to $0200
sta $40        ; Low byte ($00) in address $40
lda #$02
sta $41        ; High byte ($02) in address $41
lda #$07       ; Yellow color code
ldy #$00       ; Set index to 0
loop: sta ($40),y ; Set pixel color at address (pointer)+Y
iny             ; Increment index
bne loop        ; Continue until the page is filled
inc $41         ; Increment page
ldx $41         ; Get current page number
cpx #$06        ; Compare with 6
bne loop        ; Continue until all pages are filled



Execution Time Calculation

  • Each pixel requires 11 cycles (6 cycles for sta, 2 cycles for iny, 3 cycles for bne).
  • For 256 pixels: 11×256=281611 \times 256 = 2816 cycles per page.
  • For 4 pages: 2816×4=112642816 \times 4 = 11264 cycles.

At a clock speed of 1 MHz: 

Execution Time = 11264 cycles/1000000 cycles per sec = 0.011264 Seconds


To reduce execution time, I explored alternatives like replacing loops with unrolled code segments and optimizing memory access patterns, I nearly halved the execution time. The final optimized code executed in approximately 0.006 seconds.


Change to Light Green: Replacing the color code (#$07) with #$0D resulted in a light green display:


lda #$0D       ; Light green
sta ($40),y    ; Set color




Different Colors per Page:
Modified the loop to use a different color code (#$07, #$0B, etc.)

lda #$07       ; Yellow for the first page
sta ($40),y
inc $41        ; Move to the next page
lda #$0B       ; Light blue for the next page
sta ($40),y

Random Colors per Pixel:
Using the pseudo-random number generator provided:

jsr random     ; Generate random number
sta ($40),y    ; Use random number as the color




Reflection
In this lab, I learnt that small changes had a significant impact on performance, debugging in assembly requires careful attention because even subtle errors can be very impactful.

Comments

Post a Comment

Popular posts from this blog

Image
  Automatic Function Multi-Versioning for GCC Introduction: For this project, I will be working with the GCC compiler and learning how it works by building it from scratch on an AArch64 platform (which is 64-Bit). Setting up GCC like this lets me dig into how it compiles code and optimizes functions for different CPUs, especially as the goal is to experiment with Automatic Function Multi-Versioning (AFMV). Guide to Building GCC for AArch64 Step 1: Cloning the Source Code To get started, I needed the GCC source code. Cloning from the official GCC repository keeps things organized and up to date. Here’s the command to clone it: git clone git://gcc.gnu.org/git/gcc.git ~/gcc This creates a directory called ~/gcc , where all the source files are stored. The cloning process might take a few minutes, depending on your internet speed. Step 2: Setting Up a Build Directory It’s recommended to create a separate directory for building GCC instead of doing it directly in the source directory. ...
Read more

Building GCC Part 2

This is my attempt to learn and work with GCC as part of my SPO600 course. I’m working on Stage 2 of the project, where I have to create and test a Clone-Pruning Analysis Pass. You can find the first part in my blog page. Creating the Dummy Pass I started by creating a basic pass that should iterates through the program functions and output their names to a dump file.  Iterating Through GIMPLE Statements Next, I added logic to traverse the GIMPLE representation of each function. GIMPLE is an intermediate language used by GCC, and understanding it was crucial for the project. By iterating over the GIMPLE statements within each basic block, I could analyze the structure of functions. This step highlighted the importance of diagnostic dumps, as they provided a detailed view of what the pass was processing. While the GIMPLE code initially felt overwhelming, breaking it down into smaller sections made it easier. Setting Up The first step was to get the provided files into my working dir...
Read more

Wrapping Up Project : Stage 3

With the final stage of the SPO600 project, my journey into the GCC compiler comes to a close. This stage was all about tying up loose ends from Stage 2, testing the Clone-Pruning Analysis Pass, and reflecting on what I’ve learned throughout the project. Progress Overview The focus of Stage 3 was to finalize the work I started in Stage 2. Building on my earlier implementation, I managed to create a pass that iterates through functions, analyzes their GIMPLE representations, and outputs information to a dump file. Here's what my custom GCC pass can now do: Print Function Names : The pass successfully identifies and prints the names of all functions. Output GIMPLE Statements : It iterates through the GIMPLE representation of each function, printing the statements to the dump file. Count Statements : The pass tracks and stores the number of GIMPLE statements for each function. A snippet of my pass code from tree-ctyler.cc demonstrates the approach: unsigned int pass_ctyler::execute(fu...
Read more