4K HP 67 Games rom attached for testing

[Dieter]

(11-01-2016 10:00 PM)Gene Wrote:  The rom could include a label that uses the PASN functions to assign the AOS global labels as an initialization routine. Don't have a 41CX? then don't use that label. :-) Or if nothing else, running it would simply produce an error.

I think this may be omitted.

(11-01-2016 10:00 PM)Gene Wrote:  I had thought these assignments:

Labels +, -, * and / to the corresponding keys.
Label = to the ENTER key.
Label YX to the Y^X key.
Labels < and > to the X<>Y and RDN key. (these <> characters are shift I and J in alpha).

X<>Y and RDN are fine since these keys are not used in AOS mode.

(11-01-2016 10:00 PM)Gene Wrote:  I thought shift backarrow for CLR and CHS itself for CHS. This would be user mode only so if you want to do the CHS real function switch out of user mode. Where else would you put the CHS assignment ?

Maybe Shift CHS.
But first we should be sure the CHS routine is working as it is supposed to.

(11-01-2016 10:00 PM)Gene Wrote:  I might take a swing at the easier golf program. I think that's a good thing to consider?

Do you have the 41 version of Golf that you referenced ?

Sure, here it is. It's essentially a 1:1 translation of the original 67/97 version.

Dieter

[Gene]

Here's your Golf game with a bit of alpha. I think this plays a bit more fun.

Feel free to optimize :-)

Golf 2

[Ángel Martin]

Guys, there are two different approaches and both use the Time Module one way or another:

1. The SandMath implementation uses two functions, SEEDT and RNDM, and a buffer to store the seed. The seed can be entered manually or by the Time Module if the user inputs zero.
This requires a buffer to store the seed. The succesive values of RNDM are calculated using the stored seed, by means of the "popular algorithm" . The calculated RNG becomes the new seed.

2. the other implementations uses a simpler approach that only requires one function (RAND) and no buffer since there's no seed. The Time module is always used to come up with the suitable seed "on the fly" using the current time - no more, no less. This approach I have used already in the FUNSTUFF and several other modules...

I think we should use the latter approach for simplicity and as far as I can tell equivalent results.

Hope this helps, it's actually quite simple.

[Dieter]

(11-02-2016 06:50 AM)Ángel Martin Wrote:  Guys, there are two different approaches and both use the Time Module one way or another:

If the Time Module is required for this implementation of an RNG, this – IMVHO – is not an option. I think the planned ROM should be useable in any standard 41C/CV.

(11-02-2016 06:50 AM)Ángel Martin Wrote:  1. The SandMath implementation uses two functions, SEEDT and RNDM, and a buffer to store the seed. The seed can be entered manually or by the Time Module if the user inputs zero. This requires a buffer to store the seed.

OK. But is does this buffer require the Time Module? Or is it possible to store the last random number (i.e. the seed for the next one) somewhere in a standard 41? I assume the new ROM itself cannot be used for this since it's, well, a ROM (read-only).

So there is a simple question: Since a usual RNG calculates the next random number from the previous one the latter has to be stored somewhere. Is there a way to store a number in a "safe place" within a standard 41? Or: is the buffer that's now used in Sandmath for this also possible with the upcoming Games ROM without any additional hardware?

In other words: is it possible to store a number "somewhere" in a standard '41 with only the Games ROM plugged in? If not, we could reserve a regular data register for this, e.g. R00, and adjust the programs accordingly.

(11-02-2016 06:50 AM)Ángel Martin Wrote:  I think we should use the latter approach for simplicity and as far as I can tell equivalent results.

I'd prefer the former version since it allows to set a seed so that results can be reproduced for test purposes.

Dieter

[Dieter]

(11-02-2016 01:45 AM)Gene Wrote:  Here's your Golf game with a bit of alpha. I think this plays a bit more fun.

Feel free to optimize :-)

Done. Here's a version with 194 instead of 205 bytes.
Also replaced "FEET" with "FT" to avoid "1 FEET" messages.

Dieter

[Ángel Martin]

The time module has nothing to do with the buffer. Buffers are created in RAM by any module, so the 67GAMES could also do that - but this is getting too complicated so I'll suggest we do a standard routine that prompts the user for the seed and stores it in a regular data register. Then it's up to the program to use that seed and apply any pseudo-random algorithm to come up with a RND value.

[Gene]

Got it.

Angel, we will continue on the path of having each program use a random number generator. Easiest thing to do. No problem!

Should be done with this soon!

[Gene]

Ok, link to the (final?) .zip of .raw files for the first 4K HP 67 games rom.

zip of raw files

One last check before we bother Angel again? :-)

Includes these games / files:

2636 - game of 26/36
1130 - game of 11-30
CH - HP67 chess by Valentin
GF - Golf
F67 - Follow Me
CHK - Chuck-a-luck
BSP - Battleship
SP - Space War
ST - Star Trek
ART - Artillery
OB - One Arm Bandit
JT - Jive Turkey
TTT - Tic-Tac-Toe
ML - Moon Lander
AOS - Algebraic Operating System
SD - Sum of the digits (this is new)

[Gene]

Ah, not quite the final. I found a NOP report on the AOS program by Jim Horn (as he thought there had been).

NOP corrections to AOS program

Here's my version of the AOS raw file with the corrections made. I think I did them correctly. I also realized there is no need for a separate CLR or CL label (Clear). The AOS label itself can simply be the global label for "clear". LBL AOS LBL a SF 27 etc. This saves some bytes. It is at 350 bytes now.

AOS

I still don't think this addresses the CHS functionality that we question. I would think "CHS" would make + or - but it seems to do nothing.

With all of these changes, I think we have 11 spare bytes if my math is correct at the moment. I've asked Angel to confirm. :-)

[Dieter]

(11-02-2016 07:00 PM)Gene Wrote:  I still don't think this addresses the CHS functionality that we question. I would think "CHS" would make + or - but it seems to do nothing.

It seems to work after another CHS call. Try it and press f C a few times. ;-)
There seems to be something wrong with the stack pointer management. Maybe Jim can help here.

(11-02-2016 07:00 PM)Gene Wrote:  This added FIVE bytes so we are four over.

I just modified the Golf file which saves four bytes. 8-D

Just move the ISG 04 CLA sequence from its position after LBL 04 to LBL 03. Then the same commands after LBL E can be omitted. Also replace the STO 04 ST- 04 at the beginning by a simple CLX  STO 04.

(11-02-2016 07:00 PM)Gene Wrote:  I have cut FIVE bytes from SPW (SpaceWar). I cut two ADV instructions in there and shortened two alpha messages by one character each (DAYS is now DYS and TRPDO is now TORP). The label is now SP not SPW. That's five!

These modifications are not necessary if Golf is modified in the mentioned way.
ADV is useful if a printer is connected. Remember: VIEW and AVIEW messages appear on the printer.

(11-02-2016 07:00 PM)Gene Wrote:  I think edited the new Golf program to replace 'space (a single space put in alpha) before an ARCL with a CLA. This happened twice before displaying distance and how many shots it took to finish a hole. This saved two more bytes.

Again, this is not required. I think the output looks much better if a message with a numeric value does not start at the very left border. Insert a space an the number shows up in the position where it usually is displayed in manual calculations. So Gene, please leave this as it is.

I am sure that - if required - we can save much more than just three or four bytes, and this without affecting the user interface at all.

BTW there seems to be an issue with the Golf program. Usually the displayed distance is positive (in yards) and it decreases as you approach the hole. However, if you overshoot (ball lands beyond the hole) the calculated distance becomes negative and will decrease further with every shot, but since the absolute value is displayed the distance seems to increase... #-)

Dieter

[Gene]

Ok, heard back from Jim. Here's what he said:

===============================================
Remember, you're essentially entering an algebraic statement. "1+2x3"
gives 7, but "1+2x3~" doesn't make any sense. The final "~" means
"negative..." but there's nothing to get the negative of.It's not like
"CHS", the RPN change-sign function. So it has to precede whatever value
it applies to. Isn't algebraic grand?

So ~(1+2)x3 should work, as should 3~(1+2), where the ~ negates the (1+2)
and there's an implicit multiply after the 3, so it's treated as
3x(-1x(1+2)). I don't have the program running so I can't check if that
works. It should also work for numeric entry: 5/~4 should return -1.25 if
it's OK.
===============================================


Gene: And it works the way he describes. 5 / chs 4 = gives -1.25. I think we are ok.


I have updated Golf with your byte saving suggestions. Great catch. I also put back in the leading space in two places. We have room for it now :-) and it does look nicer, I agree.

The original Golf write-up describes the putting behavior. If you are one foot away from the cup but put in a really high force for the put, the ball goes past the hole and instead of a negative number displayed, it switches to positive as you observe. This is intended per the original write-up.

Link to updated .zip file here:

zip file of raw files

If my math is correct, we have 13 spare bytes, so I think we are good.

[Dieter]

(11-02-2016 08:40 PM)Gene Wrote:  Ok, heard back from Jim. Here's what he said:
===============================================
(...)
So it has to precede whatever value it applies to. Isn't algebraic grand?

So ~(1+2)x3 should work, as should 3~(1+2), ...
5/~4 should return -1.25 if it's OK.
===============================================

*facepalm* #-)

(11-02-2016 08:40 PM)Gene Wrote:  Gene: And it works the way he describes. 5 / chs 4 = gives -1.25. I think we are ok.

OK. So if you want to use global labels for this program this function should not be named CHS, maybe something like NEG would be better.

(11-02-2016 08:40 PM)Gene Wrote:  The original Golf write-up describes the putting behavior. If you are one foot away from the cup but put in a really high force for the put, the ball goes past the hole and instead of a negative number displayed, it switches to positive as you observe. This is intended per the original write-up.

Fine. But this doesn't make it better. #-)
Of course this can be changed, but this would significiantly increase the byte count.

Dieter

[Jim Horn]

Thank you, Gene and Dieter! I never expected to see the AOS program running again after all these years.

Now that it's in '41 form, it would be trivial for anyone to extend it to handle as many functions as desired and assign them to the '41s USER keys, making it act like an AOS machine. To add new functions, each would be assigned an alpha label, an integer ID number and a priority level. Each alpha label would be followed by the ID concatenated with the priority level and a GTO 00. At the end, each would have a LBL (id number), the function itself, a SF 00 if it takes a single operand, and a RTN. Assigning all the functions' alpha labels to the corresponding '41 keys in USER mode would complete the lobotomy, oops, I mean, the transformation.

Of course, this wouldn't fit in the proposed ROM but might be fun to play with, especially with one of the fast 41CL or emulated machines. Will have to give that a try - I've got Thomas Okken's fantastic Free42...

[Gene]

(11-02-2016 09:02 PM)Dieter Wrote:  OK. So if you want to use global labels for this program this function should not be named CHS, maybe something like NEG would be better.

Dieter

Gene: I like it. LBL NEG it is.


and thanks to Jim for this delightful program from the past. At full speed on an i41cx iPhone emulator it is pretty reasonable. :-)

Can't wait to see it on a 41CL at TURBO50.

[Dieter]

(11-02-2016 03:42 PM)Gene Wrote:  Ok, link to the (final?) .zip of .raw files for the first 4K HP 67 games rom.

So "SPW" is out?

I'm asking because I found something that might be an error or not. Take a look at the LBL 00 routine starting at line 107. A counter in R05 is set to zero and then increased if the input matches R20, ... R23. This is done with an ISG command followed by CLX, but these CLXes are never executed as they will always be skipped. So the program compares R20 with R21, R21 with R22, ... etc. Is this how it is supposed to work? After looking at the original Games Pac code (page L06-02) I'm still not sure. For me it looks like the original '67 program also has an error here.

Dieter

[Gene]

SPW is still in. It is just called SP now. It will be included.

I'll take a look at the behavior you mention. Probably best to load it up on a real HP 67 and compare too.

[Gene]

(11-02-2016 09:33 PM)Dieter Wrote:  I'm asking because I found something that might be an error or not. Take a look at the LBL 00 routine starting at line 107. A counter in R05 is set to zero and then increased if the input matches R20, ... R23. This is done with an ISG command followed by CLX, but these CLXes are never executed as they will always be skipped. So the program compares R20 with R21, R21 with R22, ... etc. Is this how it is supposed to work? After looking at the original Games Pac code (page L06-02) I'm still not sure. For me it looks like the original '67 program also has an error here.

Gene: At a first glance, it does not appear to be the same. In the original, LBL 1 recalls 10 and adds it to memory 5. Robert's port adds 1 to memory 5 for a alglog detection using ISG and after the scan, multiplies the total by 10. That is fine, but the CLX is always skipped by the ISG (problem because we don't have an INCrement instruction.

A fix is to change the instruction after the ISG 05 to a true NOP and then the CLX. That will add 4 ? bytes, but that's ok we have them to spare.

[Dieter]

(11-02-2016 09:49 PM)Gene Wrote:  Gene: At a first glance, it does not appear to be the same. In the original, LBL 1 recalls 10 and adds it to memory 5. Robert's port adds 1 to memory 5 for a alglog detection using ISG and after the scan, multiplies the total by 10. That is fine, but the CLX is always skipped by the ISG (problem because we don't have an INCrement instruction.

Now look at the original '67 code. Here a subroutine is called that adds 10, but on return this "10" still is in X on the stack (!). Then the CLX commands clear X, which may be this 10 or the value of R20/21/22..., depending on whether the increment routine was called or not. Looks a bit strange to me.

(11-02-2016 09:49 PM)Gene Wrote:  A fix is to change the instruction after the ISG 05 to a true NOP and then the CLX. That will add 4 ? bytes, but that's ok we have them to spare.

This should work if the code is supposed to increment R05 each time the input matches R20, R21, R22... etc. If this is what the routine should do the '67 version is buggy as well, and the ST+5 commands in line 147 and 151 should be followed by a RDN. But maybe there is another very clever reason why they are not, and I am simply unable to see it. #-)

Dieter

[Gene]

Hmm. I checked the errata / NOP listings for all the HP-67 games pac programs and there were no changes to the SpaceWar program.

I do see what you mean, but sadly my real HP 67 card reader is not reading cards tonight. :-(

I also can't figure out how to email the cards to my RPN-67 SD emulator.

So, I'm a bit stuck.

[Dieter]

(11-03-2016 02:33 AM)Gene Wrote:  Hmm. I checked the errata / NOP listings for all the HP-67 games pac programs and there were no changes to the SpaceWar program.

I do see what you mean, but sadly my real HP 67 card reader is not reading cards tonight. :-(

Well, there is a way to get a printed listing into an HP67... ;-)
On the other hand... do you also have a 41 with card reader ?-)

But do we have to know how the original program behaves? If it really has a bug here it's not how the 41 version should behave. Looking at the listing I'd say that the routine at LBL 0 returns the number of Alglogs (that's what the comment says) by comparing the input with register A, B and C (Alglog positions), adding 10 for each match. If this is correct, the routine is buggy.

BTW, the program does not seem to use the secondary registers, so R20...25 can be replaced by R10...15. Maybe I'll post a reviewed version that you can test.

Regarding the random number generator: here is an overview that shows which programs use a RNG with or without a seed prompt:

Code:

Prog   RND?  SEED?
------------------
2636   R00    yes
ST     ---    ---
ART    R00    yes
ML     ---    ---
OB     R01    no
CH     ---    ---
BSP    R03    yes
JT     R02    no
SPW    R09    yes
GF     R00    yes

The ones that do not use R00 can be easily modified so that a common RNG routine for all programs is possible. However, I am not sure if this saves memory. How many bytes does a call like XEQ"R" require? The simple frac(x+pi)² generator is merely 6 bytes...

Finally, I just did another BSP version with a bit more friendly output ("you win / "you lose"), requiring 174 bytes (compared to 173 for the current version) including a "SEED?" prompt. There also is a (very) slightly different version with just 164 bytes.

Dieter