Recovering from shutting down

[adrian4096]

The hp 48gx has trouble recovering from a shut down state. Which would be tolerable, if it didn't automatically shut down after some time.

[adrian4096]

System is arch, built from the https://aur.archlinux.org/packages?O=0&K=x48ng-git package.
Version is x48ng 0.36.0

[gwenhael-le-moine]

I witness that sometimes but can't find a way to reproduce it. I launched an instance this morning and it hasn't auto-shut-off yet (it's been many hours now.)

Keeping the issue open.

[adrian4096]

On my machines it also happens if i manually shut it down. Would any sort of logs help to debug this?

[gwenhael-le-moine]

Ah nevermind, it did freeze but I hadn't noticed because the screen stayed the same except for the ⌛ annunciator being on.

It's still a bit random. It freezes now when I turn it off manually but this morning it didn't…

[gwenhael-le-moine]

This bug also occurs in the original x48 in my test in the same environment (sway, wayland, Slackware-current.)

x48 hangs up sometimes after a manual OFF

[adrian4096]

For me the bug shows consistently in x48ng and never in x48

Screencast.from.2024-01-08.08-31-50.webm

[edson-acordi]

The same happens to me. When I minimize the x48ng window for a while (with x48ng LCD on), after maximizing it, the x48ng returns with the LCD off and I can´t turn it on. I need to close x48ng and open it again. And it keeps happening again after a while...

Note: occurs on v0.36.0. I have the old version v0.12.0 installed on another laptop that works fine (this problem happens sometimes, but less frequently).
OS: Ubuntu 22.04.3 LTS x86_64
Kernel: 6.5.0-21-generic

[MatMoul]

In my opinion, this bug is due to the sleep mode programmed in the ROM.

It is important to note that at the time it required 4 AA batteries.
When the HP48 was asleep, we had to press the ON button.

I looked for an option to deactivate in the HP menus but I found nothing.

Some possibilities would be:

• Send a signal every 4 minutes (not great).
• Send a signal when activating the window (acceptable?).
• Edit the ROM in assembly language (very hard)
• Other (brains request)?

[gwenhael-le-moine]

The actual issue is the emulator getting stuck and not responding after shutting down.

I can reproduce this by manually clicking Right-Shift + On. It sometimes gets stuck with the ⌛ indicator displayed, the screen as if on and the emulator not responding.

I thought of somehow preventing the OFF command (in the emulator, not touching the ROM) but I don't like this way much.

(Funnily while I was writing this my stuck emulator unstuck itself…)

I also tried to follow IDLE_TIMER, ticks_10_min in the source…

Investigation still ongoing, slowly because my brain is a bit fried lately.

EDIT: I see the same behavior (on manual OFF) in the original x48 0.6.4

[MatMoul]

I confirm that manual power off creates the same problem but I have the impression that the calculator goes to sleep faster than before.

By using the -T option, it takes longer to go to sleep and I have less trouble turning it back on.
It's not perfect because it still happens that I end up with the bug (probably inherited from x48).

When this happens, an x48ng -r fixes everything instantly but clear all data.

It would be interesting to make diffs on the data files.
Perhaps a write that not finish before the end of a timer.

[MatMoul]

It's crazy, after an hour of various tests, I encountered almost no bugs and that's without the -T option or any modification...
And if I restart x48ng after the bug, I don't need -r.

Could this be related to the PC timezone?

[gwenhael-le-moine]

No real progress here.

A kind soul sent me toward a workaround used (but no longer) in Emu48 ⇒ https://codeberg.org/gwh/emu48-mirror/src/branch/main/beep.48

This sent me on a path to procrastinate by putting the available Emu48 source in a git repo https://codeberg.org/gwh/emu48-mirror/ Can't do much with that on Linux but it can be a reference

This led me to continue procrastinating by resurrecting another hp48 emulator that also doesn't have this bug: https://codeberg.org/gwh/saturn_bertolotti

With https://codeberg.org/gwh/hpemu that's 3 other, different emulators to look into for a clue.

On another PC I tried to diff (cmp) between the state and ram of both stuck and not-stuck states but not much to see there for the moment.

Still investigating.

[gwenhael-le-moine]

I've pushed a release https://github.com/gwenhael-le-moine/x48ng/releases/tag/0.36.90 with a work-around.

[hpsaturn]

Hi, I have the same issue, but like @MatMoul mentioned is easy to handled using -T, and after happen the issue, use -r and you are able to have the control again. Sometimes the -r option, can't turned on easy the Hp again, it seems that it still "rebooting" for many time and some libraries stuck the HP when you have the expansion cards, but with some ON signals during the reboot step, should turn on the Hp again.

Around the option --inhibit-shutdown the bad thing is that it consume a lot of power.. in my RaspberryPi it takes one core at 100% of CPU.