Proposal: BBFS

[interfect]

I'm still working on filesystems. I scrapped my old design (based around tables of "extents" for each file) and came up with this instead:

; BBFS: Bootable Bfs512 File System.
; Filesystem based on FAT and DCPUB's bfs512, with a BBOS boot sector.
; See <https://github.com/Blecki/DCPUB/blob/master/Binaries/bfs512_raw.dc>
;
; Disk structure:
;
; --------------+-------------------------------+
; Sector 0      | Bootloader                    |
; --------------+------------+------------------+
; Sector 1      | FS header  | Version          |
;               |            | (1 word, 0xBF56) |
;               |            +------------------+
;               |            | Reserved         |
;               |            | (5 words)        |
;               +------------+------------------+
;               | Free mask                     |
;               | (90 words, 1=free)            |
;               +------------+------------------+
;               | File       | First 416        |
;               | Allocation | FAT words        |
; --------------+ Table      +------------------+
; Sector 2      |            | Next 512         |
;               | (1440      | FAT words        |
; --------------+  words)    +------------------+
; Sector 3      |            | Last 512         |
;               |            | FAT words        |
; --------------+------------+------------------+
; Sector 4      | First sector of file for root |
;               | directory (a normal file)     |
; --------------+-------------------------------+
; Remaining sectors: file data
;
; The filesystem works around a file allocation table, with 1440 words in it.
; Each entry stores the next sector used for the file using that sector. 0xFFFF
; is used for sectors that are not part of a file, and for sectors that are the
; last sectors in their files.
;
; There is also a free bitmap, storing a 1 for free sectors and a 0 for used
; sectors. Bits are used from words in LSB-first order.
;
; Mirroring bfs512, we define a file API that identifies files by their start
; sector, and then a directory API on top of the file API, with the root
; directory being the file starting at sector 4.
;
; Directory structure:
;
; +---------+-----------------------+
; | Header  | Version (1 word)      |
; |         +-----------------------+
; |         | Entry count (1 word)  |
; +---------+-----------------------+
; | Entry 0 | Type (1 word)         |
; |         +-----------------------+
; |         | Start sector (1 word) |
; |         +-----------------------+
; |         | Name (8 words)        |
; +---------+-----------------------+  
; | Additional entries              |
; | ...                             |
; +---------------------------------+
;
; File names in a directory are packed 2 characters to a word, for a maximum
; length of 16 characters. File types are 0 for a subdirectory, and 1 for a normal file.

Basically it's the on-disk layout used by the filesystem libraries for DCPU B (a small C-like language which I'm not sure if anyone ever used), but shifted down by one sector to make room for the bootloader.

The bootloader on a disk formatted in this way would have to be a little cleverer than the default BBOS bootloader. It couldn't just start loading at sector 1. I think if the disk were set up right, with the boot image being the first file allocated, it would probably be able to start loading at sector 6, and use the FAT to pick which other sectors to load. If it wanted to be really clever, it could understand filenames and load "BOOT.BIN" or something.

Does this sould like a system worthy of the "BBFS" name? I'm working on a library implementing it on top of BBOS disk calls at the moment.

[interfect]

One potential problem is that the lengths of files are only represented to the nearest sector. People reading files would have to deal with trailing garbage, or at least trailing null bytes.

[MadMockers]

As this relates to the bootloader and not BBOS, I'm going to move the example bootloader to it's own repository and we can continue the conversation there.

See: https://github.com/MadMockers/DCPUBootloader/issues/1