AntOS Libraries

The hub for the AntOS libraries — storage, terminal, network, data, AI, and system access. Each is a native C library that C++ applications link directly, plus a Luau binding over it, so the same API serves both. Standard Luau deliberately sandboxes these capabilities away (see standard libraries); AntOS supplies its own, shaped to DBFS and the CM5 Linux environment — and does not sandbox them away from you.

Back to the Luau scripting hub. For the architecture behind these libraries — the two-layer model, the folder layout, the command PATH, and the standard-compatibility contract — see AntOS Libraries (design spec).

How the docs are organised

Every AntOS library is two units (see antos_library_design): a native core libantos_<name> and a thin Luau binding over it. Each therefore has two pages:

antos_<lib> — the native library reference: what it's for, its design, and the C core (libantos_<name>) that C++ applications link against.
luau_<lib> — the Luau binding reference: the exact require("<lib>") script API — functions, arguments, return values, [standard] / [antos] tags, and examples.

Writing a script? Start with the luau_<lib> pages. Writing a C++ application? The antos_<lib> pages are your API reference — those libraries are public, not internal plumbing.

These are one API, not two. A Luau script calling fs.dir() and a C++ program linking libantos_fs reach the same code, because the binding is a thin shim over the native core rather than a reimplementation. Nothing is reserved for the system, and there is no scripting tier you graduate out of — you pick the language that suits the job, and AntBASIC is a third way in. See Developing for the Ant64.

The libraries

Library	`require`	Reference	Bindings	Notes
`os`	global / `require("os")`	antos_os	luau_os	Standard time/process is stock Luau, untouched; AntOS only adds host bits
`io`	global / `require("io")`	antos_io	luau_io	Standard Lua file handles; drive-letter paths + optional DBFS tags
`fs`	`require("fs")`	antos_fs	luau_fs	AntOS filesystem extras — dir, stat, mkdir, tags, query
`db`	`require("db")`	antos_db	luau_db	Raw DBFS/SQLite — custom tables & advanced SQL, below `fs`
`floppy`	`require("floppy")`	antos_floppy	luau_floppy	Real floppies at flux level (Greaseweazle) — read/write, decode, copy, inspect; auto-mounts as a drive letter (design)
`terminal`	`require("terminal")` (alias `term`)	antos_terminal	luau_terminal	Coloured output + application mode
`audio`	`require("audio")`	antos_audio	luau_audio	System audio — `audio.buzzer` (via Clicky)
`imgui`	`require("imgui")`	antos_imgui	luau_imgui	Windowing — script windows in the ImGui desktop (design)
`gui`	`require("gui")`	antos_gui	luau_gui	Retained/event UI over imgui — the app default (design)
`net`	`require("net")`	antos_net	luau_net	HTTP, DNS, sockets, diagnostics
`data`	`require("data")`	antos_data	luau_data	JSON, base64/hex, checksums & hashing; MFM/GCR disk codecs
`crypto`	`require("crypto")`	antos_crypto	luau_crypto	Ed25519 signing, HMAC, TLS CA trust store
`sys`	`require("sys")`	antos_sys	luau_sys	Tasks, memory, uptime, event log
`probe`	`require("probe")`	antos_probe	luau_probe	Tagged-memory breakpoints — sync to a running simulated system without altering it (design)
`led`	`require("led")`	antos_led	luau_led	RGB(W) status LED string (via Clicky)
`nfc`	`require("nfc")`	antos_nfc	luau_nfc	PN532 tags — UID, NTAG, Mifare, NDEF
`clipboard`	`require("clipboard")`	antos_clipboard	luau_clipboard	Shared text clipboard
`image`	`require("image")`	antos_image	luau_image	Image codec — PNG, Atari PI1/PC1; screen capture
`accelerator`	`require("accelerator")`	antos_accelerator	luau_accelerator	Two graphics backends — FireStorm hardware, or the always-available software chipset (design)
`sprite`	`require("sprite")`	antos_sprite	luau_sprite	Movable image objects — hardware or software-chipset backend; a stage target (design)
`motion`	`require("motion")`	antos_motion	luau_motion	Path sequences — turtle, sprites & animation, run in the background (design)
`stage`	`require("stage")`	antos_stage	luau_stage	Animation/interaction substrate — one tick, target registry, event bus (design)
`tween`	`require("tween")`	antos_tween	luau_tween	Property animation — colour, alpha, scale, over easing (design)
`collision`	`require("collision")`	antos_collision	luau_collision	Overlap detection — bounds, layers, enter/stay/exit events (design)
`timeline`	`require("timeline")`	antos_timeline	luau_timeline	Sequencing — parallel/sequential arrangements, seekable (design)
`physics`	`require("physics")`	antos_physics	luau_physics	Opt-in deterministic physics — bodies, forces, fixed-step (design)
`input`	`require("input")`	antos_input	luau_input	Per-tick input — buttons, axes, actions, record/replay (design)
`spawn`	`require("spawn")`	antos_spawn	luau_spawn	Target lifecycle — pooled spawn/despawn, bounded registry (design)
`particles`	`require("particles")`	antos_particles	luau_particles	Emitters — pooled, seeded-random transient targets (design)
`camera`	`require("camera")`	antos_camera	luau_camera	Viewport transform — follow, shake, zoom, bounds (design)
`state`	`require("state")`	antos_state	luau_state	Per-target state machines driving animations (design)
`path`	`require("path")`	antos_path	luau_path	Waypoints, splines, steering — emits motion (design)
`tilemap`	`require("tilemap")`	antos_tilemap	luau_tilemap	Grid worlds — tile collision, layers (design)
`netsync`	`require("netsync")`	antos_netsync	luau_netsync	Deterministic multiplayer — lockstep / rollback (design)
`videotext`	`require("vt")`	antos_videotext	luau_videotext	Teletext page server (40×25, TCP)
`printer`	`require("printer")`	antos_printer	luau_printer	Network printing over IPP
`packer`	`require("packer")`	antos_packer	luau_packer	Archive pack/unpack (ZIP today)
`ftp`	`require("ftp")`	antos_ftp	luau_ftp	FTP server control
`telnet`	`require("telnet")`	antos_telnet	luau_telnet	Telnet (remote console) server
`xfer`	`require("xfer")`	antos_xfer	luau_xfer	X/Y/Zmodem transfer over any stream
`netimgui`	`require("netimgui")`	antos_netimgui	luau_netimgui	Mirror the UI to a PC (remote ImGui)
`debug`	`require("dbg")`	antos_debug	luau_debug	GDB remote debug server
`wiki`	`require("wiki")`	antos_wiki	luau_wiki	On-device markdown docs
`gossip`	`require("gossip")`	antos_gossip	luau_gossip	Ed25519 trusted P2P social mesh
`ai`	`require("ai")`	AI subsystem	luau_ai	Talk to configured AI providers
`mcp`	`require("mcp")`	antos_mcp	luau_mcp	Model Context Protocol client (usable with no AI)
`basic`	`require("basic")`	antos_basic	luau_basic	The AntBASIC engine — program store, run, vars, save/load, inline assemblers (design)

(A hw library — I²C / SPI / GPIO / LED / cartridge access over the CM's Linux interfaces — is planned; it will follow the same two-page pattern as antos_hw / luau_hw once its surface is settled.)

The one rule that shapes all of them

Where an AntOS library overlaps a standard Lua/Luau library, it matches the reference contract exactly, and only ever adds — new names and optional arguments, never redefined behaviour. So:

os time is stock — os.time/os.date/os.clock/os.difftime behave as reference Luau; os.clock() stays process-CPU seconds. Wall-clock uptime is a different thing and lives on sys, not os.
Files are stock io — io.open(path, mode) returns a normal Lua file handle with the usual methods and nil, err failures. The only AntOS-visible difference is that path is a drive-letter string.
Genuinely-new functionality gets its own namespace — directory listing, stat, tags, and queries live on fs, not bolted onto os/io.

The same rule applies between AntOS libraries, not only against the standard ones. floppy is the worked example: its flux calls are not added to fs, because fs is metadata and structure over volumes that already exist and would stop meaning that if it grew a device surface. The two meet at one point — floppy mounts a decoded disk, fs then sees an ordinary catalogued volume. Correspondingly, floppy's pure transforms (MFM, GCR, the format checksums) live in data with the other codecs, while everything needing a recovered clock or a tolerance policy stays in floppy. Purity decides, in both directions.

Each binding page tags every function [standard] (behaves as reference Lua) or [antos] (an AntOS addition), so the boundary is explicit per call. The full rationale is in antos_library_design §5.

Storage model (context for `fs` and `io`)

AntOS storage is DBFS — a database-backed filesystem on SQLite, mounted as the D: drive, with user scripts under D:/scripts. Two characteristics shape the I/O libraries:

Files can be essentially unlimited in size — DBFS uses SQLite's incremental BLOB interface, so a file is bounded by disk space, not RAM. Large objects stream rather than being read whole.
It is structured storage — every file created or updated on D: is auto-catalogued (path, size, mtime, checksum, kind) in the same transaction as its data, whoever wrote it. The optional tags/meta on io.open / fs.tag layer user intent on top. See antos_library_design §7.

Files on plain FAT volumes (A:/B:/E:) work through the same standard io handles; only the DBFS extras (tags, catalogue queries) are D:-only.

Where to go next