Week 4 - Lecture

This week's lecture started with how we can display text on the 6502 emulator. I found it fairly easy.
Here is a sample code:

define SCREEN $f000
           ldy #$00
 
 char:     lda text,y
           beq done
           sta SCREEN,y
           iny
           bne char
 
 done:     brk
 
 text:
 dcb "S","P","0","6","0","0",32,"i","s",32,"a","w","e","s","o","m","e",".",00

This was accomplished by having a text as dcb and looping it to load and store it in accumulator.
Spaces were put using number 32 and all characters were put in double quotes.

Next we talked about compiling the code. We compiled a simple C program inside linux and saw its executable was larger than its original file. We also learnt about dynamic and static linking and how each of them have their own pros and cons. While static being larger in size and dynamic was relatively smaller. Then we learnt about different compatibility modes it had to offer and how it could range from O0 (almost no optimizations) to O3 (most optimized) and we were also shown how many flags for optimized content was set to active and how we could manipulate it. Og was used to optimize for debugging. We almost looked upon certain commands like make which could be used to make partial builds inside of whole when small changed are made to source files.

This week's lecture ended with us touching upon something new and we were also told text was the last thing we learnt on 6502 and we wont be working with it anymore.

Week 4 - Lab 3 continued

This week's lab started with us giving a quiz. We were all a bit surprised as we did not expect it but it turned out to be just fine in the end since it was just matching and there were no short or long questions to answer. Rest of the lab was given to us to figure out more about lab 3 and work on it.
We still did not have much to end the lab with so we decided and talked to professor a bit more about it and understanding it in more detail.
After much discussions finally we were able to incorporate everything we know and combined declare constant byte's knowledge to get rid of multiplication, used delay loop that would keep counting as necessary to give us necessary delay to give an effect of moving, incremented rows and columns accordingly to direct the graphic and finally filled the display with black color where the graphic is no longer there. Here is the full code for this lab:

; zero-page variable locations
 define ROW        $20    ; current row
 define    COL        $21    ; current column
 define    POINTER        $10    ; ptr: start of row - upper left corner of object
 define    POINTER_H    $11
 define    WPOINTER    $12    ; ptr: start of row - write pointer
 define    WPOINTER_H    $13
 define BOUNCE_X    $14
 define BOUNCE_Y    $15
 define ROW_COUNT    $16
 define TIMER        $17    ; ptr: delay timer
 define TIMER_H        $18 
 define TIMER_CONTROL    $19 ; contains the base of the high bit of the timer

; constants
define WIDTH         7     ; width of graphic
define HEIGHT         7     ; height of graphic
define GREEN        $05    ; GREEN
define BLUE        $03    ; BLUE
define BLACK        $00    ; BLACK
define RIGHT        $19    ;  defining where the graphic must change direction accounting for its size
define    LEFT        $00    ;
define TOP        $00    ;
define BOTTOM        $19    ;

        lda #$0         ; initialize delay loop counter
        sta TIMER   
        sta TIMER_H
        lda #$40      ; setting the initial speed of the timer
        sta TIMER_CONTROL
        lda #$01        ; assume that the object is moving across the screen
        sta BOUNCE_Y ; contain the rate motion of the box along the Y axis
        lda #$01
        sta BOUNCE_X ; contain the rate motion of the box along the X axis
        lda #$03     ;setting were object starts on screen
        sta ROW
        lda #$06
        sta COL

loop:
    clc
    ldy ROW            ; load POINTER with start-of-row
    lda table_low,y
    adc COL
    sta WPOINTER
    lda table_high,y
    sta WPOINTER_H
    lda #$00            ; number of rows we've drawn
    sta ROW_COUNT         
    ldx #$00            ; index for data
    ldy #$00            ; index for screen column

draw:   ; draws graphic
    lda data,x   ; set up where graphic starts on sreen
    sta (WPOINTER),y
    inx
    iny
    cpy #WIDTH
    bne draw
    inc ROW_COUNT            ; increment row counter
    lda #HEIGHT            ; end of graphic by height
    cmp ROW_COUNT
    beq done            ; exit
    lda WPOINTER           ; load pointer
    clc
    adc #$20            ; add 32 to drop one row
    sta WPOINTER
    lda WPOINTER_H        ; carry to high byte if needed
    adc #$00
    sta WPOINTER_H
    ldy #$00
    beq draw

done:
    lda TIMER_CONTROL ; initialize timer with current speed
    sta TIMER_H

delay:  dec TIMER ; wait
        bne delay
        dec TIMER_H
        bne delay

        clc
        ldy ROW            ; load POINTER with start-of-row
        lda table_low,y
        adc COL
        sta WPOINTER
        lda table_high,y
        sta WPOINTER_H
        lda #$00            ; number of rows we've drawn
        sta ROW_COUNT         
        ldx #$00            ; index for data
        ldy #$00            ; index for screen column

wdraw:   ; remove graphic were it has been draw
    lda #BLACK
    sta (WPOINTER),y
    inx
    iny
    cpy #WIDTH
    bne wdraw

    inc ROW_COUNT            ; increment row counter
    lda #HEIGHT         
    cmp ROW_COUNT
    beq wdone            ; exit

    lda WPOINTER           ; load pointer
    clc
    adc #$20            ; add 32 to drop one row
    sta WPOINTER
    lda WPOINTER_H        ; carry to high byte if needed
    adc #$00
    sta WPOINTER_H
    ldy #$00
    beq wdraw

wdone:  ; check graphic if hitting a sides and if so change direction
    clc
    lda COL
    adc BOUNCE_X
    sta COL
    cmp #RIGHT
    bne no_bounce

    pha
    lda #$ff   ; using the fact that the register overflows adding ff is the same as subtracting 1
    sta BOUNCE_X
    pla
 
no_bounce:
    cmp #LEFT
    bne no_bounce1

    lda #$01
    sta BOUNCE_X

no_bounce1:
    clc
    lda ROW 
    adc BOUNCE_Y
    sta ROW
    cmp #BOTTOM
    bne no_bounce2

    pha
    lda #$ff
    sta BOUNCE_Y
    pla
 
no_bounce2:
    cmp #TOP
    bne no_bounce3

    lda #$01
    sta BOUNCE_Y

no_bounce3:

getkey: 
    lda $ff        ; get a keystroke
    ldx #$00    ; clear out the key buffer
    stx $ff
    cmp #$2d    ; is it a minus
    bne check

    clc   ; slow down timer
    lda TIMER_CONTROL
    adc #$01 ; changing speed of timer by adding to the timer
    bcs ignore

    sta TIMER_CONTROL

ignore:
    jmp move_it

check:
     cmp #$2b    ; is it a plus
     bne check0

    sec  ; speed up timer
    lda TIMER_CONTROL
    sbc #$01 ; changing speed of timer by subtracting from the timer
    beq ignore

    sta TIMER_CONTROL
    jmp move_it

check0:
    cmp #$80    ; check key == up
     bne check1

    sec
    lda ROW        ; ... if yes, decrement ROW
    sbc #$01
    beq ignore

    sta ROW
    jmp move_it

 check1:
    cmp #$81    ; check key == right
     bne check2

    lda COL        ; ... if yes, increment COL
    adc #$01
    cmp #RIGHT
    beq ignore

    sta COL
    jmp move_it

 check2:
    cmp #$82    ; check if key == down
    bne check3

    lda ROW        ; ... if yes, increment ROW
    adc #$01
    cmp #BOTTOM
    beq ignore

    sta ROW
    jmp move_it

 check3:
    cmp #$83    ; check if key == left
    bne move_it

    sec
    lda COL        ; ... if yes, decrement COL
    sbc #$01
    beq ignore
 
    sta COL
    bcc move_it

move_it: 
    jmp loop

data:  ; for the graphic
dcb 00,03,03,03,03,03,00
dcb 03,02,03,03,03,02,03
dcb 03,03,03,03,03,03,03
dcb 03,03,03,03,03,03,03
dcb 03,02,03,03,03,02,03
dcb 03,03,02,02,02,03,03
dcb 00,03,03,03,03,03,00

 ; these two tables contain the high and low bytes
 ; of the addresses of the start of each row

 table_high:
 dcb $02,$02,$02,$02,$02,$02,$02,$02
 dcb $03,$03,$03,$03,$03,$03,$03,$03
 dcb $04,$04,$04,$04,$04,$04,$04,$04
 dcb $05,$05,$05,$05,$05,$05,$05,$05,

 table_low:
 dcb $00,$20,$40,$60,$80,$a0,$c0,$e0
 dcb $00,$20,$40,$60,$80,$a0,$c0,$e0
 dcb $00,$20,$40,$60,$80,$a0,$c0,$e0
 dcb $00,$20,$40,$60,$80,$a0,$c0,$e0

Week 3 - Lecture

Like last week, I was expecting the professor to give us the code for lab 3 as we were not able to make much improvements in our code, but it did not happen. Anyhow he gave us some very important logic on how each of the problem could be approached. You can view all of them here:
https://wiki.cdot.senecacollege.ca/wiki/6502_Assembly_Language_Math_Lab
So for our problem he told us we could approach it in a way where we could use deltaX and deltaY to manipulate rows and columns and he also showed us different techniques on how multiplication could be performed otherwise since there is no instruction for multiplication in assembly. He also suggested we could use dcb logic used in Etch-a-Sketch Style Drawing code on page:
https://wiki.cdot.senecacollege.ca/wiki/6502_Emulator_Example_Code.

Although I did not get what I wanted, I still got an insight of what I was looking for and I had more to think of. After this he proceeded to tell us about different addressing modes that were there and explained utility for each of them. There were a total of 13 of them.
You can find the list and more about each of those modes under:
https://wiki.cdot.senecacollege.ca/wiki/6502_Addressing_Modes

Then he also talked a little bit about possible projects that we could be working on and how to find one of them in future.
Some key points I collected from the possibilities were:
1. It should be an open source package.
2. Should be CPU intensive: could be

• codec
• compress
• images
• crypto
• math
• large data sets

The class ended and next target I had in mind was to work on and finish lab 3.

Week 3 - Lab 3

This week's lab started with professor asking us to discuss lab 2 if anyone in the group had any doubts about which I blogged about last week. Once we were done with it we were given a bunch of options to choose from for our lab 3 challenge. After plenty of discussions our group decided to go for a moving graphic across the screen. Full Challenge:

Option I: Bouncing Graphic
Create a simple graphic in a square that is 5x5 or 7x7 pixels in size. Use the colours available in the emulator's bitmapped display. The graphic could be a ball, a happy face, a logo, an emoji, or anything else (appropriate!) that you want to use.
Encode that graphic in bytes using DCB (declare constant byte) instructions.
Write code to make the graphic bounce around the screen, reflecting off the edges when it hits. Note: for simplicity, it is OK if the object always bounces at 45-degree angles.
Make the speed keyboard-adjustable (faster/slower) and perturb the object's path once in a while.
Challenge: randomize the starting position, and make the object bounce at angles other than 45 degrees.

Rather than getting it all at once. We decided to take a step by step approach to it. So we started by one person working on the face using declare constant byte instructions and other were trying to figure out how we could get to move a pixel in one direction first, then at an angle, then figuring out the edges and how it would bounce from it, and finally moving the whole smiley face.

While there was very limited time left when we started to work on this lab. By the end of this lab we were only able to figure out the smiley face which was pretty straight forward and creatively done by our groupmate.The following dcb instructions were used by our groupmate:

dcb 00,03,03,03,03,03,00
dcb 03,02,03,03,03,02,03
dcb 03,03,03,03,03,03,03
dcb 03,03,03,03,03,03,03
dcb 03,02,03,03,03,02,03
dcb 03,03,02,02,02,03,03
dcb 00,03,03,03,03,03,00

Week 2 - Lecture (Lab 2 continued)

Continuing from the previous blog we were still working with 6502 emulator for the course (http://6502.cdot.systems/) and on the last two questions on the lab which were:

Writing Code, Part 1[edit]

14. Write code to draw a green line across the top of the bitmap screen and a blue line across the bottom.

Writing Code, Part 2[edit]

15. Extend the previous code to draw a yellow line down the left side of the screen and a purple line down the right side.

The professor thankfully gave us the answers to these questions.

Q. 14 was comparatively easier to 15 and was acheived by loading green color in the accumulator and starting from 0200, progressing it with the index same way we did earlier using a loop, but only for 20 iterations since one line was 32 bits which is 20 in hexadecimal and we would compare it using cpy #$20 and once y reaches 20 we make it exit the loop since cpy #$20 makes it to remember the result make it exit the loop. and for blue line we again load accumulator with blue color and starting to fill it from 05E0 which is start of last line and keep progressing it using loop until next 20 iterations.

Q.15 involved a little more complexity since only incrementing y index would not work so we got to learn a new instruction which was for addition adc which stands for add with carry and adds the number specified including the carry flag. Since carry flag can be set or unset at times and can cause uncertainty so we were advised to always clear the carry before doing additions and set the carry flag during subtractions due to similar reason. (subc). So we just amend the previous idea to add 20 during each cycle of loop so it ends up being on next line on the exact next pixel vertically and continue till it it fills whole of the display.

Then we were shown a part of code that would move a pixel with the help of arrow keys. Code can be found under Etch-a-Sketch Style Drawing on this link: https://wiki.cdot.senecacollege.ca/wiki/6502_Emulator_Example_Code

There are few things I would point out in this code that I thought were important; dcb stands for declare constant byte and was used in this code to declare the values for the high and low bytes of specific positions on the screen. The last pressed key is stored in $FF as ASCII code. To ensure the pixel does not go out of screen and overflows to appear at other end the instruction to draw rows and columns were anded with #$1F which is for 31 and ensures pixel always remains on the screen. Checks were coded from #$80 to #$83 to check if up, right, down, left keys were pressed respectively, then according to the key rows and columns were incremented and decremented to move the pixel accordingly.

Honestly, every week I feel there was alot more stuff thrown at us than expected. It could be because we are new to this language but not new to programming. So I guess once we get an hang of it, it should not be that hard.

Week 2 - Lab 2

As with last week, this week too we were expected to work with 6502 (Wiki: https://wiki.cdot.senecacollege.ca/wiki/6502) emulator (http://6502.cdot.systems/). We had to complete a group lab and we were given an initial code to start with:

lda #$00 ; set a pointer at $40 to point to $0200
 sta $40
 lda #$02
 sta $41

 lda #$07 ; colour

 ldy #$00 ; set index to 0

loop: sta ($40),y ; set pixel

 iny  ; increment index
 bne loop ; continue until done the page

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

This code fills the whole bit mapped display with yellow color. More information on how this code works can be found in my last blog under Week 1 - Lecture. Lab is followed under:

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

 tya

What visual effect does this cause, and how many colours are on the screen? Why?

tya instruction transfers index Y to accumulator. Since accumulator is used to determine what color will be drawn on the screen and since y is loaded with 00 and gets transferred to accumulator, so first pixel gets loaded with color black and after that y register keeps incrementing and gets transferred to accumulator in start of every iteration of the loop so display gets filled with 16 different colors as lower bit becomes same after 16 iterations and again until it fills the entire display.

Add this instruction after the tya:

 lsr

What visual effect does this cause, and how many colours are on the screen? Why?

lsr instruction stands for logical shift right and shifts all the bits to the right once. This causes the bytes to be divided by 2 and same color gets outputted twice and we don't see repetition of colors this time and only 16 colors are outputted.

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

When lsr is tested by putting it two, three, four and five times in a row, the same result multiplies and bytes get divided by 2 each time it is done and the colors take up twice the size of pixels than previous result which is:

Two:      Each color is taking up 4 pixels. Outputting all colors now requires two lines.

Three:   Each color is taking up 8 pixels. Outputting all colors now requires three lines.

Four:     Each color is taking up 16 pixels. Outputting all colors now requires 8 lines.

Five:      Each color is taking up 32 pixels. Outputting all colors now requires 16 lines.

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

asl stands for arithmetic shift left which can considered opposite to lsr and instead of shifting bits to right it shifts it to right, resulting in multiplying of byte by 2 and amount of colors being displayed starts dividing by 2 so at once asl it divides the number by 2 i.e 16/2 results in displaying first 8 colors then after second it displays first 4 colors, 2 colors on executing asl 2 times and results in only black color being printed in 4th and fifth execute which is because it displays only black color.

Remove the tya and all asl and lsr instructions.

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

This results in one yellow and one black line after one 2 executions of iny which is because it is adding 2 indexes to the y in each iteration and results in it skipping one pixel and filling every even pixel. and next iteration makes it add 3 indexes and this one fills entire display because it only exits loop after y reaches FF but since it takes 3 iterations over whole display for it to reach FF it eventually fills in entire display (1,4,7). After 4th time it skips 4 pixels and hits FF at first iteration itself so we just see one yellow followed by 3 black lines. Something similar to putting iny 3 times happens when we execute iny 5 times consecutively and it also starts from start, prints yellow after 5 pixels and does this to very end of display but does not hits FF and comes back to 2nd pixel from start and keeps doing this until it hits FF and fills in entire display.

Writing Code, Part 1[edit]

14. Write code to draw a green line across the top of the bitmap screen and a blue line across the bottom.

Writing Code, Part 2[edit]

15. Extend the previous code to draw a yellow line down the left side of the screen and a purple line down the right side.

There were another two questions in the lab which are listed above which we were not able to figure out due to end of time for the class. Overall it was a fun lab, playing around with the bits and colors over the display using different instructions and their executions.

Week 1 - Lecture

The first week's lecture started with giving us an insight of how different forms of data was interpreted by the machines. Integers are interpreted in the forms bits as the combination of 0's and 1's. Same as integers, characters were also represented by the 0's and 1's as bits and it's value was figured out by using the ASCII table. Digital sounds are represented as series of time based measurements which was called Pulse Coded Modulation. but as PCM took alot of storage, sound was compressed by either lossless or lossy modes of compressions. Images are represented as collection of pixels which in turn are made of combination of RGB colors ranging from 0-255 giving a total of 16 million color combinations. Same as sound raw storage of graphics took alot of space so they could also be compressed by either lossless or lossy compressions. Videos are interpreted as moving images and can be compressed by encoding differences between each frame. Different compression techniques which could be applied on these are listed here:
https://wiki.cdot.senecacollege.ca/wiki/Winter_2020_SPO600_Weekly_Schedule#Week_1_-_Class_II

Moving on we were introduced to 1970's processor which was 6502. Here is a introduction about the same if you guys are interested: https://wiki.cdot.senecacollege.ca/wiki/6502.
We were then taught that the processor was divided into different sections, first 0-100 for storing the variables, 100-200 was the stack, 200-600 was the bitmapped display. There are 3 registers on this processor that we can work with which were A, X and Y.

Then we were shown the emulator for 6502 (http://6502.cdot.systems/) that were dealing with in the first few weeks of this course. Here is the first program we were shown for this course:

lda #$00 ; set a pointer at $40 to point to $0200
 sta $40
 lda #$02
 sta $41

 lda #$07 ; colour

 ldy #$00 ; set index to 0

loop: sta ($40),y ; set pixel

 iny  ; increment index
 bne loop ; continue until done the page

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

This code fills the bitmapped display with the color yellow.

Explanation:
Starting from the top, the lda instruction loads the accumulator with number 00 (Note: starting with $ is a hexa decimal address and starting with # is just a hexa decimal number). the second instruction sta stores that instruction at address 40, which is repeated on next two instructions, putting 02 at adjacent address 41. This combination acts as a pointer thus pointing to 0200 (aligned little endian) which is the start of the display.
After this, the instruction lda loads the accumulator with number 07 which is for the color yellow. and ldy sets the index at 0 at Y register. The loop starts with storing yellow color as loaded earlier at address 40 + y and sets first pixel in the display's color to yellow. iny then increments the index at y register and increments it by 1 and this loop keeps going until Y reaches number FF as it can range from 00 to FF and once it hits that it returns to be 00 and exits the loop. Since this also marks ends of first page it is now essential to increment page so we can fill in next page and so on until it reaches 06 which marks last page. Instruction inc $41 which hold 02, increments it by 1, making it 03 and reaches the next page. We then create a check to stop incrementing pages as we hit the last one, so ldx $41 pulls which page we are on and sort of remembers it. cpx #$06 checks if the last remembered result is number 06, if so it exits the program, otherwise keeps branching it to loop created earlier to fill in individual pages. And in this way whole of the display is filled with yellow color.

Week 1 - Lab 1

For this lab, we were asked to research on two open source software with different licenses and find out the process to contribute to its source code and observe an iteration of the same. The software I have chosen for this lab are Firefox and React respectively, which have MPL 2.0 and MIT licenses respectively.

1. Mozilla Firefox (license: MPL 2.0)

Introduction: Firefox uses a forum named BugZilla to work on the bugs where different members of the community review and comment on the forum for that particular bug.

Software patch : The bug I looked into was ID: 651266 in which the google map maker was missing some style elements. While the bug was reported by Leman Bennett, around 5-6 people worked on reviewing it and got it resolved. Alice0775 White pointed out an attribute selector was failing while loading it and looked like it was a typo in a file named gw.css. Then the Google was contacted about this issue and finally after a few days Christopher Blizzard received an email, that the issue was fixed internally but were just waiting to push it. Once it was pushed everything seemed normal and the bug was fixed and the issue was changed to resolved. The process took a few weeks and the participants were quite active with their frequent responses. Here is the link to that bug: https://bugzilla.mozilla.org/show_bug.cgi?id=651266

Findings: I also looked at the guide suggesting how we could contribute to the community. It suggested getting the code reviewed once we feel it was fixed, from a mentor if we were working on a mentored bug or finding reviewers which could be the ones working on similar issues. Following up with the reviewers is necessary once we don't get a reply within a particular frame of time. Once it is accepted by the reviewers the patch is ready to be merged but needs to go through the try server and the automated testing. Once they are successful, the patch is then merged into the main tree. Here is the link the guide: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction

Advantage and disadvantage: Advantage for this type of bug tracker is that it automates documentation while a disadvantage is that some developers have complained that it is hard to manage the logged in errors.



2. ReactJS (license: MIT)

Introduction: All the contributions to react are created, reviewed and submitted through software development version control called Github.

Software patch: I looked at one of the latest releases of ReactJS which was v16.12.0. It had about 34 contributors working on it and was being worked on for over 2 months. The contributors to the post were quite responsive as we saw commits being made to it almost everyday. The patch dealt with 2 major fixes being for passive effects (useEffect) not being fired in a multi-root app for React DOM (#17347) and lazy and memo types considered elements instead of components for React ls (#17278). I found just 5 comments on Github so there was not much to be understood about the problem being fixed. But still there was a function named didScheduleRenderPhaseUpdate which was being set to true immediately after the first render phase update so they had to change code to be traversed to through the work-in-progress list. As of today, there have been 164 commits made to it already. Here it the link to the patch: https://github.com/facebook/react/releases/tag/v16.12.0


Findings: All the contributions are made via Github and there are guides to how we can contribute to an open source project on Github. Once you are ready to submit your code you can submit a pull request via master branch of the latest stable version. And from there on the core team reviews the request and either closes or applies it with an explanation. There are some steps to be taken before submitting the request and also the guide on how one can contribute both of which can be found in the link below:
https://reactjs.org/docs/how-to-contribute.html

Advantage and Disadvantage: I feel this is a very organized way of submitting patch requests but with the limitation of it taking more time for users to fulfil their requests.