Z64

Generated by scripts/gen-format-pages.py from docs/data/format-metadata/, FILE_FORMATS.csv and docs/formats-master.csv. Do not edit by hand: change the source, then run the script.

N64 ROM Preview.

At a glance

How much Poka reads

B4 Summary. The container and metadata are read and summarised (counts, properties, structure), but the main content is not rendered.

Confidence: medium (the reviewer read the code). Basis: Reviewed 2026-10-26: read parsers/poka-n64-rom/src/main.rs (212 lines) and plugin.json. No unit tests or tests/samples.rs, and the corpus has no .z64, .n64, .v64 and .u64 sample. Covers .z64, .n64, .v64 and .u64. The card reads the first 64 bytes, normalises the three byte orders by the first word, and shows the internal name, game ID, region, version, byte order, clock rate, entry point, release and the two CRCs; the rest of the file is only measured. Judgement: B4 rather than B5, because the whole header is decoded and checked; nothing of the ROM content (code, graphics, sound) is.

What Poka does not read

• ROM content is not decoded: no code, graphics or sound
• CRC1 and CRC2 are shown but not verified
• The boot code and CIC chip variant are not identified
• Media type (cartridge, disk) in the game ID is not decoded
• The file size stops counting at 128 MiB

Libraries

Libraries Poka uses or has assessed for this format, with the status, licence and language the registry records.

• n64_cart (candidate; MPL-2.0 / LGPL-2.1+ / GPL-2.0+; Rust; https://lib.rs/crates/n64_cart) — Parses N64 ROM header metadata; only big-endian (z64) ROMs recognised; licence combination not confirmed.
• n64rom (candidate; MIT; Rust; https://github.com/saneki/n64rom-rs) — Library and n64romtool for header and IPL3 info, CRC checks and byte-order conversion; requires Rust nightly.

Sources

• parsers/poka-n64-rom/src/main.rs
• parsers/poka-n64-rom/plugin.json