newRPL - build 1255 released! [updated to 1299]

[Luigi Vampa]

(09-14-2018 05:29 PM)The Shadow Wrote:  I'm embarrassed to say that I don't know how to make an image of an SD card. What's the process? Is there software you would recommend?

Another option:
https://sourceforge.net/projects/win32di...t/download

[The Shadow]

Thanks for the information, guys. I appreciate it.

[Claudio L.]

(09-06-2018 12:34 AM)acoto Wrote:  I think it may be interesting to always speed up when starting a calculation, no matter if simple or complex, calculator may feel faster, and always return to low speed when finish and returning to UI.

(09-06-2018 02:07 PM)Claudio L. Wrote:  The calculator UI feels pretty quick as it is. Most simple calculations are instantaneous, and speeding up the clock makes them feel instantaneous just the same, but burning more battery.
The idea with the clock switch is that only when a computation is taking long enough to be annoying to the user we'll run at full power. The 300 ms (or 500ms) feels fine. Perhaps we can have a user setting to tune that timer from 50ms to 500 ms, so the user can control how "responsive" their calculator feels.

And it's done.
All ROMs updated to build 1111 (nice number).
The only changes are:

* Fixed a critical bug (rare but critical) in multiplication assembler routines
* Added support for system flag -88 "Responsive mode"

The first is a very rare bug. I only found it accidentally by running the cos^2+sin^2=1 test from another thread.
On all my tests, it produced an incorrect result when computing 11 COS (in radians), but only when using 64 digits precision. Instead of 64 correct digits it produced only 56 correct digits.
For example, using On+Up set the precision to 64 digits, run 11 COS, then On+Up to 80 digits, 11 COS - and see that the difference is 10^-56 when it should be < 10^-64.
It's all fixed now.

Then there's the "responsive mode" that came from our friend acoto's concern about speed. When system flag -88 is set, newRPL only waits 30 ms before running at full speed. With flag -88 cleared, the normal is 500 ms before the faster clock kicks in.
It does feel more responsive but nothing to "wow" the crowds, it will certainly drain batteries a bit faster but I have no measurement to back up that claim (that's for all of you to test!).

[okkama]

integrate cos(x^x) from x=4 to 5
Degrees correct 0.073558
Radians incorrect -0.05813825 vs 0.0017302449 (wolframalpha & maxima)

[Claudio L.]

(10-02-2018 08:04 PM)okkama Wrote:  integrate cos(x^x) from x=4 to 5
Degrees correct 0.073558
Radians incorrect -0.05813825 vs 0.0017302449 (wolframalpha & maxima)

I'll have to investigate. I think the adaptive algorithm might be stopping too early because of the oscillatory nature of the function. Thanks for reporting!

[Claudio L.]

(10-03-2018 03:02 AM)Claudio L. Wrote:  

(10-02-2018 08:04 PM)okkama Wrote:  integrate cos(x^x) from x=4 to 5
Degrees correct 0.073558
Radians incorrect -0.05813825 vs 0.0017302449 (wolframalpha & maxima)

I'll have to investigate. I think the adaptive algorithm might be stopping too early because of the oscillatory nature of the function. Thanks for reporting!

The result seems to be correct, depending on your requested error threshold. This particular case since it's about thousands of additions cancelling each other you just need to request additional precision and be patient...
I tried 0.00001 and not surprisingly I got 0.00099 as an answer. Gave it 4 more zeros and got 0.0014, 3 more zeros and... 0.001732449205, but I had to wait over 5 minutes to get that answer. It's just that the extremely high frequency of this function means your step needs to be exponentially smaller to get any meaningful result out of it.
Why does it work better in degrees? Because the frequency is much lower! 5^5 = 3125, and dividing by 360 is a relatively small number versus dividing by 2PI.
EDIT: Basically, when dealing with periodic functions, make sure your step is such that the algorithm won't skip over a bunch of cycles.

[brickviking]

I'm just catching up with the state of the PC simulator; does this work under Linux when compiled, and will it be the 1089 release, or the latest-at-this-time hot smoking 1111 release? I only see the 1089 release for Windows on SourceForge. Can I simply plug in the latest 1111 firmware anywhere?

Additionally, I couldn't initially get that 1089 to work, I kept getting the following error:

Code:

This application failed to start because it could not find or load the Qt platform plugin "windows"
in "".
Reinstalling the application may fix this problem.

... followed by the following error:

Code:

This application has requested the Runtime to terminate in an unusual way.
Please contact the application's support team for more information.

I then removed the QT dlls and tried running e:\qt\5.9.2\msvc2015\bin\windeployqt.exe "e:/newRPL Desktop/newrplui.exe", but got a weird error message in QtCore.dll, understandably.

Code:

The procedure entry point _Z21qRegisterResourceDataiPKhSO_S0_ could not be located in the dynamic link library Qt5Core.dll.

I suspect that's because the newrplui executable was compiled against QT-5.8.0-mingw32. I reran windeployqt from the mingw53_32\bin and that gave me a working newRPLui. Finally.

Personally, I've found that running the newRPL firmware on x49gp is a better option, except for the png being the original HP50G keyboard instead of the modified one. It's nice that I can now click on each of the individual keys rather than just relying on the PC keyboard for the newRPLui.

(Post 295)

[Nigel (UK)]

(10-03-2018 01:18 PM)Claudio L. Wrote:  The result seems to be correct, depending on your requested error threshold. This particular case since it's about thousands of additions cancelling each other you just need to request additional precision and be patient...
<snip>

As a comparison, the HP Prime in Home mode gives an answer agreeing with the one from Wolfram Alpha to 10 significant figures in about 4 seconds.

I'm not complaining - I can't imagine ever wanting to do an integral like this! - but I'm impressed that the Prime is so fast.

Nigel (UK)

[Claudio L.]

(10-04-2018 02:53 AM)brickviking Wrote:  

Code:

This application failed to start because it could not find or load the Qt platform plugin "windows"
in "".
Reinstalling the application may fix this problem.

Very strange, I always test the installers and last time was no exception. Could it be you are the one and only person that installed the latest release? In any case, I'll see if I have time to investigate this weekend, and perhaps upgrade to the latest.
Regarding Linux: Sure, if you compile it yourself the simulator works just fine on Linux. I still haven't had time to investigate the possible packagers (snap, etc.) to publish a Linux version as well.
As far as "snapping" the firmware image somewhere: The application is recompiled to run natively on Windows/Linux, etc. there's no emulator, so you can't simply change the firmware.

Now if you followed this thread, you are probably aware that there were huge improvements to x49gp. This last week alone I committed to my repository a major upgrade to allow SD card emulation to work within newRPL (x49gp had very basic MMC emulation, enough for the bootloader to work but not newRPL which uses the more advanced SD commands). It only emulates SD, not SDHC (that's a whole other batch of commands that need to be emulated), so don't make images more than 2 GB. Also, the image is kept in RAM at all times while mounted, so it's probably wise to keep it around 256 MB.
Make sure you pull my repo and recompile.

[Claudio L.]

(10-04-2018 09:41 AM)Nigel (UK) Wrote:  As a comparison, the HP Prime in Home mode gives an answer agreeing with the one from Wolfram Alpha to 10 significant figures in about 4 seconds.

I'm not complaining - I can't imagine ever wanting to do an integral like this! - but I'm impressed that the Prime is so fast.

Nigel (UK)

The Prime uses the standard C trig functions with standard 'doubles'. That's hugely optimized when you compare it with the decimal, variable precision arithmetic used in newRPL. Also, transcendental functions in newRPL take an extra penalty because of the variable precision, which means no tables with precomputed constants can be used.
And finally, the Prime has vasts amounts of memory, I imagine the algorithm takes advantage of that, while newRPL has to use an integration algorithm that has a very minimal footprint.
So yeah, expect the Prime to leave newRPL way behind on this one case.

[brickviking]

Yah, I was well aware that x49gp had a significant improvement, it's what I'm using under Linux with the new 1111 firmware, and it seems to work well. My question was more about installing the PC simulator under Windows, but it looks like I'll have to have that QTMake thing you discuss in the instructions for building. I'll have to go looking for that, I'm hoping I installed it when I added Qt to my machine. And it looks like I may have to rat around the system to see what version of mingw32 I happen to have.

(Nine Hundred Years Later)

Well. I got there on Linux (Fedora) and finally managed compile newrpl-fw firmware up to 1107. Now all I'm awaiting is the 1111 release to hit SourceForge's git repo.

EDIT: removed a whole lot of irrelevant guff...

(Post 297 - nearly 300!)

[brickviking]

I'm guessing there's no way to "import" the USB-handling stuff from newRPL into x49gp, is there? That might just handle the one remaining issue left for x49gp's usefulness in comparison to the Connectivity Kit.

Also, I note that x49gp has a rather binary understanding of the 49g+/50G that doesn't take the newrpl UI into account. NewRPL's UI (at least in the desktop simulator) has modified several buttons, and I was wondering how easy it would be to have that implemented in some manner. Quite some time ago, there used to be a "image=..." parameter, but I note this has since been removed, citing lack of use or function. I think I just came up with a use: newRPL's UI.


(Post 298 - even closer to 300)

[Claudio L.]

(10-05-2018 06:01 AM)brickviking Wrote:  I'm guessing there's no way to "import" the USB-handling stuff from newRPL into x49gp, is there? That might just handle the one remaining issue left for x49gp's usefulness in comparison to the Connectivity Kit.

Also, I note that x49gp has a rather binary understanding of the 49g+/50G that doesn't take the newrpl UI into account. NewRPL's UI (at least in the desktop simulator) has modified several buttons, and I was wondering how easy it would be to have that implemented in some manner. Quite some time ago, there used to be a "image=..." parameter, but I note this has since been removed, citing lack of use or function. I think I just came up with a use: newRPL's UI.


(Post 298 - even closer to 300)

Why don't you post this on the x49gp thread? I'm sure 3298 wouldn't mind adding that option, but if I remember correctly, the image of the keyboard is completely blank, and the text on the keys is hardcoded in the emulator. My guess is this was done to improve readability at some point, now in retrospective was perhaps a bad idea to hard code it, it should be something for the user to reconfigure, much like KML scripts in Emu48. But back then the intent was to emulate the 50g stock rom, nothing else. We are pushing the emulator well outside its intended use (now it's a complete debugging platform for newRPL development, on top of other improvements).

PS: I can't reply to your private messages, you seem to have that option disabled, but thanks for your suggestions, I'll try to find some time this weekend to update the wiki. I haven't pushed to SF because the most recent code because newrpl-ui does not compile at the moment, it's being modified for Android and I don't want to have code in SF that is broken. I know, I should work on a separate branch, then merge, etc. but bear with me for a little while.

[orthocube]

Hello, everyone.

Today, I just discovered about newRPL and this is the most awesome thing ever.

My first graphing calculator was MIDP-Calc, an RPL-based programmable graphing calculator for Nokia phones. Since then, I loved calculators and most importantly, I loved RPN input.

I bought an HP 39gs (the only one I can afford) but was quite annoyed by the fact that it doesn't have RPN input support, but was still happy, since it's the first HP calculator I owned.

But today, that changed when I learned about newRPL. I installed it on my 39gs immediately and while I was a bit confused with the key layout (can we please have some 39gs key layout support?), the fact that most (or is it all?) functions are also accessible via the 6-key menu is a good thing.

I plan to use this as the OS for my 39gs and will always keep it up to date with the latest released versions.

I have a question, though. I can see that so far, 54% of the target features are already implemented. While I'm happy with the current features, I cannot deny that CAS and graphing features are a huge advantage. But what I'm afraid of is that the ROM is already about 1MB--the limit of the 39gs. With every new version, the ROM size keeps getting bigger and bigger... and I'm scared that a future release will not be available for 39gs models...

Is that possible to happen? I'd really love to continue to use newRPL with my 39gs... (and before you say that I can just buy a 40gs or a 50g, please, I really wish that I do have the money, even for a second-hand cheap Chinese sold one)

In any case, I really wish this project all the best, and of course, I would like to thank the author(s) for this great piece of work. Thank you!

[Zaphod]

I'm trying this for the first time on a 50g

So I

• Formatted a 128MB card with FAT16 format (I've also tried formatting in the calc)
• Loaded newrplfw.bin to the card - the file is ~954kb)
• Created update.scp as a plain text file (tried both Unicode8 and 16) the file is 26bytes , and saved that to the card
  

But when the card is put in the calc and it's set to update it fails with "Read card Timeout ....Wait, reset or enter"

What , if anything, am I doing wrong?

(I'm doing it all on a mac, but I've double-checked I'm definitely writing a plain text file), does it need to be capital letter file names perhaps?

[ijabbott]

(10-06-2018 07:02 PM)Zaphod Wrote:  I'm trying this for the first time on a 50g

So I

• Formatted a 128MB card with FAT16 format (I've also tried formatting in the calc)
• Loaded newrplfw.bin to the card - the file is ~954kb)
• Created update.scp as a plain text file (tried both Unicode8 and 16) the file is 26bytes , and saved that to the card
  

But when the card is put in the calc and it's set to update it fails with "Read card Timeout ....Wait, reset or enter"

What , if anything, am I doing wrong?

(I'm doing it all on a mac, but I've double-checked I'm definitely writing a plain text file), does it need to be capital letter file names perhaps?

26 bytes sounds like you are saving the update.scp file as UTF-16 with Unix line endings (<LF> character). Try saving as ASCII (or UTF-8) with MS-DOS line endings (<CR><LF>).

[Zaphod]

Sorted now....

I discovered macOS was appending a .txt extension on top of the .scp :rolleyes

But then it still didn't load... so I rewrote it (using Unicode-8 this time (again)) and it still didn't work
So I downloaded the firmware file yet again and voila it finally worked.

[Zaphod]

Sorry for a newb question, but I was just wandering about on the keyboard discovering stuff (without reading the manual wiki) and the top (hitherto blank) stack area suddenly had alternating dark and blank vertical bands (probably single character width at a guess) filling up that entire area ... I thought I'd crashed it.
Lots of button pressing got me back to normal .. not sure what I did ? I can't replicate it now.

I’ve just managed to do it again and capture it:

[Claudio L.]

(10-06-2018 08:49 PM)Zaphod Wrote:  Sorry for a newb question, but I was just wandering about on the keyboard discovering stuff (without reading the manual wiki) and the top (hitherto blank) stack area suddenly had alternating dark and blank vertical bands (probably single character width at a guess) filling up that entire area ... I thought I'd crashed it.
Lots of button pressing got me back to normal .. not sure what I did ? I can't replicate it now.

Anyone can replicate it, just do a long-press on the P key. It switches to the Forms engine which is still not enabled, so for the time being just displays those bands. Long press P again will get you back to the stack. In the future this will cycle between open Forms programs. Forms is (or should I say will be?) the replacement for the INFORM engine.

[Zaphod]

Thanks Claudio