BigO

The game selections that have you driving on ice are fun.

That sounds more like something from Panda Express than a martial art.

Through duck duck go, I find this and other references using this search: The AtariAge site itself reports that it's still indexing so that might be the issue on that end.

I've never noticed one being tight. That would concern me a little. But if it moves smoothly I would expect it to work. These use mechanical contacts. I have some that are loose enough that I can feel the drag from the contacts when they are engaged. I haven't heard of failures in these controllers so it's probably going to work okay. There's one way to find out. 🙂

In Forums: Recent Status Updates, I'm seeing what appears to be a PM from one member to another (arthurgill to Richard H.) Is that a misused feature, a bug, or ? I successfully replied to it as a test and so the involved parties might know that the message was somehow made public.

The described behavior is a property of the game and/or emulator software. If the software keeps track of the last (calculated) position it can hold that position until it gets more input from the controller. It is true that the driving controller doesn't output a discrete value indicative of a position or steering angle. It outputs signals on two pins. Those two signals only change when the rotary controller position changes. And, to determine a direction of motion, the software would need to keep track of the previous reading. Only one of these two signals/bits can change at a time. Holding a turn on a long corner could be a matter of just not turning the controller. But, if the software decides to self-center after some amount of time, that would be the software author's choice. That's not like a real steering wheel, but they could choose to do that. On the other hand, a real steering wheel's position does correlate to a physical turn angle (more like a potentiometer) whereas any meaning in the rotary driving controller's position is derived from comparing the current output state to the previous output state. I have a prototype controller on my bench that tracks relative rotary controller (quadrature encoder) input and outputs an absolute value. For a particular mode, my software will return the output to "center" after a time, but for another mode I will have it hold the value until more input is received from the encoder. It's a matter of implementation. The "badness", if any, of the driving controller is the low resolution: only 16 state changes (four full quadrature cycles) per 360 degrees. For comparison, the encoder I'm currently using provides 1440 state changes (360 full quadrature cycles) per rotation.

Your saying that "I know that pressing play on the tape can send signal to joy1down" doesn't sound quite right to me. I would expect that pressing play prepares the tape to play by mechanically engaging the playback head with the tape. Sending a signal from the console to the tape player allows the tape to motor to run, thus playing the tape which in turn sends a pattern of signals to the console and the software interprets what the tape is playing. Some pattern means "end of tape", some other pattern may mean "song playing" some other pattern probably means "end of song". But, I wouldn't expect that pressing the "Play" button on the deck directly sends any signal to the console. The software controls the tape deck by sending a run/no-run signal to the deck (which can only send signals back to the game software when the game software allows the tape motor to run). The music coming out of the audible channel really would have nothing to do with the control methodology but this is where you would record your voices. Each of the cassette deck/game console signals is probably one way only: output from the console = discrete on/off signal to stop/start tape motor output from the deck to the console = encoded digital messages telling the game software what's happening with the tape (beginning of audible message/song, end of audible message/song, beginning of tape, end of tape, etc.) I think it's the library of messages and the encoding scheme of the messages that need to be deciphered and documented. Bear in mind that I'm speculating based on bits and pieces of information gathered from experience and reading information on the internet.

There's a hacked 2600 version of Omega Race that uses a standard joystick. If you have a Harmony or other flash cart, you can play it without the Booster Grip or adapter. A hardware adapter for Omega Race was, I think, my first controller hack. http://atariage.com/forums/topic/100984-omega-race-booster-grip-alternative/?p=1325116

Gone to Goodwill.

Unfortunately, the chips don't appear to be socketed, based on the few internet pictures I've seen. That makes it a much tougher job to repair if the problem is a bad chip.

The dates might not be exactly the same, but within a year or two, this.

I never did write my name on my games because they weren't "my" games. I had three brothers. And, I knew only one other person with the same console and they the same games I had and then some. I wonder, was it an "only child" thing to write first or full names on a game cartridge? Or maybe other kids didn't didn't have to share. We didn't have that kind of money. I kind of like getting 2600 cartridges with personal identification on them. I have one somewhere that has a sticker with a doctor's office information. I can kind of now share in the memory of "that doctor's office that had the Atari in the waiting room when we were kids".

The description sounds like what would happen if you're using TB mode on a game that wasn't built for trackball input. The trackball output uses the same pins as a joystick. But, when you're rotating a trackball like this one in TB mode, one pin (per axis) toggles between on and off depending on the direction being rolled and the other pin on that axis toggles between on and off as the ball rolls a given amount so that the game can see how fast/far the ball is rolling. (The above described motion encoding scheme is commonly referred to as "Up/Down Clock". Other trackballs may output a count sequence known as "Gray Code", from which can be decoded direction and speed/distance the ball is rolled. This can provide greater resolution than Up/Down Clock but is a bit more complex to interpret.) In TB mode, pins are turned on and off in patterns that won't be meaningful to joystick game software. In addition to the signals not representing the 4 cardinal directions, the TB mode will set both pins of an axis to active at the same time which is an "impossible" condition for a joystick to produce. How a particular joystick game handles that condition would just be a side effect of how that game program was written. It doesn't really sound definitively like your trackball is defective, unless you're actually testing TB mode with a game specifically built to be compatible the signals output in TB mode. You didn't clearly say this, which leads me to infer that you are testing TB mode using a joystick only game. If that's not the case then it's still possible that your trackball is defective.

("Omaga"? Is that like some alternate universe mashup of the last two US presidents?)

Is rapid/auto fire a big attraction for people? I'm considering building it into a 2600 controller but I never have really used it.

Last bump.

Monday morning bump.

I bought 5 or 6 of those several years ago and scavenged the cables for custom controllers. The cables turned out to be slightly short, but worked out okay.

Anybody know if this would be expected to run on an XEGS? That's the only 8-bit Atari I have that I could possibly test this on.

Spinnaker Delta Drawing for Atari 8-Bit $15 + shipping. (Ship to Continental US Only.) Untested.

https://etim.net.au/2600rgb/ Got it. So the switch would be added in the console. There should be quite a few people able to add a switch as described. Good luck with getting the bypass installed.

Does the CX80 have independent 7800 compatible buttons or something? I'm sure there are a lot of people who could do the mod. It's probably simple but we'd need additional information about the incompatibility in question (I don't know who Tim is so I can't reason it out from that info. You might narrow down the pool of potential fixers by giving your location. Edit: I looked at the above referenced schematic and don't see a reason that one of the fire buttons would be different from the other. So I must be missing or misunderstanding something. What/where is the extra button that must be disabled?

Does anybody know where to get a schematic for this thing? There's supposedly a field service manual, but I can't find it online. (And, Google, when I put in the search term "schematic", that is not the same thing as "manual").