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