Specifications

1
1
0 1 0 00 0 1 0
X X
X
C A
L
B
UDR
X
X X
S
7 0
1
2
0
That is, the fir st byte will have the value MTCP POLL OK, the second and third will contain active-low
bit masks of which buttons are pressed; that is, a bit will be ‘0’ when the corresponding button is
pressed. The C, B, A, and START (S) buttons are in the second byte, and the right (R), down (D),
left (L), and up (U) bits are in the third. Bits marked as ‘X’ in the diag ram are unused.
MTCP
LED SET See mtcp.h fo r the definition of the LED SET bytes
Finally, a few im portant notes about the Tux controller:
For debugging purposes, when the controller receives an erroneous command, it locks up and displays 00P5 on the
seven-segment display. Pressing the reset button returns it to a usable state. This behavior can be disabled by sending
an MTCP
DBG OFF command; after this is sent, an erroneous command will elicit an MTCP ERROR respon se.
Additionally, when the controller is reset, for example by pressing the reset button, it asynchronously sends an
MTCP RESET packet to the PC. Your code must detect this condition and re-initialize the controller to the same
state it was in before the reset. In order to accomplish this your code must internally keep track of the state of the
device.
Debugging the Tux Controller:
Debugging in kernel space is not as simple as debugging in user space. You made find it h elpful to use printk()
from your driver module. printk() is like printf() for kernel mod e.
For mor econhen the kernel loads the tuxctl module, it may load it anywhere it pleases in its address space. This means
GDB needs to know where th e module was loaded bef ore it can start debugging it. The object file for the tuxctl also
needs to be loaded into GDB so that the proper symbols ca n be resolved.
Once your debug machine loa ds, load the tuxctl module (see above). You now need to find out where in memor y the
kernel loaded the module. Issue the com mand cat /proc/modules to print o ut the location of a ll modu le s currently
loaded in the kernel. You should see a line such as
tuxctl 6792 0 - Live 0xd0813000 (P)
at the top. 0xd0813000 is the add ress the module was load ed at. (It will probably be different for you). Back in
your devel machine , in the module director y, launch gdb w ith no arguments. Once in G D B, type add-symbol-file
./tuxctl.o ADDRESS where ADDRESS is the address tha t was printed out in for the module in your debug machine,
0xd0813000 in my case. GDB will then ask you to confir m. Type y and hit enter. Now you will need to connect
GDB to the remote machine by typing target remote 10.0.2.2:1234. You may now define breakpoints fo r yo ur
driver and continue as norma l.
Again, make use o f the stand-alone input prog ram in input.c before tackling the full game.
Final CP: VGA Palette Manipulations
The rest of the MP, which is also only due at the final d ue date, consists primarily of manipulating VGA pale tte colors
and making use of the event loop to control timing.
Find the VGA documentation for setting palette colors. As with the status bar, doing so was part of PS2. Write a
function that sets a palette color. Put the func tion in modex.c.
Make the player glow. The play e r’s center is a special color, so you just need to pick a color cycle and design it into
the event loop. Ticks range from 20 milliseconds down to abou t 5 ms; you can ma ke the colors change in ter ms of
ticks or absolute time, as you pref e r.
Make the maze walls and status bar change color with level. There are ten levels. Pick some colors. Make su re that