Lab 1 - Experiments

                                                    Experiments


Add this instruction after the loop: label and before the sta ($40),y instruction: tya



Visibly I see 32 stripes of color by running the above code.

Adding the tya instruction before sta ($40),y causes the value of the Y register (the current index) to be transferred to the accumulator (A). Since sta ($40),y writes the value of the accumulator to memory, this change means that the color stored at each pixel now depends on the current value of Y. As Y increments from 0 to 255 within each page, the accumulator's value also changes, resulting in different color codes being written to the screen. This creates a series of stripes, as each pixel or small group of pixels gets a unique color based on its position within the memory page. The variety of colors is due to the sequential progression of the Y register value.

Add this instruction after the tya: lsr

Adding the lsr instruction after tya divides the value of the Y register (transferred to the accumulator) by 2, reducing the range of color codes. Originally, Y values from 0 to 255 produced 256 possible colors, but after the shift, the range is halved to 0–127. Since the 6502 supports only 16 unique colors (0–15), the colors now repeat every 16 values, resulting in 16 distinct colors displayed on the screen. The visual effect is wider stripes of color, as each color spans two consecutive pixel rows due to two Y values mapping to the same color after the shift.


Repeat the above tests with two, three, four, and five lsr instructions in a row. Describe and explain the effect in each case.



The 8-bit Y value (ranging from 0–255) creates 32 distinct color groups, each group representing 8 consecutive rows (256/32 = 8 rows per stripe). This results in the 32 stripes horizontally, with the appearance of horizontal bands because each stripe is repeated for a certain number of rows based on how the Y value maps to the color. As more lsr instructions are added, the color resolution continues to decrease, leading to fewer stripes with wider bands. The horizontal layout is inherent to how the rows are scanned and colored sequentially in memory. 


Repeat the tests using asl instructions instead of lsr instructions. Describe and explain the effect in each case.

Using asl (Arithmetic Shift Left) instead of lsr produces vertical stripes as the color values shift to higher bits, doubling each time. Each asl operation effectively multiplies the Y register's value (transferred to the accumulator by tya) by 2, increasing the separation between color groups. This results in fewer, wider color bands because higher bit values change less frequently. For instance, after one asl, there are 32 vertical stripes. Adding more asl instructions continues to reduce the number of stripes while further widening them, as the bit values become less granular and more uniform over wider sections. The stripes are vertical because the memory addressing for screen pixels maps color changes across columns, rather than rows, when the bit values shift.


Repeat the tests using asl instructions instead of lsr instructions. Describe and explain the effect in each case.

The ASL (Arithmetic Shift Left) instruction shifts all bits in the accumulator (A) one place to the left, effectively multiplying the value by 2. Unlike LSR, which divides by 2, ASL increases the spread between values, causing fewer, wider color bands to appear on the screen.


The original code includes one iny instruction. Test with one to five consecutive iny instructions. Describe and explain the effect in each case. Note: it is helpful to place the Speed slider is on its lowest setting (left) for these experiments.

In the original code, a single INY instruction increments the Y index register by 1, ensuring that each pixel is written to sequentially. Increasing the number of consecutive INY instructions affects how frequently colors are written to the screen, creating different visual effects.



Observations for Different INY Counts
One INY Instruction (Original Code)

The program colors every pixel sequentially, with smooth color transitions.
The screen is filled completely with the set color.

Two INY Instructions

The Y register increments by 2 each iteration, skipping every other pixel.
Creates striped horizontal bands, where every other pixel remains uncolored.

Three INY Instructions

The Y register increments by 3, skipping two pixels between each colored pixel.
Wider horizontal gaps between colored pixels, with colors appearing every 3 pixels.

Four INY Instructions

The Y register increments by 4, coloring only every fourth pixel.
Very noticeable horizontal gaps, creating a checkerboard-like effect when combined with multiple pages.

Five INY Instructions

The Y register increments by 5, skipping four pixels between each color.
The screen is filled with scattered pixels, each spaced further apart, making the pattern appear sparse.





Comments

Post a Comment

Popular posts from this blog

Lab 2 - Lab Results

Introduction In this blog post, I will share my experience working on a lab where we animated a small 5x5 graphic to move diagonally across the screen and bounce off the edges. The lab required an understanding of low-level memory manipulation, conditional logic, and efficient screen rendering. I'll walk you through the code, the changes made to implement bouncing logic, and my reflections on the learning process. **Since we collaborated as a group on optimizing the code, my work may resemble that of my teammates =================================================================== Initial Code The following code moves a 5×5 graphic diagonally across the screen: ; ; draw-image-subroutine.6502 ; ; This is a routine that can place an arbitrary ; rectangular image on to the screen at given ; coordinates. ; ; Chris Tyler 2024-09-17 ; Licensed under GPLv2+ ; ; ; The subroutine is below starting at the ; label "DRAW:" ; ; Test code for our subroutine ; Moves an image diagon...
Read more

Project Stage 1

Image
In this project, I set out to create a custom GCC pass that analyzed GIMPLE files by iterating through every function, counting the basic blocks, and tallying the number of GIMPLE statements. I successfully integrated this pass into the GCC build system and tested it on a simple C program. Here’s how I did it. 1. Writing the Pass Code I began by writing the pass code in C++ and saved it in a file named tree-my-new-pass.cc within the gcc subdirectory of my GCC source. My pass, which I named "my_new_pass", was designed to run during the GIMPLE phase. The code looked like this: #include "config.h" #include "system.h" #include "coretypes.h" #include "backend.h" #include "tree-pass.h" #include "pass_manager.h" #include "context.h" #include "diagnostic-core.h" #include "tree.h" #include "tree-core.h" #include "basic-block.h" #include "gimple.h" #include "gimp...
Read more

Lab 5 - Part 1 - Aarch 64

Image
In this lab, my goal is to dive into assembly programming on both the x86_64 and AArch64 platforms. For Task 1, 1. I will closely examine how the AArch64 assembly source code—written in a human-readable format—is transformed into an object file containing machine code. This investigation will help me understand the assembly process by highlighting the differences between the high-level source instructions and the low-level binary output generated by the assembler. Source file Object file 2 : Constructing a Loop That Prints “Loop” Six Times In this task, I need to adapt the assembly code on the aarch64 server so that it outputs the word “Loop” exactly six times. Starting with the provided code, I will introduce a counter in one of the general-purpose registers, initialize it to zero, and increment it after each print. Once the counter reaches six, the loop will terminate. This requires adjusting the assembly instructions to compare the loop counter against a maximum value, calling the a...
Read more