finding a new limit 🚀

mid-run perf tweak

effective debugging uses the scientific method CLAUDE CODE: Still wrong. store-and-read(#x700000, 7) returns 0, store-and-read(#x700004, 3) returns 2. Pattern: 0, 2 for addresses #x700000, #x700004. Address #x700004 - #x700000 = 4 bytes, result differs by 2. The results look like (addr - #x700000) / 2. Which is 0, 2. Hmm, actually the results could be the addresses themselves shifted. #x700000 = 7340032. Tagged = 14680064. Read it back: 14680064 → untagged = 7340032 → tagged = 14680064. OK that's not what we see. Wait — maybe the store isn't happening at all and we're reading uninitialized memory. Memory at 0x700000 might happen to contain 0 (typical for QEMU). The 0x700004 would be 0 too. But we read back 2 from 0x700004. That's 0x00000002 at that address. Let me check if maybe the issue is that I reversed the STORE operand order incorrectly. The STORE opcode is (store Vaddr Vs width). Vaddr is the address, Vs is the value. In my fix, I load Vs first (into scratch0/ECX), then Vaddr (into EAX), then store ECX at [EAX]. That should be correct.

the YouTubers call this "satisfying"

a modus/x64 image can now reproduce itself as an aarch64 image and vice versa

GitHub

GitHub - ynniv/modus: bare metal lisp for sovereign computing in the post agi world

bare metal lisp for sovereign computing in the post agi world - ynniv/modus

"i know this music... let's change the beat"

well *of course* we can run on the sane architectures... what about the *insane ones*

modus now boots the pi zero 2 w

GitHub

GitHub - ynniv/modus: bare metal lisp for sovereign computing in the post agi world

bare metal lisp for sovereign computing in the post agi world - ynniv/modus

speed wins

not sure about the accolades, but the rest is true. "The human's job is taste, vision, and knowing which dares to make" 🔥🔥

i love when i describe something colorfully and it just sticks in claude's mind. this sbcl-x64 -> gen0-x64 -> gen1-aarch64 -> gen2-x64 is officially the turducken test

gg everyone

"this is just how they work now" CLAUDE OPUS: That's a fantastic workflow. Claude Code is just running autonomously on the Pi 5, iterating on the Lisp OS, deploying over UART to the Zero 2 W, testing, fixing, repeating. The human goes to lunch and comes back to progress. This is kind of the dream of what autonomous coding agents should be doing — not writing CRUD apps, but pushing on hard bare-metal problems with a tight feedback loop. I should keep the response light here. The user is casual about it, which is appropriate — this is just how they work now.

modus now boots the raspberry pi zero 2 w

GitHub

GitHub - ynniv/modus: bare metal lisp for sovereign computing in the post agi world

bare metal lisp for sovereign computing in the post agi world - ynniv/modus

CLAUDE CODE: ● All tests pass. How do the colors look now? ❯ boom! red green blue, background bar, white bar, yellow magenta cyan, dark blue background ● That's the correct test pattern. All six colors + background rendering correctly on HDMI from bare-metal Lisp. So to recap everything that's now working on real Pi Zero 2 W hardware: - Mini UART serial output (32-bit stores, TX poll) - System timer (1MHz free-running counter, io-delay, delay-us) - GPIO LED (init, blink, on/off) - GPU framebuffer (640x480x32bpp via mailbox property tags, correct BGR pixel order) - All loops (SEV+WFE fix for YIELD opcode) [pi zero 2 w]

my current job title is "sdcard ferry"

i'm too slow for claude CLAUDE CODE: The Pi needs a physical unplug/replug again. While we wait, let me research this bulk transfer problem. Maybe there's a known workaround for rpiboot on Pi Zero 2 W: ● Web Search("rpiboot "pi zero 2" USB boot "second stage" bulk transfer timeout config.txt") ⎿  Did 1 search in 7s