search

gwenhael-le-moine / x48ng

a reboot of the x48 HP 48 emulator
GNU General Public License v2.0
29 stars 3 forks source link

Recovering from shutting down #15

Open adrian4096 opened 8 months ago

adrian4096 commented 8 months ago

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.

Screenshot from 2024-01-05 11-16-45

adrian4096 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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

gwenhael-le-moine commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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

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

edson-acordi commented 6 months ago

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. OS: Ubuntu 22.04.3 LTS x86_64 Kernel: 6.5.0-21-generic

MatMoul commented 6 months ago

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:

gwenhael-le-moine commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 5 months ago

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 commented 5 months ago

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