Lab - 2 6502 Assembly Language Lab

-

 We are required to alter a piece of code in 6502 Assembly language lab that was provided to us in order to achieve the following results:

1) Change the code to fill the display with light blue instead of yellow: Changing LDA #$07 to LDA #$0E, which is a binary code that turns the color of yellow into light blue, is all that is necessary to accomplish this. As we are sending the instruction for the color to change to light blue, we are aware that LDA signifies that something is going to be loaded in the accumulator.

2) Change the code to fill the display with a different color on each page: Four loops are necessary for this since they will vary the color of each page. As demonstrated in class using basic code, such as loading a byte with some color in y and then storing it in byte, it is incremented and made to loop until all 256 bytes have been used, at which point it becomes one loop. 

The basic code looks like this: 

1) Code to fill the display with light blue instead of yellow:

        lda #$00	; set a pointer in memory location $40 to point to $0200
	sta $40		; ... low byte ($00) goes in address $40
	lda #$02	
	sta $41		; ... high byte ($02) goes into address $41

	lda #$0E	; colour number

	ldy #$00	; set index to 0

loop:	sta ($40),y	; set pixel colour at the address (pointer)+Y

	iny		; increment index
	bne loop	; continue until done the page (256 pixels)

	inc $41		; increment the page
	ldx $41		; get the current page number
	cpx #$06	; compare with 6
	bne loop	; continue until done all pages

The result of first code:



2) Code to fill the display with a different color on each page:
lda #$00    ; set a pointer at $40 to point to $0200
        sta $40
        lda #$02

        sta $41

        lda #$07    ; colour number

        sta $10 ; store colour number to memory location $10

        ldy #$00    ; set index to 0

loop:    sta ($40),y    ; set pixel at the address (pointer)+Y

        iny ; increment index

        bne loop    ; continue until done the page

        inc $41 ; increment the page

        inc $10 ; increment the color number

        lda $10 ; colour number

        ldx $41 ; get the current page number

        cpx #$06 ; compare with 6

        bne loop ; continue until done all pages
The result of second code:



This is a straightforward process that involves repeating the action four times and printing in a different color each time. Adding an ASL command just beneath the first bne loop is all that is required to alter this code using the original base code. The value will be increased or shifted to the left and the color will be changed as in certain default values when it is finished. Following the completion of the first bne loop, when the first page with some color is printed, we give the instruction to change pages since we may either print the bitmap in its whole or in 4 pages.


#Calculating the Performance:



Comments

Post a Comment

Popular posts from this blog

Lab 5 - Algorithm Selection Lab

-
In this lab, I wrote a set of programs that generates sound samples in a data array. It generates 5000000 samples as specified in the provided "vol.h" file, then scales the samples by a factor of 0.75 and returns them to the array. As a result, the program generates and displays a sum from the output array. To test the run time for each program, we'll use the command "time./programName," which will run the program and output the results as well as the time it took to run it. The program's real time is the sum of two sections: "user time" and "system time." Task 1: I obtained the base run time data we will work with when I ran the initial program, "vol1." This program runs with the volume factor unchanged. This allows us to test the other programs and observe any significant changes in run time data. Running the same program will not always produce the same results; there may be slight differences. This could be due to initial r
Read more

SPO600 - Project Stage 2

-
Introduction: This tool generates three versions of the function specified as the second argument. Then, while building the main output file from these functions, this tool employs the ifunc capability to select the best method.  The tool was written in Python, while the ifunc resolver function is written in C. In this blog, I will explain the tool's working mechanism and limitations, as well as the procedure for testing the tool. Accessing the tool: The tool is hosted on GitHub. The tool is available for download at https://github.com/puja1102/SPO600Project . The GPL version 2 licence governs the use of this tool. The tool's main files are as follows: tool.py: the main tool written in Python that builds the functions and generates the output binary files using the best SIMD implementation. template.txt: This is a text file containing the template for the ifunc function, as well as the resolver function for the ifunc. The ifunc.c file is created using this template. This tool
Read more

Auto Vectorization

-
 I'm working on a blog post about the concept of automatic vectorization in parallel computing, which can help reduce the number of cycles and chains in loops. It means that instead of scalar implementation, code can be converted to perform vector operations, which means a single operation can be performed on multiple operands. The GCC compiler is sophisticated enough to use vectorization to optimise code and improve performance. It is possible to accomplish this by using optimization flags such as -03 and -ftree-vectorize. AArch64 supports three extensions: SMID (Single Instruction, Multi Data), SVE, and SVE2. SVE  and SVE2 Scalable Vector Extension 2 (SVE2) is an armv9 extension that provides variable-width SMID capability. The main difference between SVE2 and SVE is the functional coverage of the instruction set. SVE and SVE2 both allow for large amounts of data to be collected and processed. For an aarch64 system, run the following command to enable SVE: gcc -g -O3 -c march=arm
Read more