In Search of 15C+ ROM image

[John Keith]

(07-18-2022 07:04 AM)redglyph Wrote:  ... But for me the HP-48 is easier to use, with its unlimited stack, clear matrix operations and readable programs. That series would be my first choice today for student or professional use, but I don't know if others feel the same, maybe it's just personal preference (and the HP-15 isn't far behind). Anyway I'm not convinced they'd make another one of those either.

Indeed, the only emulators I use are EMU48 and Free42/Plus42. Much as I like the HP-15 (it was my first HP), the one-line display and 10-digit precision seem dated. As neat as it was to have matrices and complex numbers in a handheld device, those features are not that convenient to use.

[ijabbott]

(07-17-2022 07:43 AM)J-F Garnier Wrote:  Maybe Eric will someday comment and maybe tell us more about the HP-15C LE story.
After all, this is history now, HP is no more in the calculator business and a re-introduction of this machine by the HP licensee is unlikely.

Here is a quote from Klaas Kuperus on the "HP Calculator Fan Club" facebook group recently: "Don’t tell anyone; they might be back…. ".

[Divasson]

For some unknown reason, after clearing the matrices with MATRIX 0 the calculator has reverted to old memory size (from 30-163 to 30-35: it kept my register allocation). It had not happened before. On and off or playing the self test did not work to restore the full memory.

I have reprogrammed it again and it works. I have tried to reproduce the error again to no avail: it still keeps the memory allocation as expected.

Has it happened to anyone of you?

[J-F Garnier]

(07-19-2022 11:14 AM)Divasson Wrote:  For some unknown reason, after clearing the matrices with MATRIX 0 the calculator has reverted to old memory size (from 30-163 to 30-35: it kept my register allocation). It had not happened before. On and off or playing the self test did not work to restore the full memory.

I have reprogrammed it again and it works. I have tried to reproduce the error again to no avail: it still keeps the memory allocation as expected.

Has it happened to anyone of you?

Are you sure you actually cleared the matrices with MATRIX 0, since the difference is just 128 registers = 2 8x8 matrices.
Maybe the MATRIX 0 keystroke bounced.
If you experiment it again, check with RCL MATRIX A etc that the matrices are actually cleared.
And you don't need to reprogram, just reset the 15C LE with the ON - sequence.

I never experimented such behavior with the (patched) HP emulator, I can't say for sure for the 15C LE since my machine is not patched, yet.

J-F

[Massimo Gnerucci]

(07-18-2022 07:36 PM)ijabbott Wrote:  Here is a quote from Klaas Kuperus on the "HP Calculator Fan Club" facebook group recently: "Don’t tell anyone; they might be back…. :-/ ".

So why you told us? :)

[dmh]

Is Olivier's commented (or anyone else's) disassembly of the 15C ROM available anywhere?

Alternatively, what's the current recommended NUT disassembler?

(07-13-2022 06:42 AM)J-F Garnier Wrote:  

(07-10-2022 02:47 PM)Stevetuc Wrote:  This is discussed in an earlier archived thread.
https://archived.hpcalc.org/museumforum/...08646.html
Olivier De Smet has produced a rom patch with 224 registers and J F Garnier one with 192 registers.
Hopefully they will make the patches available on the forum.

Not only Olivier and I. Probably Eric Smith and HrastProg were the first ones to do it around 2006. And don't forget David (SwissMicros). For various (or obvious) reasons none has been published.

So yes, I have a 192-register patched version, that I first built for my private HP-15C emulator (emu15) in 2011.
I then tried the same patch set for the HP-15C emulator for Windows from HP, and fortunately it worked well meaning that the emulator allocates enough RAM space, probably the full 256-register space.
Since the HP emulator and the physical HP-15C LE are very close (even the PSE bug is "correctly" emulated), we can guess that the HP-15C LE also allocates the full 256-register space (it would be a very small gain not to do it, and would complicate the emulator code). But of course this is not guaranteed and must be tested.

Since my 2012 message, I also patched the MEM display to have a nice display for all memory partitions, not only the initial 94-99 allocation.
I didn't release my patched HP-15C XE (eXtended Edition) emulator yet, mainly because:
- the exe file was (still is) copyright HP,
- patching the exe file corrupts the HP digital signature, which may be interpreted as a potential risk.
Now, 10 years later, and as HP-15C LE ROM images have been published here, I think I can release my HP-15C XE emulator and the corresponding patch list, for "research and education purposes only".

[Divasson]

(07-19-2022 11:45 AM)J-F Garnier Wrote:  

(07-19-2022 11:14 AM)Divasson Wrote:  For some unknown reason, after clearing the matrices with MATRIX 0 the calculator has reverted to old memory size (from 30-163 to 30-35: it kept my register allocation). It had not happened before. On and off or playing the self test did not work to restore the full memory.

I have reprogrammed it again and it works. I have tried to reproduce the error again to no avail: it still keeps the memory allocation as expected.

Has it happened to anyone of you?

Are you sure you actually cleared the matrices with MATRIX 0, since the difference is just 128 registers = 2 8x8 matrices.
Maybe the MATRIX 0 keystroke bounced.
If you experiment it again, check with RCL MATRIX A etc that the matrices are actually cleared.
And you don't need to reprogram, just reset the 15C LE with the ON - sequence.

I never experimented such behavior with the (patched) HP emulator, I can't say for sure for the 15C LE since my machine is not patched, yet.

J-F

I also wondered if that was the case since the size was the same - but both a and b matrices returned as 0 0 after the MATRIX 0 command. Like the memory space had not been reclaimed. Still, it happened only once this morning and the calculator works wonderfully before and after, otherwise.

[J-F Garnier]

(07-19-2022 03:47 PM)Divasson Wrote:  

(07-19-2022 11:45 AM)J-F Garnier Wrote:  Are you sure you actually cleared the matrices with MATRIX 0, since the difference is just 128 registers = 2 8x8 matrices.
...

I also wondered if that was the case since the size was the same - but both a and b matrices returned as 0 0 after the MATRIX 0 command. Like the memory space had not been reclaimed. Still, it happened only once this morning and the calculator works wonderfully before and after, otherwise.

Strange, but maybe worth to investigate.
Did you use other special functions that claim for free registers, such as complex mode, integrate/solve?
What kind of matrix operations did you use, roughly, if you can remember?
Any use of the MATRIX 2 and 3 operations that change the matrix size?
Did you use only two 8x8 matrices, or also a vector for system solving?
No program step at all?

J-F

[Divasson]

Hi,

At the time of the issue, I had not done any calculation with the matrices - just dimensioning them. But you're right: what I did was setting "on" the complex flag and setting it off later, but before I executed the MATRIX 0 command. That may be a cause.

[J-F Garnier]

Ok, this narrows the search for a possible problem.

Did you use the latest release ROM image (with the patch of course) with the PSE bug or a previous beta version without the PSE bug?

J-F

[Didier Lachieze]

Also if you go to the 15C LE auto test 2:C, what is the checksum displayed for the patched firmware?

[dmh]

I've patched and tested the release 15C LE firmware version (04/15/2011) and get checksum E7FFh.

I've created large matrices and programs but not tested complex as yet.

(07-20-2022 07:21 AM)Didier Lachieze Wrote:  Also if you go to the 15C LE auto test 2:C, what is the checksum displayed for the patched firmware?

[Divasson]

PM sent to J-F et Didier

[Divasson]

Hi,

I reviewed the hex file again and found a couple of missing bytes from the patch set - maybe I did not save it properly. Now running tests again, but the previous problems do not reproduce.

My fault!

[Didier Lachieze]

(07-20-2022 08:03 AM)dmh Wrote:  I've patched and tested the release 15C LE firmware version (04/15/2011) and get checksum E7FFh.

Same for me, and 6079h for the 2009-08-03 beta firmware without the PSE bug.

[dmh]

I made a video demonstrating the memory upgrade patch on the production 15C LE firmware version.

I converted the patch details so they are easier to use with a hex editor (ie less chance of editing the wrong location) and have included a demonstration of performing the editing on Windows with Notepad++ and the Hex Editor plugin. A checksum to verify the patching from Windows is also included.

[Stevetuc]

(07-19-2022 02:20 PM)dmh Wrote:  Is Olivier's commented (or anyone else's) disassembly of the 15C ROM available anywhere?

Alternatively, what's the current recommended NUT disassembler?

There is a nut disassembler included with the src of non-pareil, but I've run into lots of compile errors using WSL(windows system linux) under win10 64

https://github.com/mfrasca/nonpareil

The windows executable download includes uasm assembler but not the disassembler sadly.
https://web.archive.org/web/200701031803.../download/

[rprosperi]

The video is excellent to clarify for new Voyager users how the expanded memory is used and can be easily verified on an LE, thanks for creating and sharing this here dmh! . The extra info on how to make the file mods is also clear and helpful for folks new to this stuff, though it indirectly reveals JFG's clever hints on file format .

Also, I see a lot of folks clamoring to modify the older f/w release that precedes the final f/w version with the PSE bug, and these folks need to keep in mind that the older versions also have several bugs in them, some of them significant enough to warrant being fixed, which is how the PSE bug was introduced! I was not involved in the 15C+ testing at the time, so have no notes about the reported bugs and planned corrections, but I recall Tim talking about them at the time and he cautioned that the earlier bugs were much more serious, and affected calculating results, rather than the more cosmetic nature of the PSE bug, which can be worked around easily (e.g. using [R/S] in place of PSE, or even removing PSE completely). So it probably makes more sense to use the latest f/w and deal with the PSE bug by slight mods to the programs you'll use.

[Stevetuc]

(07-13-2022 06:42 AM)J-F Garnier Wrote:  

(07-10-2022 02:47 PM)Stevetuc Wrote:  This is discussed in an earlier archived thread.
https://archived.hpcalc.org/museumforum/...08646.html
Olivier De Smet has produced a rom patch with 224 registers and J F Garnier one with 192 registers.
Hopefully they will make the patches available on the forum.

Not only Olivier and I. Probably Eric Smith and HrastProg were the first ones to do it around 2006. And don't forget David (SwissMicros). For various (or obvious) reasons none has been published.

So yes, I have a 192-register patched version, that I first built for my private HP-15C emulator (emu15) in 2011.
I then tried the same patch set for the HP-15C emulator for Windows from HP, and fortunately it worked well meaning that the emulator allocates enough RAM space, probably the full 256-register space.
Since the HP emulator and the physical HP-15C LE are very close (even the PSE bug is "correctly" emulated), we can guess that the HP-15C LE also allocates the full 256-register space (it would be a very small gain not to do it, and would complicate the emulator code). But of course this is not guaranteed and must be tested.

Since my 2012 message, I also patched the MEM display to have a nice display for all memory partitions, not only the initial 94-99 allocation.
I didn't release my patched HP-15C XE (eXtended Edition) emulator yet, mainly because:
- the exe file was (still is) copyright HP,
- patching the exe file corrupts the HP digital signature, which may be interpreted as a potential risk.
Now, 10 years later, and as HP-15C LE ROM images have been published here, I think I can release my HP-15C XE emulator and the corresponding patch list, for "research and education purposes only".

Here is the patch list:

Code:

exe          NUT       org 64 reg     ext 192 reg
offset       addr      19 - 46        94 - 99

1- memory size
30024        0356:       0c0          040
30036        035f:       310          110
3003A        0361:       350          250
3003C        0362:       090          350
3114A        0be9:       0c0          040
34600        2644:       350          150
34C42        2965:       0c0          040
34C48        2968:       0d0          050
34C54        296e:       0c1          041
34C5A        2971:       0c2          042
34C62        2975:       0c3          043
34DF2        2a3d:       0bb          03b
34E0C        2a4a:       0c0          040

2- MEM display fix
347f6        273f:       31c          3cd      
347f8        2740:       361          0dc     
347fa        2741:       024          03b     
34800        2744:       27e          000    
3695e        37f3:       000          1c6     
36960        37f4:       000          016     
36962        37f5:       000          381     
36964        37f6:       000          0cc     
36966        37f7:       000          260     
36968        37f8:       000          03c     
3696a        37f9:       000          2f6      
3696c        37fa:       000          360     
3696e        37fb:       000          276     
36970        37fc:       000          3e0

exe offset is the position in the hp15c.exe file, NUT addr is the address in the NUT CPU ROM space.

Enjoy!

J-F

Thank you for posting this patch list. If you have any notes you can share to help understand the implementation of the memory size patch that would be great.

[brouhaha]

(06-27-2022 01:38 PM)Stevetuc Wrote:  Some useful info on the 12c+ versions here:

https://lithcore.cn/hp12c-modding-assets/

From same site, interesting info on patching an original rom binary file (10c, 11c ,16c(buggy)) into address 4800-77FF on a rev2 leaving the nut emulator in situ:

https://lithcore.cn/3643/

There may be a 12C rev2 that has the Nut ROM image at 4800-77FF, but that doesn't seem to be the case for the 2015-01-30 firmware, which has the Nut ROM image at 480c-780b (in the calculator), or 080c-380b (in the .bin file, because it gets programmed into the hardware starting at 4000). Note that this is not aligned to a flash page boundary.