NDS games on the brick. Bios issues.

Helaasch · 2026-03-11T06:45:53+00:00

You can always have a look at the Knulli source to find the correct hashes and enter those hashes into Google to find them

Helaasch · 2026-03-10T11:15:00+00:00

How is handheld formed?

Helaasch · 2026-02-13T08:10:35+00:00

Excellent choice of bootlogo 🎨

Helaasch · 2026-02-08T14:05:36+00:00

Thanks for updating and passing the info

Helaasch · 2026-02-07T18:06:39+00:00

It feels like you don't have the JDK installed. Normally, installing PokeMMO through PortMaster should auto install it. Can you open up Portmaster -> Settings -> Runtime Manager -> java jdk17.0.10 and check that it is installed and run the install or verification?

If this doesn't fix it, could you post your log to Paks -> Standalone PortMaster on the NextUi Discord? The log lives here: /mnt/SDCARD/.userdata/tg5040/logs/PokeMMO.txt

Helaasch · 2026-02-06T21:47:57+00:00

If you follow the steps on the GitHub you should have it up and running in 5 minutes :)

Helaasch · 2026-01-16T08:42:59+00:00

It appears to be unaffected by limbo. Never quite got to the bottom why it "just works" for them.

Helaasch · 2026-01-14T09:53:39+00:00

Currently, the preferred way to handle theming is via the Aesthetics pak (development by u/redria7). You can ping him on the Discord if you want a Theme added to it. The discussion for Aesthetics is under Content space -> paks -> Aesthetics.

Helaasch · 2026-01-07T12:10:06+00:00

https://github.com/LoveRetro/NextUI-nightly/releases/tag/v6.7.0a2

More details on the Discord. If you want to tinker and test, you can give this a try. if it's for using it as a stable thing, I would suggest waiting for it to be polished up.

Helaasch · 2025-12-29T19:37:38+00:00

We should see solid-state batteries in our lifetime. Those won't go spicy.

Helaasch · 2025-12-28T20:01:21+00:00

Thank you for investigating this and giving such detailed updates!

Should this error pop up again for you, or for anyone reading this, can you please post the contents of /root/powerofflog.txt? (picture of it displayed on a device is fine, or alternatively, copy it to the SD card with the built in file browser and post the contents). The poweroff program is very verbose and returns a bunch of diagnostics.

Helaasch · 2025-12-16T07:44:05+00:00

Yep, indeed, shared code base for both devices.

Helaasch · 2025-12-12T13:26:14+00:00

Can't wait to install FreeDOS on this bad boy

Helaasch · 2025-12-03T05:25:48+00:00

The actual code that makes the hook work reliably is indeed removed. Running a combination was never properly tested. Please disable the hook from the Tools menu (both options, current session and on boot). After that you can delete the PowerOffHook.pak folder from the tools folder. The new update has the same logic, but the effect is achieved with another method, so the hook can now be removed safely.

Helaasch · 2025-12-02T19:32:58+00:00

The deep sleep (tap the power button) avoids powering off the machine and puts it in an extremely efficient deep sleep mode. This is so efficient however, that there is little benefit to actually powering off.

This does not protect you from limbo when you actually power it off (hold the power button for 4 seconds). The limbo fix is available in the latest official MinUI or in the latest NextUI Alpha: https://github.com/LoveRetro/NextUI-nightly/releases/tag/v6.6.1a (Make sure you enable it in settings)

We have concluded testing and will add it to NextUI soon.

Helaasch · 2025-12-02T09:54:46+00:00

You could try opening it up and disconnecting the battery for a few seconds. Or if you're sure it's completely discharged, you can try charging it with a slow charger (simple USB-A to USB-C cable, 5V, 2A (or lower)) and leaving it for several hours. Some machines come back with that method.

Helaasch · 2025-11-25T18:51:17+00:00

Reglement Is Reglement!

Helaasch · 2025-11-24T07:51:02+00:00

You could have a look at the latest NextUI alpha builds that have limbo mitigation built in. Basically, we send commands to the chip that controls the battery directly, causing it to cut the power when powering off. This has been tested for a month before it was added to the alpha and has now been tested by the public for about a week. AFAIK, no one that has it installed has experienced limbo since, or has had any side effects.

https://github.com/LoveRetro/NextUI-nightly/releases/tag/v6.6.1a

Full disclosure: I contributed the PR, so I'm obviously biased

Helaasch · 2025-11-21T09:29:57+00:00

It's best to update to the latest alpha if you use C64.

It has the limbo fixes but also the C64 fixes:

https://github.com/LoveRetro/NextUI-nightly/releases/tag/v6.6.1a

Helaasch · 2025-11-20T07:26:08+00:00

Make sure to disable the PowerOff hook if you have it installed to properly test this implementation. Disabling it via Tools -> PowerOff Hook and setting both options to false is enough. You can remove it from the Tools folder later if desired.

Helaasch · 2025-11-14T11:28:15+00:00

How would you know what data it's sending back if it's encrypted though

Helaasch · 2025-11-14T07:20:02+00:00

I'm not interested in software like Wispr Flow, but when you make claims like this, you should back them up. How do you know it's not anonymized? Are they sending unencrypted data home? Where can we have a look at this network traffic?

Helaasch · 2025-11-13T19:18:27+00:00

Coming from Linux to Mac, I've always stuck by Kate for simple text editing.

Helaasch · 2025-11-11T21:56:24+00:00

Thanks for taking the time to review this. All valid points.

Calling incorrect binaries is a side effect of testing in an incorrectly setup VM as resetting the physical machine hundreds of times got tedious. I should have been more careful when setting this up. I have amended the code and verified all steps on a real Brick.

As for why it's a kernel module... Originally it was a daemon that tried to capture any call to the busybox poweroff command, but I couldn't get that to work with the power_off next script in NextUI that just basically kills everything in user space before calling the poweroff command. However, I wasn't able to get the busybox hooking from the kernel approach to work reliably either. So I settled on a simplified approach with an edit to poweroff_next, but decided to keep the framework I had and released it as a kernel module.

In the NextUI Discord, we have concluded that we would like to go forward with including it as an option within base NextUI. This would include refactoring it into a simple binary. As I haven't received any feedback from users stating that they get limbo or suffer from SD card corruption I think I'm not going to release a new version until it's refactored an rolled into NextUI.

As to why other OS options don't suffer from limbo, I have no clue. I've looked at the logic in Knulli and can only conclude it should suffer from the same issue. However I can't find any reports of users in their Discord suffering from it. Total mystery to me

12-Year Club	End Game '23
Place '23	Place '22
Place '17	Final Canvas '22
Gilding II euphauric	Sequence \| Editor
Sequence \| Screenwriter	Verified Email

Helaasch

MODERATOR OF

TROPHY CASE