newRPL - Updated to build 1510 [official build remains at 1487]
|
07-12-2020, 07:05 PM
Post: #41
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
Yessssss!!!
|
|||
07-14-2020, 05:45 PM
Post: #42
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
newRPL on the HP50g forced me to go out and buy a second HP50g. It looks as though I'm going to have to buy a second Prime now as well! I hope that HP are giving you commission on all of these extra sales that you're generating!
Nigel (UK) |
|||
07-14-2020, 08:56 PM
Post: #43
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
(07-14-2020 05:45 PM)Nigel (UK) Wrote: newRPL on the HP50g forced me to go out and buy a second HP50g. It looks as though I'm going to have to buy a second Prime now as well! I hope that HP are giving you commission on all of these extra sales that you're generating! It's a good excuse to upgrade to a G2 and keep the G1 for newRPL! — Ian Abbott |
|||
07-15-2020, 03:17 AM
Post: #44
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
(07-14-2020 08:56 PM)ijabbott Wrote: It's a good excuse to upgrade to a G2 and keep the G1 for newRPL! Do as you wish, but I have news for you: newRPL currently runs alongside PrimeOS. While they are 2 completely independent operating systems, we developed a multi-boot boot loader that allows you to switch between Prime OS and newRPL just by holding ESC when you reset the calc. That's working right now. From the Prime, you press On-Symb-Esc and the calculator reboots into newRPL. Switching back is not yet implemented from the keyboard but a paperclip reset would switch back to the Prime. |
|||
07-15-2020, 03:22 AM
Post: #45
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
(07-15-2020 03:17 AM)Claudio L. Wrote: Do as you wish, but I have news for you: newRPL currently runs alongside PrimeOS. While they are 2 completely independent operating systems, we developed a multi-boot boot loader that allows you to switch between Prime OS and newRPL just by holding ESC when you reset the calc. That is amazing. Now I'm glad I kept a few spare G1 calculators! |
|||
07-15-2020, 07:50 AM
Post: #46
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
(07-15-2020 03:17 AM)Claudio L. Wrote: Do as you wish, but I have news for you: newRPL currently runs alongside PrimeOS. While they are 2 completely independent operating systems, we developed a multi-boot boot loader that allows you to switch between Prime OS and newRPL just by holding ESC when you reset the calc. That's great, but wouldn't the keyboard need to be relabelled for newRPL? — Ian Abbott |
|||
07-15-2020, 01:50 PM
Post: #47
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build] | |||
07-15-2020, 03:24 PM
Post: #48
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
(07-15-2020 07:50 AM)ijabbott Wrote: That's great, but wouldn't the keyboard need to be relabelled for newRPL? The keyboard is really a head-scratcher, since the actual keys are very different from the 50g. Up to this point, all other hardware targets were "substantially identical" to the 50g, so we had a unique layout for all of them. I've been trying to come up with a decent layout that keeps most of the keys where the painted labels are. I'm copying below some of the thoughts we have internally, perhaps some community collaboration would help, so let's open up the discussion. My main points: * I want on-screen menus to be accessible by both touch-screen AND hard keys. Call me old school if you want, but I think most people using RPL are old school anyway :-) * I don't like the overlap of alpha and numbers. Same thing with the basic operators, I want to type '2*X+Z/2' without using shifts or changing the alpha mode. 1st Alternative: Use the 10 black keys as 2 menus. Menu on-screen would be split, there would be 2 menus, 5 items each. This will mess with some menus, as they are designed for a 6-item menu for the 50g. On the screen, you'd see the status area at the center, with one menu on the left and one menu on the right, immediately above the keys so it's intuitive which key does what. The menu items would be laid out as the keys (same principle of newRPL on the 50g, where both menus followed the layout of the corresponding keys). The blue shift to be mapped to RSHIFT. Alpha to be mapped to LSHIFT. The TOOLBOX key to become ALPHA (this is debatable? perhaps alpha should be alpha and toolbox become another shift. The location of Toolbox is not very convenient for a shift either, so I'm not fully convinced. 2nd Alternative (a compromise to free more keys): Have one of the menus use the 6 keys next to the cursors. The CAS key could switch the 6 keys to be used for Menu1 or Menu2 (though it would be confusing without a visual hint, but that can be arranged). The on-screen layout would be similar as alternative 1, with the status area at the center, both menus would have 6 slots instead of 5 (hence, same menu organization from the 50g would work here). This alternative frees up the Apps, Home, Esc and CAS keys (well, CAS would switch the menu keys, so scratch that one). Having Esc available is good, all the functionality of On would be moved to Esc (except for actually turning the calculator On), so Esc becomes the "Cancel" key, and it makes sense. On becomes LSHIFT Blue Shift becomes RSHIFT Alpha becomes ALPHA And now we have 3 proper shifts "almost" in their natural positions. I'm leaning towards alternative 2, but I'm open to all ideas. Having the keys to operate only one of the 2 menus is not ideal, but using the other menu with the touchscreen might provide some relief. As far as the letters overlapping with numbers: Proposal, in alpha mode: Help = R and Q (do Q as a shifted case?) View = S Menu = T CAS = U Apps = V Home = W Symb = X Plot = Y Num = Z These above are the letters that overlap numbers and operators. Other symbols will need to move too, the # needs to be shifted not alpha, just like on the 50g. The double quotes "" will also be shifted, not alpha so we can type the 0 in Alpha mode. Other less dramatic proposals: * The tick and the O key historically belong together, so that comma will become the single tick * Parenthesis should be shifted, and that key becomes 1/X * Vars becomes STO (same location as the 50g) * Toolbox becomes EVAL (same location as the 50g) * Home can become the main menu (P on the 50g), but only if alternative 2 is chosen. * I'm not sure what to make of the keys C,D,E, and Apps (I'm all ears) |
|||
07-15-2020, 05:55 PM
Post: #49
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
(07-14-2020 08:56 PM)ijabbott Wrote: It's a good excuse to upgrade to a G2 and keep the G1 for newRPL! I plan to do exactly that. Once the keyboard issues are ironed out it would be great to have stick-on key labels available like those for the WP-34. Hopefully there will be enough G1's out there to satisfy the NewRPL community. |
|||
09-02-2020, 08:10 PM
(This post was last modified: 09-02-2020 10:13 PM by Vtile.)
Post: #50
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
(07-15-2020 03:24 PM)Claudio L. Wrote:(07-15-2020 07:50 AM)ijabbott Wrote: That's great, but wouldn't the keyboard need to be relabelled for newRPL?<SNIP> Hello. It is nice to see the newRPL is still kicking (even more than three years ago). I have just bold proposal (coming from simple idiot) as one solution for overlapping numbers and etc... What about implementing a longpress feature as or similar than in keyman+ ??? This is not optimal, but the keys with wrong labels are not either. (PS.. HW hack: Dymo and clear nailpolish can be used for custom labeling for 50g, because the acetone? on nailpolish seems to soften the plastic used on that machine and such makes a solid pond). Back to hibernation PPS. As of units, I do lots of revolutions and degrees based calculation with really wild engineering units (not to be mixed with 'de facto' standard US or GB engineering units) on my day job (motion systems for industry). Have now introduced ie. _Re(volution), build custom unit menu to all odd but useful engineering units (for my surprise the menu will accept the keyboard shortcuts as original unit menu). I do also use conversions between _Re(= |
|||
09-03-2020, 06:06 PM
Post: #51
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
(09-02-2020 08:10 PM)Vtile Wrote: Hello. It is nice to see the newRPL is still kicking (even more than three years ago). Long press has been a feature of newRPL since day one (I guess that makes me another simple idiot, as I really like that feature). You are right as it not being optimal, takes forever to type anything if you are waiting for a long press all the time. For the most part the keyboard is done now, I kept most of the letters where they are except the numbers and operators, they all moved to the black keys at the top. I'm not 100% happy because I have 1 key less than what I'd like to have, but after using it for a while I got used to it. (09-02-2020 08:10 PM)Vtile Wrote: PPS. As of units, I do lots of revolutions and degrees based calculation with really wild engineering units (not to be mixed with 'de facto' standard US or GB engineering units) on my day job (motion systems for industry). Have now introduced ie. _Re(volution), build custom unit menu to all odd but useful engineering units (for my surprise the menu will accept the keyboard shortcuts as original unit menu). I do also use conversions between _Re(= I called it "turn" instead of revolution as somebody suggested here in the forum, but that's a system unit in newRPL. Radians are far more graciously handled in newRPL. Actually, all non-dimensional units are considered equivalent to raw numbers, not just radians. The only down side is that you can add radians and decibels, or radians per second and Hz, and the system won't say a word because they meet dimensional compatibility. So your hack wouldn't be needed: rad/s is already consider equivalent to 1/s, and if you have w=V/r for example with V in m/s and the radius in m, you can convert w to rpm and it will work in newRPL without a hitch. Of course you need to know what you are doing to avoid converting rad/s into Hz without the 2pi factor for example, but that's true also with paper and pencil.... Finally, regarding the _uno virtual unit (something like the _? on the 50g). You can define any units you like, including new base units. As a matter of fact, you don't even need to define them. newRPL will add 1_oranges and 3_oranges without questioning what the unit is. If you define the unit _uno as the scalar 1 then it will become a non-dimensional unit like Db, radians, etc. |
|||
09-19-2020, 10:58 PM
(This post was last modified: 09-26-2020 11:42 AM by Gilles.)
Post: #52
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
Hi all... I'm back from a long time ;D
I have 3 questions. 1/ is there a way to Edit a program or variable with a shortkey? or a VISIT command? like LeftShift DownArrow in HP50g RPL 2/ in a program, sequences like << 5 { 'a' 'b' 'c' } LSTO >> dont work. it works well with STO but not with LSTO I get an error "indentifier expected" 3/ I've upgrade both Windows and HP50g to version 1360. With windows 10 I cant "Copy Level 1" of the stack. I get nothing when I try to paste the data elsewhere. EDIT: The 1360 version is really impressive! Thank you so much Claudio for your work! I'll never imagined this ... Fabulous .... It just lacks the support for graphics applications but I hope it will come; D To be honest, I was skeptical at the start of the NewRpl project. I was totally wrong. The result is way above my geatest expectations. |
|||
09-26-2020, 03:49 PM
Post: #53
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
(09-03-2020 06:06 PM)Claudio L. Wrote: I called it "turn" instead of revolution as somebody suggested here in the forum, but that's a system unit in newRPL. Radians are far more graciously handled in newRPL. Actually, all non-dimensional units are considered equivalent to raw numbers, not just radians. The only down side is that you can add radians and decibels, or radians per second and Hz, and the system won't say a word because they meet dimensional compatibility. Hrm. I gotta say, this doesn't sit well with me - specifically, rad/s being the same as Hz. Given that newRPL correctly translates between turns and radians, maybe the Hz should be defined as a turn/s? (Out of curiosity, I've noticed that some energy units have 'IT' appended to them - does that stand for 'international' or something else?) Finally, is there any way for us to alter the Units menu ala the old Unitman library, short of recreating it all from scratch by TMENU? |
|||
09-27-2020, 09:25 AM
Post: #54
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
Namir’s thread about reflashing a survey HP50G leaded me to install newRPL on one of mines, and I must say it is really impressive. Performance is incredible compared to a stock HP50G.
I think next step is to create various input routines for user interaction, or maybe I did not find them? Graphing is also a priority, but I agree with your vectorial approach. Thibault - not collector but in love with the few HP models I own - Also musician : http://walruspark.co |
|||
10-11-2020, 06:39 PM
Post: #55
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
(09-19-2020 10:58 PM)Gilles Wrote: Hi all... I'm back from a long time ;D 1. I didn't think of that, do you mean by having a variable name on the stack and editing the content? I could add that functionality, but it's not included at the moment. 2. LSTO is not the same as STO. Internally it gets optimized into PUTLAMn, so it works best with a hard coded variable name before it, and has no list support for the same reason (breaks optimizations). Later, any reference to the variable name is compiled to a GETLAMn hence the need for a hard coded name so it all gets optimized at compile time. 3. I do my Windows 10 builds all the time, I'll check the clipboard issue but I've never seen that happen before. It puts the data in the clipboard with 2 MIME types: plain text (decompiled for edit) and binary internal newRPL format. So you should be able to paste it as binary within newRPL desktop instances, and as text on any other application. As for graphics... it's on hold and that's as expected. We are still working on the Prime G1 port and I'm stuck at the moment because the calculator turns off but doesn't respond to the On key. This makes it nearly useless until I can figure out what the problem is. |
|||
10-11-2020, 06:56 PM
(This post was last modified: 10-11-2020 06:58 PM by Claudio L..)
Post: #56
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
(09-26-2020 03:49 PM)The Shadow Wrote: Hrm. I gotta say, this doesn't sit well with me - specifically, rad/s being the same as Hz. Well, that's a possibility but Hz is not always coming from circular motion, so defining it in terms of turns may cause some unexpected results. For example, let's say you want to calculate a number of clock ticks in a period of time, so n=f*t with f in Hz and t in seconds. If f is in turns/sec then f*t is in turns, and n will have a unit of turns. If you operate this number n with a scalar, it would convert the turns to radians first, so n+10 would actually result in 2pi*n+10, messing up you cycle counts. I don't know, it may be better the way you suggest. I wonder if their could be other formulae that breaks because of the unwanted turns unit. You wouldn't need to recreate it completely from scratch, only the main submenu labels. You can create a TMENU that calls the unit submenus you need. You can get the menu codes for each submenu, and simply passing that code to TMENU does the trick. I don't know if this does what you need: this way you get some submenus from the standard units menu combined with some submenus of yours. There's no provision for the user to add units to the standard unit menu at the moment. |
|||
10-11-2020, 07:02 PM
Post: #57
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
(09-27-2020 09:25 AM)pinkman Wrote: Namir’s thread about reflashing a survey HP50G leaded me to install newRPL on one of mines, and I must say it is really impressive. Performance is incredible compared to a stock HP50G. Yes, graphics is important, but it needs of be very well thought in order to work seamlessly in different hardwares. Especially now that the Prime G1 port is underway, it needs to support colors, etc. and user interaction needs to work also with touch, so it's back to the drawing board for graphical APIs. Both color and touch would also bring benefits to the PC and Android ports as well. |
|||
11-21-2020, 03:37 AM
(This post was last modified: 11-21-2020 03:46 AM by compsystems.)
Post: #58
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
Hi
1: In the documentation on character strings, the character " is not displayed correctly and copying an example to the simulator generates a syntax error. “Hello ” “World!” + ERROR Source: https://newrpl.wiki.hpgcc3.org/doku.php?...r3:strings Although I would like the compiler to interpret this set of quotes, the quotes to the left indicate(“) the beginning of the string and the quotes to the right (”) indicate the end of the string. “Hello ” “World!” + "Hello World!" “"Hello ” “World!"” + ""Hello World!"" 2: When starting the simulator in Windows, the virtual keyboard does not adjust to the current monitor height, after manual adjustment, alpha, LS, RS, ... indicators are not lost. Ideal if there was the option of dividing the window, that is, placing the screen to one side and the keyboard separately and allowing independent adjustments, this facilitates the operation of the simulator, giving priority to the screen and not the keyboard. |
|||
12-03-2020, 03:02 AM
Post: #59
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
(11-21-2020 03:37 AM)compsystems Wrote: Hi I did not notice that. Seems to be a feature of the wiki to replace the quote marks, I'll have to investigate how to disable it. (11-21-2020 03:37 AM)compsystems Wrote: 2: When starting the simulator in Windows, the virtual keyboard does not adjust to the current monitor height, after manual adjustment, alpha, LS, RS, ... indicators are not lost. I tried but wasn't happy with the auto arrangement so I let it be fixed. One day I might give it another shot. |
|||
03-28-2021, 05:43 PM
Post: #60
|
|||
|
|||
RE: newRPL - Updated to build 1360 [ including official build]
Just started using newRPL on a HP 39gs. Great job with the firmware! Is there any schedule for a new release/build after 1360?
|
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 11 Guest(s)