Skip to main content

Colour Selection

Photo by Scott Webb on Unsplash


Today I'll talk about Lab 4. We had to pick two tasks out of four and develop the solution using my least favour language: assembly. Our group chose the options 2 (data input form) and 4 (screen colour selector) thinking that would be the easiest ones. The other options were adding calculator and hexdump. This post will talk about the colour selector, and my next will be the input form.

The colour selector project was quite easy to do relatively. There are only 16 colours available (0 to F in hex). We have to list them in the text area and allow the selection using the cursor (up and down). Once the colour is selected, we have to paint the graph area.

The graph area we did before. Basically, we have to store the colour code for every pixel in the display using the memory location between $0200 and $05FF. In the last post, we deal with up and down keys to change the numeric display. However, we never dealt with character display before.

The character display works the same way as the graph. Its memory locations range from $F000 to $F7CF and have 25 lines of 80 characters (80x25). The complication here is the navigation between rows. It is not a matter of just increment the high bite – meaning more code and more working hours. Fortunately, we have ROM routines to help us to navigate, get and set the characters. Just like calling a function.

To know more about the ROM routines, access the 6502 simulator notes and take a look at "ROM Routines."

I tried to put as many comments in the code that I could. Also, that was my first time using the stack (instructions pha and pla) that saved my code! The stack is a handy area to save data when you need to free registers to do something and then restore that data.

I'm proud of myself finishing this code. I know that is room for improvement, but I can see my progress using assembly. See you in the next post.

Labels:

Comments

Post a Comment

Popular posts from this blog

SIMD - Single Instruction Multiple Data

Photo by  Vladimir Patkachakov  on  Unsplash Hi! Today’s lecture, we learned SIMD - Single Instruction Multiple Data. This is a great tool to process data in a bulk fashion. So, instead of doing one by one, based on the variable size, we can do 16, 8, 4 or 2 at the time. This technique is called auto-vectorization resources, and it falls into the category of machine instruction optimization that I mentioned in my last post. If the machine is SIMD enabled, the compiler can use it when translating a sum loop, for example. If we are summing 8 bits numbers, using SIMD, it will be 16 times faster. However, the compiler can figure that it is not safe to use SIMD due to overlapping or non-aligned data. In fact, the compiler will not apply SIMD in most cases, so we need to get our hands dirty and inject some assembly. I’ll show you how to do it in a second. Here are the lanes of the 128-bit AArch64 Advanced SIMD: 16 x 8 bits 8 x 16 bits 4 x 32 bits 2 x 64 bits 1 x ...
Post a Comment
Read more

Two-digit Numeric Display

Photo by  Nick Hillier  on  Unsplash Hi! I'm continuing my blog about my SPO classes. After a brief introduction in Assembly, we are good to hit Lab3. Our instructor kindly let us choose one project out of five. And of course, we decided to go with the easiest! We had to do a two-digit numeric display where the numbers are incremented or decremented by pressing plus and minus key in the keyboard. Soon the challenges were reviled as we dive into how to code it. Should we treat every digit separated or together? How to print them into the display? After a moment of reflection, we decided to handle the digits independently to facilitate the printing display. Also, we had to add a bit-map representation of the numbers because the 6502 chip doesn’t know any font. In this post, I’ll show you the code with the logic to increment and decrement without displaying anything. You can monitor the address $13 and $14 to make sure that it is working. Le...
Post a Comment
Read more

Profiling

Photo by  Jack Millard  on  Unsplash Hi! Do you want to know which part of the code is taking more time to run? Profiling is the technique to collect runtime data that shows exactly that. We did that manually in the previous labs by adding the elapsed time for the function under analysis – this is called instrumentation. The other way is to interrupt the execution multiple times, taking snapshots along the way – this is called sampling. Sampling doesn’t change the binary, but it might not get all data. Let’s say that if a task starts and finishes between the snapshots, we won’t get it in the report. On the other hand, the instrumentation will get everything, but it has to change the executable. As a result, we will not test the final version. We have to keep that in mind to use the right tool for the situation. Speaking about tools, here they are gprof and perf. The gprof does sampling and instrumentation, while perf only does sampling. To use gprof, ...
Post a Comment
Read more