dgrubb

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:
 

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:
 

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:
 

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

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

Syndicate
Published: 1994 by Ocean
Developed: Bullfrog
 
Syndicate began life as a fairly popular overhead RTS on the PC and Amiga. The goal of Syndicate is to build the wealth, power and territory of your criminal enterprise through a combination of force, persuasion, taxation and research. The depth and novelty of the game led to a host of conversions. The last time I tried to play Syndicate was over 20 years ago and I was not at all impressed. In the intervening years, I've read that this game - including the Jaguar version - was generally well received and is thought by some to be a forebearer to the original GTA.
 
Is the Jaguar version of Syndicate a solid translation of the computer classic? Or would it have better been left to a keyboard and mouse? Read on to find out!
 

 
Gameplay: You start the game with a world map from which you select the territory you need to conquer. The more territory that you control, the more population and taxes collected. This leads to funds that you can use to buy intelligence during mission briefings, purchase equipment, or research enhancements for your agents. Once you select a territory, you are brought to a mission briefing. After accepting the mission, you get to select and equip a team of up to 4 agents, which you control in-game. "Control" in Syndicate is a relative term.
 
I'm primarily a console gamer. As such, I expect game controls to be fairly intuitive. I want to be able to jump right in and start playing without looking through a manual. If I do read the manual, it should be to clarify some nuance or quirk of the game's features. Syndicate is not that type of game. From menu options to in-game controls, Syndicate requires the player to not only read the manual, but to study it.
 
To make up for its lack of a keyboard, this computer conversion uses all of the buttons on the Jagpad. That's right, all three action buttons, plus the twelve buttons on the keypad. Because that's not enough for the actions in Syndicate, there are even button combinations that are required for certain actions. Want to zoom in? Press C+1. Need to deselect a weapon? That's C+9. All in all, I counted 26 possible actions available in-game. These are listed on pages 16-18 of the manual. Needless to say, I kept the manual handy so I had some idea what I needed to do. If that sounds tedious, that's because it is. The complexity literally stripped much of the joy and excitement out of playing this game.
 
Once in the game, I found the onscreen movement clunky. I've played a number of point and click RTS games and this just doesn't flow for me.
 

 
Graphics: The graphics in Syndicate are a bloody mess. The game world is presented in an isometric perspective that hampers navigation and can hide enemies and targets from view. The player's squad of agents, cops, enemies and targets are represented by blocky low-res sprites that look pretty bad no matter what your zoom. Some of the game maps are interesting from a distance, but lose detail and refinement when zoomed in. Scrolling across the play field is somewhat choppy and the onscreen action is anything but fluid. The in-game map is nearly useless as it's hard to differentiate between the different NPCs. There are some fun death animations, so that's something.
 
Sound/Music: The music in Syndicate consists of dark synthy chip tunes that I suppose are befitting the dystopian future of the game world. It isn't terrible but it also isn't memorable. The game's sound effects are pretty limited. In a word: average.
 
Overall: Syndicate on the Jaguar is a clunky RTS that is low on fun and high in tedium. It may have been highly regarded in its day, but there a far superior RTS experiences out there. Ultimately, the potential of the game's concept is undermined by the clunky control interface and lackluster graphics.
 
Final Verdict: If it's not yet clear, Syndicate was not my cup of tea. The overly complicated control scheme made playing the game a chore. Maybe it works well on a PC, but on the Jaguar I mark this one down for collectors only.
 
Thanks for reading and please share your memories and thoughts on Syndicate in the comments below! I'm particularly interested in hearing from those of you who enjoyed the game - either on the Jaguar or another platform.
 
The next game is from my recent Readers' Choice post and comes courtesy of The Professor: Ultra Vortek! Thanks to The Professor and RickR for the suggestions!