dgrubb

The artwork looks really nice and makes it look like you've put far more than ~20 hours into it.

Opps, indeed!

My PCBs arrived today so I was able to solder together a prototype. No magic smoke! Next up: finishing the firmware ...

Wow. Great collection, thanks!

This was one of my favourite games on the Amiga, the mix of cyberpunk-theme and depth of the world building won me over, but even then I found the control scheme a little awkward. I can't imagine how frustrating the experience must be with a controller but, to be fair, if there were any console controller with the best chance to make it work it'd be the Jaguar's and its ten-key.

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

Yep, all Nintendo handhelds up until the DS Lite are region free, which I was surprised to find out considering how particular Nintendo are about protecting the integrity of their platforms. Because the screens are all LCD you don't have to worry about region specific video signal encoding either (i.e., PAL vs. NTSC). Are you sure the printer is working correctly? You can print a test message by holding down the "Feed" button while powering it on.

Thanks for posting this, the Metroid series constitute most of my desert island games.

Sure! It was a kind of research project, really. The schematics for the 2600 are very simple looking (three ICs!) so I figured it would be possible for somebody to understand it top-to-bottom. If you can write a good emulator of a system then you can reasonably claim to have a good knowledge of it. I'm also interested in uCs and the idea of fitting an entire console into the computational power of a single IC or two tickled me a bit. Having said that, embedded stuff is usually more I/O bound so raw processing power is less of an issue than some other architecture characteristics (see below). There are a few related and experimental projects on my GitHub: HiFive-2600: https://github.com/dgrubb/HiFive1-2600 My first attempt. This is based around a new RISC-V uC which is very performant and can be clocked at a massive 300MHz+ so I thought it would be a great platform. Unfortunately, it only has 16kb of scratch memory, supplemented by an external SPI flash chip. The SPI flash is memory mapped, but the access time is comparatively slow and causes a cache flush. The result is that a lot of the massive processing power is wasted unless you can fit the whole program in 16kb, which isn't going to be the case here. Still, on this version you can load a cartridge and step through each processor tick, while printing the 6507 state on a console. STM32-RIOT-6502: https://github.com/dgrubb/STM32-RIOT-6502 Similar to the above on a slower uC, but one with enough RAM to fit the whole program and run at full-speed. I can just about get the 6507/memory/cartridge state emulation to execute within a 1.19MHz period, enough to run those parts at the the same speed as a real 2600. The TIA is out of the question though, as it uses an NTSC colour clock of 3.58MHz. As with the other project you can step through the emulation state, or run it at full-speed. The TIA has a very simple state machine, but the timing requirements are quite strict. To finish this project off and get some actual video out going I'm planning on implementing the TIA in a separate uC. That's a work-in-progress for the time being. I was pretty chuffed just to get the 6507 emulation (mostly ) working, probably quite a few bugs and mistakes which will need correcting which I'll find as I flesh out the unit tests. It got the point where I was seeing 6502 op-codes in the license plates of other cars during my commute!

Thanks for the warm welcome, guys! Yes, I'd like to go beyond Rb+ but that's probably a good place to start.

Hello, Atari IO! I'm a long-time fan of retro computing, but pretty new to Atari. I don't have very much in the way of personal experiences with Atari or arcades, as many here do, in fact I suck at playing video games, but came to it through another route. I'm an embedded software developer so I enjoy learning about different platforms, CPU architectures and clever electronics. I got started on a project to emulate a 2600 in a micro-controller (currently lacking a TIA, but the 6507 mostly works ) and came to really appreciate the elegance of it considering the cost restrictions in place, along with the creativity of the developers tasked with creating engaging games. I'm also very interested in the Jaguar. Despite its Hindenburg-esque history it remains a fascinating console: custom ASICs, weird co-processor architecture, love it. I hope to learn a lot more about it (I decided to sign up after coming across the thread with the JagDuo PCB and listening to a few of Shinto's game-by-game podcasts) and maybe even enough to be able to try my hand at a bit of homebrew hardware and software. Cheers, Dave.

I found one last night, but decided it'd be a fun project so got a start on making my own.

Cheers!

Pardon the newbie question: I found the pinout and encoding scheme for the regular controller, but I can't seem to find a definitive statement about how the Pro controller encodes the additional buttons?

Good attitude, glad you got something useful out of that machine. I usually buy Chromebooks because they're extremely cheap (~$200), the battery life is amazing and the hardware is well-supported on Linux (naturally). Then I remove the firmware protection screw and install https://galliumos.org/ or Debian. I'm going to gently push back on this point. You're on Mint so installing multiple large suites of software (simultaneously!) becomes a simple one-liner: $ sudo apt-get install <prog1> <prog2> <prog3> especially when contrasted to Windows with its ad-hoc installers, reboots and registry-rot if you remove/reinstall software? I'll grant there's a learning curve attached to the terminal, but its one which allows for far easier interaction in the long term.

It's an awesome project, I hope they pull it off. I wonder if there's any possibility of a USB-based variant (or a Jag-to-USB adapter) for emulators?

Ah, the "if this doesn't scare you away you can stay" approach!

I really dislike the aesthetics of this, reminiscent of an adolescent's impression of what manly toughness is (really, you're going with "Spartan?"). Besides that, what makes this different to the current crop of consoles? If you're not going to compete on ideas (like Nintendo) then you're just playing a game of attrition with Sony and Microsoft who, I'm sure, have much deeper pockets.

Clint, that's an amazing find! I can picture that, it's a very late-70s/early-80s view of the computer industry from a time when hardware manufacturers called the shots (IBM, Commodore, Nintendo, etc) and were the ones who instigated the big market changes by bringing out new machines. I suppose he never quite grokked how the rise of software players throughout the 80s and early 90s shifted the mechanics of the industry.