Simon Game - Programming

[jukingeo]

Hello all,

I know it has been a while since I been in the forums, I been a bit on Basic Stamp hiatus for a while, but I knew I was going to get back into it soon.

I DID have a Halloween project this past year, but I used a computer for my attraction, but this coming year I will definitely do something with the Basic Stamp.

Well, for now the reason I am posting is because I read an interesting article in this months issue of Nuts & Volts (March '10) in regards to building a Simon game based on an Atmel  ATiny2313 processor.   While I am not familiar with Atmel products (let alone how to program them), I was curious if the same type of game could be achieved using a Basic Stamp1.

I did a quick search here and 'Simon' was actually mentioned a couple of times in regards to using random numbers.  That being the case I am under the impression that it IS possible to make a Simon game out of a Basic Stamp.   However, being the owner of a Prop-2,  I am not 100% sure of the full capabilities of a project like this running on a Prop-1.

Certainly I would like to try it on a Prop-2, (just to get a feel for the programming), but it is more cost effective to go with a Prop-1 considering the Simon game uses precisely 8 i/o lines (four switches, four led/lamp outputs).

The bottom line goal would be to create a larger than life Simon game that you would play with your feet.  Yeah, something that would work like a Dance Dance Revolution footpad, but with foot pads that light up like on the original Simon.

So, is this doable?

Thank You,

Geo

[JonnyMac]

Yes, in fact, one of the earliest demos for the BASIC Stamp 1 was a Simon game.  I've attached the (old [circa 1994] and messy code).  When I'm back from my meeting this afternoon I'll clean-up the code and post a schematic.  It uses the four IO pins as inputs AND outputs; a little tricky.

[jukingeo]

Yes, in fact, one of the earliest demos for the BASIC Stamp 1 was a Simon game.  I've attached the (old [circa 1994] and messy code).  When I'm back from my meeting this afternoon I'll clean-up the code and post a schematic.  It uses the four IO pins as inputs AND outputs; a little tricky.

Thank you Jon,  I will look the program over this afternoon.  I do have to brush up on my BS1 conversions to BS2 as since it has been a while since I did that, I did forget some things (shame on me).  But I did kind of figured out that it should be easily handled by the BS1, the only real question of that the Simon game did have some sort of 'memory' and I wasn't sure how that was handled code wise.

Sidebar:  I am mostly in Ubuntu Linux right now and do not use Windows that much (only for games and certain applications that will not run in Linux).   Would you know if the Basic Editor now has full Linux capabilities?  As I recall, only the BS2 could be programmed in Linux.

Just for the hell of it I did try to put the Windows version of the Basic Editor into Wine...which is a Windows Layer that runs on top of Linux.  The program DOES open, but I am not sure if it will work sending the proper data to the serial port this way.  But in the very least I 'think' I can edit programs in Linux.

Well, I am happy to be back as I will be planning something for Halloween this year and I certainly want to put a couple of Basic Stamp projects into use.   I recently had a major virus on my Windows machine and was forced to reload all my programs, including the Basic Stamp Editor.   But thankfully, my data is kept safely on a different drive, so I didn't loose any of my Basic programs (thank goodness).

Another thing I am planning to put together is a redemption game (that will be another post) as I have to post quite a few details on that.  BUT I am back!

So I will be checking out what others have been up to in terms of projects while I was away, I am sure I have much catching up to do.

Thanx,

Geo

[JonnyMac]

Here's the secret behind Simon games: Microcontrollers use an algorithm called a Linear Feedback Shift Register to generate seemingly random numbers.  They are actually called pseudo-random because the fact is, for the same seed (input value), RANDOM will always give you the same result (output value).

What this means is that the Simon game only has to remember the initial seed for a game.  You'll see that this value is incremented during the time the program is waiting for the user to start the game.  Once a game is started only the initial seed is saved and used each time the sequence is played for memorization.

Here's a little program that demonstrates the behavior of RANDOM.  Notice that for the same seed, the list is the same every time -- it looks random, but, in fact, each result is created by the LFSR and for a given input to RANDOM there is just one output.

' =========================================================================
'
'   File......
'   Purpose...
'   Author....
'   E-mail....
'   Started...
'   Updated...
'
'   {$STAMP BS1}
'   {$PBASIC 1.0}
'
' =========================================================================


' -----[ Program Description ]---------------------------------------------


' -----[ Revision History ]------------------------------------------------


' -----[ I/O Definitions ]-------------------------------------------------

SYMBOL  Trigger         = PIN6                  ' SETUP = DN


' -----[ Constants ]-------------------------------------------------------

SYMBOL  IsOn            = 1                     ' for active-high in/out
SYMBOL  IsOff           = 0


' -----[ Variables ]-------------------------------------------------------

SYMBOL  timer           = B2
SYMBOL  idx             = B3
SYMBOL  seed            = W4
SYMBOL  lottery         = W5


' -----[ Initialization ]--------------------------------------------------

Reset:
  PINS = %00000000                              ' clear all outputs
  DIRS = %00111111                              ' make P0-P5 outputs

  DEBUG CLS
  GOTO Prompt


' -----[ Program Code ]----------------------------------------------------

Main:
  timer = 0                                     ' reset timer

Check_Trigger:
  PAUSE 5                                       ' loop pad
  timer = timer + 5 * Trigger                   ' update timer
  IF timer < 100 THEN Check_Trigger             ' wait for 0.1 sec input

  DEBUG CLS

Set_Seed:
  seed = 1234

Rnd_Loop:
  lottery = seed                                ' copy initial seed
  FOR idx = 1 TO 5
    RANDOM lottery                              ' "randomize"
    DEBUG #idx, "   ", #lottery, CR             ' display
  NEXT
  DEBUG CR

Prompt:
  DEBUG "Press Trigger"
  GOTO Main


' -----[ Subroutines ]-----------------------------------------------------


' -----[ User Data ]-------------------------------------------------------

[jukingeo]

Here's the secret behind Simon games: Microcontrollers use an algorithm called a Linear Feedback Shift Register to generate seemingly random numbers.  They are actually called pseudo-random because the fact is, for the same seed (input value), RANDOM will always give you the same result (output value).

I never fully delved into the 'mechanics' behind the random number, but I do remember that it was necessary to create a loop to run RANDOM several times to truly get a random number, otherwise (as you said), you would get the same result each time.

What this means is that the Simon game only has to remember the initial seed for a game.  You'll see that this value is incremented during the time the program is waiting for the user to start the game.  Once a game is started only the initial seed is saved and used each time the sequence is played for memorization.

So then every time you step the seed, the result would always end up the same and thus you could repeat the sequence and then just add to it?

With the Simon games I always thought there was some kind of memory in which each 'random' generated light output would be generated and then put into memory.  Then, of course, each step would have to match the button that was pressed.   But here you would be working off the constant single random seed and thus that information acts like a memory.  That is pretty interesting that normally something that would be an annoying trait (pseudo random instead of true random), could be exploited to create a game like Simon.

Here's a little program that demonstrates the behavior of RANDOM.  Notice that for the same seed, the list is the same every time -- it looks random, but, in fact, each result is created by the LFSR and for a given input to RANDOM there is just one output.

Could this be run in the editor as I don't have a Prop-1 as of yet?  I would like to examine this more closely.

Now for the BS1 Simon code you posted earlier, what does the schematic for that program look like.  I believe you mentioned that it uses a single pin for BOTH input & output.  I would like to see how that is wired so I could avoid any short circuits.

Thanx,

Geo

[JonnyMac]

The game adds a bit of true randomness by manipulating the seed until the user presses a button to start the game; this is when the now unknown seed is locked in for a game.

No, BASIC Stamp (1 and 2) programs only run in the actual machine.

[jukingeo]

The game adds a bit of true randomness by manipulating the seed until the user presses a button to start the game; this is when the now unknown seed is locked in for a game.

Yeah, I saw that the seed is 'stirred' during the attract mode at the beginning of the program.  Two final things, do you have a version of this program for the Prop-2 (since that is what I actually have right now)?   And do you have a schematic for how to wire up the buttons/Led's since both input and output share the same pin?

Thanx,

Geo

[JonnyMac]

I don't have a BS2 version but that doesn't mean it doesn't exist -- you might want to use this in a Google search:

+simon +".bs2"

I've attached a schematic for the program listing (you need four of these, one each on P0..P3).  To activate the LED the IO pin is mde low -- this allows the user to press the button at the same time without any harm.  What you don't want to do is make an output high, leave it there, and then press a button -- this could short a pin (not on the Prop-1, though, as we have protection resistors onboard).  To turn the LED off the pin is made an input (all four at once in the listing to make things easy). 

[jukingeo]

I don't have a BS2 version but that doesn't mean it doesn't exist -- you might want to use this in a Google search:

+simon +".bs2"

Ok, thanx.  I probably will end up converting the program you posted.  I used to do that anyway, but after not doing it for a while, I forgot certain things  :-[.

I've attached a schematic for the program listing (you need four of these, one each on P0..P3).  To activate the LED the IO pin is mde low -- this allows the user to press the button at the same time without any harm.  What you don't want to do is make an output high, leave it there, and then press a button -- this could short a pin (not on the Prop-1, though, as we have protection resistors onboard).  To turn the LED off the pin is made an input (all four at once in the listing to make things easy). 

Well, I am kind of worried that with a "foot operated" Simon, I am worried that someone could be standing on a button while the next sequence starts to play.  With that schematic above, would that be a problem?  If so, then I would be better off just going with separate input/outputs.

I'll do a quick search and see if there is something out there for the BS2/Prop-2  perhaps I can find something I can test and then adapt to the Prop-1.

I know I have to get a couple of Prop-1's sooner or later as most of my applications really don't the power of the Prop-2.

Thanx,

Geo

[JonnyMac]

If you're using your Prop-2 then yes, use separate inputs and outputs -- will make the code easier, too.  Keep in mind that the BS2 separates the IOs into 4-bit groups (INA, INB, INC, IND, OUTA, OUTB, OUTC, OUTD) -- this will make working with four inputs and four outputs pretty easy.

Again, the only problem with that circuit is a programming error that would set a pin high and leave it that way.  If that doesn't happen then there is no problem with the circuit.