Tuesday, 28 January 2020

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.

Sunday, 26 January 2020

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

Thursday, 23 January 2020

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.

Sunday, 19 January 2020

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.

Tuesday, 14 January 2020

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.

Sunday, 12 January 2020

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.