HP 48GX Collector’s Edition (merged) - please don't start two threads

[John Keith]

I would prefer option 3b, that is full HP 50 compatibility as well as a modernized version of RPL such as NewRPL or DB48X. I largely concur with David on the design of the ideal calculator, but there is no reason not to have both options on one device.

I do not believe that the current DM platform is up to the task, but a platform with the memory and processing power of the Prime G2 would be adequate and reasonably inexpensive. This platform could also be used for Free42 or Plus42 with even better performance than the DM42.

[3298]

My dream for a successor in the 48/49/50 line would be option 2 ... but with SysRPL, not just UserRPL. Neither DB48X nor newRPL is going there, which is sad but also understandable due to the huge additional effort.
I have dabbled with something aiming in that general direction, but it's not even at a PC-based tech demo stage and at current rate of progress (one of several hobby projects competing for my time) would take decades to reach a calculator, if ever. Moravia or SwissMicros could accelerate that timeline by making it my day job, but fat chance of that happening. (Come to think of it, any bets on Moravia hiring Claudio for newRPL?)

For the hardware I'd want neither the 48 nor the 50 keyboard, but a mashup of them - the 49/50 Enter key is a well-known complaint, but the 48's cursor keys are inferior to the 49/50, with issues like alpha-mode usability, and finding them by touch only (on the 48 they blend into the key matrix, requiring counting from a keyboard corner or a glance away from the screen to find them).
The rest of the hardware I don't care much about, as long as I get plenty of storage space, easy transfers to / from a PC (e.g. make it act as USB drive; I'm just assuming there would be a USB port because the 50g has one) and no features that require using a touchscreen (if there is one in the first place). Even the SD card is optional, though on the 50g it serves as both mass storage and easy PC link. As display I'm fine with anything from identical to the 50g to beyond the Prime and DM42 - as in, improvement is welcome but not required.

[mfleming]

(11-27-2023 08:18 AM)vaklaff Wrote:  

(11-26-2023 11:18 PM)c3d Wrote:  ...
2) a source-compatible firmware that is simply in the spirit of the HP48, but takes full advantage of today's hardware, even if that means being unable to run anything that relies on SYSEVAL or Saturn assembly language?
...
And just to share my personal preference, I'm working on option (2),
...

Looks like I'll be in the minority but only the option 2 makes sense to me:

I'd agree with option 2 as well. Assembly coders would have to have been a small minority, and I suspect those who resorted to SYSEVAL mostly did so to speed up programs. Hardware improvements since the early 90's should obviate the need for bare metal programming.

[Eric Rechlin]

(11-26-2023 11:18 PM)c3d Wrote:  1) a fully-compatible HP48 clone, using e.g. Saturn emulation and HP ROMs, much like iOS or Android apps?

2) a source-compatible firmware that is simply in the spirit of the HP48, but takes full advantage of today's hardware, even if that means being unable to run anything that relies on SYSEVAL or Saturn assembly language?

To me, option 1 only makes sense if it is on a device with the exact same keyboard layout as the 48, because trying to achieve that with fewer keys or a substantially different layout would not work very well. But then you'd suffer from what the 50g suffered from -- a dead-end platform with no real way to fix bugs or add functionality, along with being cursed with the inefficiencies of emulation.

Option 2 seems like a much better idea because it would allow for more flexibility (like support for higher-resolution screens and adding functionality), while also performing better and having a long-term future.

Given enough system resources, however, binary compatibility could be achieved by having a lookup table to translate User RPL entry points (and even System RPL, provided enough development time to handle supported entries) at runtime, if the new firmware has all commands implemented with compatible behavior. A built-in Saturn emulator could even provide binary compatibility for assembly programs, but that seems even less likely.

Option 2 is really the Free42 to Plus42 approach. First re-create everything to provide full backwards compatibility with the original calculator. Then extend it to add functionality we could never have before. The 50g AUR appendix I lists all the User RPL commands in the 50g along with which RPL model they first appeared in. I believe this is an almost complete superset of the 48SX and 48GX lists, so one possible development path would be to first get the calculator to SX-level functionality, then GX-level, and finally 50g-level and beyond.

Of course that is all just a dream because I can't see anyone having enough time to develop the above, but it would allow for my dream machine -- a platform for future RPL devices, which could behave in "48SX" or "48GX" or "50g" modes for running programs from each, perhaps with two different sets of physical hardware for the two different key layouts, or a third layout to combine the best of both. For example, starting with the 50g layout but making Row 4 have 6 keys would allow for ENTER to be moved to a double-wide position on row 6, and additionally making Row 5 have 6 keys would allow for a net increase of 1 key so that Z and ÷ wouldn't have to share a key, which would totally break backwards compatibility but would resolve my second biggest gripe about the 49/50 layout. Put all that in a stretched DM32 device and you'd have the perfect calculator.

[johnb]

(11-27-2023 09:55 PM)Eric Rechlin Wrote:  Option 2 is really the Free42 to Plus42 approach.

Eric, I can actually agree with virtually everything you expressed in your post.

However, isn't this really the Option 3 approach? (If done your way, I'd favor that.)

BTW, if someone wants to start a kickstarter, I bet someone else who's retired (or semi-) would be available to start working on this full time. Hint hint. Nudge nudge. Wink wink. Say-no-more, say-no-more.

[Helix]

(11-26-2023 11:18 PM)c3d Wrote:  1) a fully-compatible HP48 clone, using e.g. Saturn emulation and HP ROMs, much like iOS or Android apps?

2) a source-compatible firmware that is simply in the spirit of the HP48, but takes full advantage of today's hardware, even if that means being unable to run anything that relies on SYSEVAL or Saturn assembly language?

3) a combo of 1 + 2, i.e. something that is modern, but still offers some backward compatibility mode or tools?

Option 2 for me, because the emulation layer of option 1 would slow down the calculator. What’s the point of a modern 48 or 50g if there is no increase of speed, and no software improvement?

[Eric Rechlin]

(11-27-2023 11:20 PM)johnb Wrote:  Eric, I can actually agree with virtually everything you expressed in your post.

However, isn't this really the Option 3 approach? (If done your way, I'd favor that.)

Perhaps, but I specifically don't think any HP ROMs should be required, and my point on Saturn emulation was more of an aside that is at the very bottom of the priority list and probably would never happen, so I still think my preference is basically Option 2 but with a strong focus on backward compatibility. All User RPL would be able to run with recompilation, perhaps common SYSEVALs (and by extension some System RPL) could be supported, to handle certain pre-existing User RPL programs that might use some system features, and maybe support could be broadened if there is interest (both on the parts of users and developers).

We have two separate projects (DB48X and NewRPL) that are headed in this direction now, but neither seem to yet be striving for a full 48-compatibility, and developer burn-out (or just plain lack of time) may mean both are abandoned before getting anywhere near there. If efforts could be combined, and options (compile-time or run-time settings?) made available to let the software operate in, say, DB48X mode, NewRPL mode, 48 mode, or 50 mode, that would minimize a lot of duplicative effort, but would also require a lot of compromise too. I just can't see it being worth having multiple developers trying to re-implement the exact same potentially-highly-complex functionality; I'm specifically thinking of things like the Solver, Equation Writer, and stuff like that.

[M0R33z]

I also see the problem with the different developers. Everyone follows their own philosophy. And my intention was not only to have the RPL/RPN but also the CAS, which is orientated to the functions of the Prime and its speed. These are my thoughts.

[johnb]

(11-28-2023 02:51 PM)Eric Rechlin Wrote:  I just can't see it being worth having multiple developers trying to re-implement the exact same potentially-highly-complex functionality; I'm specifically thinking of things like the Solver, Equation Writer, and stuff like that.

I'm afraid I have to agree on this point, too.

(11-28-2023 03:46 PM)M0R33z Wrote:I also see the problem with the different developers. Everyone follows their own philosophy. And my intention was not only to have the RPL/RPN but also the CAS, which is orientated to the functions of the Prime and its speed. These are my thoughts.

I see the same issues. For a project of this size, there has to be some infrastructure. Someone has to be sitting in the "main coordinator's" seat. And that's going to demand a lot of their time, which probably means either a kickstarter or an investment from some going concern.

I wish I were independently wealthy and could just leave my job and take this on full-time. I haven't really done calculator development, but I've been doing software engineering for 36 years, and (back when pterodactyl's roamed the skies) actually have done some embedded work.

But (a) I'm not, (b) just can't, and (c) nobody's likely to stand up and wave a big bankroll of cash to take this kind of project to the next level. LOL.

[c3d]

Thanks a lot for all the answers and insightful comments. I will try to keep that discussion in mind during development.

In the meantime, I have been busy working on a major stepping stone in the DB48X development path, which is somewhat relevant to this discussion. As you may be aware, I was quickly reaching the limits of the DM42, currently using 99.2% of the available program space. It was clear I would fall short of parity with even the HP48SX, unless I took some drastic measure.

Today, I released v0.5.2 and 0.6.0 simultaneously. They are practically identical from a functional point of view, but 0.5.2 is the last one to use the Intel Decimal floating-point library (which consumes about 60% of its code space), while 0.6.0 is the first one to replace it with a brand new, space-efficient decimal implementation. The resulting gain in code size is dramatic (from 711228 bytes down to 409252 bytes). Additionally, the new code was designed from scratch to support variable size precision, so you can compute sqrt(2) with 2000 decimals in a few seconds. There is a hard limit to 9999 digits, but in practice, you will normally stop long before that because computations take otherwise forever (1.0 / 3.0 takes about 5 seconds at 9999 digits).

This is relevant to the current discussion for the following reason: now both newRPL and DB48X feature variable-precision decimal computations. Any precision above 12 digits is not something that can be achieved with the original HP48 code base. Whether you value that or not really depends on how you use a calculator. I know that to me, personally, both the 12-digit decimal and 64-bit binary limits of the HP48 are annoying.

[John Keith]

This sounds encouraging. Extended precision floats are an important addition to the RPL world. There is LongFloat for the hp 49/50 but the number format is not user friendly and it's not that fast- sqrt(2) with 2000 digits takes about 24 seconds.

Are you using the same format as NewRPL or something different?

[Helix]

(12-25-2023 09:59 PM)c3d Wrote:  Today, I released v0.5.2 and 0.6.0 simultaneously. They are practically identical from a functional point of view, but 0.5.2 is the last one to use the Intel Decimal floating-point library (which consumes about 60% of its code space), while 0.6.0 is the first one to replace it with a brand new, space-efficient decimal implementation. The resulting gain in code size is dramatic (from 711228 bytes down to 409252 bytes). Additionally, the new code was designed from scratch to support variable size precision, so you can compute sqrt(2) with 2000 decimals in a few seconds. There is a hard limit to 9999 digits, but in practice, you will normally stop long before that because computations take otherwise forever (1.0 / 3.0 takes about 5 seconds at 9999 digits).

With all the recent changes, the benchmark results you gave in the past are certainly outdated now. So it would be interesting to know the current performance on the calculator benchmark for the DM42 and DM32 platforms.
I’m also curious to know the results on the summation benchmark, for example with 12 and 32 digits precision, to compare with newRPL.

[avsebastian]

Simple.

A renewed hp 50g:

More RAM, More Space. 10x Faster. The same keyboard configuration

[Gil]

The EMU48 on the phone is already about 100x faster —> at least 100× faster, or possibly 1000x.

[M0R33z]

(12-28-2023 01:06 AM)avsebastian Wrote:  Simple.

A renewed hp 50g:

More RAM, More Space. 10x Faster. The same keyboard configuration

I agree with everything except the keyboard. it should be like the 48GX but better ;-)

[johnb]

(12-28-2023 10:15 AM)M0R33z Wrote:  I agree with everything except the keyboard. it should be like the 48GX but better ;-)

There's already been a LOT of discussion on what this dream machine would be like.

Why don't you start a Kickstarter campaign (or similar) to fund development of one? You'll need to simultaneously look for a team to do it: EE and CS people, and someone with an industrial engineering background to figure out how to get the physical packaging made. (Maybe a collaboration with Moravia to get the manufacturing done?) Which means we'll also need an ace negotiator, preferably one who is also a whiz at finance and business dealings, to negotiate with others and to keep the whole project solvent.

[avsebastian]

(12-28-2023 10:00 AM)Gil Wrote:  The EMU48 on the phone is already about 100x faster —> at least 100× faster, or possibly 1000x.

For that reason, and since the Moravia company only re-releases old versions, with changes only in capacity and speed, it could launch the hp 48g and the hp 50g separately... go ahead with the RPL!!