What an XCI file is on a listing

An xci file on this catalog is the written form of a cartridge dump. The physical cart is not on the desk and is not shipped from this site. What the listing holds is a fact: this title was stored as a cartridge image. This page tells that story as catalog language. It does not walk through an install, and it does not become the XCI filter.

Searchers who type xci file usually want to know what the letters mean next to an official name. Searchers who type switch xci usually want rows that carry the cartridge token. You can scan those rows on the XCI filter, then open a card. This article stays with the dump-as-fact: how the line is worded, why the token sits next to the official name, and why Get the ROM is a separate control.

The NSP file page already owns the package definition. NSP vs XCI already owns the side-by-side table. This leaf keeps a narrative so the two format pages do not clone each other.

From a cart to a catalog line

A cartridge dump starts as a plastic cart with a game on it. Someone later stores an image of that cart. This catalog does not narrate that bench and does not claim the image is authentic. It only prints the result when the fact exists: the row says XCI. That is the same class of fact as a listed size or a genre. It is not a claim that the image will run on a given console, and it is not a store listing.

On a stored row the formats field is xci, or nsp xci when a package fact is stored on the same title. The card turns that field into the XCI token on the facts list and on a file row. The official name stays the H1. Help pages do not add XCI to that heading. The token is a later line, not a suffix on the title.

The listed size is size_label for that row. If a title also has an NSP fact, the card still does not add two sizes together. Each format token is its own fact. Size is its own field. Empty size_label is omitted. Empty firmware, publisher, or title id lines are omitted the same way. This catalog does not invent a dump bench so the story looks complete.

A reader who only wants cartridge rows can stop on the filter, but the useful object is still the card. On the card the dump sits next to the official name, not instead of it. Genre, when stored, tells you the subject hub that title belongs to. Publisher and developer, when stored, are facts about the title, not about the cart. Title id, when stored, is an identifier for that listing. None of those fields replace the XCI token, and the XCI token does not replace them.

People who want a list of cartridge-token rows should leave this URL and open the XCI filter, then a title card. People who want the full browse should Open the catalog. This page will not grow a grid of games. A narrative that becomes a second filter is a clone, and this host does not need a clone.

How the listing holds the dump

The button is not the dump. Get the ROM appears only when a first-party file is stored on this host. The XCI token can still be true as metadata when the button is absent. How to read a title listing labels the cover, the facts list, the file rows, and that control so the card does not look like a store.

On the facts list you may also see genre, publisher, developer, title id, release date, region, languages, firmware, and game version — each only when stored. None of those lines is the dump. The dump is the XCI token. File rows repeat official name, XCI, and size_label when that size exists. Treat the file row as a fact line, not a transfer.

If you need NSP explained as a glossary, read the NSP file page. If you need both formats on one table, use NSP vs XCI. If you need a missing title, Ask for a title. If a published cartridge row looks wrong, use Flag a listing. To keep scanning names, Open the catalog.

First-party download help explains Get the ROM as a path on this host. This leaf does not number console steps and does not promise a file will run. After you can read the dump as a catalog line, the filter and the card are enough.

FAQ