INTY BASIC: Buttons + disc at same time

[+atari2600land]

I want to make it so whether or not a button is pressed, a=cont reads just the disc portion so I can handle button presses somewhere else. I tried various things but nothing worked.

[+DZ-Jay]

5 hours ago, atari2600land said:

I want to make it so whether or not a button is pressed, a=cont reads just the disc portion so I can handle button presses somewhere else. I tried various things but nothing worked.

What do you mean, "just the disc portion" and "handle button presses somewhere else"?

The variable CONT will always include any input pressed, whether disc or key or button.  If you just want to handle disc at some points, just ignore any other input that is not disc (or whatever disc directions you don't want).

 

Button codes do not overlap with the disc, so that should not be a problem.

 

If you give a more detailed explanation of what you want to do, perhaps I can help more.

 

    dZ.

[+atari2600land]

For example, if I wanted to check if a button was pressed, I'd do

a=cont

if a=$c0 then ....

 

But if I do that then I can't check for any of the directions on the direction pad since they'd all have their value + $c0, or $a0, or $60. What I would like to do is have the player move around AND check for button presses at the same time.

 

[+DZ-Jay]

22 hours ago, atari2600land said:

For example, if I wanted to check if a button was pressed, I'd do

a=cont

if a=$c0 then ....

 

But if I do that then I can't check for any of the directions on the direction pad since they'd all have their value + $c0, or $a0, or $60. What I would like to do is have the player move around AND check for button presses at the same time.

 

 

Ah!  Now I understand.  You need to mask the bits for that to work.  The hand-controller button and disc input share 8 bits in the "CONT" value, the top three ones are for the buttons, and the lower five are for the disc.  (The keypad overlaps with both, which is why you can only decode "disc+buttons" or "keypad.")

 

So, to test for buttons, you can do this:

button = (CONT AND $E0)

 

And to test for disc, you can do this:

disc = (CONT AND $1F)

 

You then take the value of "button" or "disc" and check to see which button or direction was pressed.

 

You can also combine them like this:

If (CONT AND $E0) Then
  ' A button was pressed ...
End If

If (CONT AND $1F) Then
  ' A disc direction was pressed ...
End If

 

Now, keep in mind that this is the "quick-and-dirty" way of decoding input -- it doesn't account for any analog signal noise (a.k.a. "signal bounce") of the mechanical control surfaces, nor whether a keypad was pressed instead which, because it overlaps with both, would mistakenly appear as if some button and some disc direction were pressed.

 

To fully account for those things would require a bit more effort, perhaps a state machine, and maybe a look-up table or two with the valid codes for each input.  IntyBASIC does this for you for the keypad itself (CONT.Key), but not for the disc and buttons.

 

You may not care enough to go through that trouble, and indeed many IntyBASIC programs do not even try so it is not such a great loss; but personally, such nuances make all the difference between an adequately playable input mechanic, with the occasional glitches and misses, and an absolutely smooth and intuitive experience; so your mileage may vary.

 

For anybody interested, I created a routine that attempts to do all the heavy-lifting of debouncing and decoding the input controls.  It is essentially an IntyBASIC translation of a similar library from my P-Machinery framework, but without the event-driven model.

 

To use it, you include the library files in your own program, and call the DecodeInput() procedure from your game loop, right after Wait.  It will assign the decoded values to an array in which each element is a type of control, or "-1" when no input was read.  The library includes useful constants to access the values.

• CtrlInput(CTRL_KEY)
• CtrlInput(CTRL_BTN)
• CtrlInput(CTRL_DISC)

For example, if you want to know if the disc was pressed, you can do something like:
 

If (CtrlInput(CTRL_KEY) <> CTRL_NO_INPUT) Then
  ' Disc was pressed ...
End If

 

To check whether the left button was pressed,

If (CtrlInput(CTRL_BTN) = BTN_BOTTOM_L) Then
  ' Left button was pressed ...
End If

 

Be aware that it treats the buttons and the keypad as simple push-down buttons, so it only decodes them when pressed.  Consequently, leaving a button or keypad pressed will set the decoded value on the frame in which it occurred; and any subsequent frame will just be CTRL_NO_INPUT because no new input is detected.  In other words, the player needs to release the button or key and press it again for new input.

 

The disc, by contrast, is treated as a continuous stream of input, so new input is decoded on every frame, as you roll your thumb over the disc, and then set CTRL_NO_INPUT only when released.

 

Oh, and it also supports the 9+1 or 7+3 "pause" combination, and goes into a loop with the screen disable, like the old-school games, waiting for any user input to return to the regular program.

 

Anyway, attached is an IntyBASIC SDK project with the code.  Feel free to use it in any way that is useful.

 

      -dZ.

 

handctrl.zip

[+atari2600land]

4 hours ago, DZ-Jay said:

it doesn't account for any analog signal noise (a.k.a. "signal bounce") of the mechanical control surfaces

Wait, what? The intv can use analog signal noise as input?

Thanks, the "quick and dirty" way works well.

[+DZ-Jay]

13 hours ago, atari2600land said:

Wait, what? The intv can use analog signal noise as input?

 

I meant, the signal noise is analog, because it is mechanical.  The codes themselves are digital.

 

I know that a lot of programmers here do not know (or care), but the Intellivision hand-controller is very "noisy" and glitchy.   There are ways to handle this and account for it, but it takes effort and ingenuity.

 

A lot of the time, when people complaint about the hand-controllers being buggy, glitchy, or unresponsive, the problem is with the game's decoding code itself.

 

13 hours ago, atari2600land said:

Thanks, the "quick and dirty" way works well.

 

No worries.  The solution is there for you or anyone to explore if you want to.

 

    dZ.