Source review: October 11, 2026. Pokémon mini research and hobby hardware use project-specific procedures. Verify the exact cartridge, firmware and tool version instead of assuming one universal workflow.
Identify the emulator and frontend
PokeMini is a Pokémon mini emulator, and its libretro core runs inside a compatible frontend such as RetroArch. Record both the core revision and frontend version; menus and options can differ between a standalone emulator and the libretro port. Start with one original homebrew image or a dump you are entitled to use. Keep the source image unchanged and record its checksum so a future compatibility test uses the same file rather than a similarly named download.
Understand BIOS and image expectations
The PokeMini core loads .min images. Its project documentation describes bios.min as optional, and the current repository README explains the bundled FreeBIOS fallback. Firmware absence should therefore be investigated against the actual core documentation rather than assumed to explain every launch failure. A hardware BIOS dump is a separate preservation artifact and should not be overwritten or distributed merely to configure an emulator. If you select a different BIOS, record that choice in the test log.
Check the controls that the software expects
The original platform includes more than a directional pad and two buttons. Map the C button, power input and shake action as documented by the core. A shake prompt that never responds may be a missing control binding rather than an emulation crash. Rumble also depends on the game, frontend and connected controller. Test one control at a time and retain a per-core or per-game mapping when needed. Avoid using an emulator's generic default mapping as evidence that the original game ignores a button.
Keep presentation choices separate from compatibility
Libretro documents LCD filtering, shading, contrast and palettes, and lists a native 96 by 64 base image with 72 Hz timing. These choices change presentation; they are not physical upgrades to an original handheld. When diagnosing flicker or poor motion, begin with the documented defaults and compare timing options separately from shaders. A screenshot captures one instant and does not establish how temporal LCD shading or a frame-rate conversion behaves during motion. Keep the exact options with any comparison recording.
Preserve native saves and states independently
The core documentation identifies EEPROM save files and emulator states as separate outputs. Copy both before updating a core or changing save directories. A state depends on the emulator's internal representation and may not survive a version change, while an EEPROM file represents persistent game data. The documentation also contains title-specific save limitations, so verify a save by restarting the game and reading it through the normal game interface. Do not rely on a state alone as proof that persistent saving works. For a bug report, include the original image checksum, versions, BIOS choice, settings and a short reproducible sequence. This makes a comparison useful to the emulator project and to a later preservation review.
Sources and project documentation
- Libretro: PokeMini core settings, saves and compatibility
- Libretro: PokeMini source and current core README
For original code, read homebrew development and research.