# A 512 byte operating system that claims 768 bytes of memory

> bootOS is a monolithic operating system that fits in one boot sector, reloads programs by sector and keeps a 32-file filesystem on a floppy. Its README says it relocates itself to 0000:7a00 and requires 768 bytes of memory starting at 0000:7700, which are two different addresses.

**nanochess/bootOS** — bootOS is a monolithic operating system in 512 bytes of x86 machine code.

- Repository: https://github.com/nanochess/bootOS
- Stars: 2,149 · Forks: 120
- Language: Assembly
- License: BSD-2-Clause
- Published: 2026-10-12 · Updated: 2026-10-12 · Language: en
- Canonical page: https://hysenlabs.com/projects/nanochess-bootos

## Two different addresses are given for the same memory

The memory description contains a contradiction worth putting next to the size claim. The system is described as a monolithic operating system in 512 bytes of x86 machine code that fits in one boot sector, and it is compatible with the 8088, the processor in the original IBM PC. Then the placement sentence says it relocates itself at 0000:7a00 and requires further 768 bytes of memory starting at 0000:7700. Those two addresses do not describe the same region: 0000:7a00 is above 0000:7700 rather than below it, so a reader cannot tell whether the code lands at the standard 7c00 boot address, at 7a00, or at 7700 with the image above it. A boot sector is 512 bytes, and 768 bytes is one and a half of those, so the two numbers describe different quantities. Programs are run the same way, as boot sectors at 0000:7c00. Anyone writing their own loader for this system should resolve those addresses in the source rather than in the prose.

## Six interrupts, and every one of them clobbers registers

The system services are the whole API, and there are six. int 0x20 exits back to the operating system. int 0x21 reads a key and shows it, taking no entry parameters and returning the ASCII value in AL. int 0x22 writes a character to the screen, entered in AL. Then come the three filesystem calls: int 0x23 loads a file, taking a zero-terminated filename in DS:BX and a 512-byte source pointer in ES:DI, returning the carry flag clear when found and set when not; int 0x24 saves a file with the same parameters, reporting success or error through the carry flag; int 0x25 deletes a file by name. Three of the six declare that they affect all registers including ES, which is a design decision a real kernel would not make and a boot sector can afford, since the caller has no stack to unwind and no context to restore. Any program written against this API saves whatever it needs across a call.

## Thirty-two files, one sector each, one track apart

The filesystem is described precisely enough to implement from the text. It uses tracks from 0 to 32 on side 0, with the directory stored in track 0, side 0, sector 2. Each directory entry is 16 bytes wide and holds the ASCII file name followed by a zero byte. Since a sector holds 512 bytes, that is 32 entries, so a floppy can hold 32 files. Each file is exactly one sector, and its disk location is derived from its position in the directory: the first file sits at track 1, side 0, sector 1, the second at track 2, side 0, sector 1, and the thirty-second at track 32, side 0, sector 1. Deleting is the simplest operation in the design, a matter of zeroing a whole entry. So the geometry is a flat mapping from directory index to track number, which is why the disk is wasted beyond the first sector of each track and why the supported sizes are the three floppy formats of 360K, 720K and 1.44MB.

## Assembling takes one nasm or tinyasm command

Building the image is a single assembler invocation, with a choice of two tools. You need either the Netwide Assembler, nasm, from nasm.us, or Tinyasm, which is the author's own assembler hosted in the same organization as the project. The command line is identical in shape:

```sh
nasm -f bin os.asm -l os.lst -o os.img
tinyasm -f bin os.asm -l os.lst -o os.img
```

The flat binary format produces the raw image, the listing file gives you the disassembly with addresses, and the output is the disk image you write. Having a listing file in the command is a detail worth keeping, because with a system this size the listing is the documentation. Two scripts are provided for faster assembling, e.bat on Windows and e.sh on Linux, which means the chmod plus ./e.sh pair rather than a single executable. Nothing else is needed to build: no makefile, no toolchain, no dependencies.

## Creating a floppy image is dd, cat and a block count

Getting the image onto something VirtualBox will boot takes a padding trick, and the README gives the numbers. For emulation the image must sit at the start of a 360K, 720K or 1440K file, because VirtualBox detects the disk type from the length of the image file. The construction is:

```sh
dd if=/dev/zero of=oszero.img count=719 bs=512
cat os.img oszero.img >osbase.img
```

Seven hundred and nineteen blocks of 512 bytes produces the 360K file, and substituting 1439 gives 720K or 2879 gives 1.44M. On real hardware the same requirement becomes a boot sector write, and the README notes the disk space is wasted because only the first two sectors and then the first sector of each following track are used. For quick testing there is a shorter path: qemu-system-x86_64 -fda os.img runs it directly, which is the route to reach for before involving a virtual machine at all. The tested configuration is stated as VirtualBox on Mac OS X running Windows XP running bootOS, which tells you the vintage of the testing rather than the requirements.

## Six commands and a first-run format step

The command line is short. ver shows the version, with the note that it shows none at the moment. dir lists the directory contents, del filename deletes a file, format initializes the directory and copies the system to the boot sector again, which the README says is useful for initializing new disks, and enter creates another file by allowing up to 512 hexadecimal bytes to be typed. The enter command has two details that matter in practice. The line size is 128 characters, so input has to be broken into chunks of 4, 8 or 16 bytes. And pressing Enter at the h prompt copies the last executed program under a new name, which is how a working program becomes a stored file without retyping its bytes. The worked example types a Hello world program in hex, names it, lists the directory, and then runs it by typing its name.

## Where bootOS is the wrong tool

Four cases, and they are not close. The first is anything with real storage: 32 files of 512 bytes each is about 16 kilobytes of user data on an entire floppy image, and there is no way to grow it without redesigning the filesystem. The second is multi-user or multi-task work, since there is a single command line and one program at 0000:7c00, and int 0x20 is the only way out of a program. The third is security of any kind. There is no memory protection, no privilege concept and no isolation between the kernel and the program it is running, so any code a reader types has the same access to the machine as the operating system itself, which is the correct behavior for a teaching system and disqualifying for anything else. The fourth is 64-bit or modern hardware as a target. Compatibility is claimed with the 8088 and the Atomchess program in the software list is marked as requiring a 286 at minimum, so the supported range is the original PC era and a few years after it. What bootOS is genuinely good for is the thing it was built to be: a complete system you can read end to end in one sitting.

## Conclusion

bootOS suits someone learning what a boot sector can do, or writing code under a hard size budget, since the whole system is one assembly file and one 512-byte sector with a six-call API. It does not suit real work: storage is 32 files of one sector, memory is under a kilobyte, and there is no memory protection between the kernel and a program. Before building it, read the relocation addresses in the source rather than in the prose, assemble with the listing output, and pad an image to 360K before handing it to VirtualBox.

## FAQ

### How big is the bootOS operating system?

One boot sector, described as 512 bytes of x86 machine code, and compatible with the 8088. The README also states that it relocates itself at 0000:7a00 and requires 768 bytes of memory starting at 0000:7700, which are two different addresses.

### How do I build the bootOS image?

With nasm or with tinyasm, both using the same arguments: assemble os.asm as a flat binary, produce a listing, and write os.img. Scripts are provided for faster assembling, e.bat on Windows and e.sh on Linux.

### How many files can bootOS store?

32. Each directory entry is 16 bytes in a 512-byte sector, and each file occupies exactly one sector, with the first at track 1 and the thirty-second at track 32 on side 0.

### What system calls does bootOS provide?

Six interrupts: 0x20 to exit, 0x21 to read a key, 0x22 to write a character, 0x23 to load a file, 0x24 to save one and 0x25 to delete one. The filesystem calls report status through the carry flag.

### How do I run bootOS?

Write it to the boot sector of a floppy disk image, padding to 360K, 720K or 1.44M with dd and cat, or test it with qemu-system-x86_64 -fda os.img. On first run you should issue the format command to initialize the directory.

## Sources

- [Issues](https://github.com/nanochess/bootOS/issues)
- [License: BSD-2-Clause](https://github.com/nanochess/bootOS/blob/master/LICENSE)
- [nanochess/bootOS on GitHub](https://github.com/nanochess/bootOS)
- [README](https://github.com/nanochess/bootOS/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nanochess-bootos