From 1cd6720bf69c3ce9b2fe448633f48b786498c3ab Mon Sep 17 00:00:00 2001
From: Gale Faraday <k4mu1kazum4@gmail.com>
Date: Tue, 7 Oct 2025 14:23:56 -0500
Subject: [PATCH] feat(docs): expanded Typst doc

---
 .editorconfig   |  2 +-
 docs/buzbee.typ | 64 ++++++++++++++++++++++++++++++++++++++++---------
 2 files changed, 54 insertions(+), 12 deletions(-)

diff --git a/.editorconfig b/.editorconfig
index b5038d3..6243ad5 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -12,7 +12,7 @@ insert_final_newline = true
 indent_style = space
 indent_size = 2
 
-[*.md]
+[*.{md,typ}]
 indent_style = space
 indent_size = 2
 max_line_length = 80
diff --git a/docs/buzbee.typ b/docs/buzbee.typ
index 0c36439..535754b 100644
--- a/docs/buzbee.typ
+++ b/docs/buzbee.typ
@@ -50,15 +50,15 @@ listed in alphabetical order. Below in @if-table is a list of available IFs.
     table.header(
       [*Name* (pg. no.)], [*Description*]
     ),
-    [`CALL` #ref(<if-call>, form: "page")],
+    [`CALL` (#ref(<if-call>, form: "page"))],
     [Call a resident routine in the MPU's address space.],
-    [`HELP` #ref(<if-help>, form: "page")],
+    [`HELP` (#ref(<if-help>, form: "page"))],
     [Display a summary of known commands.],
-    [`PEEK` #ref(<if-peek>, form: "page")],
+    [`PEEK` (#ref(<if-peek>, form: "page"))],
     [Dumps memory from the MPU's address space to the terminal.],
-    [`POKE` #ref(<if-poke>, form: "page")],
+    [`POKE` (#ref(<if-poke>, form: "page"))],
     [Overwrites memory in the MPU's address space.],
-    [`SREC` #ref(<if-srec>, form: "page")],
+    [`SREC` (#ref(<if-srec>, form: "page"))],
     [Switches into Motorola S-Record receive mode.],
   ),
   caption: [Table of IFs],
@@ -66,10 +66,19 @@ listed in alphabetical order. Below in @if-table is a list of available IFs.
 
 In the following pages these IFs are described in specific.
 
-// TODO: Talk about how IFs are tokenized.
+IFs are tokenized from their textual form into a binary "bytecode" form. This
+bytecode is not reliably stable between versions, so it isn't described here in
+specific, but a general breakdown is provided.
+
+First the text command name (eg. `CALL`) is hashed in some way into a token.
+Then conditional processing on the remainder of the line occurs. Values given in
+hex are encoded as their corresponding bytes directly. The token buffer
+mechanics are described more in @internals. Subcommands are also hashed into
+tokens.
 
 #pagebreak()
 
+// Function for creating IF page headers
 #let _ifpagehead(
   desc: none,
   syntax: none,
@@ -99,7 +108,8 @@ In the following pages these IFs are described in specific.
   ),
 )
 
-#lorem(120)
+Call takes an absolute pointer into the MPU's address space to call as if it
+were a subroutine using `JSR`.
 
 // TODO: For when CHIBI PC-09 Prototype #2 comes out or whenever we get banking
 // add it here "Special care must be taken to properly bank in the correct
@@ -172,23 +182,55 @@ BIOS routine.
 
 == External Functions (EFs) <ef-top>
 
-#lorem(120)
+External functions are any native user code that can be called with `CALL` (see
+@if-call). This mechanism is usable to run any code or routine in memory as
+though interactively using the MPU's `JSR` instruction.
 
 === EFs in ROM <ef-rom>
 
-#lorem(120)
+Some common EFs to call include the using call to reset the CHIBI PC-09 with
+`CALL 8000`.
+
+// TODO: Talk about memory test and BIOS interface
 
 #pagebreak()
 
 = BUZBEE Reserved Memory Regions <res-mem>
 
-#lorem(120)
+BUZBEE uses memory in the 0200-02FF page. A table of the layout of this memory
+is provided.
+
+// TODO: Provide a table of the BUZBEE memory layout.
 
 #pagebreak()
 
 = Building CHIBI PC-09 Firmware from Source <building>
 
-#lorem(120)
+Building the CHIBI PC-09 firmware from source requires LWTOOLS
+#link("http://lwtools.ca"), a functioning C compiler (`cc`), and a POSIX Shell
+implementation (`sh`). The firmware was developed using LWTOOLS version 4.24 on
+Linux, though later versions may work as well. A GNU Make "makefile" is provided for
+building on Linux. GNU binutils' `objcopy` is also used to build the compiled
+Motorola S-Record into a raw binary. Development is tracked using Git.
+
+Using the makefile is simple. It provides facilities for easy building, and
+development.
+
+To build an S-Record of the ROM run:
+```sh
+make generate && make boot.s19
+```
+
+To build a ROM image with `objcopy` run:
+```sh
+make generate && make
+```
+
+In order to rebuild, first the generated files and existing objects must be
+cleaned. To do this a `make clean` pseudo-target is defined.
+
+Building the documentation can also be accomplished using `make docs`, provided
+`typst` is installed.
 
 #pagebreak()