Game Boy USB – Interface and Application

Robert Meerman

Introduction• Project Motivation & Focus• USB• Nintendo Game Boy Advance• Chips / Hardware • Enumeration• Descriptors, Requests & HID Class • Firmware• Unforeseen problems of note• Limitations and Restrictions• Demonstration preamble

Project Motivation & Focus• To add connectivity to a Game Boy Advance, enabling it

to have PDA-like features.• Essentially create a PC-to-GBA connection which is

– Widely compatible with current PCs (Serial? Parallel? USB?)– Easy-to-setup (no drivers)– Easy-to-use (no manual application configuration)

• Create a proof-of-concept application pair to demonstrate the above by sending and receiving (raw) data.

• USB was chosen and implementing it became the focus of the project.

USB Overview• Universal Serial Bus had a fresh start, not backwards

compatible• Benefits

– Automatic configuration, Hot pluggable, Bus powered– 3 Speeds with max throughput of 53 MB/s, 1.2 MB/s & 800 kB/s– Flexible for developers

• 4 Transfer types: Control, Interrupt, Bulk and Isochronous

• No specific functions for signals, unlike PC parallel port’s status lines

• (Composite) classes of device. E.g. mass-storage / printer / scanner

– Native operating system support

• Devices are micro-controlled and require firmware• Problems with USB

– Legacy operating systems, Distance limits, no peer-to-peer.

USB Layers

• USB devices require a host, all terminology is from host’s perspective (IN / OUT)

• USB devices can have multiple configurations and/or interfaces per configuration

• Control Pipe always present, bi-directional, can be used for data

• Acknowledged (ACK), Not Acknowledged (NAK), Stall and Not Yet (NYET) tokens

Nintendo Game Boy Advance• The Nintendo Game Boy Advance is a popular portable

games console. Some details include:– 32bit ARM7TDMI CPU running on RISC architecture at 16.78Mhz – 32KB of “internal” RAM and 256KB of “external” RAM

• 5-mode, multi-purpose communications port– Normal, Multi-player & JoyBus – proprietary Nintendo protocols– General Purpose – 4 pin I/O, using 0 / 3.3V signals– Hardware UART – 1 byte buffer, interrupt capable, RTS / CTS

• Development– Vibrant online community of successful hobbyists– Plenty of tutorials & example and even a mature open-source IDE!– Development of a UART “dumb terminal” was done quickly

Micro-controller• The department have facilities for, and experience with,

Microchip-brand programmable PICmicro chips (“PICs”).– Equipment / experience to write programs to chips and offer help– CCS compiler, allows developing in C instead of assembly

• The PIC16F877 was recommended to me– 33 I/O pins– Likely sufficient Flash ROM (112,000 Bytes)– Likely sufficient effective RAM (368 Bytes)

• Segmented memory– RAM segmentation was not an issue as the CCS compiler

managed RAM memory– ROM segmentation was an issue. The main interrupt handler had

to be broken up and a slight redesign made.

USB chip• Common practice to have dedicated chip for signalling /

error correction / buffering USB communications• Discovered source code + schematic based around a

PIC16F877 using a Philips Semiconductors PDIUSBD11• Found further examples of D11 implementations• D11 discontinued by Philips, replaced with PDIUSBD12

– 8bit parallel microcontroller interface, instead of I2C– SoftConnect™, programmable internal 1.5k pull-ups– GoodLink™, LED indicator of USB status and traffic

• The D12 takes care of– Communicating with bus (inc. retransmissions), notifying

microcontroller of (successful) events

• The PDIUSBD12 was decided upon.

Hardware

Descriptors & Requests• Descriptors are data structures that enable the host to

learn about a device. E.g. Device descriptor includes:– USB Specification release number device complies with– Class code (Mass storage, Printer) and possible subclass code– Maximum packet size of control OUT endpoint (endpoint 0)– Vendor and product ID + device revision number– Indexes to string descriptor, number of configurations supported

• Other required descriptors:– Configuration(s), Class, Interface(s), Endpoint(s)

• 11 standard requests (not all required), minimum set:– Get_Descriptor– Set_Address– Set_Configuration

Enumeration1. Device is attached, hub provides power & detects device2. Hub does not talk to device yet, but informs host of event3. Hub detects speed of device by looking at D+ / D- lines4. Hub resets device, 10ms of logic low on both lines5. Device is in “Default State” and answers to address 0x006. Host sends “Get_Descriptor” request, learns packet size

• Windows asks for 64kB and issues a bus reset after first packet

7. Host assigns an address via “Set_Address”• Windows re-requests device descriptor, reads all of it

8. Host learns device’s abilities through successive requests9. Host loads device driver10.Device driver selects configuration11.Enumeration complete, device available to user-mode

Human Interface Device (HID) class• Needed to get PC side talking to hardware• Human Interface Device (HID) class is intended for, but

not limited to, interacting with people.– Data is exchanged in structured ‘reports’– Low throughput (Max 24.576 MB/s, 64 kB/s and 800 B/s)– HIDs use ‘interrupt’ transfer type. Not true interrupt, polled.

• Report structure defined in a report descriptor• Report descriptors are compact, but also complex• Multiple report structures can be defined, and can be

useful in saving bandwidth (send relevant data only)

Firmware

N

YBus Reset?

N

YControl OU T ?

N

Y Control IN?

N

YMain OU T ?

N

YINT _N L ow ?

N

YSetup T oken?

N

YExpec ting Report?

N

YStandard Request?

S tall endpoint

ReInitialise U SB

N

YClass Request?

Copy data to buffer

Set_Report

Get_ReportSend Report Data

F lag to expec t data

Set_Address

Get_Desc riptor

U pdate s tate

Set D12 address

P arse ROM data

Set_Configuration

N

Y Matc h Found?Mark beginning / end

of data to be sent

S tall endpoint

N

Y

N

Y

Boundry finish?

Any marked data?Send as muc h as

poss ible

Send zero-length

pac ket

N

YA ny mark ed data?S end as muc h as

poss ible

N

YB oundry fi nish?S end zero-length

pac ket

flowchart.swf

Unforeseen problems of note• Descriptors couldn’t be stored in PIC RAM due to space

limitations. Stored in ROM, separate data path. Parsing approach, more readable and flexible than before!

• Debugging statements printed to dumb terminal take milliseconds to be sent, which broke timing requirements (Set_Address in particular), added DIP switches.

• RESET_N and CS_N (chip select) lines of D12 cannot both be low at the same time, or the chip enters “test mode” (Philips FAQ). Reset by firmware not possible. Power push-button added.

• Undocumented D12 Set_Address behaviour. Address must change after “status stage” of request (i.e. an ACK). D12 buffers address and changes on next ACK, not instantly. Discovered in USB-IF webboard.

Limitations of implementation• Multi-transaction reports

– The firmware is unable to receive/send multi-transaction reports, as a large enough internal buffer was not possible. Any test would have to use fudged data. Code is in place, but cannot presently by tested satisfactorily.

– Note that sending multi-transaction descriptors has been implemented/tested and is core to the firmware.

• Get_Report– Requests a report to be sent through the Control IN endpoint,

required by spec but not needed thus far, hence tricky to test. Send correct data length, but data is all null. Believed to conflict the Set_Report which is issued by the testing application simultaneously

• Only tested on Windows. Only tested thoroughly with XP.• Not suitable for transferring large amounts of data (bulk

transfers)

Demonstration Pre-Amble• Project was successfully implemented to original (project)

specification: Driver-less, bi-directional transfers, no user configuration required.

• Device fails in a compliant manner (Stalls endpoint)• Two firmwares, both controlled from the GBA.

– HID Mouse. Offers instant feedback, was easiest to implement.– HID Joystick. Mice / Keyboards are locked by the system, demo

app needed an unlocked device. Joystick still offers good feedback using Control Panel’s “Game Controllers” panel.

• Will show data being captured by a user-mode application• Will show data being sent from host to device, and

displayed on the GBA• (Debugging log if time permits)

Debugging Log (time permitting)CO DIR=I TO=D wV=0100 wI=0000 wL=0040 SREQ Get_Descriptor

GD(01) i=00(12, 01) Lo=00 Ll=12 DS

CI DS

BR

CO DIR=O TO=D wV=0004 wI=0000 wL=0000 SREQ Set_Address Z AS

CI ACK

CO [...] Get_Descriptor [...]

CI [...]

CO [...] Get_Descriptor [...]

CO DIR=O TO=D wV=0001 wI=0000 wL=0000 SREQ Set_Configuration

CI ACK

CO DIR=O TO=E wV=0000 wI=0082 wL=0000 SREQ Clear_Feature

CI S_CI ...