Software · Nick Allevato

wr64-decomp

Sat, 24 Oct 2026 00:00:00 +0000

Wave Race 64 turned back into C that compiles, with Nintendo’s own compiler, to the exact same ROM.

make toolchain && make init # with your own US Rev 1 ROM as baserom.us.rev1.z64

What it is

Wave Race 64 shipped in 1996 as a compiled MIPS binary. This turns the binary back into C source, and that source, compiled with the same compiler Nintendo used (IDO 5.3), produces the same ROM down to the last byte. Every build ends with a SHA-1 check against the cartridge, so one wrong instruction fails it.

It’s a fork of LLONSIT/Wave-Race-64, which did the groundwork: the ROM split, the build system and the first nine hundred or so functions. This fork is written with Claude, and upstream doesn’t take AI-generated code, so it runs independently and nothing goes back.

Where it stands

Area	What’s in it	Matched
`libultra`	Nintendo’s N64 OS library	157 / 157
other	handwritten assembly, loose segments	55 / 55
`audio`	sequence and sound playback	227 / 228
`overlays`	courses and menu screens	148 / 151
`codeseg`	HUD, menus, text, popups, fades	210 / 219
`sys`	boot, threads, memory	35 / 37
`game`	race logic, riders, camera, water	470 / 501
total		1,302 / 1,348

The functions that don’t match yet keep a readable C attempt beside the assembly, with a note on what still differs. make NON_MATCHING=1 builds with those, so most of the game can already be read and changed as C. The ROM differs then, which is expected.

What it’s for

A matching tree is the floor everything else stands on: how the water simulation really works, bug fixes, a native port, and mods well past what patching a binary allows. The one I want is in 64 riders in Wave Race 64, which stopped short of growing the game’s four-rider arrays from the inside because the decomp wasn’t far enough along.

After the bytes comes the half of the job the hash can’t judge: names, structs, documentation. The hash will say when the bytes are right. Nothing will say when the names are. That argument is the bytes don’t remember the names.

You need your own copy of the game, US Rev 1, .z64. It isn’t in the repo and never will be.

Mission: Impossible Recomp 0.1.0

Wed, 21 Oct 2026 00:00:00 +0000

The 1998 N64 Mission: Impossible, statically recompiled into a native Linux program: 60 FPS, widescreen at any resolution, keyboard and mouse.

Releases → the AppImage → chmod +x, run, pick your ROM on first start

What it is

This isn’t an emulator. All 1,697 of the game’s MIPS functions are translated to C ahead of time by N64Recomp, compiled into an ordinary executable, and run on N64ModernRuntime, with RT64 doing the drawing. Before this the game had no decomp, no recomp and no PC port.

It went from first commit to all twenty levels loading and running at 59 to 61 FPS in under five hours. The next morning added smooth frame pacing, crash fixes and the first level mod.

What it adds

60 FPS without speeding the game up. Game logic runs on the video clock, and a hook interpolates root motion so walking stays smooth between the 30 Hz keyframes.
Keyboard and mouse. WASD, mouse-turn, right-click to aim. The mouse also drives the sniper scope and the gunboat turret.
Analog camera on the right stick.
Level tooling. The “Burp” archive format and level table are decoded, any level exports to OBJ with textures, and edited level data loads at runtime.

What you need

Linux with Vulkan, and your own copy of the cartridge as a .z64. The AppImage is one file; there’s a .tar.gz beside it if you’d rather. The release is built on Ubuntu 22.04, so most current distros run it. Building from source takes clang and a handful of tools the README lists.

Claude did the reverse engineering and I played it. The README says so and doesn’t apologise.

evo-sim

Wed, 07 Oct 2026 00:00:00 +0000

An open, numerical audit of Vox Day’s Probability Zero argument and of his critics, where every number reruns. The groundwork for a simulator you can tune yourself.

python3 -m venv research/.venv && research/.venv/bin/pip install -r research/requirements.txt matplotlib
research/.venv/bin/python -I research/checks/baseline_textbook.py # must pass before any check

What it is

Vox Day argues that evolution can’t fix enough mutations in the time available. His critics say his math is wrong. Both sides mostly argue in posts. evo-sim takes the argument apart into 234 claims, each with a verbatim quote, a formal statement, a prediction written down before the check, and three verdicts, then runs the checks: exact chains, forward simulation, coalescent models, real data where it exists.

It scores both sides with the same rules. His empty-pipe formula is exact for its premise; the ancestral pipe was full, not empty, and he has since withdrawn that start. Both of those are on the same scorecard, at the same length.

What you can do with it

Rerun anything. Seeds are fixed, the textbook baselines have to pass before any check is allowed to run, and a lint ties every claim to the argument tree and to where it came from. If a number on this site is wrong, the repo is where to prove it, and corrections from either side are invited as issues with a locator.

What it isn’t yet

It’s an AI-run audit with no independent human review. All 65 reviews are by the same model family and none were blind. Of 57 checks, 10 were registered clearly before their results. The book itself hasn’t been read; the audit works from Day’s posts and papers. Nobody named in it has been shown the findings. The README leads with those gaps, in a table, before any result, and so does this page.

The simulator you can tune is the stated next phase. Today it’s the audit that has to come first.

Chessbrief

Wed, 12 Aug 2026 00:00:00 +0000

Reads every game you have ever played on Chess.com and tells you the true things, in order of how well the evidence supports them.

open it ↗

What it is

Point it at a Chess.com account and it pulls the whole archive — five thousand games across three and a half years, in the case above — and writes a briefing. Not a dashboard. A briefing: a ranked list of claims about how you play, each one with the numbers that support it sitting directly underneath.

The top of the page picks a format and says why it picked it: blitz leads the briefing because it is the format with the most games still being played. That sentence is the whole design in miniature. Every choice the page makes about what to show you, it shows you.

The thing worth stealing

Analytics tools almost always overclaim, because a confident sentence is more satisfying than an honest one. This one is built to refuse.

Three habits do it:

Claims are ranked by evidence, not by drama. The heading above the first one literally reads strongest evidence on the page. The interesting-sounding finding does not get to go first just because it is interesting.

Intervals, not points. A win rate arrives as 48.5% with a 95% interval of 47.0–50.1%, so the reader can see when a difference is too small to mean anything.

It argues against its own framing. The page notes that a peak is the maximum of a noisy series — so part of any gap between where you are and your best number is just the arithmetic of maxima rather than ability you have lost. Then it does the thing almost nothing does: shows the gap, and declines to call it decline.

That last one is a tool deliberately giving up its most emotionally effective sentence because the sentence would not be true. Every rating graph ever drawn invites “you’re getting worse.” This one puts up the number and refuses the story.

What it actually finds

The claims are concrete and slightly uncomfortable, which is the point. The example above: 59% of recorded losses end in resignation, against only 33% of wins ending with the opponent resigning. Stated plainly — you concede earlier than your opponents do — and backed with the full breakdown of how games end, wins against losses, including the lopsided ones. Timeouts run 2.8× more wins than losses; abandons are 4 against 207.

None of that is a tip. It is a description, with the arithmetic attached, and it leaves the conclusion to you.

Technical details


Frontend	Next.js, React
Data	Chess.com public API — full game archive, synced on load
Scale	~5,000 games, 3.5 years, per-format breakdowns
Statistics	95% confidence intervals; explicit noise caveats on peaks
Structure	Ranked claims, each with its own evidence block

Tickler 0.20.4

Wed, 12 Aug 2026 00:00:00 +0000

A Paperclip plugin that puts every organization you run on one page, with one queue of what needs you, sorted by when you have to decide.

Settings → Plugins → Install Plugin → paperclip-plugin-tickler

What it is

Paperclip is an open-source control plane for running agents as a company — roles, budgets, issues, heartbeats — and a single deployment runs many companies with complete isolation between them. That isolation is correct for the agents. Company A’s agents have no business seeing company B. But the operator is not an agent. The operator is the one person all those companies have in common, and the product opens you inside one of them with a switcher for the rest.

Tickler is the missing floor. It belongs to no company, sits above the boundary, and answers one question: what needs me, across every org, right now?

It is a third-party plugin, not a Paperclip feature and not an official Paperclip project. It’s UI-only — it never modifies Paperclip itself, so upgrades don’t break it.

What it does

Every org on one line. Who’s working, a bar per hour of tokens spent, and the count of things waiting on you. That last column is the one no tool shows and the one that should decide where you go next. The token bars share one scale, so the org quietly burning through its budget at 3 a.m. stands out at a glance.

Answer in place. Approve, reject, reply, or pick an option on an agent’s question right on the queue row. You don’t open the item, you don’t enter the company, you don’t lose your place. Reject takes two taps, because a rejected approval can’t be undone and on a phone it sits a thumb’s width from Open.

Routines you can fire from here. Broken routines surface on their own. Pin any other routine and it stays at the top of the pane with a ▶ that runs it — press twice — and links the issue the run made.

Decide by. Mark each item Today, This week or Whenever, and the queue sorts itself into those buckets. It writes through Paperclip’s own decision triage, so the dates show up inside Paperclip too — this isn’t a private layer of sticky notes.

Trouble surfaces itself. Blocked projects, stalled runs, failed routines and overdue heartbeats rise to the top on their own. So do runs that have outlived their agent’s time limit: Paperclip has given up on those, nothing will ever close them, and they hold the agent’s run slot until somebody notices. Hovering an agent or a task shows its live narration, so “what is this thing actually doing” is a mouse move rather than four clicks.

Demo mode. ?demo=1 swaps in invented orgs, which is how every screenshot on this page was taken.

It works on a phone, which matters more than it sounds: the moment you most need to know what’s waiting is usually the moment you’re not at the desk.

How it got here

The problem came long before the plugin. I’d been circling it for years: the cost of crossing between organizations, and the fact that no tool ever absorbs it for you. Paperclip was the first place one person natively owns several organizations, so it was the first place the fix could actually be built.

The prototype shipped as Plica, Latin for “fold”. Nice idea. Nobody could guess what it meant. Version 0.7.0, shipped 27 September 2026, renamed everything — npm package, plugin id, route, CSS classes, repo — to Tickler. A tickler file is the office system that predates all of this: an accordion of dated folders whose only job is to bring a thing back in front of you on the day it needs you. That’s exactly what the decide-by queue does. The rename itself turned into a story about Latin roots and find-and-replace, told in name it after the paper.

If you were running Plica, uninstall it and install Tickler. Paperclip identifies plugins by id, so a new id is a new plugin, and you’ll need to re-enter your token thresholds. With an install base that small, a clean break beat a migration layer.

Three weeks out

Thirty-four releases in the three weeks since the rename, which is what happens when the thing you built is the thing you use all day.

npm counts about 4,700 downloads since launch, a little over 3,000 of them in the week of 5 October. I’d take both numbers with salt. A download is an npm install, not a person, and Tickler has an update button that runs one every time somebody takes a new version — so shipping 34 releases inflates the count all by itself. The better signal is quieter: somebody I’ve never met has been filing issues on the repo, and four of the releases since are things they reported or asked for.

A few of the releases I’d point at:

It updates itself, and it can undo that. 0.8.0 added an update button, because Paperclip’s Plugin Manager has none, and uninstalling to upgrade throws away the plugin’s config. 0.14.3 made the button wait until npm can actually serve the new version — for about five minutes after a publish, npm lists it as latest and still 404s the tarball. 0.17.0 went further: Tickler remembers which versions drew the page without an error in your browser, and when a new one crashes, the crash notice offers Roll back to the last good one, reinstalled from npm in place.
A crash costs only the part that broke. Before 0.15.1, any error took the whole page down to Paperclip’s catch-all, “failed to render”, with the reason buried in the console. Now one org with bad data loses only its own line, a failing pane loses only that pane, and each notice carries the error, a Try again, and a Report on GitHub that pre-fills the issue.
You can hide an org without archiving it. 0.19.0. A hidden org is dropped before Tickler asks the server for anything, so it costs nothing, and it keeps running in Paperclip exactly as before.
It admits what it is. 0.10.0 put a ? in the header saying Tickler is a community plugin, not an officially supported part of Paperclip. Somebody hitting a rough edge had no way to tell which of the two projects to be annoyed at, and the nearest obvious target was Paperclip’s issue tracker, where nobody who can fix Tickler is reading.

Most of the rest went into the left rail, which turned out to be the hardest thing in the plugin: a fixed height and four panes that each want more of it. The rail measures itself and hands each pane a header plus a whole number of rows, and Orgs or Recent can each be expanded at the cost of folding the panes beneath. Getting that to settle took more than one try. Twice the rail argued with itself until React gave up and stopped drawing the page. The better of the two: in full-screen mode, a pane’s header wrapped onto a second line, which changed the budget, which made its “+N more” chip disappear, which unwrapped the header, which brought the chip back.

The test I’d defend hardest is the least visible: a check:scroll sweep that drives the board at 32 window sizes in a real browser and fails any pane that offers a scrollbar while claiming to show everything. Two early releases went out with a pane scrolling over a single rounded pixel. Measuring with offsetHeight — an integer — against rows that are 28.297px tall will do that, and you cannot see it by looking.

Why it exists

I keep circling a thing I call the multi-organization problem: when your attention is split across several organizations, every crossing between them costs something, and almost no tool absorbs that cost for you. Every tool hands you a switcher — Slack’s workspace list, GitHub’s account menu, Chrome profiles — and a switcher assumes you already know where you’re going. Most of the time I don’t.

That’s also why a vendor will never build this for you: the vendor’s unit is the organization, and the problem lives between them. The argument is in a root to stand on; the ten-year version is the multi-organization problem.

zsh_custom

Fri, 30 Jan 2026 00:00:00 +0000

A shell suite that makes moving between sixty-nine projects cost one keystroke, and coming back after a reboot cost nothing at all.

What it is

Ten zsh files that load in numeric order, about 3,650 lines, sitting inside the home lab toolkit. The entire thing exists to answer one question faster than you can finish asking it: which project am I in, and what was I doing in it?

A single project_env/projects.json is the manifest of record — sixty-nine projects, each with an id, a display name, a repo, a canonical path, a colour, a category and a sort order. It is committed, so registering a project registers it on every machine. Everything else reads from there.

cs opens the fuzzy menu. Pick a project and the shell becomes that project: the working directory, the environment, its own .aliases, its SSH shortcuts, and the terminal background taking a hint of the project’s colour so a glance at the window tells you where you are. The context survives a shell restart, because the one thing worse than switching is switching and then having to remember.

Right arrow walks a carousel — projects, then hosts, then the client category, then back to projects — so every menu is reachable by counting presses rather than remembering a command.

The part I’d keep

The session registry, which is a fifth of the whole suite and the only part I’d call a design rather than a convenience.

A hook writes one record per Claude Code session, at start and at end. The interesting decision is that a session’s state is never stored — it is worked out at read time, from whether an end was recorded, which boot it happened under, and whether the pid is still a running process:


`live`	No end recorded, same boot, pid still running
`ended`	End fired — closed on purpose
`dead`	No end, same boot, pid gone — killed, OOM’d or crashed
`rebooted`	No end, recorded under a different boot — the machine went down underneath it

Only the last of those is a disaster, and it is the one crestore fixes: it reopens everything that was running when the box went down. The distinction matters because a stored flag would have been written by the process that died, which is exactly the process that cannot be trusted to write it.

That design came out of a measurement rather than a theory. The obvious assumption is that closing a terminal kills a session silently — it does not. Closing the terminal sends SIGHUP, which does fire the end hook. Tested, dated, and written into the source as a comment, because the next person to read it will assume otherwise.

The small one

ssh is wrapped. Modern terminals export exotic TERM values — xterm-ghostty, kitty — and a host with an older ncurses answers with unknown terminal type and a dead session. The wrapper downgrades TERM to xterm-256color for the remote side only, local terminal untouched. One environment variable turns it off.

It is four lines of real work and it removed a class of papercut that had been costing a minute at a time for a year. Most of this suite is that: not clever, just finally written down.

Why it exists

I keep circling the cost of crossing between contexts. Tickler is that argument in a browser — every organization on one page, one queue of what needs you. This is the same argument in a terminal, and it came first.

The claim in both is the same: a switcher assumes you already know where you are going, and the expensive part was never the switch. It was the reconstruction on the other side — which window, which host, which session, what was I in the middle of. The long version is the multi-organization problem; the shorter one is a root to stand on.