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
syncconcurrency 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
.machinefiles, a resolver and validator, andrealize: 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
OpusEncoderwith 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_NOFOLLOWenforcement,si_code/si_valuethroughsigqueue. - z3rs —
simplifyevaluates 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.