gbos.git/c/blk.c, branch mastergbos - a tiny Unix-flavored OS for the Game Boy Color (kernel, shell, coreutils in C, RAM filesystem)https://git.sl0p.foo/gbos.git/atom/c/blk.c?h=master2026-07-17T22:38:38Zrefactor: c/ -> usr/, compiled program blobs out of the source tree2026-07-17T22:38:38Zuseruser@clank2026-07-17T22:38:38Zurn:sha1:ba2d7ae1d7b319645b10aaa31a7f664f9f80c25c
Userland sources live in usr/ (fits the Unix theme better than 'c').
SDCC output .bin blobs land in build/usr/ with the other build artifacts
instead of littering the source dir; programs.asm INCBINs them from there.
Byte-identical ROM.
fs rewrite stage 2: inodes + root directory (block-based, persistent)2026-07-16T10:20:57Zuseruser@clank2026-07-16T10:20:57Zurn:sha1:4f2d40ca35e0e39886dc881d06256fc25ba27a77
- fs.asm: a real block filesystem on the persistent block device - superblock,
block/inode bitmaps, a 32-entry inode table (type, size, 8 direct block
pointers -> files up to 2 KiB), and a root directory of 16-byte entries.
Metadata cached in WRAMX; one-block data cache streams file/dir blocks.
- same syscall interface (open/getb/putb/list/remove) -> tools unchanged;
ls now enumerates until flist() runs out (16 files, was hardcoded 8).
- old 8-slot WRAM FS removed; cart RAM partitioned: process banks 0-7, disk 8-11.
- two register-clobber bugs fixed: alloc_block/alloc_inode returned the
bitmap-block number (write_bitmap clobbers C); db_use loaded the wrong block
on a transition (db_flush->write_block clobbers C) -> multi-block files broke.
- verified: 10+ files, multi-block (300-byte) files, delete, and persistence
across reboots. Debug 'blk' disk tool retained (fill/peek).
- README: document the block filesystem.
fs rewrite stage 1: persistent block device (bounce buffer, cart SRAM)2026-07-16T09:42:38Zuseruser@clank2026-07-16T09:42:38Zurn:sha1:057e5377af2d086917b9cd0ffb336231d7d098cb
- blk.asm: read_block/write_block move 256-byte blocks between battery-backed
cart-RAM banks (8-11, the 'disk') and a WRAM bounce buffer. Banking is hidden
in those two routines; they inline the 'restore my bank' step so they never
touch the stack while the disk bank is mapped over the process's $A000 window
(the stack lives there too -- a call/ret would rug-pull it).
- format-on-first-boot: superblock magic in block 0; otherwise the disk persists.
- cart RAM bumped to 128 KiB (-r 4); process banks 0-7, disk banks 8-11.
- debug tool 'blk fill/peek' + syscalls to validate round-trip and persistence.
- verified: round-trip incl. cross-bank (block 100 -> bank 11); block survives a
reboot via .sav; magic intact (no reformat on 2nd boot).
- old WRAM 8-slot FS still backs the tools until stages 2-3.