Category Archives: Retro Video Games

Exploring Atari VCS/2600 Adventure – part 2

4 Replies

See also: part 1, part 2, part 3, part 4 … and more to come…

How the rooms are defined

In the previous installment, I introduced how the playfields were encoded in the Atari Adventure game. I had converted the assembly data into C code and made a command-line program that would print out the room graphics.

Atari Adventure screen graphics decoded in C.

I then recreated the process in Microsoft Color BASIC on a Radio Shack Color Computer emulator.

My command-line C program was displaying on an 80-column Windows command prompt window (or Mac OS X terminal) so it had plenty of room to render the 40 pixel wide playfields. The CoCo’s 32-column screen could not, so I changed the BASIC version to use low-resolution (64×32) text-mode graphics. This also let me use colors, though the CoCo only had 8 foreground colors to work with in this mode, with some restrictions from the Motorola MC6847 video display chip.

Atari Adventure screen graphics plotted in Color BASIC.

The end result was a proof-of-concept showing I was decoding the cartridge data properly, even if I couldn’t render it exactly as the Atari VCS/2600 would have.

There is much more I need to explore. For instance, each room has a definition data structure that describes things like which graphics data to use, how it is displayed (right half of the screen reversed vs mirrored, thin line on the left or white wall), its color, as well as which rooms are connected to it (Up, Left, Down and Right). Here is an example of the yellow castle data structure bytes:

LFEB4: .byte <CastleDef,>CastleDef,$1A,$0A,$21,$06,$03,$02,$01

The first entry (CastleDef) is a two byte pointer to the graphics data elsewhere in the ROM:

;Castle Definition                                                                                                 
CastleDef:
  .byte $F0,$FE,$15 ;XXXXXXXXXXX X X X      R R R RRRRRRRRRRR                                      
  .byte $30,$03,$1F ;XX        XXXXXXX      RRRRRRR        RR                                      
  .byte $30,$03,$FF ;XX        XXXXXXXXXXRRRRRRRRRR        RR                                      
  .byte $30,$00,$FF ;XX          XXXXXXXXRRRRRRRR          RR                                      
  .byte $30,$00,$3F ;XX          XXXXXX    RRRRRR          RR                                      
  .byte $30,$00,$00 ;XX                                    RR                                      
  .byte $F0,$FF,$0F ;XXXXXXXXXXXXXX            RRRRRRRRRRRRRR

Note that the comments above are misleading. The graphics data only describes the left side of the images (the “X” characters in the comment). The right is created as the room is displayed, based on a bit in the fourth byte of the data. Here are what all the bytes mean:

;Room Data
;Offset 0 : Low byte room graphics data.
;Offset 1 : High byte room graphics data
;Offset 2 : Color
;Offset 3 : B&W Color
;Offset 4 : Bits 5-0 : Playfield Control
;            Bit 6 : True if right thin wall wanted.
;            Bit 7 : True if left thin wall wanted.
;Offset 5 : Room Above
;Offset 6 : Room Left
;Offset 7 : Room Down
;Offset 8 : Room Right

Looking at that data again, we can describe is as:

  • CastleDef – 2 byte pointer to graphics data.
  • $1A – Color.
  • $0A – B&W Color (the color to use with the Atari color switch is set to Black and White).
  • $21 – Attributes for how to display the room.
  • $06 – Room above (up).
  • $03 – Room left.
  • $02 – Room down.
  • $01 – Room right.

This early disassembly did not specifically describe what offset 4’s bits 5-0 mean, but one of them makes the room mirror (both sides look the same) versus the default of reversed. (Odd description. To me, a mirror reverses an image. It’s more like Duplicate versus Mirror in my mind. But I digress…)

The castle is a standard Reversed room:

XXXXXXXXXXX X X X      R R R RRRRRRRRRRR                                      
XX        XXXXXXX      RRRRRRR        RR                                      
XX        XXXXXXXXXXRRRRRRRRRR        RR                                      
XX          XXXXXXXXRRRRRRRR          RR                                      
XX          XXXXXX    RRRRRR          RR                                      
XX                                    RR                                      
XXXXXXXXXXXXXX            RRRRRRRRRRRRRR

It’s attributes of $21 are the bit pattern 00100001.

One of the black castle mazes is Mirrored. Here is the room that contains the secret “dot” which is used to access the hidden easter egg room:

;Black Maze #3
BlackMaze3:
  .byte $F0,$F0,$FF ;XXXXXXXX    XXXXXXXXMMMMMMMM    MMMMMMMM
  .byte $30,$00,$00 ;XX                  MM
  .byte $30,$3F,$FF ;XX    XXXXXXXXXXXXXXMM    MMMMMMMMMMMMMM
  .byte $00,$30,$00 ;      XX                  MM
  .byte $F0,$F0,$FF ;XXXXXXXX    XXXXXXXXMMMMMMMM    MMMMMMMM
  .byte $30,$00,$03 ;XX          XX      MM          MM
  .byte $F0,$F0,$FF ;XXXXXXXX    XXXXXXXXMMMMMMMM    MMMMMMMM

Note how that “box” is made up by the Mirroring of the left half. Neat! That room is defined as:

LFED8: .byte <BlackMaze3,>BlackMaze3,$08,$08,$24,$13,$16,$13,$14

Its attribute of $24 is the bit pattern of 00101000.

And in the game, the room below and to the right of the castle has a thin right wall:

Atari Adventure room with a thin right wall.

If I understand which room this it, this is the data that draws it:

;Left of Name Room 
LeftOfName:
  .byte $F0,$FF,$FF ;XXXXXXXXXXXXXXXXXXXXRRRRRRRRRRRRRRRRRRRRRRRR                                  
  .byte $00,$00,$00
  .byte $00,$00,$00
  .byte $00,$00,$00
  .byte $00,$00,$00
  .byte $00,$00,$00

;Below Yellow Castle
BelowYellowCastle:
  .byte $F0,$FF,$0F ;XXXXXXXXXXXXXXXX        RRRRRRRRRRRRRRRRRRRR   **Line Shared With Above Room ----^

Note a clever technique programmer Warren Robinett used to save three bytes of ROM space. The room definition points to the “LeftOfName” data and a room is 21 bytes. The bottom of that room (a wall with an opening in the middle) is the same as the top of another room, so the definition uses three bytes for the next room data for the last three bytes of the first room. Clever!

The definition of the “Left Of Name” room (because the hidden easter egg room with Mr. Robinett’s name is to the right of this room) is:

LFE36: .byte <LeftOfName,>LeftOfName,$E8,$0A,$61,$06,$01,$86,$02

Its attribute of $61 is the bit pattern 01100001.

And down and to the left of the castle is a room with a thin left wall:

Atari Adventure room with a thin left wall.

Grrr. That Yorgel the yellow dragon ate me while I was trying to take this screen shot.

If I am reading things correctly, I believe this uses the same graphics data as the room below the yellow castle (opening at top, wall at bottom, no walls on left or right):

LFE24: .byte <BelowYellowCastle,>BelowYellowCastle,$D8,$0A,$A1,$08,$02,$80,$03

And its attributes of $A1 is the bit pattern 11000001.

So we have:

  • 00100001 – Reversed (castle).
  • 00101000 – Mirrored (maze).
  • 01100001 – Reversed and thin right wall.
  • 10100001 – Reversed and thin left wall.

Thus, looking back at the bit definitions:

;Offset 4 : Bits 5-0 : Playfield Control
;            Bit 6 : True if right thin wall wanted.
;            Bit 7 : True if left thin wall wanted.

It looks like we have:

  • Bit 0 – Right half of screen is Reversed.
  • Bit 1 – ?
  • Bit 2 – ?
  • Bit 3 – Right half of screen Mirrored.
  • Bit 4 – ?
  • Bit 5 – ?
  • Bit 6 – Thin right wall.
  • Bit 7 – Thin left wall.

It will take some more code exploring to see what bits 1, 2, 4 and 4 are used for, but understanding what controls Reverse and Mirrored was needed to properly draw the screens. One of those bits is probably used for rendering the “invisible” mazes, but I haven’t gotten to those yet.

Query: What happens if both bit 0 (Reverse) and bit 3 (Mirrored) are on? Why would those be separate bits? Perhaps there was an efficiency reason for checking for a set bit (less instructions than checking for a clear bit?) or perhaps bit 3 is something else. I guess I need to do more checking in to this, too.

The last bit of data (I’m assuming you can figure out “Color” and “B&W Color” entries) is the bytes that show which room is up, left, down or right. This is used by the game engine so it knows which room to display when the player moves off the current screen.

I’ll discuss that in a future installment. It’s not as straightforward as it seems. Here’s a quick teaser:

The “LeftOfName” room (solid walls with an opening at the bottom) is defined as:

LFE36: .byte <LeftOfName,>LeftOfName,$E8,$0A,$61,$06,$01,$86,$02

The room exists are defined as up ($06), left ($01), down ($86) and right ($02). But there are only 30 rooms ($00 to $1e) so there can be no room $86 (134). Maybe it actually means $06 with the high bit set (100000110). But room $06 is commented as “Bottom of Blue Maze” and looks like this:

BlueMazeBottom:
XXXXXXXX  XX  XX        RR  RR  RRRRRRRR
XX    XX      XX        RR      RR    RR
XXXX  XXXXXXXXXX        RRRRRRRRRR  RRRR
XXXX                                RRRR
XXXXXXXX                        RRRRRRRR
      XX                        RR                                            
XXXXXXXXXXXXXXXXXXXXRRRRRRRRRRRRRRRRRRRR

…and that most definitely isn’t the room below the “Left of Name” room.

And, this room is different between game 1 (“Small Kingdom”) and games 2 and 3. In game 1, it’s a room with an opening at the top, and in games 2 and 3 it is part of an invisible maze.

This will have to be figured out.

Until then…

Exploring Atari VCS/2600 Adventure – part 1

8 Replies

See also: part 1, part 2, part 3, part 4 … and more to come…

I have been on an Atari Adventure kick lately, which started after I played the game on a friend’s ATGames Legends Ultimate Arcade awhile back. Ignoring the weirdness of playing an Atari VCS game on something that resembles a 1980s arcade machine, it was like stepping back in time to when I lived in Mesquite, Texas (around 1980) and got to play it on a friend’s Atari.

Side note 1: I’ll be sharing the tale of growing up during the video game revolution of the 70s and 80s in a upcoming lengthy article series.

Side note 2: I also have an upcoming series about trying to code the Adventure game logic in Color BASIC on the CoCo.

Since that first exposure to Adventure on an actual Atari, I’d seen the game a few other times.

Indenture for the PC

There was the Indenture clone for PCs in the early 1990s. You can play it in a browser here:

https://archive.org/details/IndentureV1.71996CraigPellAdventure

It was a nice flashback after not seeing the game in over a decade. The author, Craig Pell, even added new levels with many more rooms. The original had 29 screens (well, 30 counting a hidden one) but Indenture has a level with 300.

Since it was a recreation, it does not accurately recreate the gameplay of the original. But, it’s still great fun.

Stella Atari emulator

Next was an encounter with an early DOS version of the Atari emulator Stella. This allowed a modern computer to play the game pretty much exactly as it was on an original Atari. (Though, without using an Atari joystick, it never felt quite real.)

https://stella-emu.github.io/

Atari Flashback 2

When I learned about the Atari Flashback 2 machine coming out, I was intrigued enough with this mini recreation of the Atari to actually buy one. Unlike the original Flashback unit, which was a Nintendo NES chipset with reprogrammed Atari games, the Flashback 2 was an actual re-engineered Atari machine. It could even be hacked to add a cartridge connector and play real Atari cartridges! And, it game with Adventure. Though I really only powered it on a handful of times before donating it to the Glenside Color Computer Club to be auctioned off at a CoCoFEST!

Atari’s Greatest Hits

In the years that followed, various software packages were released containing officially licensed Atari games running in some form of emulator. Atari’s Greatest Hits was sold for many consoles and computers. I had the edition that came out for iPhone and iPads:

Atari’s Greatest Hits on an old iPad

It was great fun to play Adventure again, but a pain to do so using virtual touch controls on a tablet screen. Fortunately, the iOS version supported the iCade controllers and I even hacked up an interface to use a “real” Atari joystick on it (the joystick from my Atari Flashback 2). Here is is on my original first generation iPad:

Teensy 2.0 as an Atari 2600 joystick interface for iOS

That, and the Flashback 2, were the closest I’ve come to the real Adventure experience, due to accurate emulation and a real (replica) controller.

Warren Robinett speaks

My recent re-interest in Adventure was enhanced after watching this 2015 presentation by the game’s original author, Warren Robinett. He details the history of how the game was designed, and some insights in to how the code worked:

Warren Robinett’s postmortem presentation on how he wrote Atari Adventure

It was this video that got me interested in howthe game worked, rather than just how to play it.

Adventure Revisited port

I was unable to find any dedicated “Everything You Want To Know About How Atari Adventure Worked” website, but I did find a 2006 version (winventure.zip) by Peter Hirschberg. In contained a disassembly of the original Atari Adventure assembly code. He also translated that assembly into C++ and wrote new code to emulate machine-specific things like collision detection and the display. I don’t know where I found the original zip file, but here is the current version:

https://sourceforge.net/projects/adventurerevisited/

Because this version was based on the actual ROM assembly code, it should play much more accurately than the Indenture rewrite from 1991. I haven’t tested this myself since I’ve been busy playing it in an Atari emulator.

Side note: I just realized this is the guy who did the Adventure game for the iPhone back in 2008!

Dissecting Adventure

Thanks to the disassembly of the original source, and the rewritten version in C++, I was able to start looking at how the game worked. The first thing I did was look at how all the game levels we represented. Each screen was represented by 21 bytes of ROM code!

;Castle Definition                                                                                                 
 CastleDef:
  .byte $F0,$FE,$15  ;XXXXXXXXXXX X X X      R R R RRRRRRRRRRR
  .byte $30,$03,$1F  ;XX        XXXXXXX      RRRRRRR        RR
  .byte $30,$03,$FF  ;XX        XXXXXXXXXXRRRRRRRRRR        RR
  .byte $30,$00,$FF  ;XX          XXXXXXXXRRRRRRRR          RR
  .byte $30,$00,$3F  ;XX          XXXXXX    RRRRRR          RR
  .byte $30,$00,$00  ;XX                                    RR
  .byte $F0,$FF,$0F  ;XXXXXXXXXXXXXX            RRRRRRRRRRRRRR

Above is the data that is used to draw the castles in the game (yellow, white and black). There was another table that defined which set of graphics data to use, as well as what attributes such as “how” to draw it (more on that in a moment), what color to draw it, and what screens were connected to it on each side (up, right, down and left).

The screen was represented by 20 bits stored as three 8-bit bytes with four unused bits. Those bits represent the left side of the screen, then they are either reversed to create the other half of a symmetrical screen, or they are mirrored (draw the left side on the right) which was used in some of the mazes). It is amazing that the entire screen was defined by only 21 bytes! (And, since there were four unused bits for each three bytes, it could have been compressed further down to 17 bytes, though the extra code needed to handle this might not have fit in to the 2K of ROM space the game used.)

Decoding the data in C

For fun, I thought I’d try to convert those data bytes in to a C program and see if I could decode and display them. Here is the castle:

Atari Adventure screen graphics decoded in C.

My first attempt at the decoder wasn’t perfect (note that it’s missing the floor of the castle room), but it showed I was on the right track.

Decoding the data in Color BASIC

I next converted the bytes into Color BASIC DATA statements, then wrote a similar program to decode them:

Atari Adventure screen graphics decoded in Color BASIC.

The CoCo 1’s 32-column screen isn’t wide enough to display 40 ASCII characters, so I was only drawing half the image as a proof-of-concept.

I next converted the PRINT text to SET(x,y,c) plotting commands. This would let me draw on the low-resolution 64×32 8-color screen.

Atari Adventure screen graphics plotted in Color BASIC.

I made a simple program that let me enter a room number and then it would plot the data on the screen. Above is a screen shot from an Atari emulator on the left, and the CoCo screen on the right. Though the aspect ration doesn’t match, at least it shows the graphics are accurate.

This 64×32 “graphics” mode is actually made up of special text characters that represent a 2×2 graphics block. Those blocks can contain one color plus a black background. Because of this limitation, a screen block can either be the green/orange background color with or without a text character on it, or a black block with 1-4 of it’s 2×2 pixels set to a single color. Because of this limitation, graphics need to be specifically designed.

Since each Adventure screen used only one color for the graphics, I thought this might work out well. But, if I wanted to change the background color, that might present a problem since unless the graphics took up a full character block, they would always have the unused pixels set to black. I did a quick test and it looked like this:

Atari Adventure screen graphics plotted in Color BASIC.

Above you can see that certain blocks of the castle do not use up a full 2×2 block, so the unused pixels are set to black. I think this gives it a rather interesting 3-D effect, though that was not the intent. Here’s one of the mazes:

Atari Adventure screen graphics plotted in Color BASIC.

I think it looks pretty cool, though not accurate to the original.

The ROM code also contains the data that makes up the objects in the game, such as the dragons. Here’s a dragon with its mouth open:

;Object 6 : State FF : Graphic
 GfxDrag1:
  .byte $80                  ;X
  .byte $40                  ; X
  .byte $26                  ;  X  XX
  .byte $1F                  ;   XXXXX
  .byte $0B                  ;    X XX
  .byte $0E                  ;    XXX
  .byte $1E                  ;   XXXX
  .byte $24                  ;  X  X
  .byte $44                  ; X   X
  .byte $8E                  ;X   XXX
  .byte $1E                  ;   XXXX
  .byte $3F                  ;  XXXXXX
  .byte $7F                  ; XXXXXXX
  .byte $7F                  ; XXXXXXX
  .byte $7F                  ; XXXXXXX
  .byte $7F                  ; XXXXXXX
  .byte $3E                  ;  XXXXX
  .byte $1C                  ;   XXX
  .byte $08                  ;    X
  .byte $F8                  ;XXXXX
  .byte $80                  ;X
  .byte $E0                  ;XXX
  .byte $00

When I get some time, my next goal is to render all of those game characters, similarly to how I displayed my old VIC-20 game’s customer character set.

To be continued…

Atari VCS/2600 Adventure “Every Object Challenge”

Leave a reply

Here is my entry in the Atari Adventure Every Object Challenge:

This 1980 Atari VCS/2600 game included:

  • 8 movable objects (sword, magnet, black key, white key, gold keys, chalice, bridge, and the hidden dot used to access the hidden room)
  • 4 enemies (red dragon, yellow dragon, green dragon, and bat)

The challenge is to see how many of these objects you can collect on one screen.

You have to play game variant 2 or 3 in order to have access to all the objects.

There are three ways I can think of to accomplish this. The video above shows the results on a method I felt was the easiest, though maybe most time consuming.

If you want to try, you can play the game in a web-based Atari emulator. Here’s one on the website of the game’s author, Warren Robinett:

http://www.warrenrobinett.com/ecv/adv_emu1/

NOTE: Any time there are more than three objects on the screen, they start flickering. It gets really bad with all the objects on one screen and makes it impossible to take a screen shot showing them all at the same time (since only a few can be drawn at the same time). Thus, a video is required for proof. Be sure to include the hash tag #EveryObjectChallenge with your video post.

Have you played Atari today?

Selling my original Atari Jaguar setup.

Leave a reply

As much as it pains me to do so, I need the space and money more than I need all my 1990s Atari Jaguar stuff. I have eBay listings set up to sell my original (made in the USA by IBM) Atari Jaguar, the Jaguar CD unit, and all my games.

I even have a very rare add-on called a Catbox which provided all the various audio and video outputs as well as serial and the Jaguar network port. Mine was, I think, from the first run and was sent to me by the manufacturer as a thank you for some audio samples I contributed to a game they were working on. Fun times.

You can find my listings starting today at 6 p.m. PST here:

https://www.ebay.com/usr/allenhuffman

Play CoCo’s “Donkey King” in a web browser.

Leave a reply

One of the all-time best ports of Donkey Kong on a 1980s home computer was a clone called Donkey King (later renamed to The King). Although we didn’t know this until years later, it was authored by Chris Latham, who also created the first CoCo game to require 64K – The Sailor Man (a clone of Popeye).

Last week, the gang over at CoCoTalk (the weekly video chat/interview show) started a game contest where everyone is invited to try to set a high score on some CoCo game. The first game chosen was Donkey King, which is quite fitting since it’s one of the greatest CoCo games ever. Unlike most (all?) other versions of the day, it features all four levels as well as the intermissions (see the Donkey King link above for screen shots). It also plays amazing well and is as frustratingly difficult as the arcade game it was based on.

For those interested in trying it out, you can go to the JS Mocha CoCo Emulator webpage (the Java Script version of Mocha, which was original a Java CoCo emulator). It is one of the games available there.

You will find it in the second column. Just select it then click Load Bin. It uses the right joystick, I believe, so you can select “Dual Key R” from the Joystick config and that will map that to the keyboard – Arrow Keys and Space Bar (to jump).

If you want to hear the sound effects, you have to checkbox the “Sound” option in the lower right of this screen.

Give it a try and see what you think.

Until next time…

Arcade1Up replacement trackball rotary encoders

Leave a reply

NOTE: I do not own an Arcade1Up, but I have a friend who has the Centipede version. I am posting this article to give some extra exposure to research he and others are doing on the trackball problems.

Arcade1Up is a 3/4-sized 80s arcade cabinet for home use. They have several units available, with most playing four classic arcade games (and one special edition with 12 games).

The Centipede unit has a vertical monitor and comes with Centipede, Missile Command, Millipede and Crystal Castle.

After first playing my friend’s unit, we both agreed that Centipede played very poorly. This led him to dig into the problem, and he found this Do-It-Yourself solution on YouTube:

https://www.youtube.com/watch?v=1_tZPFxxhsE
Fixing the trackball rotary encoder on the Arcade1Up Centipede machine.

The trackball is a rotary encoder where, as it spins, a little wheel turns and is either blocking or allowing light to flow through and be detected by a light sensor. The software counts the pulses and determines how far the wheel has spun. (Here’s the Arduino playground on them.)

The stock encoder wheel has 30 spokes, and this D-I-Y solution shows how to make one with 24. My friend decided to try it and designed one on his 3-D printer. After installation, Centipede does indeed play much, much better, and the other games seem to still play as well as they did before (they were mostly fine, so I can’t tell if there was any significant improvement without doing a side-by-side comparison with an unmodified cabinet).

I think we could convince him into making these replacement parts available at a low-cost for folks who don’t want to DIY. Comment to this post if you might be interested.

Until then… There is an active discussion on Reddit about various problems, solutions, and modifications to the Arcade1Up machines. Be sure to drop by there check it out.

Old School Games – Pac-Man Fever returns!

Leave a reply

Buckner & Garcia, the duo/band that brought us the Top-10 hit Pac-Man Fever back at the end of 1981 (and also the full album of video game songs) is back again with a new song called Old School Games. Listen here:

https://www.youtube.com/watch?v=HEyeT7evqmEv

Their last release was the theme song to Disney’s Wreck It Ralph in 2012. I remember hearing the song Wreck-It, Wreck-It Ralph over the end credits and thinking “aw, man, they should have gotten the guys that did Pac-Man Fever to do a song!” Much to my surprise, the credits revealed that they actually did!

Sadly, original member Gary Garcia passed away in 2011, so he did not get to see the retro resurgence that is underway across America as retro arcades (and bar-arcades) open everywhere. Heck, we have three retro arcades right here in Des Moines, Iowa!

The new song may very well be the 2010s anthem to retro arcade players much like the 1980s Pac-Man Fever was to the first generation players.

They would love to have arcades add it to their playlist, so be sure to let your favorite local video game place know about it.

And, if you are looking for something a bit different, there was also last year’s (2015) Pac-Man Fever (Eat ‘Em Up) redo/redeux/remix, which you can check out at http://www.pacmanfevereatemup.com/

And, for some really neat stuff, check out the Pac-Man Fever Vault for rarities, interviews, and more.

TRON arcade game joystick research

52 Replies
  • 2014/01/28: Updated information on 4-way restrictor for flight stick.
  • 2015/02/18: A note about the HAPP joystick, and restrictor plates being made for it.

A friend of mine is in the process of building a custom arcade controller for home use. Here is some of the research that may be of interest to others trying to replicate the 1982 TRON arcade game controls. (A flight stick with a trigger button, and a paddle spinner controller).

The TRON handle can be bought from Groovy Game Gear. They claim they are using the original molds and also used the original color key chip to match the color as close as possible to the originals that were made in 1982:

http://groovygamegear.com/webstore/index.php?main_page=product_info&products_id=319

This handle is designed to replace the one for an original arcade stick, but folks have been modifying other types of joysticks to make it attach. No details on this, yet.

Next, there is a low-cost trigger stick from RetroCade.us. It is available in several places:

$20 – Paradise Arcade Shop in Hawaii:

http://www.paradisearcadeshop.com/imported-joysticks/299-import-flight-stick.html

They also sell it on Amazon.com, for $22, but shipping is cheaper there (currently $26.83 for the stick and shipping):

RetroCade.us also sells it direct through Holland Computers:

http://www.hollandcomputers.com/store/pc/Arcade-flight-yoke-stick-Joystick-eight-way-joystick-with-two-fire-buttons-and-firm-grip-p8069.htm

The stick is incorrectly described (on Amazon and at Holland) as a 4/8 way switchable stick. It is not. You need a restrictor plate to make it 4-way like the arcade TRON stick is. I have not located a restrictor plate for this joystick yet, but Paradise Arcade Shop says they may be able to custom make one.

Update: There is also a higher priced HAPP joystick commonly used for TRON:

http://forum.arcadecontrols.com/index.php?topic=78233.0

That stick is also an 8-way, but my same friend who is building the custom arcade controller now has a 3-D printer and has designed a 4-way restrictor plate for this. He will be offering them for sale, so contact me if you are interested.

As for spinner controllers, there seems to be two candidates. One is sold by Groovy Game Gear. It is the Turbo Twist 2 and it runs about $70:

http://groovygamegear.com/webstore/index.php?main_page=product_info&products_id=268

Ultimarc also sells a spinner for the same price called the SpinTrak:

http://www.ultimarc.com/SpinTrak.html

No details on which one is better for this purpose.

More to come…