4K HP 67 Games rom attached for testing

[Gene]

I will look a bit later.

Post the BSP routine you would like included. I think we have the room.

[Ángel Martin]

(11-03-2016 02:26 PM)Gene Wrote:  I will look a bit later.

Post the BSP routine you would like included. I think we have the room.

The proof is going to be in the pudding...
In the "formula" I gave you for the space requirements I failed to factor in that FOCAL files need 3 more bytes than their actual byte count (as shown in CAT-1); so this may throw a wrench into the plans.

We'll see how it goes...

[Gene]

Ah, so add 3 bytes for each focal program as well, not just 2 bytes per label ?

If so, we have 25 global labels x 2 bytes + 3 bytes x 16 program files + 12 bytes = 110 bytes overhead.

4096 - 110 = 3986 bytes available.

Our 16 program files take 4022 bytes right now. Have to cut 36.

[Dieter]

(11-03-2016 02:26 PM)Gene Wrote:  Post the BSP routine you would like included. I think we have the room.

Here it is. There are a few minor changes: the messages are more user-friendly, there is a different RNG, the test whether the ship has moved to negative coordinates is shorter and IMHO more correct than in the original version, and I think 12 torpedos are enough. ;-)

Here is a sample game.

Code:

XEQ"BSP"             SEED?

0,777 [R/S]          TORP=12
                     SHOOT

50 [ENTER] 50 [R/S]  DIST=15,30
                     TORP=11
                     SHOOT

35 [ENTER] 45 [R/S]  DIST=8,00
                     TORP=10
                     SHOOT

35 [ENTER] 50 [R/S]  DIST=3,00
                     HITS=1
                     TORP=9
                     SHOOT

30 [ENTER] 50 [R/S]  DIST=4,47
                     HITS=2
                     TORP=8
                     SHOOT

30 [ENTER] 40 [R/S]  DIST=7,07
                     HITS=2
                     TORP=7
                     SHOOT

25 [ENTER] 40 [R/S]  DIST=2,24
                     HITS=3
                     TORP=6
                     SHOOT

20 [ENTER] 40 [R/S]  DIST=1,41
                     HITS=4
                     TORP=5
                     SHOOT

25 [ENTER] 40 [R/S]  DIST=2,24
                     HITS=5
                     *DESTROYED*

Nevertheless the program requires not more than 171 bytes.
And it now uses only R00...05 instead of ...R09.

Dieter

[Dieter]

(11-03-2016 04:27 PM)Gene Wrote:  4096 - 110 = 3986 bytes available.

Our 16 program files take 4022 bytes right now. Have to cut 36.

Should be not much of a problem.
Gene, which chess version are you planning with?

Edit:
Suppose a random number generator is used in 10 programs. It's a short one like the frac(x+pi)² version with requires merely 6 bytes plus LBL and RTN. Even if the RNG is only called once in a program and no subroutine call is necessary (best case) this occupies 6 bytes times 10 = 60 bytes. A global RNG with LBL"R" requires 12 bytes altogether, and every call with XEQ"R" requires 3 bytes. This means 12 + 3*10 = only 42 bytes. In reality the savings will be even greater since the RNG is usually called with an XEQ 09 or another numeric label. This means 10x a RNG routine with 8 bytes times 10 programs = 80 bytes. BTW XEQ 09 and XEQ"R" both require the same 3 bytes, so the global RNG calls do not require more bytes and the RNG call itself makes no difference.

A common seed function would even save more bytes since the "SEED?" text occurs only once.

Dieter

[Gene]

The chess version is the 450 byte file.

I have edited the BSP2 file to change the label to BS instead of BSP. Saves a byte. I also deleted the FIX 4 near the end and shortened *DESTROYED* to KILLED. It is now 163 bytes. That's 8 of the 36 or so we need to shave off.

[hth]

(11-03-2016 04:27 PM)Gene Wrote:  Ah, so add 3 bytes for each focal program as well, not just 2 bytes per label ?

If so, we have 25 global labels x 2 bytes + 3 bytes x 16 program files + 12 bytes = 110 bytes overhead.

4096 - 110 = 3986 bytes available.

Our 16 program files take 4022 bytes right now. Have to cut 36.

Add 2 bytes per program file (this is the COPY overhead).

Multiply global labels by 2 (for the FAT).

Other ROM overhead is 16 (for FAT, poll vectors, identity and checksum).

Then you have the header shown in CAT 2. It takes (number of characters) + 2, add 1 if you want it to RTN safely, otherwise it will crash (like HP modules tend to do) if you try to execute it.

Håkan

[RobertM]

Hi Guys. Sorry for my absence.

About the LBL 00 behavior in Spacewar:

The routine is supposed to calculate the number of Alglogs that are in the quadrant specified in X. I changed the way it worked (from the 67 version) to save bytes and registers, but it the end result is the same, and the reason for the CLX is the same.

In my version, you will notice the two branch instructions back to back (X=Y? followed by ISG). Thus if X does not equal Y (Alglog is not in this quadrant) then the CLX will happen. The reason for the CLX is to disable stack lift, so the next RCL (or number entry E1) doesn't lift the stack, thus the "target quadrant" stays in Y. If X does equal Y, the CLX doesn't happen, but both X and Y are the same "target quadrant" so the next RCL does a stack lift, but it doesn't matter ... target quadrant is still in Y for the next compare.

The original 67 routine used the CLX for the same reason (disable stack lift), but it used it for both cases (X!=Y, clears the bad Alglog quadrant, or X==Y clears the 10 left over from LBL 1).

Pretty sure this works correctly, but I could be wrong.

Hope that clears up the confusion. (Clear as mud, right?).

Also ... there was an earlier comment by Dieter that the secondary registers aren't used, but they are (indirectly) for short range scan results. Might be able to change the logic to display as generated and thus not need those registers, but that's not the way the 67 version works so I left it alone.

[Dieter]

(11-03-2016 07:23 PM)RobertM Wrote:  In my version, you will notice the two branch instructions back to back (X=Y? followed by ISG). Thus if X does not equal Y (Alglog is not in this quadrant) then the CLX will happen. The reason for the CLX is to disable stack lift, so the next RCL (or number entry E1) doesn't lift the stack, thus the "target quadrant" stays in Y.

Correct. But now assume that X (say: R21) does equal Y. Then the ISG increments the Alglog counter but the following CLX will not be executed. The next RCL 22 will lift the stack. Now X is R22 and Y holds the previously tested register. But since this is equal to the previous X the test should still work OK.

I now begin to understand how this is supposed to work and why it actually seems to be a valid solution.

(11-03-2016 07:23 PM)RobertM Wrote:  Pretty sure this works correctly, but I could be wrong.

Yes, it really works this way. Thank you for pointing in the right direction. I even tried this piece of code on a "real" HP41 and Bingo – it works.

Dieter

[Gene]

Good job Robert and Dieter!


Near as I can compute, with the 16 games planned, we are going to be over the byte count by about 60 bytes.

Rather than cut cut cut, I think we should drop the last minute addition SD (Sum of Digits). That saves 101 bytes which means we would have over 40 spare bytes in the rom.

That would allow us to add seed prompts to the programs that don't have them

- ST (Star Trek) uses register 07 for the seed but has no prompt.
- OAB (One Armed Bandit - I'll add the extra A to the label now) - will get a prompt too.
- JT (Jive Turkey) will get a prompt.


Does that sound ok? We would them go with 15 games in this first 4K HP-67 games rom.


HP-67 Games rom 2 would then be discussed. :-) What could go into that? (Yes, I know I'm a madman!)...

Sum of Digits (left out above)

New 67 games from user library
Bowling
Exterminator
Mine Field
IQ Tester
Paper Rock Scissors
Shooting Gallery

Other games that got cut perhaps.
WARI67
RCTK67
BFRUIT

[Dieter]

(11-03-2016 08:21 PM)Gene Wrote:  Rather than cut cut cut, I think we should drop the last minute addition SD (Sum of Digits). That saves 101 bytes which means we would have over 40 spare bytes in the rom.

This way the cuts may be removed. For instance the battleship program may get back its *DESTROYED* message and the FIX 4 at the end that resets the display mode back to normal. ;-)

You also wrote:

(11-03-2016 08:21 PM)Gene Wrote:  That would allow us to add seed prompts to the programs that don't have them

I still would like to see the idea of a common RNG and seed prompt realized. This would save a substantial number of bytes. All what's needed is a unified use of, say, R00 for the random number generator. The few programs that use other registers can be modified easily.

(11-03-2016 08:21 PM)Gene Wrote:  - ST (Star Trek) uses register 07 for the seed but has no prompt.

Ah, yes, this one was not on my list of programs with RNG. I now see it has a quite ...creatively implemented RNG at LBL 08. ;-)

(11-03-2016 08:21 PM)Gene Wrote:  - OAB (One Armed Bandit - I'll add the extra A to the label now) - will get a prompt too.
- JT (Jive Turkey) will get a prompt.

Now that's about a dozen programs with a seed prompt. Let's assume that's is done like this:

Code:

RCL 00  ; recall current seed, will be taken if user just presses R/S
"SEED?"
PROMPT
STO 00

That's 9 bytes times 12 occurences = 108 bytes in total. Replacing the individual prompts by an XEQ"S" yields 3 bytes times 12 = 36 bytes plus 9 bytes for the prompt routine and another 6 for LBL"S" and RTN, i.e. 51 bytes. So a common seed prompt saves 57 bytes! In the ROM this would be an XROM"S" instruction – I'm not sure about the exact byte count of such a call, but you get the idea.

Now do the same calculation with a coomon RNG routine and the savings will be even greater.

(11-03-2016 08:21 PM)Gene Wrote:  Does that sound ok? We would them go with 15 games in this first 4K HP-67 games rom.

Gene, could you provide a simple ASCII text file with all the listings that finally will be part of the ROM? There were some major changes since the last version. I am sure we even can squeeze out some more bytes.

(11-03-2016 08:21 PM)Gene Wrote:  HP-67 Games rom 2 would then be discussed. :-)

Yes: "then".
Please, let's complete the current project first before we talk about the next one.

Dieter

[RobertM]

(11-04-2016 07:45 AM)Dieter Wrote:  I still would like to see the idea of a common RNG and seed prompt realized. This would save a substantial number of bytes. All what's needed is a unified use of, say, R00 for the random number generator. The few programs that use other registers can be modified easily.

My only concern about a changing to a common RNG is that the "examples" given in original documentation will no longer work (unless the common RNG is the same as the original RNG for that game). Not a big deal, but still a bummer.

[Dieter]

(11-04-2016 06:21 PM)RobertM Wrote:  My only concern about a changing to a common RNG is that the "examples" given in original documentation will no longer work (unless the common RNG is the same as the original RNG for that game).

Yes, that's true. But some of the 41 versions already use a different RNG so that the original examples cannot be reproduced anyway. Changing the RNG makes sense here and there, for instance in the Battleship program which uses a, hm... quite unusual method. Actually the original program contains two RNGs. The new version can be shorter because of the switch to a different method.

I do not think this is a problem. The original HP67 program and the corresponding HP41 version often are so much different in input and output that the example in the original solution book / Games Pac manual doesn't help much anyway. Consider the Battleship program again: the 41 version does not display 1111111111 or 8888888888, it uses plain text output instead.

I think the new Games ROM should come with a decent new manual anyway – which of course also means new examples. :-)

Dieter

[Gene]

Ok, so here you go:

zip of HP67 games rom raw files as of 20161104 7pm central time

and

Hopeful text file of game program listings


The text listing includes the global random number generator (LBL S) which expects a seed in register 00. It uses the preferred generator. All programs need to be reshuffled to use 00 as the RN register.

The PI + style RN generators fail several randomness tests. Some seeds repeat the random numbers in a very short cycle or are not centered on a 0.5 mean, etc. A lot of work was done in the PPC Journal on these in the past. The LBL S routine shown here is the one we should use.

Once in a ROM, the XEQ S would really become a TWO BYTE XROM call. Best way to code this is to put in a TIME instruction (which will be coded as an XROM) and then Angel can find the TIME instruction and redirect it to the XROM S it should be.

Another routine LBL L (load?) should be
LBL L
RCL 00
SEED?
PROMPT
STO 00
END

Another XROM call (Let's put DATE in as the placeholder) would replace the XEQ L in the programs.

[Dieter]

Gene, thank you for the text file. This time it worked.

(11-05-2016 12:44 AM)Gene Wrote:  The text listing includes the global random number generator (LBL S) which expects a seed in register 00.

I think the obvious choice for the RNG is LBL "R", and for the seed prompt LBL "S". ;-)

(11-05-2016 12:44 AM)Gene Wrote:  It uses the preferred generator. All programs need to be reshuffled to use 00 as the RN register.

Not all programs need this reshuffle.

(11-05-2016 12:44 AM)Gene Wrote:  The PI + style RN generators fail several randomness tests. Some seeds repeat the random numbers in a very short cycle or are not centered on a 0.5 mean, etc. A lot of work was done in the PPC Journal on these in the past. The LBL S routine shown here is the one we should use.

OK. But do these mathematical properties really matter for use in game programs? Also the frac(9821x+0,211327) is slower and uses 2–3x the memory of the simple generator.

(11-05-2016 12:44 AM)Gene Wrote:  Once in a ROM, the XEQ S

...XEQ "R". ;-)

BTW for the preferred generator the seed must be positive. So there should be an ABS in the seed prompt routine.

(11-05-2016 12:44 AM)Gene Wrote:  ...would really become a TWO BYTE XROM call. Best way to code this is to put in a TIME instruction (which will be coded as an XROM) and then Angel can find the TIME instruction and redirect it to the XROM S it should be.

We can directly use an XROM xx,yy instruction. Just provide the numbers for ROM and function.

(11-05-2016 12:44 AM)Gene Wrote:  Another routine LBL L (load?) should be
LBL L
RCL 00
SEED?
PROMPT
STO 00
END

That's the seed prompt, so it's LBL "S".

(11-05-2016 12:44 AM)Gene Wrote:  Another XROM call (Let's put DATE in as the placeholder) would replace the XEQ L in the programs.

See above.

Dieter

[Gene]

Gene: LBL R and LBL S - agreed. Was a bit sleepy when I was typing.

Gene: Agreed. Some programs already use R00. Those that don't need the reshuffle.

Gene: If we are going to do the global RN routine, let's use the best. New Seed = FRC (9821 x old seed + 0.211327). A bit larger, true, but the shortest routine is not good - RCL 00 R-D FRC STO 00 produces a seemingly random seed, but it cycles too quickly. Let's stay with the 9821. :-)

The proposed XROM for this is 23. Not much uses 23 in the CL library.

I've asked Angel what XROM he expects R and S would be. When I know, I will pass along.

In the listings, I think there is one place where we have 1E2 as an instruction. Be great if that could become E2. Time to optimize one last time.

[Gene]

Ok, so here's the deal.

XROM 23,00 will be the section header. 67FUN or -67FUN (I guess it needs the dash ?

There are 15 programs. The AOS program has 9 additional labels. That's 24 labels, each of which requires a place in the FAT and an XROM. So XROM 23,01 through 23,24.

XROM 23,25 will be the SEED program.

LBL S
RCL 00
SEED?
PROMPT
ABS
STO 00
END

XROM 23,26 will be the Random Number program. Let's compromise on the shorter version here which is much better than the PI + X^2 type:

LBL R
RCL 00
997
X
FRC
STO 00
END


Please double check my counting of the programs and labels. I think they are correct. :-)

[Dieter]

(11-05-2016 10:29 PM)Gene Wrote:  XROM 23,26 will be the Random Number program. Let's compromise on the shorter version here which is much better than the PI + X^2 type:

Gene, don't get me wrong, but I really would like to have some solid facts about the problems of the frac(x+pi)² generator. Do you have a link or some other information on this?

Anyway, so let's use the frac(997x) generator which is said to be okay – provided there is a suitable seed. For obvious reasons it cannot be negative or zero, and it also should not be too small: imagine you start with 1E–20... ;-) That's why I think the user input has to be "normalized" in some way. For instance by limiting to the domain 0,1...0,9 which can be done by 0,1 + 0,8*frac(abs(x)). This is just a first idea, maybe you have a better one.

Another idea: what about using the "preferred algorithm" in an MCode routine? The seed would be taken from and finally stored in R00, just as a simple FOCAL implementation.

I am currently reviewing the individual programs. What is "F67"? Do you have a source / user instructions and an example? And also one for Chuck-a-luck?

Edit:
Now I think I know how Chuck-a-luck works. Here is an improved version that should still fit as we are saving lots of bytes due to the common RNG and seed routines. It also saves two registers (now just R00...04). How do you like it? If you think it should go into the new ROM: I just did an update that is even a bit shorter. ;-)

Dieter

[Gene]

No problem. Sorry for the delay.

Chuck-a-luck is page 16 of this HP 67 solutions book:
game chance solution book

Follow me is from the HP 67 standard pac, program 6 here:
67 std pac

I will look over the chuck-a-luck game. Good job!

For RNG comments, see a new thread. Will take it out of here and not bury it so more people can see it.

[Gene]

Dieter: Anyway, so let's use the frac(997x) generator which is said to be okay – provided there is a suitable seed. For obvious reasons it cannot be negative or zero, and it also should not be too small: imagine you start with 1E–20... ;-) That's why I think the user input has to be "normalized" in some way. For instance by limiting to the domain 0,1...0,9 which can be done by 0,1 + 0,8*frac(abs(x)). This is just a first idea, maybe you have a better one.


Gene: Well, the instructions should say to input a decimal seed between 0 and 1 that is six digits or more long. Anyone who inputs 1 E-20 as a seed deserves to have a bad game. :-)

As long as someone puts in a positive seed 0-1 with six digits it ought to be ok.

In your updated games, are you able to actually insert the proper XROMs into the listings ?