Pupdate for Analogue Pocket: Installation, Core Updates, and Asset Management

Pupdate's Role in Analogue Pocket Maintenance

Pupdate addresses the recurring maintenance required after openFPGA cores and related files change on an Analogue Pocket. Its scope covers more than core binaries. The utility can check and install Pocket firmware, retrieve assets from configured archives, apply display modes, manage Pocket setup data, back up Saves and Memories, repair core JSON, clear caches, remove unselected cores, and run version-specific or instance-specific workflows.

The intended audience is an Analogue Pocket owner who already has an SD card and may be comfortable changing a small JSON file. Pupdate does not present itself as a general emulator front end. Its unit of work is the installed core and the supporting files around it. That distinction matters because the documented Update All sequence can back up data, download assets, change installed cores, build instance JSON, and remove unselected cores during one maintenance run.

Pupdate also has a broader administrative side. Its settings expose directory locations, a GitHub token, archive configuration, display behavior, and local inventory support. This makes the project more relevant to someone who wants repeatable control over an existing installation than to someone looking for a single button that always performs the same set of changes. The README also tells users to use the latest release before reporting issues because older builds are not supported.

How Pupdate Processes an Update All Run

Update All is the clearest documented view of Pupdate's data flow. The first optional stage checks for firmware updates. The next optional stage compresses Saves and Memories into a ZIP under the configured backup path. Pupdate then installs or updates every selected core, downloads missing required assets for those cores, and optionally removes cores that are not selected.

The remaining stages are feature-specific rather than universal. Pupdate can run an instance JSON builder for supported cores, including the documented PC Engine CD flow, and can rename Jotego cores to friendly titles. Settings toggles determine whether optional stages run. This makes Update All an orchestration feature built from separate maintenance actions, not a single indivisible installer.

Core selection affects the result. The Select Cores menu supports Yes, No, and Ask policies for newly discovered cores. With Yes, new cores are selected automatically. With No, they are neither installed automatically nor prompted for. With Ask, each run can request confirmation. The README also documents per-core skipping and `pinned_version` behavior.

Version pinning is inventory-based. When `pinned_version` is set, Pupdate searches the inventory release list for that version. If the requested pin does not match a listed release, Pupdate skips the core, reports a message, and continues with the run. This is a useful safeguard for reproducible installations, but it also means a pin absent from the inventory cannot be resolved through the documented process.

Installing Pupdate and Running the First Update

For users who only want to run Pupdate, the README explicitly says not to clone the repository. Download the latest release, unzip it, and place the executable for the operating system at the SD card root or in the folder already used as the installation path. The release contents must therefore be obtained from the project's latest-release page before this procedure can be completed.

After launching that executable, the documented first real use is the interactive menu. Enter Settings to walk through the toggles, or edit `pupdate_settings.json` for advanced configuration. In the full-screen interface, Pupdate exposes the same options under the Settings tab. The application also accepts `--tui`, as shown by the README's reference to the full-screen UI, although the README does not give a complete executable invocation or a full CLI command list.

macOS users may encounter quarantine restrictions when running the downloaded script. The README documents this targeted command, which removes quarantine metadata from the Pupdate script path rather than applying a broad system change:

xattr -d com.apple.quarantine /path/to/pupdate

Use it only for the relevant Pupdate script and replace the path as appropriate. After the menu opens, a cautious first workflow is to inspect Settings, confirm backup and directory locations, and then run Update All. What the reader should see is Pupdate's guided menu rather than installation output from this tutorial, because the README does not define a command that launches the downloaded executable.

Core Inventory, Version Pinning, and Update Controls

Pupdate obtains core availability through the openFPGA cores inventory linked by the README. It can also use optional local inventory files, which is significant for users who need controlled or customized discovery. Other JSON resources extend the same data-driven design: `display_modes.json` supplies recommended display settings, `image_packs.json` lists downloadable image packs, and `pocket_extras.json` describes Pocket Extras.

A local `display_modes.json` placed next to the executable can override the hosted version when `use_local_display_modes` is set to `true`. Pocket Library Images use `pocket_library_images.json`, where entries define a `menu_title`, `entries`, labels, identifiers, GitHub coordinates, and sources. Each source can identify a release asset and a `path_under_extract` pointing to `.bin` files inside the ZIP. This structure explains how Pupdate can present remote catalogs without hardcoding every menu item in the application.

Not every core follows the same asset path. The README states that users supply their own ROMs for non-arcade cores when the configured archive does not provide them. Pupdate can fetch ROMs, BIOS files, and other files from archive.org, custom archives, or core-specific sources, but it cannot be assumed to acquire every required game file. Any adoption decision must account for where each core's assets will come from.

Display configuration is another source of operational choices. Recommended modes apply a curated list to cores that reference those modes. Selected modes can apply to all compatible installed cores or only chosen cores. The change policy can Merge with core defaults, Overwrite them, or Ask during each run. Reset commands can restore defaults for all or selected customized cores.

Backups, Cache Removal, and Destructive Settings

Pupdate includes maintenance operations that go beyond downloading files. Users can update selected installed cores, install selected missing cores, uninstall cores, prune save states, clear the archive cache, pin or unpin core versions, and validate or repair core JSON. These commands make it possible to limit an intervention instead of running Update All every time.

Backup Saves and Memories creates ZIP archives from the Pocket's Saves and Memories folders. By default, backups are placed in a `Backups` directory next to the executable, unless the configured path is changed. Directory Locations settings can override the backup saves path, archive cache, and temporary directory. The README does not describe restore behavior, backup rotation, or verification of a ZIP after creation, so a successful backup message alone should not be treated as a documented recovery guarantee.

The removal stage deserves particular attention. When enabled, Update All removes cores that have not been selected. Selecting the wrong cores can therefore change the installed set, and asset availability may vary by core. The README does not document an automatic restore workflow for an Update All run. Users who depend on pinned versions, customized display settings, or manually supplied assets should inspect those settings before enabling broad removal behavior.

Cache management also has a clear but narrow purpose. Clearing the archive cache removes locally cached archive data, while prune save states targets save-state material. Neither operation is documented as a general recovery or rollback command. Pupdate's repository layout includes tests and separate menu and CLI documentation, but the README does not state whether every maintenance action can be reversed automatically.

Pupdate Release and Extension Boundaries

Pupdate is released as a free utility under the MIT license. That license permits use and modification under its terms, but this review does not interpret those legal obligations. The repository includes `pupdate.csproj`, `global.json`, source directories, tests, and C# solution files, so building from source is structurally possible. However, the README recommends a downloaded release for ordinary users and explicitly says older builds are not supported. It does not document the prerequisites or build commands needed to compile the project.

The project supports plugins for custom functionality, and its menu is documented separately in `MENU.md`. These extension points can matter to developers who need behavior beyond the stock workflows. The README does not explain plugin discovery, interfaces, compatibility promises, or sandboxing, so plugin capability should not be treated as a stable public API without inspecting those files.

A real alternative is managing the Pocket SD card manually with separate core archives, firmware downloads, and file-copy tools. That approach gives direct control over each downloaded artifact and avoids Pupdate's inventory and Update All orchestration, but it does not provide Pupdate's documented display-mode selection, version pinning, save backups, asset archive handling, or core JSON repair in one utility. Pupdate is consequently more useful as a maintenance manager, while manual management can be clearer for one-off or highly customized installations.

The repository is not archived, and its last push was on 2026-09-21. Recent release history includes 5.8.0 on 2026-09-10 with new coin-op key support and 5.7.0 on 2026-08-31 with menu reorganization. The README's instruction to use the latest release is therefore important: release numbering and feature changes do not align with a single simple upgrade path.

Editorial conclusion

Analogue Pocket owners should consider Pupdate when repeated core, firmware, asset, and setup maintenance is the goal. It is a poor fit for users who expect it to supply copyrighted non-arcade ROMs or who require a fully documented CLI workflow. Verify first that the latest release runs on the selected operating system, that the intended inventory source is reachable, and that backup and removal settings match the local SD card layout. On the documented workflow, adopting Pupdate means accepting its inventory-driven maintenance model and its responsibility to preserve user-managed assets before Update All removes unselected cores.

Frequently asked questions

Official sources

1. License: MIT
2. mattpannella/pupdate on GitHub
3. Project website
4. README
5. Releases