Jump to content
Sign in to follow this  
  • entries
    5
  • comments
    4
  • views
    3,114

About this blog

Exploring the hardware and software behind Atari.

Entries in this blog

 

In defence of emulation

A common sentiment found among retro-computing enthusiasts is that there's nothing quite like the real thing. It's understandable, computers and game consoles (i.e., computers disguised as toys and appliances) are physical items and our happy nostalgic memories are complimented by recollections of touch and heft: the feedback of button clicks, shunting cartridges into slots, and so on. However, there's a particular aficionado - we've all met him, he's a member of every fan group and forum - whose affection for real hardware gives way to an unpleasant snobbery. A "true fan" would never emulate, he says, implying that a gaming community is only a place for those with disposable income, space, and a nihilistic acceptance that the platform will die with the original hardware.   I'm certainly not arguing against the value of hardware and experiences which come with it, we're all in agreement of its importance, but I do insist that emulation is also a first class citizen without which a platform has no future.   Ashes to hardware ashes   Take the Atari Jaguar; fewer than 250,000 are known to have been produced, with even fewer numbers of accessories such as CD-ROM drives. Of that number a great deal will have been owned by people with no interest in preservation. Many Jaguars have likely been dumped in the trash along with an avalanche of VCRs. Of the survivors many will suffer electrical faults due to old-age (the dreaded open-circuit capacitor problem). Many more will simply be damaged in accidents.   This is already a serious problem for CD-ROM units which were produced in much smaller numbers than the console itself and are notoriously failure prone - although, arguably, no more so than other CD-ROM drives from the time.   Taking the long view there will be a time when, for most people, original hardware will no longer be a viable way to access the content produced for the platform!   New developments   This is perhaps the strongest argument in favour of emulation. New content is vital for a platform and emulation is key to lowering the barrier in producing new content. In the late 70s it took highly skilled programmers with excellent design sense (a very select cross-section of personality) months to produce new games for the Atari 2600 using mainframe computers costing thousands of dollars. Today, a cheap PC with the Stella emulator, which includes an excellent debugger and the ability to step through program execution and inspect the emulated Atari's emulated state. Imagine what those original Atari and Activision programmers could have achieved in an afternoon with such capabilities! Imagine what today's programmers, of all kinds of skill levels, can achieve!   A more thoughtful perspective   I highly recommend that anybody with an interest in retro-gaming listen to Frank Cifaldi's GDC talk on the subject of emulation. It's witty, thought-provoking and quite brilliant. There's a lot to unpack, but in under an hour he touches on numerous relevant subjects such as preservation, the ethics of piracy, and how emulation can be leveraged in the most positive (and commercial!) ways:  

dgrubb

dgrubb

 

Jaguar USB Tap: Wrapup

Busy month, but I'm elated to have, finally, nailed down the hardware design and have working firmware!     A few words on USB ...   In ye olde' days, such as when the Jaguar was developed, connections with the outside world were often turn-key and very simple. On the Jaguar controller, a selection of pins are used as address selectors and each data pin is tested in turn. Easy to code for and cheap hardware to build, little more than latches and diodes. However, such interfaces are not portable and there's no connector on a modern PC which could be contrived to be made compatible with such a scheme (maybe the old parallel port with a suitable breakout?). USB seeks to solve this problem by being the Ultimate Protocol, fully configrable and compatable with any imaginable use-case, from gamepads to webcams. Normally, I'd regard such ambitious goals as unrealistic and error prone. If you recall the early days of USB, and the extremely buggy drivers stacks of the time, this concern was clearly warranted. Having said that, something about the scheme works as over a decade later it's become a ubiquitous standard that actually kind of works.   Being every solution to every problem means that USB is huge. It takes a surprising amount of processing power to drive even a simple USB connection and the description of the specification itself is voluminous, a >100MB download. All this to say that almost all the code, and almost all the processing power, in the Jaguar USB Tap is devoted just to the task of driving USB. I don't know if it's progress, but the scope of it leaves me awed.     The Jag stuff   This was the easy part: all I needed to do is continually poll the Jaguar controller pins and check for changes in state from the previous check. Something like: for (all buttons): if (this button's address not set) { set the pins for this button's address } read some pins if (these pins are different from the last time I checked) { print readout on the UART send a USB message }
The USB stuff is a bit convoluted, but essentially I send a table of data: USAGE_PAGE (Generic Desktop)USAGE (Gamepad)USAGE_PAGE (Button)[... 17 one-bit states for all the buttons ...][... followed by 7 bits of padding as USB frames must be byte aligned ...]USAGE_PAGE[... Two axis, one byte each, for the D-pad ...]END_COLLECTION
Even though the D-pad is made out of digital buttons I still treat it as if it were a piece of analog data. This follows a convention in USB gamepads to distinguish direction from action buttons, but the uC also has the ability to read analog values. Maybe one day I can get my hands on a rotary modded controller and will be able to support Tempest 2K as Jeff Minter intended.   One last thing ...   USB devices use unique vendor ID (VID) and product ID (PID) codes to identify themselves and to prevent driver collision. This is a reasonable thing to do but it costs $5000 to register a VID! Very hostile to small businesses and community projects. Fortunately, one very gracious small-business has gifted their VID for community usage and unique PIDs can be requested from http://pid.codes for hobby scaled projects. I've made a request and, if I get the PID, can embed it into the firmware going forward.   Wrapup   I can now play Jaguar games with the control scheme the original developers intended, and enjoy a speed advantage where emulation performs better than a real console (granted, the opposite is the case for most games. Emulation is hard so I really appreciate the work that's gone into virtualjaguar. Thanks, guys!). I've also grown quite fond of the controller itself. The groves on the back allow it to sit comfortably and I don't find myself cramping my hands to reach all the controls so it makes a pretty decent controller for other consoles too. The Mega Drive is a particularly nice fit as it shares the D-pad + three primary action button layout.  

dgrubb

dgrubb

 

Jaguar USB Tap: The agony (of hardware bugs) and the ecstacy (of firmware)

Development environment   To start writing code for our STM32F07 series uC via an ST-Link programmer (embedded in a cheap Nucleo board, see previous entries) all we need are a few easy to obtain tools: a C compiler (although Rust is becoming more interesting as an embedded language), a debugger and a tool for handling communication with the uC over the ST-Link. ST provide several options for fully integrated IDEs with varying levels of platform and license support but my personal preference is to avoid all of them. I dislike large IDEs; partially because they absorb system resources and obfuscate underlying details, partially because of my political zealotry and partially because kids today have it too damn easy with their iThings, ghetto-blasters and whatnot. Rather, I shall be using the GCC compiler, the GDB debugger and OpenOCD for programming, all of which are completely open-source, readily available across platforms and are simple to use (IMHO, YMMV). On a Debian-derived Linux distribution, such as Ubuntu or Mint, they're installed with a one-line apt-get invocation: $ sudo apt-get install gcc-arm-none-eabi gdb-arm-none-eabi openocd
Magic.   As I'm not planning on using an IDE I need to add a few extra targets to my Makefile to perform the programming and debugging functions an IDE would normally integrate: make # Build the projectmake clean # Delete compiled objectsmake upload # Use OpenOCD to program the target devicemake debug # Open a debugging session with the targetmake run_gdb # Connect to a debugging session
Fail   With a development environment and initialisation code I was ready to start programming! I hooked up the ST-Link to the target uC, double checked all my power connections, and ran make flash. Nothing. OpenOCD's output indicated it was unable to detect a target. However, it did detect the target supply voltage so at least some part was functional. As an experiment I applied a jumper from VDD to one of the uC's GPIO and everything came to life. OpenOCD detected and programmed the target. Curious ...   I programmed the uC a few times with some simple code that just went into loops or incremented variables to ensure that I could connect a GDB debugging session without any further problems. Satisfied, but still confused about the previous behaviour, I tried setting the GPIO as input pins whereupon I lost contact with the uC again. This time, applying power to GPIO failed to revive the board. Confused and frustrated I went back to my original schematic to search for any kind of clue. It was pretty obvious what had happened: I had made a mistake in drawing the schematic symbol for the uC itself, assigning the same number to two different pins.  
This error percolated all the way down to the trace routing leaving VDDA unconnected. By bridging the GPIO to VDD I had inadvertently provided sufficient power to the GPIO block for the pins to function, that in turn allowed the GPIO pins which double up as a serial programming port to work. By enabling the GPIO pins as inputs I was switching their power source to VDDA. One quick mod to verify this was what was going on ... 
... and I'm going to need to redesign the PCB. Lesson learned, which, frankly, I should have already been cognizant of, is not to rush and take the time to double, triple and quadruple check your design before sending the gerber files off to the PCB manufacturer.  We can rebuild him   As I'm going to have to redesign the PCB anyway I'm going to make a few changes I was thinking about doing anyway: Switch from the 20-pin TSSOP uC package to a larger 48-pin LQFP. I really liked the idea of using the smaller package for space efficiency and all the required functions fit nicely into that layout. However, it also meant I had to dedicate the two programming pins to GPIO functions so I can't debug while running all the pins. That won't be much of a problem after I've finished all the code, but for the sake of an easier debugging process it'll be nice to separate those functions. Add jumpers to the output enable lines of the logic level translation chips so I can manually control those devices, allowing me to turn them on, off, or let the uC drive them. With the larger uC package I can also make use of one of the UART ports for a bit of simple status output without an ST-Link. Could come in handy. Add a button to allow for manual control over NRST, so I can reset the uC without powering down the whole device.


We'll get to the Jaguar parts soon. Honest.

dgrubb

dgrubb

 

Project: Jaguar USB Tap

Justification   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.   Design Philosophy   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.  
Component selections   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 - GND 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  
Result   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.       Resources   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

dgrubb

dgrubb

Sign in to follow this  
×