HP-15C expanded memory firmware: problems with matrix larger than 8x8

[brouhaha]

Alternate firmware for the 15C to provide more user memory has existed since 2005. I did early work on this, and Hrast Programmer and J-F Garnier found additional necessary code changes that I missed. J-F Garnier posted the latest version of our mod, supporting 192 registers (plus registers 0, 1, and I) in the forum back in July. These patches have been used in simulation (e.g., Nonpareil), as well as on the 15C Limited Edition. Also, Swissmicros has versions of firmware for their DM15 and DM15L calculators that probably contain similar patches.

A 15C with extended memory can handle matrices with more than 64 elements, including square matrices larger than order 8. Unfortunately the 15C cannot properly do matrix division, inversion, or compute the determinant of matrices larger than order 8. Attempting these operations can yield incorrect results, or even hang the calculator. J. Fossy Weinzinger determined (as quoted in the Swissmicros Voyager User Manual, Appendix B) that this is due to the way the 15C firmware computes the LU decomposition of the matrix. In the process, the firmware may interchange rows of the matrix, and it records the row interchanges in three extra bits in the diagonal elements of the matrix. Unfortunately there are only three such bits available, so the calculator can only indicate an interchanged row offset for up to eight rows.

Fixing this problem would be rather difficult, and although I have an idea for where to store additional bits, I haven't analyzed enough of the code to even begin to code it. It's also not certain that there aren't other problems with the LU decomposition of order 9 and larger matrices waiting to be discovered even if the row interchange problem is fixed. However, I could change the code that tests for square matrices, which generates an Error 11 if the matrix is non-square, to also generate the Error 11 if the matrix is square but larger than order 8.

If I generate 15C firmware for extended memory with 192 registers (plus R0, R1, and I), that has the patch described, would anyone care to test it? I would provide the patched firmware as a text file as used with Nonpareil. People have used the Nonpareil files with other simulators, or on the HP-15C LE, but I am not able to provide the instructions for doing that, or support for doing it, therefore this is only recommended for people already experienced with dealing with 15C firmware on their platform.

The main things that need to be tested are:
* whether the patch interferes with any matrix operations that DO NOT involve dividing, inverting, or computing the determinant of a matrix larger than order 8
* whether the patch interferes with any other 15C functionality (unlikely)

[J-F Garnier]

Ouch ! You frightened me Eric with your post subject. I thought you found a new problem in the expanded memory firmware.

Fixing the known problem with matrix larger than 8x8 and operations involving the LU decomposition would be nice for sure, even if I'm not sure there is a real practical need for it.

For me, the main benefit of the expanded memory versions is that we don't have any practical memory limitation.

With the standard 64-register version, using two 4x4 matrices leaves only 14 registers for programming, but not even enough for integration.
With the 192-reg expanded version, we can have two matrices up to 8x8 (128 reg.), use the complex mode (5 reg.) and the solve&integrate features (23 reg.), and still have 18 registers (126 bytes) for a non-trivial program.

However, your idea to trigger Error 11 in case of a matrix > 8x8 is interesting, it would protect unaware users from potentially bad consequences.
This would be consistent with the other minor limitations of the extended versions:
- we can't allocate more than 99 storage registers,
- we can't create a matrix with more than 99 elements in a row or column,
both cases that trigger Error 10 and so are harmless.

It remains the (IMHO minor) bug with program steps beyond 999 , especially step 1000 that is displayed as: " 000-000000"
Any way to limit the steps to 999?

[Edit:]
While we are at it, it would be nice to improve the MEM display for configurations with more than 99 free/program registers.
Currently, this is displayed with my patch as, e.g. " 19164 10-0" or " 19 64110-0"
Not so difficult to read when we are used to it, but may be confusing for new users.
It would be nice to add a '.' separator such as " 19.164. 10-0" or " 19. 64.110-0"
but I didn't try to do it at the time.

J-F

[brouhaha]

(01-11-2023 01:15 PM)J-F Garnier Wrote:  It remains the (IMHO minor) bug with program steps beyond 999 , especially step 1000 that is displayed as: " 000-000000"
Any way to limit the steps to 999?

It would be easier to limit it to 994 steps. I'll look into that.

[brouhaha]

The patch for square matrices larger than order 8 to generate an Error 11 instead of an incorrect result or hang is available here:
http://www.brouhaha.com/~eric/hpcalc/hp1...atch.xhtml

[Giorgio]

I wanted to try this patch to generate an Error 11, but I noted a discrepancy.
The original data (before patching) should be 000 at addresses 13F9-13FD, but I found different data in the original ROM:

13F9:08B
13FA:0E5
13FB:2D3
13FC:2C6
13FD:0F5

Did I miss something?

[brouhaha]

(07-03-2024 09:32 AM)Giorgio Wrote:  I wanted to try this patch to generate an Error 11, but I noted a discrepancy.
The original data (before patching) should be 000 at addresses 13F9-13FD, but I found different data in the original ROM:

13F9:08B
13FA:0E5
13FB:2D3
13FC:2C6
13FD:0F5

Did I miss something?

Those value are most definitely not from an "original" 15C ROM. Those contents were in the modified 15C ROM distributed with Nonpareil until two years ago, which bears my copyright, is not open-source, and is not authorized for use in anything other than Nonpareil.

I suggest you get a proper dump of the original 15C ROM. One can be found in the Nonpareil github repository.

If you can't use the true original HP-15C ROM, for instance, if you're trying to use it on modern hardware that requires a modified ROM, then it should be OK to make the patch even though those five locations were not zero.

[Giorgio]

I found those non-zero values in the HP-15C Limited Edition ROM, and I just checked that the same values are also in the HP-15C Collector Edition ROM.

It is not obvious to me how I could test your patch using the original 15C ROM. But since you confirmed that it is OK to overwrite non-zero data at these addresses, I have flawlessly patched my 15C CE and the PC emulator of the 15C LE that I am using regularly.

If acceptable, it would certainly be useful if HP/Moravia could embody this patch in a future upgrade of the 15C CE firmware.

[brouhaha]

(07-06-2024 04:46 PM)Giorgio Wrote:  Thanks for explaining the source. I was unaware of the provenance of the 15C LE and 15C CE firmware, and had never checked it myself.

Someday perhpas I'll explain the precise detials of how the Nonpareil modified ROM images came about, but not today. The only functional difference was the shifted "r" in "running". The remaining differences were for identification, and to make the checksum for self-test come out right. At the time I didn't know which words of ROM in the Voyager claculators were the checksum adjustment, so I just added a second adjustment. More recently, I've identified (to a very high degree of confidence) whcih words of ROM were HP's checksum adjustments.