COMP 1588: Computer Architecture - Simon Says (Hard)

Jacob Bowyer 06/05/2012

Contents
1 Design 1.1 State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Development Testing Evaluation 4.1 Meeting the brief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Improvements and enhancements . . . . . . . . . . . . . . . . . . . . . . . Reection 5.1 Weaknesses and struggles . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Strengths and progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 3 4 4 5 5 6 6 6 7

2 3 4

1 Design
The design o the application was actually quite simple when the problem was broken down and assessed in steps, if you looked at the problem from a more abstract view then it didnt seem so clearly dicult. With the random number generator explained in the documentation the only steps left to identify were the exact ow and process of the project, I decided on a poll style interface, given many dierent labels I could poll them to see if specic events had happened. This broke my problem down into the following algorithm (given here in pseudo code) Generate random number Enter l o o p D i s p l a y number Get u s e r i n p u t Check i n p u t == number i f equal d e c r e a s e time jump t o t h e s t a r t else : check u s e r i s out o f time i f out o f time buzz jump t o s t a r t else jump t o s t a r t o f l o o p

1.1 State Machine

From this I developed the ow chart for the application, seen on the next page. The state machine is simple enough given that the program only has 3 / 4 given states

1.2 Flow Diagram

2 Development
When developing the code I made it clear that the ow layout should all extend from main. Main would be responsible for calling out to all other labels and all other labels should ALWAYS return to main with the exception of clock which is allowed to break o to a lose label which then returns to clock. With the specic sections of the code boiled away in dierent callable labels, like random, reset and so on it was now time for the registers to be named and given specic uses this is where giving names to the registers helped. I named all the registers that I used in specic places in the program for example, time, seed, answer, panel1 and so on. These registers are also below 16 which means they cannot be used with ldi and can only have data moved into them using the mov instruction this gave me a form of quasi protection meaning that I never accidentally wrote a value into a register that I was using somewhere else I would always have to explicitly mov into that register to mutate it. This made debugging and developing rather simple as I could always see where the ow of the code was going and I knew exactly which labels could manipulate what registers. With each stage of the program and the use of the labels I was able to develop each feature one after the other nishing with the clock, giving my code a very modular feel.

3 Testing
Testing was slow for the assembly problem, not having worked at the lowest level before I struggled with not having specic higher order functions and abilities like unit-testing, so it meant much of my testing was spent running code either over the board or via the simulator to assert the exact values were in the correct registers. To further test the problem I kept my code as distinct and separate as possible, by splitting the code down into callable labels that always return to specic places it gave me a chance to remove a label and then test that label solely on its own. This is the method I used to test the random number generator, the digit display was tested by removing all the code that didnt help in displaying numbers and then simply ashed the code onto the Amtel board to ensure that the correct numbers were displaying and that the values were successfully looked up and written, something that assisted in bug tracking was good documentation and using .def and .equ, by giving things names and using r16 and r17 as only temporary registers where no immutable data should ever be stored I was able to develop the application without the worry of other registers getting lost or mutated. A horrible bug that testing couldnt help me track down was to do with the timer, a video of which can be found here. http://www.youtube.com/watch?v=lMT_QTpzJDQ where when the user ran out of time (simulated by setting the time out to a really low value for this example) then the display would cycle through numbers and beep endlessly. This bug was actually caused by the clock being reset incorrectly. out RESETSECOND, r 1 8 out RESETFIRST, r 1 8

Originally I did them in the other order as the name indicates but it caused the bug as shown so by switching the two (and I never got round to updating the names for some reason) it xed the bug. Although there was no specic testing plan the functionality of the project was fully tested with each part extracted to provide the best coverage possible.

4 Evaluation
4.1 Meeting the brief
Breaking down the brief into steps is the best way to evaluate the success of my project. The rst step of the project was; the random number is now displayed on the the dual seven display (see problem four above) in hexadecimal. My program reaches this very clear goal and succeeds in generating a pseudo-random, this number is then successfully written to the dual seven display and continually drawn enough so it seems to be constant. The pseudo-random number generator isnt quite as useful as I would have liked, it often loops after only 5-6 seeds. To x this issue and to work on a real random number generator it could be possible to use the clock as the seed for each new random number, this would mean grabbing the clock value, storing it in the seed register then generating the random number from this value giving a slightly better and more random outcome. The user should then enter then the number displayed in binary via the switches on the switch light box. This goal was rather easy compared to other tasks required by the brief, simply reading the input on the input port is enough to store the binary number into a given register. The program should allow the user a limited amount of time to enter the number. Once I understood the clock code, the timing tasks started to become rather simple, the clock as I have covered earlier just requires setup - polling - pass/fail this could be done far better using interrupts but at the level we are working at I decided to waste less time on learning the extra steps and just getting a working prototype done, the clock was actually the very last think implemented in my program because it took the most time. after each correct entry the program should display another random binary number on the the dual seven display Using my random number code that was abstracted to its own label the process of simply generating a new random number generator follows, getting a new number, setting the number in the two panels registers then drawing the number out on the output port. 5

Once I had called the two labels required to do this I could return to the main loop and carry on execution. and decrease the amount of time the user has to enter the next number. This particular goal was simple to implement, because I was doing a branch if greater than or equal to (unsigned) I could simply decrement the value I was comparing too a few times, this meant that when it ran the comparison it would take the original clock value of 40, then if the user won it would dec 40 twice meaning the timer value is now 38, then when it reached the clock checking section it would simply do clock = 38. If the user is timed out before the correct number is entered, the program should alert the user of the error by sounding the buzzer, and restarting the game. The branch on greater than or equal allowed me to direct the code to a failure label, where I could clean-up the clock and then using the same steps as win, generate a random number, and display it out before returning to the main loop.

4.2 Improvements and enhancements

I had already pointed out a huge major enhancement to the random number generator, by using the clock value as the seed for the next number this would decrease the chance of predictability and increase the randomness in the generator. Other improvements could include; playing a more complicated tune via the buzzer for winning and or losing, displaying the clock out onto another separate dual seven digit display, or even adding loading or generating animations to the current display when the program is resetting. All of these would give better feedback to the user and provide a much better interface for the user.

5 Reection
This project was hard. Especially as I left it later than I should have, I set myself a challenge to learn and understand all of the problem and have it implemented inside of two days. I achieved this goal. Using the documentation provided, my peers and other resources I could lay my hands on I now have a strong and condent grasp of assembly programming and can solve other problems without fear.

5.1 Weaknesses and struggles

By far the hardest bit was learning to manipulate the clock, this required much more research and lots of help from other students around me to understand the process of conguring the clock, polling the clock and also doing it in the right order, as explained above not fully understanding the clock actually introduced a rare bug into the program that was almost impossible to track down until I stopped working and thought backwards. I struggled at rst to also get the ow control between the main game loop, the 6

win condition and the lose event. This is xed with a slightly neater design now but it took some time to decide on the specic route the program would take with the clock poll and then from there to win/lose or main. The last challenge was the look-up table for converting hex into the values for the display, this was nally overcome by thinking of it in a dierent way and simply putting the value for 0 rst and the value for 9 at the 9th position, doing this allowed me to add the value I was looking for to the pointer value and then just load that into r0 giving me the number, then depending on the situation ip the 7th bit so that I could display it on the other half of the dual 7 display.

5.2 Strengths and progress

I realised that after only a tiny amount of time I was beginning to understand ow control in the program and also reading and writing to ports with the given data directions, this made getting user input and writing the numbers out to the display a rather simple task, this was further compounded by the fact that my code is split cleanly into labels almost like methods or functions that never leak and are only called from the main event when needed. Doing this allowed me to both prototype the design quickly and eciently and also keep the layout and design of the code clear and concise. I also had another advantage in my clear design, using the lower registers which cannot be loaded directly into I was able to store data in a more immutable way so that other labels I wrote would not accidentally write over the top of any value that I wished to store.