Buyers remorse of HP 48

[Jonathan Busby]

As others have stated, in terms of HP calculators that use HP in-house designed custom CPUs, the Saturn based calculators are the fastest in terms of overall raw speed. But, the UI / GUI is slower due in part to the fact that there's much more for the CPU to do to display a proper graphical GUI on the 131x64 pixel display ( and there's no GPU ), whereas one or two line HP calculators have much less to deal with when it comes to the UI / GUI. But, this isn't the main reason that the HP48 series GUI is slow : It's slow due to mainly three different things. Firstly, the GUI on the HP48 series makes heavy use of slow Sys-RPL routines under the hood, especially ones that operate on composite objects ( Particularly lists, and also "meta" objects on the stack produced by =INNERCOMP ) and also slow Sys-RPL local variable accesses. Secondly, said GUI code isn't very efficient in terms of minimizing "junk" or intermediate composite objects in TEMPOB, which leads to more garbage collections, and this leads to further slow-downs / pauses. Thirdly, said garbage collection events are *slow* due to the naïve algorithm used.

Years ago, when I posted a Saturn assembly language fix to the HP49 list-processing bug, I went even further and re-wrote the entire HP48 list-processing subsystem in mostly Saturn assembly ( although the code hasn't been published ). I did test the code and the speedup was *massive*

Also, the way the HP48 series garbage collector is implemented in Saturn assembly is *slow*. It performs *four passes* ( technically *seven* passes, but I'm keeping it simple here ) over TEMPOB :

1. The first pass iterates over all TEMPOB memory slots and modifies each one's link / marker field so that the end of the TEMPOB slot can be detected during the GC.
2. The second pass performs a mark-and-sweep over said TEMPOB slots using all the root pointers and adjusts pointers that reference addresses in TEMPOB accordingly to reflect their new addresses after TEMPOB has been compacted.
3. The third pass removes unreferenced TEMPOB slots which involves a lot of slow memory block moving.
4. The forth pass once again iterates over the ( now compacted ) TEMPOB slots and modifies each slot's link / marker field and returns it back to its usual form.
   

The above, in addition to being slow in general, has a worst case running time of \(O(n^{2})\) due to the method used to check if the TEMPOB slots are still referenced. Now, garbage collection, even a simple mark-and-sweep algorithm, doesn't have to be this slow. A long time ago I also re-wrote the GC algorithm in two different ways that sacrificed a little memory space for a *huge* speed-up, and I reduced the worst case running time to only \(O(n)\) or \(O(n \cdot log(n))\), depending on the version used. One version used a kind of direct-mapped hash ( the \(O(n)\) version, but it used much more memory during the GC operation** ) and another version used a type of self-balancing binary search tree ( the \(O(n \cdot log(n))\) version, which used much less memory during the GC operation ). I did test both algorithms and the tests demonstrated that the new algorithms were much, much faster.

( ** NOTE : I did play around with using free memory in a bank in port 2 as scratch memory for the GC algorithms, although I never really finished implementing it )

In conclusion, I think that the original HP48 software dev team cared more about space than speed, and that is why the HP48 is sluggish when it comes to the GUI. I'd recommend that you install Raymond Del Tondo's awesome SpeedUI library if you can get your hands on an HP48G/G+/GX

Regards,

Jonathan

[DavidM]

(07-15-2020 08:14 PM)Jonathan Busby Wrote:  Years ago, when I posted a Saturn assembly language fix to the HP49 list-processing bug, I went even further and re-wrote the entire HP48 list-processing subsystem in mostly Saturn assembly ( although the code hasn't been published ). I did test the code and the speedup was *massive*

I'd be very interested in finding out more about your efforts in the area of list processing enhancement. I've spent some time in that area as well, and would like to know more about what you focused on.

This may be off-topic for this thread, so feel free to move this to a different thread (or PMs) if more appropriate.

[EdS2]

Very interesting post, thanks - and interesting work behind it too.

(07-15-2020 08:14 PM)Jonathan Busby Wrote:  In conclusion, I think that the original HP48 software dev team cared more about space than speed, and that is why the HP48 is sluggish when it comes to the GUI.

Another possibility: time to market pressure. They had to produce their product and have it final and fully debugged in some limited time. The GC was just one of many things that needed to be done, and done right.

[John Keith]

(07-16-2020 08:06 AM)EdS2 Wrote:  

(07-15-2020 08:14 PM)Jonathan Busby Wrote:  In conclusion, I think that the original HP48 software dev team cared more about space than speed, and that is why the HP48 is sluggish when it comes to the GUI.

Another possibility: time to market pressure. They had to produce their product and have it final and fully debugged in some limited time. The GC was just one of many things that needed to be done, and done right.

Actually both:

"Life is short and ROM is full."-
Bill Wickes

[rprosperi]

(07-16-2020 08:25 PM)John Keith Wrote:  

(07-16-2020 08:06 AM)EdS2 Wrote:  Another possibility: time to market pressure. They had to produce their product and have it final and fully debugged in some limited time. The GC was just one of many things that needed to be done, and done right.

Actually both:

"Life is short and ROM is full."-
Bill Wickes

As often as this quote is used, I don't think it was ever as appropriate as used here, John. That had to feel good to post!

[Marcovecchio]

I'm wondering if no one ever tried to rewrite the HP 48s/g ROMs using all optimizations included in SpeedUI or MetaKernel. Since the ROM is a separate IC, which is possible to replace on the PCB, that would be a matter of finding a compatible flash ROM, and write the new ROM image to it.

Is that a viable idea? I have no idea on how complex the task would be, software wise, and I also have no idea if there are tools to do this kind of development on a regular PC.

Eduardo

[AnalogJoe]

My fav. calculator of all time is the 48GX, my second best is the 50g which is now being sold for an insane ammount of money. The 15C and 11C are both great aswell but nothing compared to the 48GX or 50G, they are good for crunching numbers thou.

Regarding the 35s, I have two of them, the first one seems to have firmware issues because it will return erroneous calculations and so on, I had to toss it. I also had a WS-34S but the keypad is the worst, a lot of missed keystrokes so I also had to quit using it.

More recently I've been using the Droid48 HP 48G emulator app for android, I miss the real keys but its a pleasure to have a 48G in my phone.

[John Keith]

(07-20-2020 03:54 AM)AnalogJoe Wrote:  More recently I've been using the Droid48 HP 48G emulator app for android, I miss the real keys but its a pleasure to have a 48G in my phone.

I prefer EMU48 (50g mode). Next best thing to a real calculator and 50 times as fast as a physical 50g. The only down side is that Port 2 is not available due to Android "security features".

[SammysHP]

(07-20-2020 11:01 AM)John Keith Wrote:  The only down side is that Port 2 is not available due to Android "security features".

It is available, but writing to it is rather unreliable. You have to duplicate the ROM and manually save the state. I had some issues with it, but it is good enough for libraries.

[DavidM]

(07-20-2020 01:58 PM)SammysHP Wrote:  ...You have to duplicate the ROM and manually save the state. I had some issues with it, but it is good enough for libraries.

I do something similar with m48+. I create a virtual 50g on my laptop using Emu48, store libraries in appropriate ports and working data in ram, then make a copy of the ROM file and rename with the required name that m48+ uses. Once copied to the phone, it presents the same emulated calculator that exists on the laptop. It's a bit of a pain, but at least I can use libraries in the preferred ports that way.

[HP67]

(06-24-2020 03:10 AM)Potato Wrote:  Hi,
I'm relatively new to HP calculators and had bought an HP 48S due to the appeal of having more than a 4 level stack (I'm probably not going to end up using the graphing features of it tbh), but when I received it today, it feels VERY sluggish compared to something like my father's HP 15C (bad comparison I know but that feels much better to use).

Should I sell it and buy an HP 35S instead?

The 48S is perhaps the most beautiful HP made and that is saying a lot. I hate the display and it is slow for programming but I have a buddy who uses one for a desk calculator and likes it. If it's in good shape there is no point in selling it except in case of dire need. They aren't making any more of them.

For me the G/GX is about the best possible balance between fast enough for most things with a reasonable display while reaching the peak of usefulness because of the menu layout. I hate the color scheme though. I can't imagine a 35S being nearly as useful as even a 48S.