Specifications

level programs such as the game. You must implement the following ioctls for your device abstraction:

TUX INIT Takes no argume nts. Initializes any variables associated with the driver (see TUX READ LED) and

returns 0. Assume that any user-leve l code that interacts with your device will call this ioctl

before any oth e rs.

TUX

SET LED The argume nt is a 32-bit integer of the following form: Th e low 16-bits specify a number whose

hexadecimal value is to be displayed on the 7-segment displays. The low 4 bits of the third byte

speciﬁes which LED’s should be turned on. The low 4 bits of the highest byte (bits 27:24) specify

whether the correspo nding decimal points should b e turned on. This ioctl should return 0.

TUX

BUTTONS Takes a pointer to a 3 2-bit integer. Retu rns -EINVAL error if this pointer is not valid. Otherwise,

sets the bits of the low byte corresponding to the currently pressed buttons, as shown:

startright left up a

bcdown

For full cr edit, use an interrup t-driven ap proach ra ther than polling.

Your changes to the device driver should be limited to the ﬁles tuxctl-ioctl.h and tuxctl-ioctl.c. The func-

tion tuxctl

handle packet handles all packets received by the compute r from the Tux controller. The function

tuxctl

ioctl handles calls from user code ( the gam e ) to ioctl. You may a dd more ioctl calls, however the

required ioctls above must work as intended.

Tux Controller communication protocol:

The Tux controller pro tocol for interacting with the PC is described in mtcp.h, as you saw in PS2. Messag e s sent to

the Tux controller are of variable length, while messages sent to the computer ar e always three bytes in length of the

following general form:

Responses from the controller to the PC are always sent as three-byte packets of the following general form:

0 1 0R4 R3 R2 R1 R0

7 data bits

The 5- bit vecto r R[4:0] in byte 0 represents an opcode. All possible opcodes are deﬁned in mtcp.h The other three

bits in byte zero are ﬁxed as indicated. Notice that b it 7 of each byte is ﬁxed and used to frame th e packets. This is a

feature of th e packet format because the COM port emulation in the old Microsoft Virtual PC software that we used to

use was unreliable a nd occasionally lost bytes sent through it. The pr ovided kernel patch includes code to detect this

behavior and avoids providing y ou with broken pac kets. See the code in tuxctl-ld.c for details.

The Tux controller supports many different comm ands, eac h of which is d eﬁned in mtcp.h. You are on ly required to

use a couple of them for this MP.

We reco mmend that you make use of MTCP

BIOC ON and MTCP LED SET, in which case you must handle MTCP ACK

and MTCP

BIOC EVENT. You must also handle MTCP RESET p ackets sent to the computer by attemp ting to restore the

controller state (value displayed on LEDs, button interrupt generation, etc.).

MTCP

POLL This command consists of a single MTCP POLL byte (0xC2) sent to the controller: The response is a

three-byte packet with the following format: