For the second assignment, testing was conducted to verify the correct functionality of the ASM program. Although tests using the AVR board were also conducted, like testing for led flashes and user input, the results are harder to document without using something like video recordings and so they will not be provided here. Macros were used to structure the code and even thought some macros like the store_pattern macro may seem like it could have been omitted, the thought behind constructing it was that it provides separation of concerns and scalability for future development. There were 4 important parts of the program that needed to be thoroughly tested and simulated:
- The storing in XRAM without using a stack, by calling the address directly
- The custom jump of the XRAM address pointer
- The modulo 8 used in the random seed generation
- The shifting of a bit to the right
.dseg ; Data segment
.org $420 ; Start storing at 0x420
storage: .byte 1 ; Allocate 1 byte for storage
.cseg ; Start code segment
ldi yH, high(storage) ; y High byte pointer
ldi yL, low(storage) ; y Low byte pointerSince data was saved to RAM without using a stack to point to address space, this test was written to confirm the fact that you can point to memory address directly by using the x, y, or z pointers.
.macro store_pattern ; stores the pattern and increments the pointer
st y+, @0
.endmacro
test_store_pattern: ; tests the store_pattern macro
store_pattern r16 ; should store the value of r16, in register 0x420 + current index
dec r16
brne test_store_patternThe store_pattern macro was used, that simply takes a register as argument and stores that register’s value into y+. Starting from register number 0x420 the value from r16 was stored. r16 started with an initial value of 10 (0a), so the expected result matches the actual result.
The result was as expected, and the test was marked as passed.
As the game grows in levels, a new pattern is added to the memory. Since each level the patterns are presented from the first, it meant that the y address pointer needed to be reset every new level, so it starts from the beginning again. In other terms, at the end of each level, the yL was set to point to current yL pointer minus the level number. To test this functionality, a test that increments the y pointer with a custom value was constructed.
test_custom_y_jump: ; tests custom y pointer jump
ldi r16, 1
ldi r17, 4 ; should jump with a step of 4
st y, r16
add yL, r17
dec r18
brne test_custom_y_jumpThe step of 4 and the fact that the y pointer was increasing instead of decreasing did not matter in the current context.
As it is seen above, the result is a value of 1 stored starting at register 0x420 and incrementing with a value of 4. The result of the test proved that custom jumps were indeed possible and was marked as passed.
The game uses a random number generation for adding a new pattern each level. This means that each new gameplay will be different. The random number is generated by adding a counter in the wait loop that starts to count from the first button press until the level is done.
A register is filled with the maximum value available (255) and for each wait iteration this value is reduced by 1, with the safety trigger that if the value reaches 0, it resets to 255.
This ensures that a random value should be presented in that register at the beginning of each level.
The problem is that the value is between 0 and 255 and the value needed is between 0 and 7.
The solution was to apply modulo 8 to the value, which guarantees a number between 0 and 7. Since 8 is a power of 2, the modulo operation was simply AND-ing that value with 7.
The option to count from 255 to 0 and mod the result instead of counting from 7 to 0 and taking the result was made to increase the chances of a truly random number to be generated.
test_modulo_8: ; test % 8 operation. Should dispaly a pattern
ldi r18, 0 ; of format 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 and so on
mov r18, r17
and r18, r16
st y+, r18
dec r17
brne test_modulo_8A test to confirm this fact was constructed. The test iterates from 255 to 0 and applies the modulo 8 operation.
As seen above, the result is the current value of the seed register AND-ed by 7, since is the expected result, the test was marked as passed.
The result from the random generator is a number between 0 and 7 but by itself that number is not wat was needed.
The number represents how many times the bit with the value of 1 in this binary pattern 1000_0000 should be shifted to the right, thus resulting in a random led being off (before displaying and storing, the pattern is XOR-ed since a random led being on was needed).
To test the functionality of the bit shifting a test was constructed.
test_shift_bit_right:
lsr r17 ; shift the 1 value in r17 to the right
st y+, r17
dec r16
brne test_shift_bit_rightThe test should show the representation of the pattern shown above, with the bit shifted to the left one step.
Luckily, the resulting new pattern is just the power of 2 so 0, 1, 2, 4, 8, 16, 32 and 64 but reversed since the shifting is from left to right.
In the hexadecimal result the values are displayed, but maybe more sense would make to show the values in a decimal format where is easier to understand
As seen above, the expected pattern was the actual pattern and the test was marked as passed.