|
Administrator
|
The Fill.asm project is open-ended in that the assignment does not specify how you are to go about achieving the desired outcome, only what that outcome needs to be: If the user presses and holds a key down long enough, eventually the entire screen will become black, while if they leave no key pressed long enough, the entire screen will become white.
There are LOTS of ways to achieve this, some more elegant than others, some more efficient than others, and some more intuitive than others. But as long as those two criteria are satisfied, the solution is a valid solution.
Having said that, how to we confirm that the solution is valid?
This is easier said than done. There are 8192 16-bit memory cells in the SCREEN memory map, meaning 131,072 pixels on the screen. Ideally, the test script would put some keycode in the keyboard buffer (the KBD register) and then let the program run until every pixel was black. It would then put a zero in the keyboard buffer and run until every pixel became white. There are two problems with this approach. First, what if the program doesn't work properly such that the screen never does become entirely black or entirely white? At what point should the test script give up? Second, testing the entire contents of the screen is very time consuming, so how frequently should it be checked? A test script that would take hours (or years) to execute even on a well-written and correct program is useless.
So the testing of Fill.asm represents a compromise.
There are actually two test scripts. The first one, Fill.tst, isn't really a test script at all, it merely tells you to run your program and press a key and for you to visually confirm that the screen eventually turns all black, and then to release the key and for you to visually confirm that the screen eventually turns all white. This script should not be run on the command-line version of the CPU Emulator because it never stops. Also, the command-line version does not allow for keyboard input or screen output. The result is that the emulator will run forever without yielding any results -- this script is purely for interactive testing via the GUI version of the emulator.
The second test script, FillAutomatic.tst, is an attempt to automate the testing process, but passing it does NOT mean that your program actually worked properly -- and failing it does not mean that your program didn't. Here's why.
The test script performs three tests. First, it clears the keyboard buffer and then executes your script for one million clock cycles. The belief is that if your program hasn't made the screen all white by then, it likely never will. But if your program would do it in three million clock cycles, the program is technically correct, even though the test script probably declared it a failure. After the one million clock cycles, the test script checks nine specific memory addresses to see if they contain the expected values. It then repeats this process after placing a keycode in the keyboard buffer, running the program for another million clock cycles followed by checking those same specific addresses again. Finally, it clears the keyboard buffer, runs a million clock cycles, and checks those nine addresses a third time.
If those nine address all contain the correct value, then the script assumes that all 8K memory addresses in the screen buffer are correct. These nine addresses were chosen to examine commonly missed pixels, as well as a few "random" locations. The belief is that it is unlikely that an incorrect program would happen to correctly set all nine of these RAM cells in all three tests. But if yours does, then the script might declare your program correct even when it isn't.
A couple of final observations: It might sound like a million clock cycles is a lot, but if your program has a loop that sets the value of a single pixel on each pass, then that only allows each pass to consume an average of 7.6 clock cycles. At the other end of the spectrum, this problem can be solved with a program that requires a little over 100k clock cycles per test.
|
Locked
