In recent years the retro-gaming community has taken a revisionist view of the Atari Jaguar. What was once a console marred by failure is now more regularly being perceived as a missed opportunity. Rather than maintaining a reputation as a broken console the Jaguar is becoming more highly regarded as a technical innovator failed by a lack of capital and business acumen of the company who developed and marketed it. Consequently, demand for Jaguar consoles and peripherals has increased enormously with prices for used equipment rising accordingly. Emulation provides an easy way for newcomers to enter the scene without having to pay a heavy upfront cost for access.
Since the Jaguar's era the video gaming market has changed considerably with controller designs becoming more or less standardised around a layout favoured by the two current dominant platforms, Microsoft's XBox and Sony's PlayStation: two analog sticks, a D-pad, four action buttons and a pair of shoulder triggers and buttons. Vendors of PC compatible gamepads have aped this layout in turn but, unfortunately, the Jaguar controller doesn't easily map to this format due to the inclusion of a twelve-key numeric pad embedded into the controller front face. This makes emulating Jaguar games with off-the-shelf PC gamepads somewhat dissatisfying, forcing the player to make use of a keyboard in addition to gamepad, or forgo a controller altogether.
Even though a complete Jaguar console may be prohibitively expensive, a Jaguar controller can be purchased for ~$20. Combined with emulation a genuine controller can allow an affordable path to enjoy the Jaguar's eclectic library of games with the input device they were designed for, if the controller can be made to work with the standard inputs of a modern PC. Hence I intend to design and build a cheap converter device: the Jaguar USB Tap.
I am greatly influenced by the goals of the free software movement initiated by Richard Stallman. I also want the community surrounding Atari and the Jaguar to be healthy and robust. Making this project as open as I can possibly make it is a natural consequence of these two impetuses. Therefore, there are several requirements I must adhere to:
- All source code must be published with a Free/Libre license and made available through a convenient and readable mechanism (e.g., plain source hosted on a service such as GitHub).
- All hardware design files - such as schematics, PCB layouts and Gerber files - must be published in the same manner.
- Hardware design files must be available in formats which are standard and trivially readable. For example, if the schematics were published freely but couldn’t be opened without an expensive proprietary tool then they wouldn’t be open in any reasonable sense.
- When selecting components consideration must be given to how easily another person can reproduce the design. For instance, parts which require special soldering equipment or advanced techniques, such as quad-flat pack ICs with no pins (QFN), are undesirable.
Fulfillment of these requirements shall influence technical and non-technical decisions alike. For example, an FPGA would be a good technical solution but a poor choice for the goals of this project as they require expensive proprietary software and programming devices.
Even though I shall be using entirely surface-mount (SMD) components, with the exception of connectors, I will be selecting components with relatively large footprints such as 1812 for non-polarised capacitors. Larger components will result in a board being much bigger than it needs to be, but I feel this to be an acceptable trade-off to ensure that the design is accessible as they require less skill to solder but can also be identified and handled more easily by those with poorer eyesight.
At the heart of the board shall be an STM32F070 microcontroller (uC) (http://www.st.com/en/microcontrollers/stm32f070cb.html). This part contains an ARM processor core, a USB peripheral and a small handful of GPIO pins making it highly suited as an embedded processor in USB human-interface devices (HID). While the part is a good technical fit for the project there are also accessibility reasons for using an STM32 uC. Chiefly, firmware can be developed using entirely open-source tools, such as gcc, on the user’s platform of choice (Linux, Mac OS or, I suppose, even Windows).
A programmer device is required to upload firmware to the uC but this is another area where ST have done extremely well in providing an accessible solution. Every STM-Nucleo development board (~$10) contains an ST-Link programmer device which be used for programming external uCs in addition to that built into the board: http://www.st.com/content/ccc/resource/technical/document/technical_note/group0/30/c8/1d/0f/15/62/46/ef/DM00290229/files/DM00290229.pdf/jcr:content/translations/en.DM00290229.pdf
Jaguar controller interface
The hardware interface of the Jaguar controller is extremely simple. Button presses cause particular pins on the DB15 connector to be set high in contrast to some later systems, such as the Nintendo64, which serialise controller state data and maintain active two-way communication between controller and console. All that’s really needed is for the STM uC to detect rising-edge voltages on GPIO pins connected to a DB15 socket and send a USB HID message to the host PC.
The controller has twenty-one buttons (n.b., even though the Pro controller has more buttons they’re mapped to buttons which exist on the original controller so no additional interpretation is required) and the DB15 connector provides fifteen pins. Button states are encoded with two bits worth of information: a column (or address) pin, and a data pin. This mapping is:
- Column 1 address (option, 3, 6, 9, #)
- Column 2 address (C, 2, 5, 8, 0)
- Column 3 address (B, 1, 4, 7, *)
- Column 4 address (Pause, A, N, S, E, W)
- Row 1 data (pause)
- +5VDC Source
- Row 2 data (A, B, C, Option)
- Row 3 data (E, 1, 2, 3)
- Row 4 data (W, 4, 5, 6)
- Row 5 data (S, 7, 8, 9)
- Row 6 data (N, *, 0, #)
For example, when the player presses the A button pin 4 and pin 10 are set high. Source: http://arcarc.xmission.com/Web%20Archives/Deathskull%20%28May-2006%29/games/tech/jagcont.html
A high logic level for the controller is 5v but the STM32F070 runs at 3.3v (only two pins are 5v tolerant: D+ and D- USB data connections) so an interface chip is required to translate the two voltage levels. I’ve selected the TX01060 which provides an enable signal line allowing the uC to programmatically disable the connection to the controller if required. This is a useful point for attaching an LED for visual indication that the device is running as expected and for basic debugging. A regulator is also required to the convert the 5v power provided from the upstream USB connection to a level safe for the uC.
All design files, documentation and source code is available through my GitHub account and shall be updated as the project progresses: https://github.com/dgrubb/Jaguar-USB-tap