Fixing 'BIOS Not Found' and Bad Checksum Errors in Emulators

A “BIOS not found” message means the core did not recognize a required or optional firmware artifact where it expected one. “Invalid,” “bad checksum,” or “wrong firmware” usually means a candidate was found but its bytes did not match an accepted revision. The distinction matters: renaming the wrong file may silence a path error while leaving an incompatible firmware image.

Use only firmware dumped from hardware you own through a lawful method applicable in your jurisdiction. RetroArch and Libretro explicitly do not distribute copyrighted system files. Avoid BIOS packs, key bundles, and search-result downloads: they may be mislabeled, unauthorized, modified, or malicious.

Step 1: verify the exact core requirement

Load or select the core, then inspect:

Main Menu → Information → Core Information

The firmware section identifies names and whether files are present, missing, optional, or required. Confirm the exact core: two PlayStation cores can accept different revisions or use different subdirectories. Also read that core’s current official documentation; menu data can lag a package if core-info files are stale.

Do not assume every system requires original firmware. Some cores provide high-level reimplementations, while others need firmware for boot or compatibility. Adding an unnecessary BIOS can change behavior and should be documented as a configuration choice.

Step 2: identify the configured System/BIOS directory

RetroArch shows the active location at:

Settings → Directory → System/BIOS

The path may differ between portable, Flatpak, mobile, Steam, and operating-system packages. A guide that names a generic system folder does not prove that your build is using it. Save the current configuration and verify the displayed path.

Some cores require a subdirectory such as dc/, not the System/BIOS root. Follow the core page exactly. Do not scatter duplicates across the content directory, application directory, and home folder in hopes that one will work; that makes later auditing ambiguous.

Step 3: match the exact filename and extension

Compare spelling, extension, and capitalization character by character. Filesystems vary in case sensitivity, and hidden extensions can create names such as firmware.bin.bin. Inspect the actual filename rather than the label shown by a simplified file manager.

Do not rename a compressed .zip or .7z archive to .bin. Unless the core explicitly documents archive support for firmware, extract your own verified dump into the required location. Confirm that an operating-system security feature or sandbox has not left the file available only in cloud storage without local bytes.

Step 4: compute the documented hash

Libretro’s BIOS hub lists accepted hashes, often MD5, on core pages. Use the same algorithm the documentation specifies; an SHA-1 result cannot be compared with an MD5 string.

macOS:             md5 filename.bin
Linux:             md5sum filename.bin
Windows PowerShell: Get-FileHash filename.bin -Algorithm MD5

Hash a copy before and after transfer. An exact match verifies byte identity with the documented revision; it does not establish who owns the file or where it came from. If the hash differs, do not hex-edit, truncate, pad, or download a replacement. Re-dump from your own hardware and compare again.

Step 5: distinguish region and hardware revision

Consoles can have multiple firmware revisions across regions and manufacturing runs. A legitimate dump may still be unrecognized by a particular core. Use the list of accepted filenames and hashes rather than assuming that PAL content always needs a PAL BIOS or that every same-region revision is interchangeable.

Where a core supports several accepted BIOS files, choose the one documented for the content and desired behavior. Record the hash, hardware model, region, and dump method. Do not distribute that firmware with a bug report.

Step 6: check readability without elevating the emulator

The normal user running RetroArch must be able to read the file and traverse its parent directories. On Linux and sandboxed packages, a root-owned folder or missing portal permission can look like missing firmware. Correct the directory through the package’s supported configuration and user permissions.

Do not launch RetroArch as root or administrator to bypass the error. Emulators parse complex content and cores; unnecessary privilege increases the consequences of a vulnerability. Keep System/BIOS in a user-controlled directory supported by the package.

Step 7: remove ambiguity from duplicates and overrides

Search only the configured RetroArch directories and known old profiles for duplicates. A whole-filesystem command such as find / is noisy, crosses protected and mounted locations, and can expose unrelated filenames. List each candidate’s absolute path, size, timestamp, and hash.

Temporarily move extra copies into a quarantine folder outside all search paths, preserving them unchanged. Leave one verified file at the documented path. Check whether a per-core system-directory option or custom config redirects lookup.

Step 8: restart and read a fresh log

Fully quit and reopen RetroArch after changes. Revisit Core Information, then generate a log if the status remains missing:

Settings → Logging → Logging Verbosity → On
Settings → Logging → Log to File → On

The log can reveal the resolved System path and requested filename. Sanitize personal paths before sharing it. Report the expected hash and your computed result, not the firmware itself.

Step 9: prove the repair with a controlled boot

Use one legally dumped, known-good title supported by the core. Boot from a clean start rather than a save state, because a state may bypass or embed firmware-dependent state. Confirm the expected startup behavior, create an in-game save, quit cleanly, and launch again.

If Core Information recognizes the BIOS but content still fails, the firmware error is resolved; move to content structure, renderer, core options, or logging. Do not keep replacing a verified BIOS to solve an unrelated black screen.

Why clean-room replacement is a separate topic

Some emulator projects reimplement firmware behavior without shipping the manufacturer’s code. Whether that is complete enough depends on the system and core. A legal precedent about reverse engineering does not make every downloaded BIOS lawful, nor does owning hardware automatically define every jurisdiction’s copying rules.

The operationally defensible path is narrower: use official core requirements, preserve hashes and provenance, dump your own device where lawful, and never ask maintainers or users to exchange protected firmware.

Related:

Sources: