Jump to content

What does the Game Select switch actually do?


Recommended Posts

Finally, I just wanted to add that besides the driving controller the emulation is spot on. We've pretty much tested everything and proven that it all properly matches the behavior as described in the data sheet that Alex quoted.



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.



This morning I was thinking about how would a Secam 2600 might behave, where the color/bw switch is always grounded. I can only believe that port B would have exactly the same results as we already got. In pretty much the words of the data sheet, the microprocessor will ignore peripheral pins on port B and read the output register instead.

Link to comment
Share on other sites

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.

First of all, good to hear that everything works (driving controller notwithstanding, but I suspect it's an interaction between the Stelladaptor and Stella). I just want to address the point above. 'Digital' paddle speed only affects emulation of the paddles with digital devices (ie, the keyboard, a digital joystick axis, etc). It never applies to analog axes, and more particularly, to anything connected to a Stelladaptor. As you know, a digital device can be on or off. All keyboard keys are like this. Now, if you want to simulate paddle movement, there has to be a distance variable, whereby as the key is pressed, the paddle moves some amount. The aforementioned 'digital paddle speed' determines haw 'fast'/far the paddle will move while a key is pressed. That being said, I'm not really impressed with the current implementation.


Maybe I should explain that better in the manual ...

Link to comment
Share on other sites

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.

I believe the driving controllers act more like the keypad controllers, as you rotate it, different pairs of wires connect. It is not analog like the paddles.

Here is a link I was just made aware of in another thread.


Link to comment
Share on other sites

Atari driving controller knob, paddle buttons and joystick directions are all connected to switches which ground the corresponding pins or leave them unconnected (floating). In the latter case the console will read the voltage level of the riot pin ('1' if in input mode or the one written in the output register when in output mode).

Anyway other compatible controllers may output an logic '1' instead of leaving the pin floating (e.g. trackball, genesis controller), so you can have a red screen in your demo even when a #$00 is written to SWCHA depending on the specific controller you are using.



While turning the knob, the output of the driving controller on pin 1 and 2 of the port is:






It repeats 4 times per revolution. So there are 4 positions of the knob where both pin are unconnected (which explain the green screen on your demo).


If you use a custom driving controller built using optocouplers instead of mechanical switches like this one, you would have a red screen in every position of the knob.

Edited by alex_79
Link to comment
Share on other sites

  • 1 month later...

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.


You probably already have your answer, but looking at the disassembly, Combat writes 0x10 into both GameOn and DDRB at startup, copies GameOn into SWCHB after LDMult:

; Render joysticks immobile if game not in play, and
; select player and field colors according to Y
LDA  GameOn             ; Enable joysticks via bit 1
STA  SWCHB              ; of $FF game-on value


The only place SWCHB is not immediately destroyed after loading it is when it's copied to DIFSWCH at the top of NoStir. And all the uses of DIFSWCH I can see only seem to use the top two bits, where difficulty lives.


So it does seem to be taking the trouble to store a bit there, but it's never reading it?


What am I missing?



Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...