2026-08-30

Weekly open source: an emulator built from the bottom up, and H.266 nearly closes its corpus

The codec rounds carried on through most of the week, and then on Sunday a new project arrived with a burst of commits: rsemu, an emulator that deliberately starts at the bottom — the memory model, the clocks, the wires and the snapshot format — before any machine exists. By the end of the day it had a cycle-accurate 6502 and the NES around it. Meanwhile oxideav-h266 came within a handful of streams of its whole conformance corpus, and fstool learned to open encrypted volumes.

rsemu: framework first, then a NES

rsemu is "a multiplatform emulator in pure Rust, built from the bottom up." The README is explicit about the ordering: a generic framework comes first — address spaces, clock domains, wires, devices, buses and a translation IR — then CPU cores and peripherals, then machines described by a config file rather than compiled in. "If you want a NES, you write a .machine file." Starting low costs time before the first ROM boots; what it buys is one memory model, one clock, one snapshot format and one debugger shared by every machine. The design principles match the rest of the stack: no C, no FFI, an empty default cargo tree, unsafe denied crate-wide except in a few named places, a no_std + alloc core, and determinism as an explicit mode.

The first day's commits built exactly that sequence, one subsystem per branch:

  • Core — a property system, chunked versioned snapshots, wires (signal lines that carry source identity), a sync concurrency seam, address spaces with regions, flat views and dispatch, and the oscillator forest scheduler: one clock tree per crystal, exact integer ratios inside a tree ("the NES PPU advances exactly 3 dots per CPU cycle, forever").
  • The machine DSL — a lexer, AST and parser for .machine files, a resolver and validator, and realize: construct, map, wire, sweep, run.
  • A NES — cartridge images and the NROM board, a cycle-accurate APU, and the RP2C02 picture unit cycle by cycle.
  • The first CPU core — a cycle-accurate MOS 6502 interpreter, merged once it passed SingleStepTests in full, behind a conformance harness built before any core existed, plus a fuzz harness for the parser and snapshot decoder.

oxideav-h266: 50 of 56

oxideav-h266's scorecard went from 34P/12F/9U/1E to 50P/1F/5U/0E over two rounds. Round 452 added explicit weighted prediction on the translational inter path, the limited-EGk escape for residual levels (making LOSSLESS_B_3 byte-exact) and CCLM unavailable-side substitutions. Round 453 brought per-transform-block TuCResMode in the chroma deblocker — closing the chroma-margin failure family — reference picture wraparound (DMVR_A_3), weighted prediction on affine and SbTMVP CUs (WP_A_3), chroma quantization-group state, and per-slice LMCS with explicit virtual boundaries.

H.264 and H.265: encoders that use the whole spec

oxideav-h264 now encodes MBAFF frames, explicit weighted prediction with fade detection, multi-reference P coding with long-term references, MMCO and RPLM, multi-slice / FMO / ASO / redundant slices, SP/SI switching pictures, and an opt-in full trellis RDOQ; the decoder gained data partitioning, arbitrary slice order, redundant-picture discard and 12-/14-bit gates. oxideav-h265 got a recursive coding-quadtree encoder (CTB 32/64, RD splits, 4×4 DST intra), temporal MVP with multi-reference lists, adaptive mini-GOPs, non-uniform tile grids, CTU-level rate feedback, CBR with filler data, and HRD signalling with Annex C conformance.

Dolby and DTS audio

oxideav-dts, so far a decoder, gained a core encoder: a 32-band analysis QMF (the exact inverse of the synthesis bank), ADPCM prediction, transient modes, high-frequency VQ, entropy coding with two-pass allocation, dynamic range and joint intensity — validated by having an opaque reference decoder decode committed streams. oxideav-ac4 added dialogue enhancement in both A-JOC decoding modes and on the immersive route, static-core downmix synthesis into the object path, and a cargo-fuzz sub-crate whose five rounds of findings became bounds checks.

fstool: LUKS and qcow2

fstool can now read, write and format LUKS1 and LUKS2 volumes, read and write encrypted qcow2 images (and create LUKS-encrypted ones), follow qcow2 backing files and create overlays over them — all exposed through the CLI — with header-controlled allocations bounded. The crypto comes from purecrypto, so encrypted disk images stay inside the no-C stack.

Also this week

  • oxideav-opus — a unified OpusEncoder with the full §2.1 option set and the §4.5 normative mode transitions.
  • oxideav-h263 — the Annex J deblocking-filter encoder, PB-frame MVDB search, adaptive quantisation, and black-box cross-validation of every encoder family.
  • oxideav-ifc — Phase 3 of the BIM reader: named parameterised profiles, tapered sweeps, georeferencing, and EXPRESS WHERE-rule validation.
  • nixvm — syscall fidelity: real hard links on host mounts, O_EXCL/O_NOFOLLOW enforcement, si_code/si_value through sigqueue.
  • z3rs — simplify evaluates trig at special angles and folds comparisons of ground algebraic reals exactly.
  • graphitesql — more of the SQLite C API (get_table, the prepare variants, keyword introspection), released as v0.1.7.

Next week

rsemu has its framework and one machine; the obvious next step is more CPU cores and more boards on the same core, each with its own conformance suite. H.266 is down to its last few streams, and the encoders keep widening.