Threaded Mode | Linear Mode

**Gene** · 10-28-2016, 01:28 PM

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. :-)

Ángel Martin · 10-28-2016, 02:22 PM

(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 ;-)

**Gene** · 10-28-2016, 03:50 PM

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.

Dieter · (This post was last modified: 10-28-2016 07:59 PM by Dieter.)

(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

Dieter · 10-28-2016, 08:42 PM

(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

**Gene** · 10-28-2016, 09:00 PM

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.

Dieter · (This post was last modified: 10-28-2016 09:49 PM by Dieter.)

(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

**Gene** · 10-29-2016, 06:37 PM

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 ?

**Gene** · 10-30-2016, 02:11 AM

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!

Dieter · 10-30-2016, 03:29 PM

(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

Dieter · (This post was last modified: 10-30-2016 08:45 PM by 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

Dieter · (This post was last modified: 10-30-2016 09:58 PM by 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

**Gene** · 10-30-2016, 09:51 PM

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. :-)

Jim Horn · 10-30-2016, 11:33 PM

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.

**Gene** · 10-31-2016, 02:00 AM

Not me. Dieter is the coding expert here.

Never did see a NOP in the PPJCJ anyplace.

Dieter · 10-31-2016, 07:36 AM

(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

**Gene** · 10-31-2016, 04:19 PM

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

Jim Horn · 10-31-2016, 05:08 PM

(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!

Jim Horn · 10-31-2016, 05:51 PM

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!).

**Gene** · 10-31-2016, 07:04 PM

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.