Game Boy USB Interface and Application Robert

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 k. B/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: – 32 bit ARM 7 TDMI CPU running on RISC architecture at 16. 78 Mhz – 32 KB of “internal” RAM and 256 KB of “external” RAM • 5 -mode, multi-purpose communications port – Normal, Multi-player & Joy. Bus – proprietary Nintendo protocols – General Purpose – 4 pin I/O, using 0 / 3. 3 V 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 PIC 16 F 877 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 PIC 16 F 877 using a Philips Semiconductors PDIUSBD 11 • Found further examples of D 11 implementations • D 11 discontinued by Philips, replaced with PDIUSBD 12 – 8 bit parallel microcontroller interface, instead of I 2 C – Soft. Connect™, programmable internal 1. 5 k. W pull-ups – Good. Link™, LED indicator of USB status and traffic • The D 12 takes care of – Communicating with bus (inc. retransmissions), notifying microcontroller of (successful) events • The PDIUSBD 12 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

Enumeration 1. 2. 3. 4. 5. 6. Device is attached, hub provides power & detects device Hub does not talk to device yet, but informs host of event Hub detects speed of device by looking at D+ / D- lines Hub resets device, 10 ms of logic low on both lines Device is in “Default State” and answers to address 0 x 00 Host sends “Get_Descriptor” request, learns packet size 1. Windows asks for 64 k. B and issues a bus reset after first packet 7. Host assigns an address via “Set_Address” 1. Windows re-requests device descriptor, reads all of it 8. Host learns device’s abilities through successive requests 9. Host loads device driver 10. Device driver selects configuration 11. 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 k. B/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

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 D 12 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 D 12 Set_Address behaviour. Address must change after “status stage” of request (i. e. an ACK). D 12 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 w. V=0100 w. I=0000 w. L=0040 SREQ Get_Descriptor GD(01) i=00(12, 01) Lo=00 Ll=12 DS CI DS BR CO DIR=O TO=D w. V=0004 w. I=0000 w. L=0000 SREQ Set_Address Z AS CI ACK CO [. . . ] Get_Descriptor [. . . ] CI [. . . ] CO [. . . ] Get_Descriptor [. . . ] CO DIR=O TO=D w. V=0001 w. I=0000 w. L=0000 SREQ Set_Configuration CI ACK CO DIR=O TO=E w. V=0000 w. I=0082 w. L=0000 SREQ Clear_Feature CI S_CI. . .