psx-cache

Use psx-cache to track which resources occupy a fixed set of slots. It manages keys, residency state, recency and pinning; your code owns the actual asset storage.

How the crate is organized

The single module exposes SlotCache<V, N, MAX_KEY> and SlotState. Slots move from Empty to Loading to Ready. Synchronous callers use get_or_insert_with; asynchronous loaders call begin_load, which returns a Reservation, and pass it to finish_load when the transfer completes. A reservation remembers its key, so a load that finishes after its slot was evicted and reused is refused with Stale instead of being stored under the wrong key.

Integration notes

Keys are bounded by MAX_KEY, and payloads must be Copy. Pin the working set before allocating resources that could evict it. Handle a failed reservation when no slot is available. Keep byte allocation and release policy separate from this index.

Complete host example

use psx_cache::SlotCache;

fn main() {
    let mut cache = SlotCache::<u32, 2, 8>::new();
    let reservation = cache.begin_load(3).expect("free slot");
    assert!(cache.is_loading(3));
    cache.finish_load(reservation, 42).expect("slot still owned");
    cache.pin(3);
    assert_eq!(cache.get(3), Some(&42));
    cache.unpin_all();
    cache.evict(3);
    assert!(!cache.contains_ready(3));
}

Run as a host binary with a path dependency on sdk/crates/psx-cache; it does not touch hardware.

API, dependencies and source structure

SDK revision f2fec1c301f1. Structure, dependencies and features below come from this revision.

The PS1 reference includes all Cargo features. The manifest below shows which features are enabled by default.

Dependencies

No runtime Cargo dependencies.

Cargo features

This crate declares no Cargo features.

Read the complete manifest and feature comments.

Source layout

The list includes internal implementation and test files. Public modules, types, functions and their signatures are indexed in the API reference above.