Demo - Batman

[Rabbit 2600]

Just a demo I'm working on to test out what I've learned. It's a fighting game alá Double Dragon. Very basic at the moment. You can punch the enemies and walk around a bridge. Updates to come

 

 

GAME - default.bas.bin

SOURCE - default.bas

[Rabbit 2600]

Added a debounce to the punching so now you can't hold the firebutton in. Gonna see if I can remember how to set a counter up so the punch lasts for about 1 second.

 

I tried using this but could not make the counter work, some small silly mistake I made somewhere no doubt.

 

Game - default.bas.bin

 

Source - default.bas

 

 

 

rem ****************************************************************
rem *
rem * Debounce fire button.
rem *
rem ````````````````````````````````````````````````````````````````
rem ` If fire button not pressed, clear debounce bit and skip.
rem `
if !joy0fire then _Bit1_Debounce_Fire{1} = 0 : goto __Skip_Fire

rem ````````````````````````````````````````````````````````````````
rem ` If fire button hasn't been released, skip this section.
rem `
if _Bit1_Debounce_Fire{1} then goto __Skip_Fire

rem ````````````````````````````````````````````````````````````````
rem ` Turn on fire button debounce bit.
rem `
_Bit1_Debounce_Fire{1} = 1

rem ````````````````````````````````````````````````````````````````
rem ` Skip Punch.
rem `
if joy0fire then a = 120 : g = 10
if a > 0 then a = a - 1
if a = 1 then g = 10 : a = 0
__Skip_Fire

Edited June 8, 2013 by Rabbit 2600

[bogax]

Added a debounce to the punching so now you can't hold the firebutton in.

 

 

I probably shouldn't confuse you,

but that's not actually debounce.

It's more edge detection though

The term debounce seems to be

(mis)used for it a lot.

(drives me nuts, heh )

 

Probably someday you're going to

run into someone talking about actual

debounce and wonder what they're

talking about.

 

For various reasons (one being bouncy

contacts in a switch, hence debounce)

when going from, say, 0 to 1 a switch

might jump back and forth between

0 and 1 before it stays 1.

Debounce is getting past that cleanly.

 

Now suppose I decide I wont believe

its really a 1 until I've seen three

1s in a row. then it might look something

like this (each 0 or 1 is what I read

when I read the switch one time):

what I read    0001010010110110011101110111111
edge detection  0001010010100100010001000100000
debounce    0000000000000000000111111111111

Edited June 8, 2013 by bogax

[+Random Terrain]

I probably shouldn't confuse you,

but that's not actually debounce.

It's more edge detection though

The term debounce seems to be

(mis)used for it a lot.

(drives me nuts, heh )

 

So keeping a switch or fire button from activating again until it is released is not called debouncing? I better add a note to Atari's Game Standards and Procedures then:

 

http://www.randomter...starting_a_game

The Reset switch should be debounced so it does not start another game until it is first released.

 

What is it supposed to be called?

[Rabbit 2600]

Ahh, I did not know that, I learned that it was called debouncing when you can't hold a button in. Thank you for explaining it =)

[+Random Terrain]

Ahh, I did not know that, I learned that it was called debouncing when you can't hold a button in. Thank you for explaining it =)

 

He might have been talking about you wanting to add a counter. I think this might still be considered debouncing:

 

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

[Rabbit 2600]

Mhm, okay =)

[bogax]

What is it supposed to be called?

 

I'd call it edge detection.

 

Not sure it matters.

 

My impression is that, when talking about

writing games debounce is more often used

to mean edge detection than actual debounce

(but not always)

 

You might note that it's not actually debounce

but that that is the term that's used and leave

it at that.

And/or you might add a bit on actual debouncing

since that's generaly considered a good idea

even though I don't see it done here much.

(probably more likely to see it when talking asm)

[+Random Terrain]

Do you have any links to pages that define the terms? Here's one thing I found when Gooling:

 

(Debouncing) A keyswitch, when pressed, may send several rapid electrical signals in succession. This could be interpreted by a computer as numerous independent keystrokes rather than just one. A debouncing circuit is a timer or similar system to eliminate spurious responses caused by key bounce.

 

This code keeps the fire button from bouncing or having a rapid-fire effect:

 

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

  rem  ****************************************************************
  rem  *
  rem  *  Debounce Fire Button
  rem  *
  rem  *  Example program by Duane Alan Hahn (Random Terrain) using
  rem  *  hints, tips, code snippets, and more from AtariAge members
  rem  *  such as batari, SeaGtGruff, RevEng, Robert M, Nukey Shay,
  rem  *  Atarius Maximus, jrok, supercat, GroovyBee, and bogax.
  rem  *
  rem  ****************************************************************
  rem  *
  rem  *  Instructions:
  rem  *  
  rem  *  Press and release fire button to increase the score by one.
  rem  *
  rem  ****************************************************************



  rem  ****************************************************************
  rem  *
  rem  *  Create aliases for variables.
  rem  *
  rem  ****************************************************************
  rem  `
  rem  `  (You can have more than one alias for each variable.)
  rem  `
  rem  ````````````````````````````````````````````````````````````````

  rem  ````````````````````````````````````````````````````````````````
  rem  `  BitOp variable for debouncing the fire button.
  rem  `
  dim _Bit1_Debounce_Fire = d






  rem  ****************************************************************
  rem  ****************************************************************
  rem  *
  rem  *  Main Loop
  rem  *
  rem  `
__Main_Loop



  rem  ****************************************************************
  rem  *
  rem  *  Score color.
  rem  `
  scorecolor = $1A




  rem  ****************************************************************
  rem  *
  rem  *  Debounce fire button.
  rem  *
  rem  ````````````````````````````````````````````````````````````````
  rem  `  If fire button not pressed, clear debounce bit and skip.
  rem  `
  if !joy0fire then _Bit1_Debounce_Fire{1} = 0 : goto __Skip_Fire


  rem  ````````````````````````````````````````````````````````````````
  rem  `  If fire button hasn't been released, skip this section.
  rem  `
  if _Bit1_Debounce_Fire{1} then goto __Skip_Fire


  rem  ````````````````````````````````````````````````````````````````
  rem  `  Turn on fire button debounce bit.
  rem  `
  _Bit1_Debounce_Fire{1} = 1


  rem  ````````````````````````````````````````````````````````````````
  rem  `  Add one to the score.
  rem  `
  score = score + 1


__Skip_Fire




  rem  ****************************************************************
  rem  *
  rem  *  Nothing would happen without drawscreen. 
  rem  `
  drawscreen



  goto __Main_Loop

 

I don't understand how that wouldn't be considered debouncing the fire button.

[bogax]

I don't understand how that wouldn't be considered debouncing the fire button.

 

I'm not sure how to explain any better.

maybe I didn't make it clear that

 

what I read    0001010010110110011101110111111
edge detection  0001010010100100010001000100000
debounce    0000000000000000000111111111111

 

is meant to represent one key press.

 

Your code would increment score 8 times in that

example for that single keypress.

Thats not debounce

Edited June 8, 2013 by bogax

[+Random Terrain]

Your code would increment score 8 times in that

example for that single keypress.

Thats not debounce

 

I only see one being added to the score:

 

ex_debounce_2013y_03m_22d_1716t.bin

[bogax]

I only see one being added to the score:

 

I fyou're doing it on an emulator it's because the

keyboard is already debounced.

If it's on a real 2600 then most of the

bouncing might be hidden by the delay

due to drawscreen but you couldn't

count on that.

 

Either way it's still not debounce

Edited June 8, 2013 by bogax

[+Random Terrain]

I your doing it on an emulator it's because the

keyboard is already debounced.

If it's on a real 2600 then most of the

bouncing might be hidden by the delay

due to drawscreen but you couldn't

count on that.

 

Either way it's still not debounce

 

If flipping a bit off and on can't be trusted, how can anything in a program be trusted?

[bogax]

If flipping a bit off and on can't be trusted, how can anything in a program be trusted?

 

What bit are you talking about?

[+Random Terrain]

What bit are you talking about?

 

This bit:

 

_Bit1_Debounce_Fire{1}

 

The number inside of the curly brackets tells bB what bit you want to turn on or off.

[bogax]

This bit:

 

_Bit1_Debounce_Fire{1}

 

The number inside of the curly brackets tells bB what bit you want to turn on or off.

 

I'm not following you then.

The problem is when and how you set or reset that bit not the bit itself.

[+Random Terrain]

I'm not following you then.

The problem is when and how you set or reset that bit not the bit itself.

 

Would it help if I converted the debounce section into normal words? Here it is:

 

If the fire button is not pressed, the bit is turned off and the section is skipped.

 

If the fire button is pressed, but the bit is on, the section is skipped.

 

Turn on the bit.

 

Add 1 to the score.

[bogax]

debounce would be something like this

(not that this is the way I'd code it)

 if debounce then key_is_pressed

 if !joy0fire then j0f = 0 : skip
 j0f = j0f + 1
 if j0f > 2 then debounce = 1 : j0f = 0
 goto skip

key_is_pressed
 if joy0fire then j0f = 0 : skip
 j0f = j0f + 1
 if j0f > 2 then debounce = 0 : j0f = 0

skip

 

edit oops, forgot to reset the j0f counter

when debounce changes

Edited June 9, 2013 by bogax

[SeaGtGruff]

I guess I'm guilty of perpetuating the incorrect usage of debounce.

IIRC I picked up the term and its incorrect usage a few decades ago from a book about programming for the Atari 800. It certainly wouldn't be the first time that an author writing about Atari computers or game consoles had misused a term-- a good example would be the widespread misuse of the term "overscan" among Atari programmers to refer to the lines of vertical blanking at the bottom of a game screen.

 

I see what you mean about debouncing an iffy connection versus edge detection in a signal, bogax, but as I now understand the term I guess debouncing proper isn't necessary when reading the joysticks, fire buttons, console switches, etc., since the're usually being read only once per frame. I presume that any bouncing in the signal before a steady connection is made would most likely occur (on average) sometime between the two reads, while the display is being drawn, such that by the time you read the stick/button/switch during the vertical blanking period a steady connection has already been made.

 

On the other hand, an edge detection routine-- or whatever we should properly call it-- is definitely necessary in some cases, to prevent the program from responding more times than intended when the user pushes the stick in a certain direction, presses the fire button, presses one of the console switches, etc.

Edited June 9, 2013 by SeaGtGruff

[bogax]

I see what you mean about debouncing an iffy connection versus edge detection in a signal, bogax, but as I now understand the term I guess debouncing proper isn't necessary when reading the joysticks, fire buttons, console switches, etc., since the're usually being read only once per frame.

 

heh once per frame is definitely not true though it may be only noobs

(me too) that read the buttons multiple times. It's not at all uncommon to

see long strings of if statments reading the same buttons.

I generally don't worry about it I'm going to be using Stella.

But it's sloppy.

 

I'm pretty sure I've seen the subject discussed here on the forums

before but it doesn't come up much so I guess it's not much of

a problem.

I presume that any bouncing in the signal before a steady connection is made would most likely occur (on average) sometime between the two reads, while the display is being drawn, such that by the time you read the stick/button/switch during the vertical blanking period a steady connection has already been made.

 

I'm not sure you could count on that. My recollection is that 20ms is the usual

prescription (time to wait for the bouncing to stop) and that's supposed to be

plenty so 16ms is probably enough. But I know I've seen switches (relays actually)

that bounced for a lot longer than that. I have no idea what an Atari controller

would do and I have no idea what piece of air they pulled the 20ms figure from.

 

On the other hand, an edge detection routine-- or whatever we should properly call it-- is definitely necessary in some cases, to prevent the program from responding more times than intended when the user pushes the stick in a certain direction, presses the fire button, presses one of the console switches, etc.

 

Sure. I wasn't even objecting to calling it debounce (although, like I said, it drives me nuts)

It's just that there's a possibility of confusion when some noob comes across actual

debounce and it turns out to be something different from what they're expecting.

[SeaGtGruff]

Hmm, I see what you mean about multiple ifs per loop, but hopefully it isn't a problem. Perhaps the manner in which people use a joystick helps negate any potential issues with bouncing? People tend to push on them pretty hard, and to mash the fire button pretty hard.

 

I do know what you mean about the incorrect usage of a term driving you nuts. It bugs me the way Atari 2600 programmers use the term "overscan," but I know they aren't going to change, so I decided to shut up about it.

 

As far as "debounce," I've been a major offender, and now that I realize it refers to something different than what I'd thought, I'll try to figure out something else to call it. "Edge detect the fire button" sounds kind of strange compared to "debounce the fire button."

[+Random Terrain]

For the common man, Edge Detection is meaningless. Debounce at least made some sense because it contained the word bounce. When you didn't want the fire button or reset switch or select switch to "bounce" in rapid-fire succession 60 times a second if held down, the word Debounce seemed fit.

 

But if Debounce has some deeper meaning in electronics, we could use something like Repetition Restrainer instead. The code I posted can be used to stop a fire button from firing 60 times a second when held down. It can also be used to keep the reset switch from displaying a blank screen if held down. It won't keep resetting and resetting and resetting and resetting and resetting . . . My code fixes it so the game will reset once and ignore that the player still has the reset switch pressed down. The player will have to release the reset switch and press it again for it to work:

 

   rem  ****************************************************************
  rem  *
  rem  *  Reset Program:
  rem  *
  rem  *  Any Atari 2600 program should restart when the reset switch  
  rem  *  is pressed. It is part of the usual standards and procedures.
  rem  *
  rem  ````````````````````````````````````````````````````````````````
  rem  `  If the reset switch is not pressed, turn off debounce and
  rem  `  skip this section.
  rem  `
  if !switchreset then _Bit0_Debounce_Reset{0} = 0 : goto __Skip_Main_Reset


  rem  ````````````````````````````````````````````````````````````````
  rem  `  If the reset switch hasn`t been released, skip this section.
  rem  `
  if _Bit0_Debounce_Reset{0} then goto __Skip_Main_Reset


  rem  ````````````````````````````````````````````````````````````````
  rem  `  Restart the program.
  rem  `
  goto __Start_Restart


__Skip_Main_Reset

[Omegamatrix]

I'm not sure you could count on that. My recollection is that 20ms is the usual prescription (time to wait for the bouncing to stop) and that's supposed to be plenty so 16ms is probably enough

 

I seem to recall that as well. I knew what debouncing was from taking electronics at school, but I still tended to refer to edge detection as debouncing.

 

 

The 2600 has latches installed for the firebuttons. You write a 1 to bit 6 of the VBLANK register to enable them. They will remain high once enabled until the firebutton is pressed. Once pressed they will remain low until re-enabled.

 

 

I have never played with the latches as I always found reading the firebuttons once per frame worked well enough. Thinking about it now, I'm not sure how well they would work as I generally turn vblank on at the beginning of overscan and turn vblank off at the start of the kernel. And finally, yes I am using the terms overscan and vblank here, because that is how it is written in the Stella's programming guide and I have no problems with that. I've learned of some other terms before like "front porch" and "back porch" at school, but IIRC those reference are for a horizontal scanline and not the vertical.

[SeaGtGruff]

And finally, yes I am using the terms overscan and vblank here, because that is how it is written in the Stella's programming guide and I have no problems with that. I've learned of some other terms before like "front porch" and "back porch" at school, but IIRC those reference are for a horizontal scanline and not the vertical.

Yes, the Stella Programmer's Guide has perpetuated the incorrect usage of "overscan." It is the bible of the Atari 2600 programming universe and we must never go against it, even when it's wrong. That is not because it must never be contradicted, but rather because its influence is so all-pervasive that any attempts to go against it are doomed to fail before they're even begun.

 

As for "front porch" and "back porch," they are used in connection with both the horizontal and vertical timings:

 

The horizontal front porch is the horizontal blanking period that precedes the horizontal sync. The horizontal back porch is the horizontal blanking period that follows the horizontal sync. If the video signal includes a color burst signal, the portion of the horizontal back porch between the end of horizontal sync and the beginning of color burst is called the breezeway. In those cases some people appear to define the horizontal back porch as the horizontal blanking period that follows the color burst.

 

The vertical front porch is the vertical blanking period that precedes the vertical sync. The vertical back porch is the vertical blanking period that follows the vertical sync.

 

These terms are sometimes shortened by dropping the "horizontal" or "vertical" qualifiers when their meanings are clear from the context.

Edited June 9, 2013 by SeaGtGruff

[+Random Terrain]

Here's the updated fire button code with debounce removed from the REMs and any variable aliases:

 

  rem  ****************************************************************
  rem  *
  rem  *  Repetition Restrainer for the Fire Button
  rem  *
  rem  *  Example program by Duane Alan Hahn (Random Terrain) using
  rem  *  hints, tips, code snippets, and more from AtariAge members
  rem  *  such as batari, SeaGtGruff, RevEng, Robert M, Nukey Shay,
  rem  *  Atarius Maximus, jrok, supercat, GroovyBee, and bogax.
  rem  *
  rem  ****************************************************************
  rem  *
  rem  *  Instructions:
  rem  *  
  rem  *  Press and release fire button to increase the score by one.
  rem  *
  rem  ****************************************************************



  rem  ****************************************************************
  rem  *
  rem  *  Creates aliases for variables.
  rem  *
  rem  *  You can have more than one alias for each variable.
  rem  *
  rem  ****************************************************************

  dim _Bit1_FireB_Restrainer = d





  rem  ****************************************************************
  rem  ****************************************************************
  rem  *
  rem  *  Main Loop
  rem  *
  rem  `
__Main_Loop



  rem  ````````````````````````````````````````````````````````````````
  rem  `  Score color.
  rem  `
  scorecolor = $1A




  rem  ````````````````````````````````````````````````````````````````
  rem  `  Repetition restrainer for the fire button.
  rem  `
  if !joy0fire then _Bit1_FireB_Restrainer{1} = 0 : goto __Skip_Fire

  if _Bit1_FireB_Restrainer{1} then goto __Skip_Fire

  _Bit1_FireB_Restrainer{1} = 1

  score = score + 1

__Skip_Fire




  rem  ````````````````````````````````````````````````````````````````
  rem  `  Nothing would happen without drawscreen.
  rem  `
  drawscreen



  goto __Main_Loop