bitbornv0.2

HANDWRITTEN MACHINE CODE / X86 BIOS

Software born
from raw bits.

We skipped the programming language.
We skipped the assembler.
We wrote the machine code ourselves.

No C. No Rust. No Assembly. No compiler.
Just 0s and 1s.

BITBORN / BOOT TRANSCRIPT01
BIOS · 16-BIT REAL MODE
bitborn v0.1
---------------------------
NO ASSEMBLY.
NO COMPILER.
JUST BITS.

Hello from raw machine code!

512 bytes. 100% handwritten.
ANIMATED TRANSCRIPT · NOT LIVE EXECUTION
512BONE SECTOR. EVERY BYTE EXPLAINED.
0101010110101010BOOT SIGNATURE / 55 AA

YOUR NEXT EXPERIMENT

Edit. Step. Repair.

Inspect the literal bytes, predict a result, then test it. Browser instruments use a bounded teaching model; the curated boot programs are also executed in QEMU.

01 / REMOVE THE TRANSLATOR

The CPU never
needed your language.

Normally, source code becomes machine code through a compiler or assembler. Here, we start at the other end. The canonical source is the binary encoding itself.

01Write the bits10111000 00101010 00000000

Three handwritten bytes. An opcode and a little-endian operand.

02Pack the bytes./tools/bitpack

Host-side Python turns each eight-digit group into one byte. No instruction translation.

03Boot the machineqemu-system-i386

BIOS loads the sector at 0x7C00. The x86 CPU executes the bytes.

02 / INTERACTIVE BINARY PLAYGROUND

One bit changes everything.

Click a bit. Inspect the bytes. See what the instruction means. Mnemonics below explain encodings; they never generate the target program.

CLICK ANY BIT TO FLIP IT · LEFTMOST BIT = MOST SIGNIFICANT

Tab enters the bits once. Arrows move between bits/bytes; Home/End move within a byte, Ctrl/Cmd + Home/End across the instruction. Enter/Space toggles the focused bit.

ASSEMBLY REPRESENTATION / EXPLANATION ONLYMOV AX, 42

RAW BYTESB8 2A 00

Inspection context: 16-bit default.

EDUCATIONAL SIMULATION

16-bit registers. Limited instruction subset. No native execution.

AX starts at zero. Reset the state to try again.

03 / VISUAL BOOT EXPLORER

512 bytes.
No hidden machinery.

This map comes from the real boot image. Inspect every byte, find the instruction boundaries, and follow the output loop in a bounded teaching model.

BOOT SECTOR / 0x7C00
InstructionDataPaddingSignature

OFFSET 0x000 → 0x1FF CLICK OR USE ARROW KEYS

Loading the actual boot image…

FOLLOW EXECUTION / EDUCATIONAL SIMULATION

The simulator models this program's instruction subset and teletype output. It does not run QEMU or emulate a complete BIOS.

    SIMULATED SCREEN OUTPUT
    Awaiting first instruction.

    SOURCE IMAGE SHA-256 loading…

    04 / THE REAL MACHINE

    This one
    actually boots.

    The browser examples above are teaching models. This capture comes from the handwritten boot image running in QEMU, using BIOS teletype output.

    Get the boot image ↗

    512-byte boot image ↓ · SHA-256 checksums · Canonical bits

    x86 · legacy BIOS · 16-bit real mode
    Educational experiment, not a production OS.

    Actual QEMU screen showing bitborn v0.1, NO ASSEMBLY, NO COMPILER, JUST BITS, Hello from raw machine code, and 512 bytes. 100% handwritten.
    REAL QEMU CAPTURE · NOT A GENERATED MOCKUP

    05 / THE EXAMPLES

    Small programs.
    Big understanding.

    Each example has binary source, an execution environment, annotations, and a reproducible validation path. Open the source before changing a bit.

    Explore the complete source collection →

    06 / THE BOUNDARY MATTERS

    Handwritten target.
    Ordinary host tools.

    The unusual part is the source of the executable instructions. Everything surrounding it stays practical, transparent, and reproducible.

    TARGET / RAW X86

    The bytes that execute

    • Manual eight-bit groups in .bits files
    • Opcode, operands, data, padding, signature
    • BIOS real mode, starting at 0x7C00
    • No assembler or compiler in the target path
    HOST / PYTHON + JAVASCRIPT

    The tools that explain

    • bitpack converts notation into bytes
    • bitinspect shows boundaries and annotations
    • bitverify checks the reproducible image
    • bitdiff identifies individual changed bits
    Read the architecture notes →

    07 / KEEP GOING DOWN

    A small beginning.
    A visible path.

    Every milestone earns its place with reviewed bytes and execution checks. The progress feed below is generated from the repository README at every website build.

    Loading current source progress…

    Read the roadmap and evidence →

    08 / QUESTIONS, ANSWERED

    Wait. Just bits?

    Isn't all software eventually binary?

    Yes. The distinction is where it begins. In bitborn, instruction bytes are authored directly as literal binary digits using AI-assisted editing. A compiler or assembler never chooses the target instruction encodings.

    Does “no Assembly” mean no instruction names?

    No. Documentation uses mnemonics such as MOV to explain a byte sequence. They are explanatory labels, not target source passed to an assembler.

    Can I boot this on a modern computer?

    The tested environment is QEMU’s x86 machine with legacy BIOS. Native UEFI does not load this raw sector as an EFI executable. Use the documented emulator commands.

    Are the browser tools running the boot image?

    The browser tools decode bytes and simulate a bounded subset of 16-bit instructions. They are educational JavaScript, not native execution or a complete x86 emulator. The separate QEMU capture shows real boot execution.

    Why do this at all?

    To make the invisible visible. Instruction fields, byte order, relative branches, BIOS calls, and boot signatures become decisions you can inspect rather than details hidden by a toolchain.

    OPEN SOURCE / MIT LICENSE

    The next byte
    could be yours.

    Study an encoding. Improve an explanation. Add a verified experiment.
    Make every bit count.