The Museum of HP Calculators

HP Forum Archive 18

[ Return to Index | Top of Index ]

Can anyone check this strange behavior on HP-15C
Message #1 Posted by Bastian Erdnüß on 16 Mar 2008, 10:47 a.m.

I have an HP-15C. I wrote the following program (a nimb game):

LBL A:				01 - 42, 21, 11
	1			002 - 1				Start with 15 sticks
	5			003 - 5
LBL 0:				004 - 42, 21, 0
	R/S			005 - 31			User enters no of taken sticks
	ENTER			006 - 36
	INT			007 - 43, 44
	ABS			008 - 43, 16
	X =/= Y:		009 - 43, 30, 6			Make tests for correct insert
		GTO 1		010 - 22, 1			GTO 1 -> Error!
	X == 0:			011 - 43, 20
 		GTO 1		012 - 21, 1
 	CLX			013 - 43, 35
 	4			014 - 4
	X <= Y:			015 - 43, 10
		GTO 1		016 - 22, 1
	ROLL DOWN		017 - 33
	-			018 - 30			Calculate left sticks
	X <= 0:			019 - 43, 30, 4
		GTO 2		020 - 22, 2			Nothing left -> User lost
	PSE			021 - 42, 31			Show left sticks
	ENTER			022 - 36
	1			023 - 1
	-			024 - 30
	X == 0:			025 - 43, 20
		GTO 3		026 - 22, 3			If computer takes last -> user won
	4			027 - 4
	/			028 - 10
	INT			029 - 43, 44
	4			030 - 4
	*			031 - 20
	1			032 - 1
	+			033 - 40
	X =/= Y:		034 - 43, 30, 6			If possible take optimal no of sticks
		GTO 0		035 - 22, 0			-> next round
	1			036 - 1
	-			037 - 30
	RAN #			038 - 41, 36			Otherwise, take random no of sticks
	3			039 - 3
	*			040 - 20
	INT			041 - 43, 44
	-			042 - 30
	GTO 0			043 - 22 0			-> next round
LBL 1:				044 - 42, 21, 1
	0			045 - 0				-> Error!
	LN			046 - 43, 12
LBL 2:				047 - 42, 21, 2
	5			048 - 5				Show BLISS
	5			049 - 5				-> Computer has won
	1			050 - 1
	7			051 - 7
	8			052 - 8
	RTN			053 - 43, 32
LBL 3:				054 - 42, 21, 3
	3			055 - 3				Show ILOSE
	5			056 - 5				-> User has won
	0			057 - 0
	7			058 - 7
	1			059 - 1
	RTN			060 - 42, 32

It's a rewrite from the program from Genes HP.

The rules are easy: 1) Start the program. 2) 15 is shown. 3) Enter no of sticks you will take (1, 2 or 3). 4) DO _NOT_ CONFIRM WITH ENTER 5) press R/S. 6) The no of remaining sticks will be shown for a short time. 7) The no of sticks remaining after the turn from the computer is shown. 8) Go on by step 3) 9) If you do a wrong insert, Error 0 is shown, you lost. 10) If you have won, ILOSE is shown (upside down). 11) If you lost, BLISS is shown (upside down).

Now, my problem is the following: If I start by taking 1 or 3 sticks, all works fine and I lose. But if I start by taking 2 sticks (the only chance to win the game), the computer will not take any stick. It seems that the test in line 34 does not evaluate right. But If I step the program, all works fine. In the second round (and in all following) it than seems, that the ENTER in line 22 will not be executed right (so the test in line 34 fails again). Again, if I step the program, this happens not.

I guess that something may be weak in my computer, but what? It seems not to be the test (in line 9 it works very well, and replacing X =/= Y in line 34 by X >= Y doesn't changes anything). It also seems not to be the ENTER key, because in line 6 it works well and in the usual calculating also.

Or did I misunderstood something in the way my computer works and did a mistake in the program? Can anyone check this?

Has anyone a idea what could make this behavior?

Thanks, Bastian.

      
Re: Can anyone check this strange behavior on HP-15C
Message #2 Posted by Egan Ford on 16 Mar 2008, 1:01 p.m.,
in response to message #1 by Bastian Erdnüß

Quote:
But if I start by taking 2 sticks (the only chance to win the game), the computer will not take any stick.
Perhaps your 15C is a poor sport. :-)

Can you post the original source that you used as the basis for your code?

Update

I added an extra ENTER after line 22. Seems to work with 1, 2, or 3 as a starting number.

001   LBL A     014   4         027   GTO 3     040   3         053   8         
002   1         015   x<=y      028   4         041   x         054   RTN       
003   5         016   GTO 1     029   /         042   INT       055   LBL 3     
004   LBL 0     017   Rv        030   INT       043   -         056   3         
005   R/S       018   -         031   4         044   GTO 0     057   5         
006   ENTER     019   TEST 4    032   x         045   LBL 1     058   0         
007   INT       020   GTO 2     033   1         046   0         059   7         
008   ABS       021   PSE       034   +         047   LN        060   1         
009   TEST 6    022   ENTER     035   TEST 6    048   LBL 2     061   RTN       
010   GTO 1     023   ENTER     036   GTO 0     049   5         
011   x=0       024   1         037   1         050   5         
012   GTO 1     025   -         038   -         051   1         
013   CLx       026   x=0       039   RAN#      052   7         
Please post the original code.

Edited: 16 Mar 2008, 1:09 p.m.

            
Re: Can anyone check this strange behavior on HP-15C
Message #3 Posted by Bastian Erdnüß on 16 Mar 2008, 9:05 p.m.,
in response to message #2 by Egan Ford

The original source can be found here: http://www.rskey.org/gene/calcmuseum/25nimb.htm. But it is for the HP-25.

Now, it also works on my computer. Can you explain why this change is needed? I don't see it.

Thank you very much

Bastian

                  
Re: Can anyone check this strange behavior on HP-15C
Message #4 Posted by Egan Ford on 17 Mar 2008, 12:08 a.m.,
in response to message #3 by Bastian Erdnüß

Quote:
Can you explain why this change is needed? I don't see it.
I do not recall exactly, but I remembered having a similar problem that did not present itself when using R/S. The solution was the same, an extra ENTER.
                        
Re: Can anyone check this strange behavior on HP-15C
Message #5 Posted by Bastian Erdnüß on 17 Mar 2008, 9:11 a.m.,
in response to message #4 by Egan Ford

Ohh noo!! I see it.

The [ENTER] copies the content of the X register to the Y register. But then the stack will be disabled. If I would use a function now, like [x^2] or anything else (with one argument) the function would enable the stack again and use the copy in the X register for the operation. But I enter a [1] in the next step and so my copy in the X register will be overwritten. After performing [-] on X and Y I lost my copy in the Y register, of course!

But when I stepped the program, every time after the [ENTER] was executed, I checked the content of the Y register by pressing [X <-> Y] two times. But this operations have enabled the stack again, and so the next command ([1]) didn't overwrite the content in the X register, but shifted it. And so my lost copy was stored in the Z register as it should be and all worked fine.

Bastian


[ Return to Index | Top of Index ]

Go back to the main exhibit hall