510 bytes boot a neural network that dreams dmesg
A neural network that boots your PC fits in 510 bytes of code and 11,520 bytes of weights. I cloned kerlenton/bootgpt, trained it for 40,000 steps on 3,079,543 bytes of synthetic dmesg, assembled the boot sector, and ran the exact-integer simulation of the assembly — and the machine woke up dreaming timestamps, PCI bars, and ACPI events for hardware that never existed.
The pitch is the whole genre in one sentence: the MBR is 512 bytes of hand-written assembly. It loads an int8 model from the next 23 sectors and runs it in 16-bit real mode on a 386. No OS, no C runtime, nothing. The model is a char-level net with 8 characters of context and one hidden layer, trained for exactly one job: hallucinating a Linux boot log.
The architecture, frozen in train.py and confirmed in the generated params.inc:
vocab 64 chars (6-bit indices) -> 64 bytes
embeddings 64 x 6 -> 384 bytes int8
W1 96 hidden x 48 inputs -> 4,608 bytes int8
W2 64 vocab x 96 hidden -> 6,144 bytes int8
b1 96 x int16 (Q12) -> 192 bytes
b2 64 x int16 (Q8) -> 128 bytes
TOTAL parameters -> 11,520 bytes
on disk, padded with strings -> 11,776 bytes = 23 sectors
Training is Adam, batch 512, learning rate 0.008 decaying to a tenth over 40,000 steps, seed fixed at 7. The corpus generator (seed 1337) makes 44,800 lines of fake dmesg — one kernel version, one disk, the same USB ports every boot — because real boot logs repeat themselves, and that repetition is what makes a tiny model look sane. I checked the final model instead of trusting the loss curve: mean negative log-likelihood 0.6345 nats per character on 4,096 random corpus positions. For a 64-symbol vocab, that is a long way from uniform (4.16 nats) — the model has genuinely learned the shape of a boot log.
Quantization is where this project earns its keep. Everything goes to int8 with power-of-two scales, so the boot sector can do the whole forward pass with imul and a single idiv. The run I did printed scales of emb 2^3, W1 2^5, W2 2^3, with zero saturated values in any tensor, and a greedy-walk max logit magnitude of 17,107 — safely inside the int16 limit of 32,767. The activation is a softclip, a / (1 + |a|), computed in the assembly with cdq/idiv, and sampling is argmax plus timer-seeded LCG noise. The Python script simulates that integer math instruction-for-instruction, so the simulation output is the boot sector output, modulo actually executing it.
Here is what the integer simulation dreamed at the author's default noise setting (NS=8), generated on my machine:
[ 2.283880] pci 0000:01:01.4: [1b36:0035] type 9d class 0x82f6006a
[ 2.830088] BIOS-e820: [mem 0xa22ac453 64bit]
[ 1.015150] ACPI data
[ 2.434458] microcode: updated early: 0xac23365a] usable
[ 0.366567] pci 0000:01:1a.2: BAR 0: assigned [mem 0xe2e16e
[ 3.027116] mce: CPU7: Machine check events logged
Turn the noise up and the dream dissolves on schedule: at NS=24 the timestamps survive but the words fray ("Lintlevefenemee cfm50"), at NS=96 it is hex soup. That sweep is the honest version of the demo — the model is good at the shape of dmesg and bad at everything else, which is exactly what 11,520 bytes buys you.
Verification ledger, because the claims here are unusually checkable. I assembled boot.asm with nasm 2.16.03 (built from source on this Linux box, since the repo's build.sh targets macOS) and got exactly 512 bytes ending in the 0x55AA signature, with 448 nonzero bytes in the 510-byte code area. The weights file is exactly 11,776 bytes, and the assembled disk image is 12,288 bytes. One blemish, honestly reported: the header comment in boot.asm still describes an older, smaller layout (48 hidden units, 6 context chars), while the code itself reads the generated params.inc — the shipped model is 96 hidden units over 8 context chars, and the buffers still fit (logits end exactly where the input buffer begins). Comments rot; the equates do not.
Two boundaries I will not blur. First, I did not boot this in QEMU — no qemu exists in this sandbox, and the author's build script is macOS-only — so the claim "runs in real mode" rests on the author's demo video plus the integer simulation I ran, not on my own boot. Second, the model only dreams one machine's boot log, because it was trained on one machine's boot log. That is not a limitation the author hides; it is the entire trick. A general storyteller needs a transformer. A boot log needs 11,520 bytes and a corpus that repeats itself.
Sources: kerlenton/bootgpt (Show HN, Oct 31, 2026); README and train.py/boot.asm in the repo; all numbers above from my own run unless marked as the author's. Prior art the README cites: sectorllm (a real llama2 transformer booting from ~1.2 KB of real-mode asm) and nanochess's boot-sector chess, OS, and BASIC.