Lab 3 Reflection - Part 2 (Final)

Introduction

This blog entry will describe the final results regarding the work I did on lab 3. The task for lab 3 was to create a display that showed numbers from 0 to 99. In addition the display is to be controlled using the '-' and '+' keys. The controls would increment or decrement the number being displayed. The following will cover the code used to create the application, the results, and my overall thoughts on working on this lab. 


Writing Code


The code: https://gist.github.com/Megawats777/a8ac859e5f0905db83efaf76be9f26c4

Note: The font used is a custom pattern I designed.

In order to describe the code I will first start with the overall flow of logic. The first step is to check for input from the keyboard. If the '-' or '+' keys are pressed the appropriate increment or decrement procedure will be called. The second step is to actually increment and decrement the number shown and the method I chose was to have both digits be split into their own variables. In both increment and decrement routines I perform a series of checks that makes sure both digits do not get past 9 or go below zero. After the numbers are adjusted I proceeded to draw the numbers on screen. This is done by first setting values for the position and content variables which are then used by the draw function. Once the variables are set I then draw the numbers one digit at a time. Finally once the numbers are drawn I go back to checking for key presses. 


A major element used in the code are named pointers. I used named pointers for each of the digits, the starting locations for the number drawing procedure, as well as determining how the numbers are drawn. They are also used to determine the width and height of each digit displayed.


How the increment procedure works can be described in the following steps. First, I increment the right digit. If the right digit reaches a value of 10 that digit is reset to 0 and the left digit is incremented. The left digit will only increment as long it is not the number 9. The decrement procedure works similarly in that the right digit is first decreased and when that digit reaches a value of 0 the left digit is then decremented and the right digit is set to the number 9. A flaw with my increment and decrement procedures is that once the limits of 0 and 99 are reached the left digit cannot be adjusted but the right digit can be edited.


The way the drawing function works is by first having the "drawNumbers" subroutine called whenever a number is changed. This procedure first clears the screen and draws each digit one by one through the use of the "startDraw" subroutine. Before each "startDraw" subroutine is called, the starting pixel position for drawing as well as the actual content to draw is set. Selecting the starting pixel position beforehand allows each digit to be placed in the correct location, such as the left digit being placed to the left of the right digit. The content to draw is chosen through an admittedly strange process. First, there is a large list of dcb values that determine the shape of each digit and that list is divided into multiple sectors. And the value "DisplayNumIndex" determines which number in each sector is drawn. For instance, if the "DisplayNumIndex" variable has a value of 64 it would retrieve the shape of a four in the second sector. The actual draw code is built upon an example on the SPO600 wiki but this time it's using the variables I set before "startDraw" is called. It is also using the correct number sector which ensures the correct number is drawn. Finally once the drawing is finished I end the subroutine.

Drawing example code: https://wiki.cdot.senecacollege.ca/wiki/6502_Emulator_Example_Code#Place_a_Graphic_on_the_Screen


Conclusion

In the end my overall thoughts on this lab are comprised of the following. First, it was easily the longest and difficult lab I have experienced as it took me a week to complete. In addition it took several revisions of ideas to finally solve the problems put in front of me. Second, this lab taught me how to use existing source code to solve my problem even if the code I found didn't make complete sense to me. In the case of this lab I didn't completely understand the example drawing code but I understood the parts I needed to know so that I could use the existing code to my benefit. Finally, on a more personal note, this lab taught me a great lesson in persistence. As I learned that as long I stuck with the problem and allowed my head to breathe I would eventually solve the issues ahead.

Lab 3 Reflection - Part 1

It is now the third week of the course and for the first half we started work on lab 3. We were given several options on what type of assignment we want to complete for this lab, with all of them varying in difficulty. The option that my group chose was number two, which was to create a numeric display that can be controlled using the keyboard. This display would allow us to see a number from 0 to 99. So far were able to define the layout of several numbers as well being able to display a single number on screen. We are currently trying to figure out how keyboard input works in assembler as well how to display the appropriate number based on user input.

Our work so far:

Week 2 Reflection

If I were to describe this week it would be one of learning and persistence. As this week we did our first coding lab and to put it lightly it was a learning experience. This was because within one week I had to figure out how to work with all three registers as well as how nested loops work in assembler within the span of a few days. At the same time I was learning how bit and arithmetic shifting worked. The idea of persistence came in when I had to sit down and not give up on completing the lab. Despite how frustrating it got when I was just guessing hex values when drawing the vertical lines. However, the silver lining to all of this was the satisfaction of sticking with the work and seeing it completed to a mostly successful degree. Overall the main takeaway from the week is that I'll keep on trying to understand the content, accept the challenges with it, and try to see it through.

Lab 2: Assembly Language

Introduction

This post will cover my findings and overall thoughts regarding the lab I performed on Monday January 13, 2020. My findings on the bitmap code experiments as well as the results from the "writing code" segment will be covered.


Bitmap Code Results

After we copied the provided code onto the 6502 emulator we first added the statement "tya" after "sta ($40), y". The results I noticed were that there were 16 different colours and each colour occupied a column of the screen stretching down to the bottom. I believed this occurred because instead of using the predefined colour from the line "lda #$07" we instead used the incremented value in the y register as the value defining the colour. I think there were only 16 unique colours as that is the limit on amount of different colours and because we incremented the y register we essentially gone through all of them.

The next task my group did was to add the statement "lsr" after the "tya" statement we added earlier. The results were that there were less columns than before and the columns that did show up were much thicker. This was because by adding the "lsr" statement we are making each colour value last longer. For instance, without the "lsr statement" the value for blue would only last 1 pixel but by adding "lsr" the blue value would last 2 pixels. We also tried adding multiple "lsr" statements what I noticed were that less and less colours were present. As well as that if there are multiple "lsr" statements the columns would not longer stretch down to the bottom of the screen.

The test we did after was to replace the added "lsr" statements with "asl". The results were that even less colours showed up compared to when we added "lsr". Another finding was that if we added four or more "asl" statements the screen would just turn black. This was because with each time we added "asl" we were potentially increasing the colour values by 2, 4, or even 8 in each loop iteration.

The final experiment we did as a group was to remove all of the "asl" statements and add multiple "iny" lines after the original one. The findings were that if we had an even number of "iny" lines a stripe pattern would appear. But if there were an odd amount of "iny" lines then a checkerboard like animation would play and the screen would eventually be fully covered. I think this is because the more you increase the value in the y register the more you push out the position of the next pixel. 


Writing Code, Part 1

Code:
; draw a green line across the top

; Set the starting position of the line
lda #$00 ; position pt2
sta $40
lda #$02 ; position pt1
sta $41

lda #$5 ;set the colour of the pixel

ldy #$00 ; set the index

topLineLoop: sta ($40),y
iny
cpy #32
bmi topLineLoop


; draw a blue line across the bottom

; Set the starting position of the line
lda #$e0 ; position pt2
sta $50
lda #$05 ; position pt1
sta $51

lda #$6 ; set the colour
ldy #$00 ; set the index

bottomLineLoop: sta ($50), y
iny
cpy #32

bmi bottomLineLoop



The way the code works essentially is that first I set the position of the first pixel in the line. Afterwards I start incrementing the value of the y register until I reach a certain threshold. This is so that I only draw pixels until a certain point is reached. The results were that a yellow line was drawn at the top and a blue line was drawn at the bottom.


Writing Code, Part 2

Code:

; draw a yellow line down the left side

; set the starting position of the line
lda #00 ; position pt2
sta $60
lda #$02 ; position pt1
sta $61


lda #$7 ; set the colour

ldy #$00
sty $63

leftLineLoop: ldx #0
sta ($60), y

leftPush: ; set the position of the next pixel to be 32 units ahead
inx
iny
cpx #32
bne leftPush


cpy $4AA
bne leftLineLoop



inc $61 ;increment the page
ldx $61 ;store the page
cpx #$06 ; see if the page is not = $#06
bne leftLineLoop



; draw a purple line down the right side

; set the starting position of the line
lda #31 ; position pt2
sta $70
lda #$02 ; position pt1
sta $71


lda #$4 ; set the colour

ldy #$00
sty $73

rightLineLoop: ldx #0
sta ($70), y

rightPush: ; set the position of the next pixel to be 32 units ahead
inx
iny
cpx #32
bne rightPush


cpy $4AA
bne rightLineLoop


inc $71 ;increment the page
ldx $71 ;store the page
cpx #$06 ; see if the page is not = $#06
bne rightLineLoop





brk



The code works like first "writing code" segment but this time within the drawing loop there is another loop that pushes the position of the next pixel by a certain number of units. For instance, when drawing the yellow line on the left side I would push the position of the next pixel by 32 units so that on the next iteration of the loop the next pixel would be below the previous yellow pixel. Another difference is that I increment through the pages. This is so that its easier to go down the screen when drawing.


Conclusion

Overall my impressions on the assembly language is that even though its fascinating and satisfying to make something out of it. The amount of micromanagement and obscurity in the language makes my appreciate higher level languages like C++ even more. As they let me focus more on ideas and less on the deep level nuts and bolts. The main idea I learned from this lab is that where you move numbers and how you modify them can have a great impact on the results of your code. In terms of the process the main takeaway is that its a matter of constantly iterating. As this is new material to me and the best way to progress was to constantly try out different bits of code and see what comes from it.

Day 2 Reflection

Day 2

Date: January 10, 2020

This was the day where the deep dive into the course content began. The overall theme of this class was data representation with a bit of a intro to the 6502 assembler syntax. We started with a review on what a bit is as well as how to convert from binary numbers to integer ones. When this segment started I was pretty confused as the last time I dealt with binary numbers was back in ULI101 in 2017. But after a tiny bit of practice I think got the hang of it pretty okay. We then looked at floating point numbers and the difference between unsigned and signed integers as well as how they are represented in binary. The lesson then moved to the data representation of letters and in this case the difference between ASCII and Unicode. The main takeaway I got from this section is that ASCII is great for English but does not have enough capacity for other languages. As of which Unicode is great for multiple languages as it's number capacity is much higher, it even supports emojis. After the lesson on letters we then moved onto sound representation. One of the things I learned is that at regular intervals sound waves are time sliced and a value between -1 and 1 is retrieved. As well as that 44Khz is the highest frequency the human ear can hear and that if you want to add stereo you multiply that frequency by 2 and if you want surround sound you multiply that value by 5 or greater. Finally on the topic of data representation we covered graphics. What I got from that section was that each pixel is comprised of three colours red, green, blue. And that the amount of bytes per pixel affects how much colour range is available. Overall these were my main takeaways from the data representation segment of the class.

The last thing we covered for the day was a introduction to the 6502 assembler syntax. What really stuck out too me was that there was very little english built into the language as a lot of it were three letter abbreviations of commands. Another thing that stuck out was the heavy use of hexadecimals and the '$' sign. Overall this section seemed quite intimidating but I'll do what I can to get the hang of it.

Day 1 Reflection

Day 1

Date: January 6, 2020


This was the day where my journey in SPO600 began. We covered the basics of a computer's architecture and what it means to optimize your software. This includes how the CPU and RAM talk to each other as well as a basic overview of the makeup of each part. Such as how blocks of RAM are laid out and how each block is identified by the CPU. One concept that I thought was really fascinating with was the impact of optimizing your code. As initially I thought by making your code more efficient you would just make the computer run faster. But I learned in addition to that more efficient code could lead to lower power/battery consumption and better temperatures for the computer. This concept stood out from me as it made me realize that faster code isn't just about making your program faster but also about improving the overall experience for the computer and the user.


Overall while this day was quite daunting to me as I have never done anything this low level in programming before. I look forward and sort of nervous to what ideas and experiences this course will expose me to.

Lab 1: Code Review

Findings: Blender

License: GNU General Public License

Observed patch: https://developer.blender.org/D6532

Other sources:
- https://wiki.blender.org/wiki/Tools/CodeReview

- https://wiki.blender.org/wiki/Process/Contributing_Code

The review process for the Blender project works by, first giving a detailed description on what you’re trying to do. This includes what is the problem you’re trying to solve, what is the solution you’re proposing, and a mock-up of how this solution will work. This will then result in a discussion about this idea bringing out various opinions and recommendations on how this proposed idea should be brought forward. The discussion that takes place is most of the review process as while the author is working on the code, their ideas are being looked over by other developers typically 3 or 4 of them. Another part of the review process is more on the technical side such as making sure patches submitted are small and that any code changes made fit the style of the file being changed.

The advantage of the Blender project review process is that it requires developers to have some thought into their ideas before they are implemented. This is to make sure that there is a clear vision on what the developer wants to do. The disadvantage to this process is that there are quite a few roadblocks before you can get started on your idea. If I were to submit a patch to this community I would at first clearly state on what I want to do and would show something that gives some idea on what I want to accomplish with my patch. Then I would try to follow all of the technical and design guidelines during the creation of my patch, while at the same time taking in feedback along the way.

---

Findings: Atom

License: MIT

Observed patch: https://github.com/atom/atom/pull/19862

Other sources: 
- https://github.com/atom/atom/blob/master/CONTRIBUTING.md#before-submitting-an-enhancement-suggestion

- https://flight-manual.atom.io/faq/sections/how-can-i-contribute-to-atom/

The review process for the Atom project works by having your ideas and code discussed with other developers. This is done in the, “Pull Request”, section on Github as there is a forum that allows this discussion to take place. Once the author is finished they can submit a pull request and from there an automated test takes place checking if their code can work on the various platforms Atom supports. Once that check has been passed another will take place checking if the code given can merge into the base branch with no difficulties. If the merging is determined to be safe then the code given will be merged into the base branch.

The advantage to this review process is that you can just get started on your work and can even submit with no human intervention. However, the disadvantage to this approach is that the repository can be cluttered with error filled pull requests. As of which, if I were trying to contribute to this community I would first get feedback on what I want to do and as I work I will ask for opinions to see if I’m on the right track.