**Pages:** 1 **2** 3 4 5 6 7 8 9 10
Dieter,

Your game of 26 is great and does not take much space Consider it included!

Now to strip out the game of 36 and get a version of it running.

We will then have non-card reader requiring versions of all the programs for the 4K rom and it will be ready for Angel to work his magic. :-)

(10-28-2016 01:28 PM)Gene Wrote: [ -> ]We will then have non-card reader requiring versions of all the programs for the 4K rom and it will be ready for Angel to work his magic. :-)

Can't wait ;-)

New game to be put into the 67 games rom! Angel, don't redo the rom yet. I'll send all the .raw files when it is good to go. :-)

The game is "11/30" - 142 bytes. Raw file attached. Similar to this old HP 65 ! game:

HP-65 11/30 write-up
XEQ 1130. Enter decimal seed and then enter an initial bank deposit.

HP will generate two random numbers between 11 and 30. Display will show 12.25 BET?

You enter a $$ amount to bet that the NEXT random number between 11 and 30 will actually fall between the two displayed values, end points inclusive.

So key 10 R/S to bet $10. You win if the next number is 12, 13, 14...24, 25. You lose if it is 11, 26, 27...30.

Press R/S to try again.

When the 41C has shown the win or lose display, press E to display current bank roll. Press A to start over with two new numbers.

Hope to get this into the 4K rom.

1130 raw file
Example:

XEQ alpha 1130 alpha

SEED? 0.123456789 R/S

POT? 50 R/S

12.14 BET? (Gene: Not very likely next number is between 12-14!)

0 R/S (Gene: Bet $0)

LOSE 28-12.14 (I lost $0 because the next number was 28 - outside range of 12-14).

R/S

14.22 BET?

20 R/S

WIN 21-14.22

R/S

17.24 BET?

5 R/S

WIN 18-17.24

E (Gene: Check bank)

POT =$75

A (Gene: Start new set of numbers)

25.28 BET?

0 R/S

LOSE - 15-25.28

and so on.

Note: I'm not worried about the language of "losing" $0. That's a win in reality, but I didn't want to make this game any longer than it is.

Enjoy.

(10-28-2016 01:28 PM)Gene Wrote: [ -> ]Your game of 26 is great and does not take much space Consider it included!

Thank you, but wait for the combined 26/36 program.

It's nearly finished and only requires some testing.

Edit: here it is. Try it and see if you find any errors or other things you would like to have changed.

Major parts of the code have been rewritten, e.g. to make sure it does not stop with pending subroutine calls. Also the random number generator has been improved. The program uses R00...05, so SIZE 006 is sufficient. Wins and losses of both games, "26" and "36", sum up in one common bank total. I made the game of "36" a bit more challenging in that the user now has to stop his sequence exactly in the second the summed score is displayed, i.e. you have just one second to decide whether to continue or not (by pressing the "0" or "." key). ;-)

Here is a sample session:

Code:

`XEQ "G2636" SEED?`

0,12345 [R/S]

BANK $0,00

Play a game of "26".

Choose 4 as your number.

4 [A]

4365462324

3245265322

1123433545

5342233261

6542162331

6414663321

3544316143

3452424615

2615443465

1441262663

2451544355

4361541344

1635621155

28 TIMES

WIN $1,00

BANK $0,75

Play a game of "36", place a bet of $10.

You go first.

10 [B]

5...9...15...20...26...27...31...33...

Stop here. Type "0" or "." as soon as the "33" is displayed.

Now it's the calculator's turn:

5...10...13...19... 21...27...33

The calculator stops here with the same score as you.

It decided not try one more roll. So this time there is no winner.

WIN $0,00

BANK $0,75

Now let the calculator go first.

Bet $10 again.

10 [C]

3...8...11...12...13...17...20...24...26...30...33

The calculator stops here.

Now it's your turn:

4...8...11...12...18...21...25...29...35

Press "0" now!

This time your score (35) is higher, so you win:

WIN $10,00

BANK$ 10,75

If you would have dared one more roll the score would have grown to 40

and you would have lost ("PAY $10,00").

The current bank total can be displayed with [D].

Any errors or suggestions?

Dieter

(10-28-2016 03:50 PM)Gene Wrote: [ -> ]Hope to get this into the 4K rom.

Be sure to include a CF 29 first. ;-)

Dieter

Thanks - forgot about the CF29. :-)

On the game of 36, how about having the program display HP: XX You:YY as either the player or the HP is rolling ? My version of "36" does that and it makes it more fun to play, IMO. I don't think it will take that much extra space. It looks very good!

I'm hoping we can squeeze all of these into a 4K space.

I hope to get a 4K done and then if we can find enough good material not already present in existing 41 series games and if there is enough interest here :-) perhaps a second 4K image. I'd rather do that than wait to get an 8K put together.

(10-28-2016 09:00 PM)Gene Wrote: [ -> ]On the game of 36, how about having the program display HP: XX You:YY as either the player or the HP is rolling ? My version of "36" does that and it makes it more fun to play, IMO. I don't think it will take that much extra space. It looks very good!

No problem – 335 vs. 309 bytes.

Here it is.

Dieter

Ok, so here are the 14 files that are candidates for the 4K HP 67 games rom. The .zip file linked to below contains the .raw files for the programs.

Angel - don't take these just yet :-)

4K HP67 games rom .raw files
Games include:

1130

FollowMe

26/36

Golf

Battleship

ChuckaLuck

Artillery

Chess

JiveTurkey

Lander

One Arm Bandit

SpaceWar

Star Trek

TicTacToe

Of those, I think Golf and Artillery could use some extra review. If my math is correct, these take 3778 bytes as shown (I shortened a few global labels). That leaves about **278** free bytes to either use to drop another game in or to make some of these games a bit more friendly.

I am hoping to get this sent off to Angel very soon. He is a very patient guy especially with me!

thoughts ?

This is an AOS (algebraic operating system) program for the HP 41 from an original written by Jim Horn (Hi Jim!) found on my website here:

http://rskey.org/gene/calcmuseum/67aos.htm
with a link to the original PPC Journal program listing here:

HP-67 AOS
I wonder if my use of flag 2 rather than 22 has messed this up for number entry (possibly) or something else I have not quite done right. I don't understand the last two steps either.

here's the .raw file.

AOS .raw file
here's the text listing:

Code:

`01 LBL "AOS" `

02 LBL a

03 CF 01

04 CF 02

05 CF 03

06 CLRG

07 12

08 STO 23

09 -1

10 STO 24

11 CLX

12 RTN

13 LBL A

14 61

15 GTO 00

16 LBL B

17 51

18 GTO 00

19 LBL C

20 42

21 GTO 00

22 LBL D

23 32

24 GTO 00

25 LBL b

26 14

27 GTO 00

28 LBL c

29 23

30 GTO 00

31 LBL d

32 5

33 LBL 00

34 10

35 /

36 STO 22

37 INT

38 X!=0?

39 GTO 00

40 FS? 01

41 XEQ 03

42 LBL 00

43 RDN

44 FS?C 03

45 XEQ 02

46 RCL 22

47 RDN

48 FS?C 03

49 XEQ 02

50 RCL 22

51 INT

52 X=0?

53 GTO 00

54 RCL 24

55 X<0?

56 GTO 00

57 STO 25

58 RCL IND 25

59 FRC

60 RCL 22

61 FRC

62 X>Y?

63 GTO 00

64 RCL IND 25

65 INT

66 X!=0?

67 XEQ 01

68 LBL 00

69 RCL 24

70 1

71 +

72 STO 24

73 STO 25

74 13

75 X<=Y?

76 ASIN

77 RCL 22

78 STO IND 25

79 RCL 23

80 STO 25

81 RCL IND 25

82 CF 01

83 GTO B

84 LBL e

85 1

86 STO 22

87 X<>Y

88 FS?C 03

89 XEQ 02

90 RCL 24

91 X<0?

92 SQRT

93 STO 25

94 RCL IND 25

95 INT

96 X=0?

97 GTO A

98 XEQ 01

99 GTO e

100 LBL A

101 RCL 24

102 1

103 -

104 STO 24

105 RCL 23

106 STO 25

107 RCL IND 25

108 SF 01

109 GTO B

110 LBL E

111 1

112 STO 22

113 X<>Y

114 FS?C 03

115 XEQ 02

116 RCL 24

117 X<0?

118 GTO 00

119 STO 25

120 RCL IND 25

121 XEQ 01

122 GTO E

123 LBL 00

124 RCL IND 25

125 XEQ a

126 RDN

127 RDN

128 SF 03

129 GTO b

130 LBL 02

131 21

132 RCL 23

133 1

134 +

135 STO 23

136 STO 25

137 -

138 X<0?

139 SQRT

140 RDN

141 STO IND 25

142 RCL 22

143 INT

144 X!=0?

145 RTN

146 LBL 03

147 RCL 24

148 1

149 +

150 STO 24

151 STO 25

152 4.2

153 STO IND 25

154 RDN

155 RDN

156 RTN

157 LBL 01

158 RCL 23

159 1

160 -

161 STO 23

162 STO 25

163 RCL IND 25

164 ISG 25

165 LBL 10

166 RCL IND 25

167 R^

168 STO 25

169 RDN

170 XEQ IND 25

171 RCL 23

172 FS? 02

173 10

174 FC?C 02

175 0

176 +

177 STO 23

178 STO 25

179 13

180 -

181 X<0?

182 SQRT

183 X<>Y

184 STO IND 25

185 RCL 24

186 1

187 -

188 STO 24

189 RTN

190 LBL 01

191 Y^X

192 RTN

193 LBL 02

194 CHS

195 LBL 00

196 SF 02

197 RTN

198 LBL 03

199 /

200 RTN

201 LBL 04

202 *

203 RTN

204 LBL 05

205 CHS

206 LBL 06

207 +

208 LBL B

209 RTN

210 SF 03

211 END

If we can get this working and if it will fit, I'd like to include it in the HP 67 4K rom file.

Help!

(10-29-2016 06:37 PM)Gene Wrote: [ -> ]Ok, so here are the 14 files that are candidates for the 4K HP 67 games rom. The .zip file linked to below contains the .raw files for the programs.

(...)

26/36

...

There is a new version of the 26/36 game. Version G2636z now is down to 308 bytes as some duplicate steps in the "36" program could be saved and a bit of optimizing was done. I also did a slight change of the calculator's strategy in that it now risks another roll if the score is up to and including 33 (before: 32). After all at this point there is a 50:50 chance to succeed. ;-)

Dieter

(10-30-2016 02:11 AM)Gene Wrote: [ -> ]I wonder if my use of flag 2 rather than 22 has messed this up for number entry (possibly) or something else I have not quite done right.

I haven't checked your listing but the 67/97's data entry flag 3 is equivalent with the 41's flag 22. So SF 3, CF 3 and F? 3 become SF 22, CF 22 and FS?C 22.

BTW, this sequence...

Code:

`171 RCL 23 `

172 FS? 02

173 10

174 FC?C 02

175 0

176 +

177 STO 23

...will not work either. This adds 10 or 0. The original program adds EEX 0 = 1 (!) if flag 2 is set (or 0 otherwise). On the 41 you could do it this way:

Code:

`171 RCL 23 `

172 1

173 FC?C 02

174 CLX

175 +

176 STO 23

- or with one stack level less -

171 RCL 23

172 FS?C 02

173 ISG X

174 LBL 09

175 STO 23

And there are more errors. For instance steps 047...050 are duplicating the ones before and have to be removed, or a GTO B turned into GTO b.

Addendum:
(10-30-2016 02:11 AM)Gene Wrote: [ -> ]I don't understand the last two steps either.

Maybe I got the idea behind this. The (second) label B at line 217 of the original program seems to be the common endpoint where the result is displayed. The instructions say that here a [R/S] will re-enter a value calculated by a function that was not part of the program, e.g. sqrt or log. This [R/S] will then set flag 3 and quit (c.f. the last two instructions) so that subsequent operations accept the result as a new entry.

I now have a corrected version for the '41 but it still does not work quite right. So there's still something left to do. And I'm sure the 41 version can get shorter than the original as storage arithmetics is available for R23 and R24, and because not just R25 can be used for indirect addressing.

Dieter

(10-30-2016 02:11 AM)Gene Wrote: [ -> ]This is an AOS (algebraic operating system) program for the HP 41 from an original written by Jim Horn (Hi Jim!) found on my website here:

(...)

If we can get this working and if it will fit, I'd like to include it in the HP 67 4K rom file.

Help!

Here is a first version that seems to work. Try 1+2x3^4 and get 163. I replaced two duplicate labels A and B, otherwise the program is essentially unchanged. And that's why this definitely will not be the final version. There is a lot that can be done more efficiently. But now try this first attempt and see if it works.

Dieter

Thanks, sorry but I was traveling today. I quickly typed in the program as best I could last night and wanted to get it posted here. I will look it over. I have also invited the original author, Jim Horn, to come take a look here. :-)

Wow, Gene, you were able to translate the code from the original Neanterthal...

The '67/97 AOS program was an early attempt to squeeze a flowcharted algorithm for algebraic entry parsing from a Fortran class I took in the spring of 1972, just to see if I could do it. The same issue includes an article describing it. And a later one should have a correction as the textbook I got the flowchart from was in error which I dutifully embodied in the code. Sigh - some things don't change.

The program was terribly useless as it was really, terribly slow. Of course, a '41CL would be lightning fast, eliminating that problem. As mentioned by others, the '67/97 flag functions differed compared to the '41 so that needs to be dealt with.

Some of the oddities (why EEX 1 instead of 10, etc.) were due to tricks in the '67's timing. They were done as they were faster, not more readable(!). Since the '67 had a fixed number of registers, I put the index registers at the (known) top worked a stack down from there. The '41's reconfigurable memory would allow a stack to work up with the SIZE value being the only limit.

As I recall, each function was encoded into a function stack as a two digit number. The INT(value/10) was the function value (each function had a distinct value to allow branching later); the units digit was a priority level - the higher the value, the higher priority which took precedence over the lower values. Thus addition would be held until multiplication was done, etc. If I recall, the book/flowchart/algorithm/'67 program bug was that once a higher priority operation could be done, it was popped from the stack and evaluation continued. Instead, it should have looked to see if the next item down the stack was due for evaluation and, if so, do so until either the stack was empty or priorities indicated otherwise. The later version corrected this.

Dedicating an entire register to hold an operator stack value is terribly inefficient but that's all I was able to squeeze into 224 steps. A '41 ROM that has more room for code could consider doing binary packing a whole lot more efficiency. But then again, who needs hundreds of levels of parentheses? Even the most enthusiastic AOS fan would pale at the prospect!

Ah, the days of spending hours and hours to save a millisecond or byte. It wasn't practical but was terrific mental exercise! Best wishes to all who wish to dig into such paleosoftware! Since my rather modified '67 went to a good home decades ago, I have nothing to run this on. Will have to check out the various simulations out there.

Not me. Dieter is the coding expert here.

Never did see a NOP in the PPJCJ anyplace.

(10-30-2016 11:33 PM)Jim Horn Wrote: [ -> ]The program was terribly useless as it was really, terribly slow. Of course, a '41CL would be lightning fast, eliminating that problem.

A standard '41 already runs 3x as fast as the 67/97, and there are several things that can be done shorter and faster. But still...

(10-30-2016 11:33 PM)Jim Horn Wrote: [ -> ]Some of the oddities (why EEX 1 instead of 10, etc.) were due to tricks in the '67's timing. They were done as they were faster, not more readable(!).

I wonder if 1/10 s or less makes a difference when a routine runs for about 10 seconds.

But you can also find "E" instead of "1" in some HP41 programs. #-)

(10-30-2016 11:33 PM)Jim Horn Wrote: [ -> ]Since the '67 had a fixed number of registers, I put the index registers at the (known) top worked a stack down from there. The '41's reconfigurable memory would allow a stack to work up with the SIZE value being the only limit.

Yes, that's an obvious choice which I have been thinking about. But this requires a better understanding of the program. ;-)

(10-30-2016 11:33 PM)Jim Horn Wrote: [ -> ]As I recall, each function was encoded into a function stack as a two digit number. The INT(value/10) was the function value (each function had a distinct value to allow branching later); the units digit was a priority level - the higher the value, the higher priority which took precedence over the lower values.

Ah, good, that's how I thought it would work. This priority check is done in step 064...064. The lowest level is 0, assigned to the "(" function.

(10-30-2016 11:33 PM)Jim Horn Wrote: [ -> ]Dedicating an entire register to hold an operator stack value is terribly inefficient but that's all I was able to squeeze into 224 steps. A '41 ROM that has more room for code could consider doing binary packing a whole lot more efficiency.

I think this would get way too slow.

(10-30-2016 11:33 PM)Jim Horn Wrote: [ -> ]Ah, the days of spending hours and hours to save a millisecond or byte. It wasn't practical but was terrific mental exercise! Best wishes to all who wish to dig into such paleosoftware! Since my rather modified '67 went to a good home decades ago, I have nothing to run this on. Will have to check out the various simulations out there.

A really good one was recently developed in this forum by "Panamatic".

But now let me ask a few questions about your program:

As already posted, I think that the (second) label B near the end of the program is the point where all routines stop and the result is displayed. Pressing [R/S] at this point will set flag 3 and thus simulate a new data entry, as mentioned in the instructions. Is this correct?

As far as I can tell the CHS function requires this additional [R/S]. A simple [f][c] after a calculation does not change the sign of the result. At least it does not in my translated '41 program, only another [f][c] does it. Is this the intended behaviour?

BTW, why did you use label A and B twice? There are other unused labels available, e.g. 8 and 9.

Finally, could you say something about the use of flags 1 and 2? What are they used for?

Dieter

As of now, we are at 4094 bytes for this 4K rom. To cover the overhead of the FAT, etc., we need to be down to around 4050 or so. We need to trim about 45 bytes.

I was thinking of changing the labels to 2-3 characters. TTT probably needs to stay TTT, but SPW67 could go to SPW (saves two bytes) and ST67 could be ST (2 more), etc.

These are the games / programs targeted to be included in the first 4K rom.

G2636

1130

CH41c

GOLF

F67

CHK

BSP

SPW67

ST67

ART

OAB

JT

TTT

ML

AOS

(10-31-2016 07:36 AM)Dieter Wrote: [ -> ]But now let me ask a few questions about your program:

As already posted, I think that the (second) label B near the end of the program is the point where all routines stop and the result is displayed. Pressing [R/S] at this point will set flag 3 and thus simulate a new data entry, as mentioned in the instructions. Is this correct?

As far as I can tell the CHS function requires this additional [R/S]. A simple [f][c] after a calculation does not change the sign of the result. At least it does not in my translated '41 program, only another [f][c] does it. Is this the intended behaviour?

BTW, why did you use label A and B twice? There are other unused labels available, e.g. 8 and 9.

Finally, could you say something about the use of flags 1 and 2? What are they used for?

Dieter

Hello, Dieter!

An honor to have you looking at my old program. I'll dig into it and try to remember exactly what's going on with it, flags and all. Will try to answer you questions later tonight (tomorrow in Europe). Best to you!

A few findings for the '67 version: Flag 1 marks an implied multiplication. If an open parenthesis isn't preceded with an operator, a multiplication is assumed. So "5(3+7)" or "(1+2)(3^5)" will both work.

Flag 2 is to prevent a operand stack drop after negation (i.e. a unary operator only takes one operand, not two, so the operand stack doesn't get smaller). The LBL 0 before the SF 2 (original line 204) was if other unary operators needed that but was never used - no room for square root, inversion, etc.

The arcsine and square roots are to throw errors if a stack tries to shrink below having no entries. Crude but they work.

When this was written, there was a sometimes heated exchange going about the relative merits of RPN versus inferior (oops, excuse me) alternative entry systems. In coding the textbook algorithm, I decided to add implicit multiplication, automatic parenthesis closure and such to make the resulting system as efficient as possible. That RPN was still significantly more efficient still was not surprising. I'm still so used to it that alternatives are painful for me to use (though Mathematica is pretty nifty!).

Ok, here are the candidates for inclusion in the first HP-67 4K games rom for the HP-41.

Link to zip of .raw files - 15 of them
If my math is correct, these add up to 4047 bytes, which is SEVEN bytes shorter than we have to have! Woohoo. Lol.

If Dieter manages to shrink the AOS program even a little bit, I will go back and give all the programs 3 letter program labels.

Please look these .raw files over.

**Pages:** 1 **2** 3 4 5 6 7 8 9 10