1 / 17

Game Boy USB – Interface and Application

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.

kalliyan
Download Presentation

Game Boy USB – Interface and Application

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Game Boy USB – Interface and Application Robert Meerman

  2. 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

  3. 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.

  4. 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.

  5. 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

  6. 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

  7. 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.

  8. 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.5kW 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.

  9. Hardware

  10. 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

  11. Enumeration • 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, 10ms of logic low on both lines • Device is in “Default State” and answers to address 0x00 • Host sends “Get_Descriptor” request, learns packet size • Windows asks for 64kB and issues a bus reset after first packet • Host assigns an address via “Set_Address” • Windows re-requests device descriptor, reads all of it • Host learns device’s abilities through successive requests • Host loads device driver • Device driver selects configuration • Enumeration complete, device available to user-mode

  12. 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)

  13. Firmware

  14. 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.

  15. 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)

  16. 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)

  17. 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 ...

More Related