I noticed that be.philippe does not always test the WP43S on DM42. That is likely because of the complication to load the firmware and then reload afterwards.
For easier comparison on a single DM42, I compiled a custom version of a minimally modified WP43S code, not having that complication.
This recent exercise was very productive, thank you for reporting. I definitely need more people testing the functions that are provided. The problem of course with fixing bugs is the possibility of adding more bugs than fixed, so please test and test and test.
The new version is updated with the latest WP43S code as usual, so the corrections Walter mentioned should also be pulled in. I have not had time to check and test. Please do.
Unfortunately the DM42 is too large again, so I had to temporarily remove more functions from the DM42 image. All functions and even test and demo functions are still in the simulator version. This time I also removed the complete XEQM programming code from DM42, so none of that will work. For a test version.that is no problem, as none of those things were changed. The problem is they also need testing ...
Please report back here, or create a bug report on the Gitlab site.
According to WP43S documentation, p147, 1011 00112 [RL] 2 should display 1100 11102, it actually shows 10 1100 11102 (the WP43S simulator does the same). The actual value is 1100 11102, as shown by [.d] [#]2.
Philippe Martens
Elec Eng, Software Architect
[HP41C, DM41X, DM42]
On C43 106f, both DM42 and simulator, [SHOW] of a "big" small integer can overflow the display.
1234567890#H [SHOW] display the value in bases 16, 10 and 8, with the 3rd line being empty. 12345678#H [SHOW] display the value in bases 16, 4, 8 and 10.
With both on the stack, [SHOW] [Up] tries to display 1234567890#H in base 4, but the end of the line is truncated: Y: 1 02 03 10 11 12 13 20 21 (the end 004 is missing).
After [x<>y], [SHOW] display both values in bases 16, 10 and 8, although the smaller one is displayable in base 4.
Philippe Martens
Elec Eng, Software Architect
[HP41C, DM41X, DM42]
Storing the config in a global register with STOCFG 00, and then saving the data to the FAT with SAVE crashes the DM42 (version C43_105L1.pgm).
After RESET, trying to LOAD crashes the 43C again.
According to WP43S documentation, p147, 1011 00112 [RL] 2 should display 1100 11102, it actually shows 10 1100 11102 (the WP43S simulator does the same). The actual value is 1100 11102, as shown by [.d] [#]2.
First one: Not yet attempted. Issue #54.
Second one seems fixed: I tried that example just now on Mac Simulator and on 106f in DM42. Have you made it an 8-bit word?
On C43 106f, both DM42 and simulator, [SHOW] of a "big" small integer can overflow the display.
1234567890#H [SHOW] display the value in bases 16, 10 and 8, with the 3rd line being empty. 12345678#H [SHOW] display the value in bases 16, 4, 8 and 10.
With both on the stack, [SHOW] [Up] tries to display 1234567890#H in base 4, but the end of the line is truncated: Y: 1 02 03 10 11 12 13 20 21 (the end 004 is missing).
After [x<>y], [SHOW] display both values in bases 16, 10 and 8, although the smaller one is displayable in base 4.
On C43 106f, both DM42 and simulator, keying 8.7 [RCL] L should push 8.7 and Last X on the stack, but 8.7 is overwritten.
f[LAST x] and other [RCL] commands have similar effect.
Fixed, thanx.
I've installed the build environment on my home Mac, and successfully built version 106g including this fix, both Simulator and DM42.
(By the way, how do you debug the sim ?).
I see you did fix the [RCL] problem, but not [LAST x] nor any other command pushing some value on the stack ([MEM?], [WSIZE?], ...).
Philippe Martens
Elec Eng, Software Architect
[HP41C, DM41X, DM42]
I've installed the build environment on my home Mac, and successfully built version 106g including this fix, both Simulator and DM42.
(By the way, how do you debug the sim ?).
That is great news!
I just pushed small changes in the pipeline, #fa4b382.
I see you did fix the [RCL] problem, but not [LAST x] nor any other command pushing some value on the stack ([MEM?], [WSIZE?], ...).
Yes, I did exactly that. I made an exception for ITM_RCL. I seem to recall that I checked the LASTx as well, but apparently not. I will re-look at that. If only a few, exceptions can work the same way, otherwise I need to figure another way. The eRPN is a real challenge to implement trying to not change too much from the 43S code.
I am currently busy debugging the STOCFG and SAVE crash. I confirmed that it crashes on WP43S as well, but am first looking to see if I can see the problem before I report the bug.