HP Forums

(02-14-2020 12:23 PM)J-F Garnier Wrote: [ -> ]A version 2b will come out soon, in a couple of weeks, with enhancements of the matrix function set.
I didn't want to spend a version letter for such an insignificant correction - nobody noticed it, right? :-)
And you know, I may need much more than 26 (or 52 with lowercase letters) versions if I start using one for each minor change, see how many builds were produced for Free42 or newRPL.

J-F

Great news JFG!! I did not expect continued improvements, so indeed you are right about version increments.

Another option would be to adopt the trend of versioning to something like Ver X.Y.Z.A.B.C

X new feature
Y change to API
Z bug correction
A artwork revision
B code change but no functional impact
C change in wind direction

On second thought, maybe not...

(02-14-2020 12:23 PM)J-F Garnier Wrote: [ -> ]A version 2b will come out soon, in a couple of weeks, with enhancements of the matrix function set.

So here is, a few weeks late, a test version 2b1 with the following enhancements:
- addition of the AMAX/AMIN/MAXAB/MINAB and SUM/ABSUM array functions
- implementation of the AROW/ACOL functions

Users of the HP75 Math ROM and Series 80 Matrix ROM will recognize the array min/max and sum functions, and the AROW/ACOL functions provide the same functionality than resp. the individual RNORMROW/AMINROW/AMAXROW/MAXABROW and CNORMCOL/AMINCOL/ AMAXCOL/MAXABCOL of the Series 80 Matrix ROM.

I started to write a HP71 Math Pac 2 Owner's Manual Supplement, à la mode des HP71 Owner's Manuals, you will find all the details in this document.

This is not the final Math Pac 2 development, I'm now working on new MAT statements.

Enjoy!

J-F

Hello HP71 fans and HP Basic friends,

I released an update of the Math ROM 2 test version (now 2b2). It adds 3 new MAT statements taken from the HP75, Series 80 and Series 200/300 Basic: MAT ... CROSS, MAT ... CSUM and MAT ... RSUM.
With this version, I'm getting closer and closer to the HP75 Math ROM features (one of my goals with this project).

Adding new MAT statements was not trivial. The Math ROM was not designed to do so, and the simple idea to just add the needed keywords and execution code was causing serious compatibility problems. I found a way to overcome these problems, I will document it in a future article.

I know it's very late to propose a new MATH ROM version, after more than 35 years, and that the community interest may be limited. Technically I could have done it 10 or 15 years ago, I had all the tools but it's only now that I have the time to do it (reversing the Math ROM is VERY time consuming). Anyway, it's a great project for me and gives me a lot of fun ! A good part of the fun is to write the manual in the HP style of the time.

A little challenge for you : during my tests I found a minor problem in some of the new keywords of the previous test version (2b1, see post above). I didn't fix it yet (so still in 2b2, will fix it in a later version) and your mission, would you accept it, is to find the problem...
It's not a major problem, it will not crash your HP71 nor make your big engineering calculations completely fail, but still this is not fully correct and so it may be called a bug.
Hint: the HP75 and Series 80 don't have (and *can't* have) the same problem with these keywords...

Have fun !

J-F

(04-27-2020 09:42 AM)J-F Garnier Wrote: [ -> ]Hello HP71 fans and HP Basic friends,

I released an update of the Math ROM 2 test version (now 2b2). It adds 3 new MAT statements taken from the HP75, Series 80 and Series 200/300 Basic: MAT ... CROSS, MAT ... CSUM and MAT ... RSUM.
With this version, I'm getting closer and closer to the HP75 Math ROM features (one of my goals with this project).

Adding new MAT statements was not trivial. The Math ROM was not designed to do so, and the simple idea to just add the needed keywords and execution code was causing serious compatibility problems. I found a way to overcome these problems, I will document it in a future article.

I know it's very late to propose a new MATH ROM version, after more than 35 years, and that the community interest may be limited. Technically I could have done it 10 or 15 years ago, I had all the tools but it's only now that I have the time to do it (reversing the Math ROM is VERY time consuming). Anyway, it's a great project for me and gives me a lot of fun ! A good part of the fun is to write the manual in the HP style of the time.

A little challenge for you : during my tests I found a minor problem in some of the new keywords of the previous test version (2b1, see post above). I didn't fix it yet (so still in 2b2, will fix it in a later version) and your mission, would you accept it, is to find the problem...
It's not a major problem, it will not crash your HP71 nor make your big engineering calculations completely fail, but still this is not fully correct and so it may be called a bug.
Hint: the HP75 and Series 80 don't have (and *can't* have) the same problem with these keywords...

Have fun !

J-F

I'm not so deep in mathematics, but I like your enthusiasm with developing the math modul to the next step. Maybe it makes me more curious to get more in touch with the matrix functions.
THANKS for your great work and share it with us.

Erwin

I just released the latest revision (2b5) of the Math Pac 2 with the long-awaited complex DET function. This function was one of main missing features of the original Math Pac, together with the missing complex inverse trig/hyper functions.

This release also includes a nice little feature suggested by Valentin Albillo to reduce the number of keystrokes when using the INTEGRAL and FNROOT functions.
Now, instead of typing (for instance)
INTEGRAL(0,1,E,IVAR^3-IVAR^2+IVAR+2)
you can just type:
INTEG(0,1,E,IX^3-IX^2+IX+2)

With these additions, the Math Pac 2 reaches the BETA stage, meaning that I will no more add features and will wait for more tests and possible feedbacks before promoting it to the final 2B version.

It's not the end of the Math Pac 2 project, I already have several ideas for future enhancements and it is (very) possible that there will be a version 2C later, but it will not be before several months because I have other projects to complete first.
Also Valentin made several proposals that go well beyond my initial project goals, they may be part of an "Advanced Math Pac" later on.

The Manual Supplement for the Math Pac 2B is available here.

J-F

      
Hi, Jean-François:

(08-08-2020 09:37 AM)J-F Garnier Wrote: [ -> ]I just released the latest revision (2b5) of the Math Pac 2 with the long-awaited complex DET function.

Great !   Way to go !

Quote:Also Valentin made several proposals that go well beyond my initial project goals, they may be part of an "Advanced Math Pac" later on.

For interested people, this is a direct link to the PDF article describing in detail my proposals, click it to see or download:

                  HP-71B Math Pac 2 Comments and Proposals.

Best regards and enjoy your summer vacations (careful with the crownbug, though).
V.

The HP-41 series had a gaussian random number generator with the PPC rom routine GN. It is only sensible that the HP-71B have one in the enhanced math LEX !

A neat normal random number generator can be done using the Box-Muller transform. It gives two normal values from two uniform but it's okay to toss one away.

Pauli

(08-08-2020 10:14 PM)Valentin Albillo Wrote: [ -> ]Lambert W function...

However, though every worthy math package includes it (though called ProductLog in Mathematica) to this
day no calculator has a button to compute it, so let’s right this wrong and implement it in the Math Pac 2.

The WP 34S has this and AGM


Pauli

(08-09-2020 10:10 AM)Paul Dale Wrote: [ -> ]A neat normal random number generator can be done using the Box-Muller transform. It gives two normal values from two uniform but it's okay to toss one away.

Pauli

But the Marsaglia polar method is faster because it does not require trig functions.

(08-08-2020 10:14 PM)Valentin Albillo Wrote: [ -> ]      


For interested people, this is a direct link to the PDF article describing in detail my proposals, click it to see or download:

                  HP-71B Math Pac 2 Comments and Proposals.

I strongly second the request for a SORT command. As far as scalar functions I would also like to see the LOGGAMMA function which returns LN(Gamma(x)) accurately for large values of x.

.
Hi, John:

(08-09-2020 02:16 PM)John Keith Wrote: [ -> ]

(08-08-2020 10:14 PM)Valentin Albillo Wrote: [ -> ]For interested people, this is a direct link to the PDF article describing in detail my proposals, click it to see or download:

                  HP-71B Math Pac 2 Comments and Proposals.

I strongly second the request for a SORT command. As far as scalar functions I would also like to see the LOGGAMMA function which returns LN(Gamma(x)) accurately for large values of x.

Having such functions available would be nice, John, but consider that only 5 Kb are available for implementing all enhanced capabilities, thus we can't fit everything that comes to mind, only the absolutely most generally useful functions and only if they don't take too many bytes to implement, some of which are the ones (22, all fiiting in about 3.5 Kb) that my proposal addresses.

Just for instance, Sorting is a generally useful functionality for most everyone, and frequently used. On the other hand, your proposed LogGamma is a very specialized function useful to a handful of people, and rarely used.

In other words, we can't go and suggest every fancy function or functionality under the sun, a fair amount of pondering is mandatory to select the most useful, affordable functionalities, which is just what I did in my proposal. I didn't select the first functions that came to mind or that I personally liked the most, but instead I carefully pondered what would be the most generally useful while still affordable.

There's also the fact that Jean-François is the one who will have to use tons of his free time to do the implementation, not an easy or enjoyable task, so a further restriction is to select functionalities that aren't too hard and/or time-consuming to implement in assembler, out of deference and respect for J-F.

This means that, for non-trivial functionalities, it's mandatory to supply J-F with the full algorithm, highly-optimized (but simple) working code and comprehensive sample results, for he to just first convert it to assembler and afterwards check the assembler results vs. the working code and the sample results, for correctness.

This I'm willing to provide for each of my 22 proposed keywords.

Regards.
V.

(08-08-2020 09:37 AM)J-F Garnier Wrote: [ -> ]I just released the latest revision (2b5) of the Math Pac 2 with the long-awaited complex DET function. This function was one of main missing features of the original Math Pac, together with the missing complex inverse trig/hyper functions.

This release also includes a nice little feature suggested by Valentin Albillo to reduce the number of keystrokes when using the INTEGRAL and FNROOT functions.
Now, instead of typing (for instance)
INTEGRAL(0,1,E,IVAR^3-IVAR^2+IVAR+2)
you can just type:
INTEG(0,1,E,IX^3-IX^2+IX+2)

With these additions, the Math Pac 2 reaches the BETA stage, meaning that I will no more add features and will wait for more tests and possible feedbacks before promoting it to the final 2B version.

It's not the end of the Math Pac 2 project, I already have several ideas for future enhancements and it is (very) possible that there will be a version 2C later, but it will not be before several months because I have other projects to complete first.
Also Valentin made several proposals that go well beyond my initial project goals, they may be part of an "Advanced Math Pac" later on.

The Manual Supplement for the Math Pac 2B is available here.

J-F

Hello,

quite impressive work ... I will try the new ROM and the features, although with old programs. Today I wanted to install it in exchange of the original ROM in my FRAM71 kit on D0000 so overwrite the old mathrom. I POKEd the IRAM identifier in D0000 but it doesn't run when I tried to copy the LEX file in this port - it ends in an error. Don't want to keep it in memory cause then it is parallel to the old one.
So how can I change it without starting the whole procedure with the FRAM71 again or destroy the actual configuration?
So do you have any idea what I'm doing wrong?

Thanks in advance
Erwin

(08-10-2020 08:21 PM)Erwin Wrote: [ -> ]Today I wanted to install it in exchange of the original ROM in my FRAM71 kit on D0000 so overwrite the old mathrom. I POKEd the IRAM identifier in D0000 but it doesn't run when I tried to copy the LEX file in this port - it ends in an error. Don't want to keep it in memory cause then it is parallel to the old one.
So how can I change it without starting the whole procedure with the FRAM71 again or destroy the actual configuration?
So do you have any idea what I'm doing wrong?

Thanks in advance
Erwin

After removing the ROM and re-configuring that FRAM Port as RAM, did you FREE PORT (5.0x) to convert it to IRAM?

If so, can you copy files there and see them with CAT :PORT(5.0x), and find free space using MEM(5.0x)?

Once you can do the above things, the new LEX file should be OK.

(08-10-2020 09:42 PM)rprosperi Wrote: [ -> ]

(08-10-2020 08:21 PM)Erwin Wrote: [ -> ]Today I wanted to install it in exchange of the original ROM in my FRAM71 kit on D0000 so overwrite the old mathrom. I POKEd the IRAM identifier in D0000 but it doesn't run when I tried to copy the LEX file in this port - it ends in an error. Don't want to keep it in memory cause then it is parallel to the old one.
So how can I change it without starting the whole procedure with the FRAM71 again or destroy the actual configuration?
So do you have any idea what I'm doing wrong?

Thanks in advance
Erwin

After removing the ROM and re-configuring that FRAM Port as RAM, did you FREE PORT (5.0x) to convert it to IRAM?

If so, can you copy files there and see them with CAT :PORT(5.0x), and find free space using MEM(5.0x)?

Once you can do the above things, the new LEX file should be OK.

Hi,

thanks I think I did some mistyping ... Now in the 3rd run it was successful. Here is how I did it in the end - in my case original mathrom is in Port(5.01) on adress D0000:

First tests were running

best regards
Erwin

(08-11-2020 02:47 PM)Erwin Wrote: [ -> ]... Now in the 3rd run it was successful. Here is how I did it in the end - in my case original mathrom is in Port(5.01) on adress D0000:

Code:

POKE "D0000","B3DDDDDE" ... set RAM identifier
POKE "2C004","95" ... config as RAM in the FRAM71
On/off
FREE PORT(5.01)
COPY MATH2B5:TAPE TO :PORT(5.01)
POKE "D0000","00000000" ... remove RAM identifier
POKE "2C004","D5" ... config as ROM
On/off
VER$ ... recognized Math:2b

Just for information, the POKEs to D0000 have no significant effect. The first POKE to D0000 does nothing as the memory is initially ROM. You can verify this by PEEKing D0000. The second POKE to D0000 to remove the IRAM identifier has no significant effect for two reasons.

1. A ROM can run with an IRAM identifier - look at the Finance ROM.
2. The file copied to PORT(5.01) is a LEX file (I presume) which runs just fine in an IRAM.

Dave

EDIT: The fourth byte of a ROM contains a checksum, so by POKEing zeros to D0000 you're likely invalidating the checksum. See the ROMCOPY doc.
https://drive.google.com/file/d/0B-GPxmp...sp=sharing

(08-11-2020 04:24 PM)Dave Frederickson Wrote: [ -> ]

(08-11-2020 02:47 PM)Erwin Wrote: [ -> ]... Now in the 3rd run it was successful. Here is how I did it in the end - in my case original mathrom is in Port(5.01) on adress D0000:

Code:

POKE "D0000","B3DDDDDE" ... set RAM identifier
POKE "2C004","95" ... config as RAM in the FRAM71
On/off
FREE PORT(5.01)
COPY MATH2B5:TAPE TO :PORT(5.01)
POKE "D0000","00000000" ... remove RAM identifier
POKE "2C004","D5" ... config as ROM
On/off
VER$ ... recognized Math:2b

Just for information, the POKEs to D0000 have no significant effect. The first POKE to D0000 does nothing as the memory is initially ROM. You can verify this by PEEKing D0000. The second POKE to D0000 to remove the IRAM identifier has no significant effect for two reasons.

1. A ROM can run with an IRAM identifier - look at the Finance ROM.
2. The file copied to PORT(5.01) is a LEX file (I presume) which runs just fine in an IRAM.

Dave

EDIT: The first 8 nibbles of a ROM contain a checksum, so by POKEing zeros to D0000 you're likely invalidating the checksum. See the ROMCOPY doc.
https://drive.google.com/file/d/0B-GPxmp...sp=sharing

Thanks for your kind feedback Dave,

I didn't check it - my fault, sorry for this ... so I would have seen that there is no change. The invalid checksum was not in my mind so I have to be more precise in the future. I think in this case it was not a problem cause of the FREE PORT I did.
The second part I want to "mark" it as ROM (like the original MATHROM) so it is consistent to my other module definitions except my playground that is IRAM and RAM (I wrote in another thread here) - but of course in this special case its only a LEX file and not a ROM image so I could let it stay in IRAM (thanks for correction) till it is in the final state. So in principe when it's an IRAM I only have to make a purge and a copy for e new release of the MATHROM2. So for now I'll let it stay as an IRAM :-)

best regards from Vienna
Erwin

Hi Erwin,

If the goal is to configure FRAM71 with a Math ROM image I would normally suggest using the binary image, however, the binary image in the Math 2b distribution pack is NOT a ROM image but an IRAM image. So, if you want to try loading an image into FRAM71 using ROMCOPY you'll need to create a ROM image.

You can do this starting with the IRAM image, TITANCHK, and a hex editor. Knowing that the checksum for the first 16k is in byte 4 and the checksum for the last 16k is the last byte, you can manipulate the image to pass TITANCHK and load it using ROMCOPY. Then you should convert the RAM to ROM by POKEing the FRAM71 config string.

Dave

(08-11-2020 05:17 PM)Dave Frederickson Wrote: [ -> ]Hi Erwin,

If the goal is to configure FRAM71 with a Math ROM image I would normally suggest using the binary image, however, the binary image in the Math 2b distribution pack is NOT a ROM image but an IRAM image. So, if you want to try loading an image into FRAM71 using ROMCOPY you'll need to create a ROM image.

You can do this starting with the IRAM image, TITANCHK, and a hex editor. Knowing that the checksum for the first 16k is in byte 4 and the checksum for the last 16k is the last byte, you can manipulate the image to pass TITANCHK and load it using ROMCOPY. Then you should convert the RAM to ROM by POKEing the FRAM71 config string.

Dave

Thanks a lot Dave … so I have to try to find a Windows PC for that … I‘ll try it the next time and will report the result here.

regards
Erwin

(08-13-2020 07:35 AM)Erwin Wrote: [ -> ]

(08-11-2020 05:17 PM)Dave Frederickson Wrote: [ -> ]Hi Erwin,

If the goal is to configure FRAM71 with a Math ROM image I would normally suggest using the binary image, however, the binary image in the Math 2b distribution pack is NOT a ROM image but an IRAM image. So, if you want to try loading an image into FRAM71 using ROMCOPY you'll need to create a ROM image.

You can do this starting with the IRAM image, TITANCHK, and a hex editor. Knowing that the checksum for the first 16k is in byte 4 and the checksum for the last 16k is the last byte, you can manipulate the image to pass TITANCHK and load it using ROMCOPY. Then you should convert the RAM to ROM by POKEing the FRAM71 config string.

Dave

Thanks a lot Dave … so I have to try to find a Windows PC for that … I‘ll try it the next time and will report the result here.

regards
Erwin

You should be able to do this with a Mac or Linux machine. I'll spin off a new thread and give you the details.

Dave