KNULLI Game Appears but Will Not Launch: Diagnose Emulator, BIOS, and Content Handoff

Safety and scope

FACT: This guide starts only when the exact game is already visible in its intended EmulationStation system on an RG CubeXX. Visibility proves that the frontend discovered and listed an entry. It does not prove that the content is complete, compatible, readable at launch, correctly linked to companion files, supplied with required firmware, or handed to the expected runtime.

If the game is absent, stop here and use KNULLI Games Not Showing Up. Do not use launch-failure troubleshooting to repair a discovery problem.

There is no single root cause or universal fix for a visible game that will not launch. The safe approach is to preserve the before-state, observe one ordinary launch, and follow only the branch supported by that evidence.

Before doing anything:

• change one variable at a time;
• preserve original games, archives, descriptors, playlists, companion files, saves, and states;
• use only legally obtained content and firmware;
• do not reset settings, delete files or folders, reflash, format, bulk rename, bulk extract, recompress, move a library, or perform bulk edits;
• do not rewrite configuration files or edit knulli.conf, batocera.conf, EmulationStation XML, generated RetroArch configuration, or core files;
• do not invoke a launcher manually or apply unsupported shell fixes;
• do not download copyrighted ROM or BIOS material;
• do not copy Firefly or Gladiator II system configuration into Scarab.

If valuable progress makes an emulator comparison risky, first use Back Up KNULLI Saves and Personal Data. A backup is a safety measure, not a diagnosis.

Short Answer

Record the RG CubeXX, exact KNULLI release, exact visible game entry, exact visible per-game Emulator value, and the observable result. Then make one ordinary, unchanged launch attempt.

Route the result instead of guessing:

• an exact warning or dialog goes only to the branch its wording supports;
• structured content is checked against the exact platform’s requirements;
• explicit firmware evidence goes immediately to the Missing BIOS guide;
• a recorded known-good launch baseline may permit one controlled emulator comparison;
• an unexplained return, black screen, hang, or unknown warning may justify fresh launch logs;
• a known-good same-platform control can distinguish a target-specific pattern from a broader one, but cannot prove corruption.

SOURCE-CONFIRMED: KNULLI builds a launch from effective EmulationStation settings and passes emulator/core choices into a configuration-generator/launcher handoff. The selector and logs describe configured handoff; neither independently attests which final binary or core executed.

Release matrix: identify the build first

Exact choices, labels, dialogs, paths, and log behavior can vary by release. Do not transfer an inventory or instruction from one release to another.

UNCONFIRMED until checked on the affected installation: the exact selector options, warning wording, and ancillary behavior available on that device. This article has no owner testing and does not claim an RG CubeXX observation.

Record the before-state

Before changing a selector, descriptor, playlist, or test artifact, record:

1. Device: RG CubeXX / H700.
2. Release: exact release name and build, such as Firefly 20241204, Gladiator II 20250813, or Scarab 20260511.
3. Entry: exact visible title and intended EmulationStation system.
4. Selector: exact visible per-game Emulator value, including AUTO if shown.
5. Result: exact warning/dialog, immediate return to the frontend, black screen, hang, or another observable outcome.

Treat AUTO literally. SOURCE-CONFIRMED: AUTO is inheritance from the next applicable settings layer; it is not one fixed emulator. The visible selector is launch-configuration input, not proof of final runtime identity.

Make one ordinary baseline attempt with that state unchanged. Record what happens and the attempt time. Do not cycle through retries. One targeted unchanged reproduction is allowed later only if fresh, correlatable launch logs are needed after the before-state has been captured.

If the game launches but the built-in controls no longer respond while an external controller works, stop launch diagnosis and restore handheld Player 1.

If the game reaches stable play, exit normally. Do not continue changing settings merely to seek a different explanation.

Decision tree at a glance

1. Is the exact game absent? Stop. Use Games Not Showing.
2. Did an exact warning or dialog appear? Record its exact wording and follow only the matching evidence branch below.
3. Is the item structured content? Check the precise platform/source requirements for its real extension, archive member, descriptor, companions, playlist, disc set, or package.
4. Does explicit evidence identify BIOS/firmware? Hand off immediately to KNULLI Missing BIOS Warning.
5. Does a fresh log or release-specific definition identify an emulator/core/generator issue? Keep standalone and libretro separate. Compare one installed alternative only if a recorded known-good baseline exists.
6. Is there still no supported route? Inspect fresh launch evidence, using one targeted unchanged reproduction only if necessary.
7. Would a control narrow the scope? Launch one legally owned known-good game for the same platform, build, and effective setting once, unchanged.
8. Still unresolved? Preserve a multicausal diagnosis and prepare the evidence packet for official or platform support.

A black screen, hang, or immediate return identifies failed launch behavior, not its cause.

Branch 1: exact warning or dialog

Trigger: A notification, warning, or dialog appears during the unchanged attempt.

Evidence: Quote the exact observed text, including punctuation when practical, and record the attempt time. Do not turn an approximate memory into diagnostic wording.

One bounded action: Route only when the wording itself supports the route:

• wording that explicitly identifies BIOS or firmware goes to the BIOS handoff;
• wording that explicitly identifies an unsupported or incompatible content format goes to the exact platform/content branch;
• wording that explicitly identifies an unavailable emulator, core, or generator goes to the release-bounded emulator branch;
• wording that does not match one of those categories remains UNCONFIRMED and goes to fresh logs.

Do not infer BIOS from a black screen, corruption from a return to the menu, or a core failure from a generic error.

Verification: The specialist branch must produce its own deterministic result. This article does not convert warning wording into proof of root cause.

Rollback: None for recording a warning. If a later branch changes a copied test item or selector, use that branch’s exact rollback.

If retaining a private screenshot for support, crop it to the exact warning or exact before-value. Redact ROM and library names, paths, BIOS details or hashes when sensitive, account data, network identifiers, and tokens. A screenshot proves only the displayed wording or selector value—not the hidden cause or runtime identity. No screenshot in this article is presented as an owner-tested RG CubeXX observation.

Branch 2: content handoff and platform-specific structure

A listed entry can still fail because the selected emulator does not accept its real content form, because a wrapper contains the wrong member structure, or because referenced companions cannot be resolved. Corruption and incompatibility remain hypotheses until evidence separates them.

There is no universal KNULLI extension or archive list. Use the exact KNULLI/Batocera system page or the emulator’s authoritative platform documentation for the affected platform and release.

Exact extension or content form

Trigger: The listed extension/content form may not be accepted by the effective launch configuration.

Evidence: Record the real extension and content form, exact platform, release, visible selector value, and the platform-specific source that says what is accepted. Do not rename an extension and call that conversion.

One bounded action: Inspect one preserved copy, or compare one legally obtained known-good title under the same platform, build, and effective setting. Change no BIOS or emulator setting during this comparison.

Verification: Record whether the control launches once while the target still fails, or whether both fail in the same unchanged state.

Rollback: Remove only the diagnostic copy, leaving the original untouched. The result may support a content-form or compatibility hypothesis; it does not prove that the target is corrupt.

Archive and member structure

Trigger: The visible item is an archive accepted for listing.

Evidence: Record the archive type, member names and structure, and the exact platform-specific archive rule. Listing the wrapper does not prove that its member is valid or readable by the selected path.

One bounded action: Perform read-only inspection, or test one copied archive/artifact only when the exact platform documentation supports it. Do not bulk-extract or replace the original.

Verification: Confirm that the required member and structure match the documented platform requirement, or record the unchanged result from one known-good same-platform archive control.

Rollback: Keep the original untouched and remove only the diagnostic copy. If the platform source does not document the structure, stop rather than generalize.

CUE, M3U, and other descriptors with companions

Trigger: The entry is a .cue, .m3u, or another platform-documented descriptor or playlist.

Evidence: Record its relative references, filename case, companion-file presence, and the exact platform/source requirement. A neat single entry can hide broken references to disc images or other members.

One bounded action: Prefer read-only validation. If a reference must be tested, correct only one reference in a copied diagnostic descriptor; never edit or replace the original.

Verification: Every required relative reference resolves with the documented case and structure, and the copied test either launches once or yields a narrower, specific error.

Rollback: Remove the diagnostic copy and confirm the original descriptor and companions remain unchanged.

Multi-disc content

Trigger: An M3U or documented playlist represents several discs.

Evidence: Record disc order, relative references, filename case, and companion presence. Presentation or hiding settings do not prove that the referenced files can launch.

One bounded action: Test one copied playlist containing documented relative references. Do not change emulator or BIOS settings at the same time.

Verification: The playlist resolves and starts its first disc once, or the same specific failure remains.

Rollback: Remove only the copied playlist. This article stops at initial launch; it does not troubleshoot disc swapping.

Computer, arcade, port, and packaged content

Trigger: The item is a computer package, arcade set, port, subsystem item, or another structured platform type.

Evidence: Record the exact platform, content form, release, and its official system-page requirements.

One bounded action: Apply one documented requirement to a copied/test item only. Do not turn a platform package into a generic “ROM fix.”

Verification: The platform-defined start condition succeeds once, or a narrower exact warning/log line appears.

Rollback: Restore the recorded before-state and remove only the test copy. Continue with the exact platform or upstream documentation rather than a universal extension list.

Branch 3: BIOS evidence—immediate handoff

Enter this branch only when at least one explicit indicator exists:

• an exact BIOS/firmware dialog;
• a checker result relevant to the named system;
• an exact firmware requirement for the configured core/platform; or
• a fresh launch-log line naming missing or questionable firmware.

Evidence: Preserve the exact wording/status, release, platform, configured core if known, and fresh timestamp.

Action and endpoint: Make no BIOS change from this article. Go directly to KNULLI Missing BIOS Warning for placement, hash, required/optional, and verification work.

SOURCE-CONFIRMED proof limits:

• some checker entries are optional or conditional;
• a missing checker entry may therefore be optional rather than the blocker;
• RetroArch Core Information showing Present proves path presence, not checksum correctness, a correct dump, or runtime use;
• checker status is routing evidence, not proof that firmware is the sole cause;
• even correct firmware does not exclude content, core/generator, storage-read, or platform-specific causes.

There is no rollback here because this branch performs no firmware modification.

Branch 4: emulator, core, generator, standalone, and libretro handoff

SOURCE-CONFIRMED: The broad path is effective EmulationStation settings → configuration-generator/launcher handoff → generated launch command. A visible selector value is an input. A log line naming an emulator or core is configured-handoff evidence, not independent proof of the final binary/core identity.

Enter this branch only if a fresh log or a tagged release/system definition identifies an unavailable or incompatible emulator, core, or generator, or shows that a guide’s choices do not exist in the installed release. Do not infer this branch from a black screen alone.

Baseline gate for changing an emulator

An emulator/core alternative is allowed only when the same game has a recorded known-good launch baseline and the exact prior selector value is known. Without that baseline, do not experiment; keep diagnosis open.

When the gate is met:

1. Record the exact prior selector value, including AUTO if that was the actual value.
2. Use only one alternative actually offered for that system on that installed release.
3. Follow Change the Emulator for One Game for selector mechanics rather than duplicating them here.
4. Launch once and record whether it reaches stable play or reproduces the failure.
5. Restore the exact previous value—not blindly AUTO.
6. Reopen the selector and verify that exact value.
7. Launch the recorded baseline again and verify that it still works.

If the alternative launches, exit normally. That one result does not establish a best emulator, universal compatibility, performance, accuracy, save/state portability, or final runtime identity.

Keep standalone and libretro separate

Use RetroArch/libretro diagnostics only when the effective family is supported by fresh evidence or a release/system definition. Do not apply RetroArch Core Information or Quick Menu diagnostics to a standalone emulator.

The KNULLI Quick Menu Not Opening guide becomes relevant only after a libretro session actually launches. The Quick Menu is not a pre-launch repair tool.

Branch 5: source-bounded fresh launch logs

Use logs when there is no exact route, the title immediately returns to the frontend, a warning is unknown, or prior evidence remains ambiguous.

The following locations are official Batocera documentation plus directly inherited/tagged-source-consistent KNULLI behavior; not tested here on RG CubeXX:

1. /userdata/system/logs/es_launch_stderr.log — inspect first; it may contain warnings or errors associated with the captured attempt when timestamp and content correlate.
2. /userdata/system/logs/es_launch_stdout.log — inspect second; it may contain informational or diagnostic launch output from that attempt.

Presence and useful content are not guaranteed on every build. Logs can be stale or overwritten.

Procedure:

1. Keep the recorded before-state unchanged.
2. If the ordinary baseline did not create correlatable evidence, make one targeted unchanged reproduction—no repeated retry loop.
3. Immediately confirm the log timestamp/freshness and correlation with that attempt.
4. Inspect stderr first, then stdout, through an access method that is already configured.
5. Quote only the minimum relevant line or lines.
6. Route only a specific line: for example, explicit firmware wording to the BIOS handoff, explicit format wording to the exact content branch, or explicit emulator/core/generator wording to the release-bounded branch.

Empty, ambiguous, or stale logs neither diagnose nor exonerate content, firmware, emulator/core/generator, storage-read, or platform-specific causes. A log is evidence from one attempt and is not necessarily complete or authoritative. A line naming an emulator/core documents configured handoff; it does not independently attest the final process or binary.

Never publish a complete raw log by default. Redact ROM paths and names, private filenames, usernames, hostnames, IP addresses, network shares, account IDs, achievement credentials, tokens, and unrelated library titles. If a log screenshot is retained privately, crop it to the minimum relevant line and apply the same redactions.

This guide intentionally contains no shell commands, launcher commands, verbose-mode toggles, configuration edits, or file-access tutorial.

/userdata/system/configs/emulationstation/es_log.txt is official Batocera frontend-path / directly inherited behavior; not tested here on RG CubeXX. Use it only when EmulationStation itself freezes, crashes, or fails. It is not a substitute for launch stdout/stderr and is not the default diagnostic for one game’s launch failure.

Branch 6: known-good same-platform control

Trigger: Evidence does not yet distinguish a target-specific problem from a broader platform/configuration problem.

Evidence: Identify one legally owned, known-good title for the same platform, KNULLI build, and effective setting. Do not change a selector, BIOS state, or content structure during the comparison.

One bounded action: Launch that control once.

Verification:

• if the control succeeds while the target fails, the evidence narrows toward target-specific content, references, revision, or compatibility;
• if both fail, the evidence remains consistent with a broader configuration, firmware, emulator/generator, platform, or storage-read problem.

Rollback: None; no setting changed. Remove a temporary test copy if one was introduced.

Control success does not prove that the target is corrupt. It also does not prove the innocence of all configuration or firmware factors; title-specific requirements can differ.

Verification and rollback matrix

After any reversible change, reopen the relevant selector or copied artifact and verify the exact original value/content. A vague “changed it back” is not a rollback check.

If the result remains unresolved

Do not fill an evidence gap with a reset, reflash, format, random core trials, or copied configuration. Keep the result explicitly multicausal.

Prepare this minimum evidence packet for official KNULLI, exact platform, or emulator support:

• RG CubeXX / H700;
• exact KNULLI release;
• exact platform and content form, without exposing private library details;
• exact visible Emulator value, including AUTO;
• exact observable result and attempt time;
• exact warning text, if any;
• whether one same-platform/build/effective-setting control succeeded or failed;
• only the minimum fresh, redacted stderr/stdout line when available;
• the one variable compared and confirmation that it was rolled back.

Do not attach full logs or library-wide screenshots by default. Do not expose ROM/library names, paths, BIOS details or hashes when sensitive, account identifiers, network identifiers, tokens, or unrelated titles.

For broader navigation, use the KNULLI on RG CubeXX Troubleshooting & Setup Hub.

What each result proves—and does not prove

FAQ

The game is visible. Doesn’t that mean its format is supported?

No. FACT: Visibility proves discovery/listing only. A recognized extension or frontend entry can still hand off incomplete, incompatible, misreferenced, or platform-specific content.

Should I keep launching it until the error changes?

No. Make one ordinary unchanged observation. Make one targeted unchanged reproduction only if it is needed to create and correlate fresh logs after recording the before-state. Repeated retries add risk without controlling a variable.

Should I switch away from AUTO?

Not as a guess. SOURCE-CONFIRMED: AUTO inherits from another settings layer; it is not one fixed emulator. A controlled alternative requires a recorded known-good baseline and exact rollback through the Change Emulator guide. Without a baseline, keep diagnosis open.

Can I rename the file extension to make it compatible?

No. Renaming is not conversion. Check the exact platform/source requirements and preserve the original.

Does a successful game from the same system prove this game is corrupt?

No. It narrows the issue toward target-specific factors, which can include structure, references, revision, requirements, or compatibility. It does not prove corruption or clear every firmware/configuration factor.

The BIOS checker says Present. Is BIOS ruled out?

No. Present indicates path presence, not checksum correctness, dump validity, or runtime use. Conversely, a missing checker entry may be optional. Use the BIOS branch only with explicit evidence, then follow the Missing BIOS guide.

Can I use RetroArch Core Information or the Quick Menu?

Only for a confirmed libretro path, and the Quick Menu only after a libretro session launches. Those diagnostics do not apply to standalone emulators and cannot repair a pre-launch failure.

Which launch log should I inspect first?

For a correlated launch attempt, inspect /userdata/system/logs/es_launch_stderr.log first and /userdata/system/logs/es_launch_stdout.log second. These paths are official Batocera documentation plus directly inherited/tagged-source-consistent KNULLI behavior, not tested here on RG CubeXX. Confirm freshness immediately and treat silence or ambiguity as unresolved.

Should I use es_log.txt when one game returns to the menu?

Not by default. /userdata/system/configs/emulationstation/es_log.txt is reserved for EmulationStation itself freezing, crashing, or failing; it is not a substitute for launch stdout/stderr.

Would a reset, reflash, format, or old config fix it?

Those are not appropriate one-game diagnostic steps. Do not reset, reflash, format, or copy Firefly/Gladiator II system configuration into Scarab. Scarab’s major-update configuration is incompatible with Gladiator II configuration.

Related diagnostics

• If the title is absent from the frontend, use KNULLI Games Not Showing Up.
• If KNULLI or RetroArch shows explicit BIOS evidence, use KNULLI Missing BIOS Warning.
• If you have a known-good baseline and exact rollback, use Change the Emulator for One Game.
• If a confirmed libretro session runs but its menu will not open, use KNULLI Quick Menu Not Opening.
• If a stable game accepts external input but ignores the built-in controls, restore handheld Player 1.

For other KNULLI/RG CubeXX symptoms, use the troubleshooting and setup hub.

Sources

Claims above use the labels FACT, SOURCE-CONFIRMED, and UNCONFIRMED to keep evidence limits visible.

• KNULLI About
• KNULLI Game Settings
• KNULLI Multi-Disc Games
• KNULLI Game Storage
• Firefly 20241204 release
• Firefly tagged launcher
• Firefly tagged system definitions
• Firefly tagged logger
• Gladiator II 20250813 release
• Gladiator II tagged launcher
• Gladiator II tagged system definitions
• Gladiator II tagged logger
• Scarab 20260511 release
• Scarab tagged launcher
• Scarab tagged system definitions
• Scarab tagged logger
• Batocera: Adding games and BIOS
• Batocera Troubleshooting
• Batocera Systems
• Libretro Quick Menu
• Libretro: Generating Logs
• KNULLI Games Not Showing Up
• KNULLI Missing BIOS Warning
• Change the Emulator for One Game
• KNULLI Quick Menu Not Opening
• Back Up KNULLI Saves and Personal Data
• KNULLI on RG CubeXX Troubleshooting & Setup Hub

Owner testing: NO. This article is source-bounded and does not claim an RG CubeXX owner test, an observed device dialog, or verified on-device access to the listed logs.