What does the Game Select switch actually do?

[goldenegg]

As a kid, I never owned a 2600. We had a Colecovision at home. I remember walking by Atari carts in stores and wanting them, for no other reason that the "27 Video Games" exclaimed on the package. I didn't know at the time that it wasn't as I imagined in my head, but I can imagine that was a pretty big selling feature for the system and games.

 

I know what the switch does as far as the player is concerned, but what is actually involved technically? Is it something as simple as developers using it to set different values to variables that can alter gameplay? Is there something specific the system itself is doing when using this switch, which developers can get these extra games for 'free' (meaning little to no code changes)?

 

Looking forward to learning more about this!

[+Random Terrain]

As a kid, I never owned a 2600. We had a Colecovision at home. I remember walking by Atari carts in stores and wanting them, for no other reason that the "27 Video Games" exclaimed on the package. I didn't know at the time that it wasn't as I imagined in my head, but I can imagine that was a pretty big selling feature for the system and games.

 

I know what the switch does as far as the player is concerned, but what is actually involved technically? Is it something as simple as developers using it to set different values to variables that can alter gameplay? Is there something specific the system itself is doing when using this switch, which developers can get these extra games for 'free' (meaning little to no code changes)?

 

Looking forward to learning more about this!

You could make your own Atari 2600 program and find out:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#switches

 

 

Classic Atari 2600 programmers didn't use BASIC to make games, but you can. You'll see that everything that happens has to be programmed.

[goldenegg]

You could make your own Atari 2600 program and find out:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#switches

 

 

Classic Atari 2600 programmers didn't use BASIC to make games, but you can. You'll see that everything that happens has to be programmed.

 

Coming from a development background myself, I'm familiar with the process of creating a game.

 

I was mainly interested in the specific functionality of the switch itself. From the link you provided, it would appears it's just a simple toggle that a developer can use as a trigger for pretty much anything.

[Nukey Shay]

Yup...the hardware can only detect what state it's in (the same is true for other switches except the power and channel select switches).

 

Info from the spec faq:

Controllers: Console Switches (SWCHB)

 

Aside from external controllers, the console includes five built-in switches or buttons.

 

Accessing Console Switches

 

Configure Port B as input (SWBCNT=00h). Switch/Button data can be then read from SWCHB as follows:

 

  Bit        Expl.
 SWCHB.0    Reset Button          (0=Pressed)
 SWCHB.1    Select Button         (0=Pressed)
 SWCHB.2    Not used
 SWCHB.3    Color Switch          (0=B/W, 1=Color) (Always 0 for SECAM)
 SWCHB.4-5  Not used
 SWCHB.6    P0 Difficulty Switch  (0=Beginner (B), 1=Advanced (A))
 SWCHB.7    P1 Difficulty Switch  (0=Beginner (B), 1=Advanced (A))

 

 

Note: Older consoles used switches instead of buttons for reset/select.

SECAM consoles do not include a color switch (Bit 3 is grounded).

 

Software Switches/Buttons

Above buttons/switches may (or may not) be used by software for whatever purpose. Namely, the Reset Button does not reset any hardware, and the Color Switch does not have any effect on the video output (unless the software processes it as such).

 

Hardware Switches

On the contrary, the Power Switch and TV Channel Select Switch cannot be processed by software.

 

Data Direction Register (SWBCNT)

Port B is hardwired to console switches (inputs), normally SWBCNT should be always 00h. However, the three unused bits could be configured as output, the respective SWCHB bits can be then used to store 3bits of custom read/writeable data (as done by Combat).

[alex_79]

Yup...the hardware can only detect what state it's in (the same is true for other switches except the power and channel select switches).

 

Info from the spec faq:

 

[...]

 

Data Direction Register (SWBCNT)

Port B is hardwired to console switches (inputs), normally SWBCNT should be always 00h. However, the three unused bits could be configured as output, the respective SWCHB bits can be then used to store 3bits of custom read/writeable data (as done by Combat).

 

According to the 6532 datasheet, when port B is configured as output, the microprocessor will read the output level previously set instead of the actual logic level on the pins.

Is it safe to set the pins connected to the switches as output, or would the chip be damaged in case the corresponding pin is grounded?

If it is safe, then also the other bits of the port B register could be used to store data when the corresponding switches aren't needed.

 

Here is an extract from the 6532 datasheet about the I/O ports:

I/O PORTS AND REGISTERS

 

The I/O Ports consist of eight lines which can be individually programmed to act as either an input or an output. A logic zero in a bit of the Port A Data Direction Register (DDRA) causes the corresponding line of Port A to act as an input. A logic one causes the corresponding Port A line to act as an output. The voltage on any line programmed to be an output is determined by the corresponding bit in the Port A Data Register (DRA).

 

Data is read directly from the data pins during any read operation. For any output pin, the data transferred into the processor will be the same as that contained in the Data Register if the voltage on the pin is allowed to go to 2.4V for a logic one. Note that for input lines, the processor can write into the corresponding bit of the Data Register. This will not affect the polarity on the pin until the corresponding bit of DDRA Is set to a logic one to allow the I/O line to act as an output.

 

The operation of the Port B is exactly the same as the normal I/O operation of the Port A. Each of the eight lines can each be programmed to act as either an input or as an output by placing a 0 or a 1 into the Port B Data Direction register (DDRB). In the output mode, the voltage on a peripheral pin is controlled by the Port B Data Register (DRB).

 

The primary difference between Port A and the Port B is in the operation of the output buffers which drive these pins. The Port B output buffers are push-pull devices which are capable of sourcing 3 ma at 1.5V. This allows these pins to directly drive transistor switches. To assure that the microprocessor will read proper data on a "Read Port B" operation, logic in the R6532 allows the microprocessor to read the Output Register instead of reading the peripheral pin as on Port A.

[+SpiceWare]

I know what the switch does as far as the player is concerned, but what is actually involved technically? Is it something as simple as developers using it to set different values to variables that can alter gameplay? Is there something specific the system itself is doing when using this switch, which developers can get these extra games for 'free' (meaning little to no code changes)?

 

Looking forward to learning more about this!

A typical usage would increment a byte used to denote game options, and you'd use the bits to tell you what option the player selected. ie: a game with variations 1-16 would be stored in the byte as 0-15 and might be decoded as such:

bits: 76543210 - the lower nybble (bits 3 thru 0) are used to hold the game variation

bit 0 = # of players (off = 1, on = 2)
bit 1 = slow/fast bullets (off = slow, on = fast)
bit 2 = slow/fast aliens (same)
bit 3 = shields (off = nope, on = yes)

the game matrix in the manual for such a game would be:

Game #   1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16
Players  1  2  1  2  1  2  1  2  1  2  1  2  1  2  1  2
Bullets  S  S  F  F  S  S  F  F  S  S  F  F  S  S  F  F
Aliens   S  S  S  S  F  F  F  F  S  S  S  S  F  F  F  F
Shields  N  N  N  N  N  N  N  N  Y  Y  Y  Y  Y  Y  Y  Y

 

 

Due to only 128 bytes of RAM, most programmers would also use the the upper nybble to store additional information, for example I'd use bit 6 or 7 to denote is the game at the menu or is it currently being played. I'd use either of those bits because their state can easily be tested using the 6502 BIT command.

Edited August 5, 2010 by SpiceWare

[Video]

It's just a switch. As far as what it does, it's just like a joystick button or direction. It's just telling the computer to preform action X, and it's up to the individual games to be programmed as to what to do with it when it is used, if anything.

 

Some games use the TV color switch to pause the game for instance.

[Pioneer4x4]

Is it something as simple as developers using it to set different values to variables that can alter gameplay?

For me it is the "I got a perfectly good Chase the Chuckwagon for under $20 switch!"

That game uses it to start a game, and apparently the person that I got it from thought it was busted because he didn't RTFM!

I got a Chase the Chuckwagon

[scorpion]

 

Some games use the TV color switch to pause the game for instance.

 

 

Which games use it to pause?

[Nukey Shay]

Fast Eddie was (IIRC) the first game to feature that.

[A.J. Franzman]

I was mainly interested in the specific functionality of the switch itself. From the link you provided, it would appears it's just a simple toggle that a developer can use as a trigger for pretty much anything.

You got it -- all it does, is change a certain bit from 1 to 0, while it's in the "down" position. The program itself must be reading that bit and have instructions for what to do when it changes to zero, in order for anything useful to happen.

[Omegamatrix]

According to the 6532 datasheet, when port B is configured as output, the microprocessor will read the output level previously set instead of the actual logic level on the pins.

 

 

Tested on a 7800 and Atari Jr, and confirmed as working great. Attached is the demo I wrote to try it. I originally wrote this a few months ago. At that time I didn't get it working because I was changing SWCHB back to all inputs to read it. Made sense to me, but in this case it's plain wrong. That little tip of leaving those 3 pins configured as output when reading it was what I needed.

 

 

 

TestSWCHB(rev1.1).zip

 

 

Also note this demo fails in emulation, but works great on real hardware.

[Video]

 

Some games use the TV color switch to pause the game for instance.

 

 

Which games use it to pause?

Like Nukey said, Fast Edie. And I know 007 does too (I remember having that game for years thinking it was broken LOL,luckily I never throw anything away)

[+stephena]

Tested on a 7800 and Atari Jr, and confirmed as working great. Attached is the demo I wrote to try it. I originally wrote this a few months ago. At that time I didn't get it working because I was changing SWCHB back to all inputs to read it. Made sense to me, but in this case it's plain wrong. That little tip of leaving those 3 pins configured as output when reading it was what I needed.

 

Also note this demo fails in emulation, but works great on real hardware.

Thanks for the report in the Stella tracker that this doesn't work in emulation. I *had* asked if the test ROM covers all possibilities, but now I realize of course it does (3 bits for 8 possible values). I can get this fixed for the next release, which is due out this month.

[+stephena]

Tested on a 7800 and Atari Jr, and confirmed as working great. Attached is the demo I wrote to try it. I originally wrote this a few months ago. At that time I didn't get it working because I was changing SWCHB back to all inputs to read it. Made sense to me, but in this case it's plain wrong. That little tip of leaving those 3 pins configured as output when reading it was what I needed.

 

Also note this demo fails in emulation, but works great on real hardware.

OK, this is now fixed in Stella SVN, and will be included in the next release. I have one question, though. Nukey mentioned that Combat uses these bits somehow. Under what circumstances does this happen? Because if true, this means that Combat wasn't properly emulated until now.

[Omegamatrix]

I *had* asked if the test ROM covers all possibilities, but now I realize of course it does (3 bits for 8 possible values).

 

Yes, it covered those 3 bits. Then I became curious about how all the other bits in SWCHB would react to I/O settings. Here is a new test program for you Stephena.

 

 

 

TestSWCHB_IndvBits.zip

 

 

Open the disassembly to configure different switches as I/O. Compile and run. The program will write #$00 and #$FF to the SWCHB register. It Then checks to see if the inputs were unaffected (as they should be). It also checks the output switches every frame to make sure their values don't change. The program gives you ~ 4 seconds to press whatever console switches before changing the write value. You are really meant to be flicking switches during that time to try and make it fail. It alternates between #$00 and #$FF write values every 4 seconds. If something fails the checks then the screen turns permanently red.

 

 

Try it out. I myself found that you can turn any of the switches on SWCHB to output, and pressing the appropriate console switch won't affect the the last written output value. This becomes especially useful when you think about how many games don't use the difficulty switches. You can configure those P0 difficulty and P1 difficult bits to be output, and then use them for marking Negative and Overflow flags. Bits 7 and 6 are always useful for flags.

 

 

I will try SWCHA today to see how it behaves.

[+stephena]

Open the disassembly to configure different switches as I/O. Compile and run. The program will write #$00 and #$FF to the SWCHB register. It Then checks to see if the inputs were unaffected (as they should be). It also checks the output switches every frame to make sure their values don't change. The program gives you ~ 4 seconds to press whatever console switches before changing the write value. You are really meant to be flicking switches during that time to try and make it fail. It alternates between #$00 and #$FF write values every 4 seconds. If something fails the checks then the screen turns permanently red.

EDIT: Actually, scratch that last request. It would be great if you could create a test ROM that cycles through all possibilities. That is, it writes all possible values to SWCHB and SWBCNT, then does a peek and tests the results. I think I have the problem fixed, but a comprehensive test ROM would confirm it for good.

 

And I'm also interested in seeing your tests on port A.

[Omegamatrix]

I just wrote a program to test SWCHA. It differs from port B.

 

 

TestSWCHA_IndvBits.zip

 

SWCHA

1) a pin is configured as output (say P0 up)

2) you write a value of 0 to that pin

3) you press up on your P0 joystick, and there is no change (because the joystick grounds when a direction is pressed)

4) now you try writing a 1 to that pin

5) you press up on P0 joystick, and it'll change the value there to a zero, even though the DDR is configured as output for that pin

 

 

SWCHB

1) configure any pin as output (say color/bw switch)

2) you write a value of 0 to that pin

3) you toggle the switch up and down, and there is no change

4) you write a value of 1 to that pin

5) you toggle the switch up and down, and there is no change

This result is the same for all of the pins on port B. No switches seem to affect them.

 

 

 

As for the test rom with expected and actual values, you can configure individual pins in the test roms I posted. The ones that you choose as outputs are having values written to them. Those values are either 0 or 1, and are displayed on the game screen as $00 or $FF. So at anytime you know if your expected value is supposed to be a 1 or 0. If the screen goes red (test fails) you know the actual value was opposite for that pin.

 

 

I tested my programs on a 7800 and a Jr, but I haven't tried a 4 or 6 switcher.

[Omegamatrix]

It would be great if you could create a test ROM that cycles through all possibilities. That is, it writes all possible values to SWCHB and SWBCNT, then does a peek and tests the results.

 

 

You can do that, but that doesn't account for people pressing the console switches while it is checking all these possibilities. It's these outside influences that you need to be checking. With the original test program I wrote for the 3 unused bits I just wrote & checked every value, and that seemed fine since there is no switch connected to them.

 

 

With these new test roms I configured the DDR as all output. I let them run for a while and saw no change. Then I started flipping switches and moving the joysticks. You can configure what pin you want as input/output in these test roms, and try different combinations that way.

[+stephena]

I just wrote a program to test SWCHA. It differs from port B.

 

SWCHA

1) a pin is configured as output (say P0 up)

2) you write a value of 0 to that pin

3) you press up on your P0 joystick, and there is no change (because the joystick grounds when a direction is pressed)

4) now you try writing a 1 to that pin

5) you press up on P0 joystick, and it'll change the value there to a zero, even though the DDR is configured as output for that pin

I have an issue with this one. If you write 1 and then press P0 up, the value should definitely be overridden (you're grounding the pin, so it doesn't matter what's in DDRA). However, what you read back will not be a 1, which your test program will treat as a failure, even though this is exactly what should be happening. I make this point because doing what is required to pass your test breaks AtariVox/SaveKey support. This is confirmed on real hardware.

 

SWCHB

1) configure any pin as output (say color/bw switch)

2) you write a value of 0 to that pin

3) you toggle the switch up and down, and there is no change

4) you write a value of 1 to that pin

5) you toggle the switch up and down, and there is no change

This result is the same for all of the pins on port B. No switches seem to affect them.

Seems to be working fine here too.

 

I tested my programs on a 7800 and a Jr, but I haven't tried a 4 or 6 switcher.

I'm testing on a 6-switch, which seems to give the same results as you explain.

[Omegamatrix]

I just wrote a program to test SWCHA. It differs from port B.

 

SWCHA

1) a pin is configured as output (say P0 up)

2) you write a value of 0 to that pin

3) you press up on your P0 joystick, and there is no change (because the joystick grounds when a direction is pressed)

4) now you try writing a 1 to that pin

5) you press up on P0 joystick, and it'll change the value there to a zero, even though the DDR is configured as output for that pin

I have an issue with this one. If you write 1 and then press P0 up, the value should definitely be overridden (you're grounding the pin, so it doesn't matter what's in DDRA). However, what you read back will not be a 1, which your test program will treat as a failure, even though this is exactly what should be happening. I make this point because doing what is required to pass your test breaks AtariVox/SaveKey support. This is confirmed on real hardware.

 

I think we are saying the same thing here. The reason I made the screen go red is because the value got changed. The red screen doesn't say something is bad, it just says the value read is not the same as the value written.

 

 

When you have write a 1, and you push up on the joystick the screen goes red on real hardware. For the SWCHA rom Stella emulated this correctly so you don't have to change anything. Both Stella and real hardware treated the rom the same so Stella is emulating correctly. I think the red screen was throwing you off, that's all.

 

 

I'll try some paddles and driving controllers this afternoon or tonight in Stella and see if it matches what the rom does on real hardware.

[+stephena]

When you have write a 1, and you push up on the joystick the screen goes red on real hardware. For the SWCHA rom Stella emulated this correctly so you don't have to change anything. Both Stella and real hardware treated the rom the same so Stella is emulating correctly. I think the red screen was throwing you off, that's all.

Yes, I was stuck on red means bad, green means good I was almost positive the port A handling was correct, because I went through that code extensively for AtariVox support in version 2.6 or so. So I was getting nervous that it wasn't working again.

 

I'll try some paddles and driving controllers this afternoon or tonight in Stella and see if it matches what the rom does on real hardware.

Yes, please get back to me on this. I plan to do a new release in the next week or two, and it would be nice to get the fixes included. I can send you a test binary if you like. If so, let me know what OS and 32 or 64 bit.

[Omegamatrix]

I can send you a test binary if you like. If so, let me know what OS and 32 or 64 bit.

Sounds good. Windows 7 32 bit if you can! I'll test the paddles and driving controllers tomorrow. My company stayed too late tonight.

 

I also wrote a program to test every value against every I/O combination for SWCHB.

 

 

TestSWCHB_AllValues.zip

 

So this will run a black screen for a few seconds until it finishes all of the checks. Then you'll either get a blue screen (all values written to outputs remained the same, and no inputs were affected), or you'll get a red screen for a mismatched value. I tested it on my 7800 and Jr and got blue screens on both.

 

Note: unlike the previous tests, you are not meant to flick console switches while this runs. Just let it do its thing. Flicking switches while this rom is running will cause it to fail.

[+stephena]

I also wrote a program to test every value against every I/O combination for SWCHB.

This works in Stella as well (blue screen). And check your PM for a message about the test build.

[Omegamatrix]

Alright, first I tested my paddles and driving controller to see if they working correctly. Then I used the test version of Stella you sent me Stephena, making sure to set the game rom properties to "paddles" or "driving" as appropriate. Testing was done via a Stelladaptor.

 

Notes:

In the demo rom, D7 is always left as 0 in the VBLANK register. Writing a 1 to D7 would dump inputs 0-3 to ground.

 

 

Paddles

- You can spin the paddles all day, and the screen won't turn red. It doesn't matter if #$00 or #$FF is being written.

- The screen only turns red when you press a firebutton on one of the paddles while #$FF is being written in the demo screen. Pressing the fire button while #$00 is being written has no effect.

 

The digital paddle speed was tried in Stella at 1,6, and 15. The different speeds had no effect on the test rom. All in all the paddles behaved the same in Stella as they did on real hardware.

 

 

 

Joysticks

- Firebutton has no effect (as it shouldn't)

- Pressing a direction has no effect while a #$00 is being written. Pressing the joystick will cause the screen to got red only when a #$FF (high value) is written to the output pin on SWCHA. Obviously the grounding of the joystick is changing the value (bringing it low).

 

Stella correctly emulates real hardware for the joysticks.

 

 

 

Driving Controls

- Firebutton has no effect

- Spinning while the controller has no effect while #$00 is written

- Spin or no spin, MOST of the time the screen goes red as soon as #$FF is written.

 

On real hardware I noticed that depending on where the position of the nob was, sometimes the screen would stay green on a #$FF write. There seems to be a sweet spot in these controllers where they are either open or have a really high impedance. I unplugged the driving controller and measured it with my ohmmeter, and it overloaded it. It's just a cheap little Nextech and the highest setting is 2M ohms. So I couldn't tell from it if I was measuring an open or really high resistance, but I think it would be an open because the test rom never went red. After playing around with the driving controller I can only picture it in my head as 2 coils of wire (each coil is one semicircle) with a 2 pole sweeping across them. When the poles line up between the intersections of the semi-circles it is an open. I might have to take one of these apart sometime and have a look.

 

 

Anyhow when I found this sweet spot I tried the controller on the 7800 and the screen was still green. However in Stella the screen was green for the same knob position. I don't know if there is a way around this. I'm not sure if the Stelladaptor is affecting anything, or if it's just Stella. I mean it's got to be hard to try and do this perfectly in software.

 

 

Wow, what a long post!