4K HP 67 Games rom attached for testing

[Dieter]

(10-31-2016 04:19 PM)Gene Wrote:  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.

No problem. There is much room for savings and improvements. The AOS program alone will probably save the required bytes.

(10-31-2016 04:19 PM)Gene Wrote:  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.

I think there is no need to do so.

BTW...

(10-31-2016 04:19 PM)Gene Wrote:  These are the games / programs targeted to be included in the first 4K rom.

G2636
1130
CH41c
...

The "CH41c" does not relate to the calculator, it's just version "c" of the CHess program for the 41. So the label is simply "CH". Or "CHESS";-)

Dieter

[Gene]

Ooops. I think you replied to an older message. :-)

See the more recent post that has all the current .raw file versions for the rom.

[Dieter]

(10-31-2016 07:04 PM)Gene Wrote:  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.

Here is a new version of the AOS program. From 346 bytes of the first version it is now down to 299 bytes. I did not do much testing, so please, Gene, do your own tests and see if it works correctly before it gets included in the new ROM.

(10-31-2016 07:04 PM)Gene Wrote:  Please look these .raw files over.

There is no way to review raw files unless you convert them to human-readable text listings. That's why I include both in my zips. Gene, having to convert 14 raw files to text before they can be evaluated maybe is ...a bit too much.

EDIT / IMPORTANT NOTE:
The original attachment had one step too much (a STOP command used for debugging). Here is the corrected version, with 1 byte less (298 bytes). Please use only this newer version for testing.

Dieter

[Gene]

Sorry. I thought you were loading them up into an emulator.

I will post the .txt versions of these later tonight. I really don't TRY to make things hard on people. :-)

Thank you for all your help here. I'll look over the AOS rom tonight.

[Gene]

and here is a link to *most* of the games in the rom as text listings.

Single Word document with all of them pasted into it.

Word doc

[Dieter]

(10-31-2016 09:58 PM)Gene Wrote:  and here is a link to *most* of the games in the rom as text listings.

Single Word document with all of them pasted into it.

Word doc

That's not a .doc file, but an XML-based .docx file as it is used by newer Word versions which I do not have.
But who needs a Word file? What about a simple ASCII text file ?-)

Dieter

[Dieter]

(10-31-2016 09:51 PM)Gene Wrote:  Thank you for all your help here. I'll look over the AOS rom tonight.

I just noticed that the original zip file contained a version with a step too much (a STOP command that I used for debugging). Please be sure to download the modified AOS_2.zip version from the edited post.

So it's 298 bytes now. ;-)

Dieter

[Gene]

Got it.

Here's the link to the .txt file. Sorry about that.

text files of programs for the 4K HP 67 Games rom

[Dieter]

(10-31-2016 11:49 PM)Gene Wrote:  Got it.

Here's the link to the .txt file. Sorry about that.

Hmmm... in a simple text editor I see a lot of "Ê" characters instead of spaces, and just the G2636 program – in a somewhat scrambled version that looks like a mix of various versions. I'm not sure what this is, but it sure doesn't look like a regular text file. ;-)

BTW... since this is a ROM module with various games that mostly use random numbers: what about one common random number generator with a global label that can be called from any program? Maybe Àngel even has some MCode RNG that could be used here? I think it does not make much sense to include, say, ten separate RNGs in ten different programs. A seed function could also be added.

Dieter

[Gene]

Ugh. Ok, try these.

RFT text file

or

PDF version


I will ask Angel about a common RNG. I know he has a RNG in mcode. Would have to perhaps add a LBL RNG step in each program where a call to the mcode RNDM function should be placed and then depend on his forbearance again. :-)

[Dieter]

(11-01-2016 12:12 AM)Gene Wrote:  Ugh. Ok, try these.

Gene, with some "search and replace" and features of notepad++ I was able to generate a standard text file which is attached here. Here are my comments.

Chess: The file contains the original version that prestores all moves in 25 data registers. I recently posted a shorter version that requires just one single data register, using the same output format as the original program. There also is a version that displays moves in a more readable form (cf. here). That's the "CH_41c" version. Post #5 has the version with simple HP67-style output attached ("CH_41").

Space War: I am not sure about the memory usage of this program. Are all 26 registers used? At the first glance I only see registers up to 9 and then 20...25.

Golf: I think it's quite difficult to translate the original 67/97 version. Especially the "print stack" function should be replaced by something different, for instance labelled output. Also some other improvements can be applied (e.g. the last eight steps are simply 9 ST/24 ST*21).

(11-01-2016 12:12 AM)Gene Wrote:  I will ask Angel about a common RNG. I know he has a RNG in mcode. Would have to perhaps add a LBL RNG step in each program where a call to the mcode RNDM function should be placed and then depend on his forbearance again. :-)

I think a common RNG would be great. This and a SEED function that allows to reproduce a given sample game. Which also means that all "Seed?" prompts and the respective routines can be removed. And of course these functions could be used for further user-programmed games as well.

The games included in the ROM would simply call the RNG instead of their own code. This can be changed easily without much effort.

Dieter

[Gene]

Dieter, thanks again for looking these over. More than one set of eyes is always good. Even with the PPC ROM, a bug remained where the BE routine had a GTO BE near the end instead of a GTO local label. I am nowhere NEAR as clever as all those people were.

Re: Chess. I really thought I HAD included the labeled chess program, but obviously I did not. It is in the folder properly now.

Re: Golf. This is one I have really spent very little time on so far. I put in the "STACK" prompt where the print stack functions were as a placeholder, but it could really use some improvement. :-)

Re: Space War - all of the secondary registers are used in LBL A for the Short Range Scan.

Re: Common RN generator. I have spoken with Angel and the RNDM mcode function he uses can be put into these programs relatively easily if I edit them and put the TIME function (placeholder as an XROM instruction to be replaced with the XROM for the RNDM function call). As to the storing of a SEED, that's a bit more problematic. If we use the seed Angel uses (he takes it from the Time Module functionality in the 41CX) then these won't play on a 41C or 41CV. That may mean it is best to leave the seed storing label in the games. What do you think ?

Re: AOS. I had a crazy idea here but it would take up too much space. If you put in global alpha labels such as LBL +, LBL = and LBL CHS, etc., then the functionality of this could be assigned to the 41C keys and while in USER mode, the machine would work nearly as an AOS style machine. Assign = to ENTER and voila. However, that takes a LOT of memory space which is tight. Still, it makes it much more fun than having to press 1/x for subtraction. :-)

[Dieter]

(11-01-2016 08:09 PM)Gene Wrote:  Re: Golf. This is one I have really spent very little time on so far. I put in the "STACK" prompt where the print stack functions were as a placeholder, but it could really use some improvement. :-)

OK then.

(11-01-2016 08:09 PM)Gene Wrote:  Re: Common RN generator. I have spoken with Angel and the RNDM mcode function he uses can be put into these programs relatively easily if I edit them and put the TIME function (placeholder as an XROM instruction to be replaced with the XROM for the RNDM function call).

Does this RNDM function use some kind of internal register that stores the current random number from which the next one is calculated? Or does it work differently so that a random number is generated in another way, i.e. not based on the previous value, so that no special memory that holds the previous random number is required? In this case a SEED function would not be possible.

In other words: how exactly does RNDM work?

If everything else fails we could define a common register (e.g. R00) for all games where the last random number is stored, and a dedicated RDNM routine would calculate the new random number from this value (and store it there again).

(11-01-2016 08:09 PM)Gene Wrote:  As to the storing of a SEED, that's a bit more problematic. If we use the seed Angel uses (he takes it from the Time Module functionality in the 41CX) then these won't play on a 41C or 41CV. That may mean it is best to leave the seed storing label in the games. What do you think ?

That depends on the way RNDM works. ;-)
How does it generate its (pseudo) random numbers?

(11-01-2016 08:09 PM)Gene Wrote:  Re: AOS. I had a crazy idea here but it would take up too much space. If you put in global alpha labels such as LBL +, LBL = and LBL CHS, etc., then the functionality of this could be assigned to the 41C keys and while in USER mode, the machine would work nearly as an AOS style machine. Assign = to ENTER and voila.

That's not a crazy idea at all – this is exactly how I use my version of the AOS program on V41. ;-) I was about to suggest the same idea.
However, you should not assign the CHS routine to the CHS key since it's required for regular data entry

(11-01-2016 08:09 PM)Gene Wrote:  However, that takes a LOT of memory space which is tight.

Memory? There is so much room for improvement and more efficient memory usage (consider the chess program) that this should not be much of an issue. But is there a way to automatically assign these routines to the respective keys or will the user have to do this manually? And if even this is not possible, we simply can define a user-code function "R" that does this, which is then called from the different programs.

Dieter

[Gene]

The RAND or RNDM (I think I've seen it spelled both ways in different modules) function is used in Angel's Sandmath rom. Taken from his manual:



"It’s a little known fact that the SandMath module also uses a buffer to store the current seedUU used for random number generation. The buffer id# is 9, and it is automatically created by SEEDT or RAND the first time any of them is executed; and subsequently upon start-up by the Module during the initialization steps using the polling points.

SEEDT will take the fractional part of the number in X as seed for RNG, storing it into the buffer. If x=0 then a new seed will taken using the Time Module – really the only real random source within the complete system.

RAND will compute a RNG using the current seed, using the same popular algorithm described in the PPC ROM - and incidentally also used in the CCD module’s function RNG."

[Gene]

Ok, so on the other comments:

Golf - Care to take a swing at that one? It's from the HP-67 games manual and is very complicated compared to the easy golf program on my webpage here:

HP-67 golf

That would certainly take less space and less brain power to play. But, if we are going to keep the one that is in here now from the 67 games pac... would you care to take it on? I'm not sure the size can be shrunk that much given that it really needs alpha outputs on the STACK commands. Maybe the smaller version should be put in here to make room for ...

the LBL + and LBL = etc. in the AOS program ? Adding in those labels takes 55 bytes plus 20 bytes for the extra FAT overhead (so 75 total) before making use of PASN to assign these to the keys. The rom had 44 spare bytes so we are short. That's why I'm wondering about changing to the easier GOLF game.

?


And speaking of the AOS program, from a CLR state, should 5 XEQ c result in a -5 showing? When I type 5 then XEQ c I see a 5 showing. If I do an XEQ c again, it shows -5 at that point. ?

[Dieter]

(11-01-2016 08:49 PM)Gene Wrote:  "It’s a little known fact that the SandMath module also uses a buffer to store the current seedUU used for random number generation.

OK, I now have found this in the Sandmath manual. But is this buffer a special Sandmath feature or would this also be possible in the new Games ROM?

(11-01-2016 08:49 PM)Gene Wrote:  SEEDT will take the fractional part of the number in X as seed for RNG, storing it into the buffer. If x=0 then a new seed will taken using the Time Module – really the only real random source within the complete system.

So the Time Module is only required if x=0. In this case the module generates a "true", maybe time-based random number, initializing the RNG similar to a "randomize" function in other programming languages. This is not required for the Games ROM, so if x=0 the seed may simply be set to zero. So the time module should not be required.

(11-01-2016 08:49 PM)Gene Wrote:  RAND will compute a RNG using the current seed, using the same popular algorithm described in the PPC ROM - and incidentally also used in the CCD module’s function RNG."

Please forgive my ignorance, but I do not know which "popular algorithm" is meant here. How does it work?

Dieter

[Gene]

The algorithm is: New Seed = Fraction ( 9821 x Old Seed + 0.211327 )

Used in the PPC ROM and many earlier programs in the PPC Journal. Has a longer cycle between repeating and doesn't have the problems that the RCL 00 PI + style generators do. The algorithm of New Seed = Fraction (997 x Old Seed) is pretty good as well.

Angel and I had already been talking about saving a bit of space by using the mcode function here so I think it would be available and work.

Remember, this is the first 4K module. I know there are more games that can go into a second rom, but I'm hoping that this first rom will be born soon. :-)

[Dieter]

(11-01-2016 08:52 PM)Gene Wrote:  Golf - Care to take a swing at that one? It's from the HP-67 games manual and is very complicated

Yes, I tried a translation some time ago but I was not satisfied with the result, so I finally gave up on this.

(11-01-2016 08:52 PM)Gene Wrote:  ...compared to the easy golf program on my webpage here:

That's an easy one. I already did a 41 version some time ago. In that thread I wrote:

"The Games Pac version sure is much, much more sophisticated. Maybe a bit too sophisticated for the limited memory of the 67/97 (some actions require the user to store values manually in certain registers). But changing this would come close to a more or less rewritten version for the 41."

And that's what I still think.

(11-01-2016 08:52 PM)Gene Wrote:  Maybe the smaller version should be put in here to make room for ...

the LBL + and LBL = etc. in the AOS program ? Adding in those labels takes 55 bytes plus 20 bytes for the extra FAT overhead (so 75 total)

That's not so much that it could not be done. ;-)

(11-01-2016 08:52 PM)Gene Wrote:  before making use of PASN to assign these to the keys.

PASN requires a CX or a X-Functions module, so I think using this function is not an option here.

(11-01-2016 08:52 PM)Gene Wrote:  And speaking of the AOS program, from a CLR state, should 5 XEQ c result in a -5 showing? When I type 5 then XEQ c I see a 5 showing. If I do an XEQ c again, it shows -5 at that point. ?

That's what I observed, too. I think if you want to enter –5 simply press 5 CHS as you would normally do on an HP calculator. But still the "CHS" function of the AOS program does not work as I would have expected. That's why I mentioed this point in my reply to Jim's post.

Dieter

[Gene]

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

Labels CLR and CHS to ?
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 ?

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 ?

[Dieter]

(11-01-2016 09:37 PM)Gene Wrote:  The algorithm is: New Seed = Fraction ( 9821 x Old Seed + 0.211327 )

OK, that's the one I know from my first HP calculator's manual, the 34C.
But this RNG can only generate about one million different values.

(11-01-2016 09:37 PM)Gene Wrote:  Used in the PPC ROM and many earlier programs in the PPC Journal. Has a longer cycle between repeating and doesn't have the problems that the RCL 00 PI + style generators do.

What problems does this algorithm have?

(11-01-2016 09:37 PM)Gene Wrote:  The algorithm of New Seed = Fraction (997 x Old Seed) is pretty good as well.

But it requires a seed with a fractional part > 0.

(11-01-2016 09:37 PM)Gene Wrote:  Angel and I had already been talking about saving a bit of space by using the mcode function here so I think it would be available and work.

Does this mean we will have a RAND function (as well as SEED)?

Dieter