docs(buzbee): update docs to represent feature completion state

docs/buzbee.typ

@@ -49,24 +49,29 @@ listed in alphabetical order. Below in @if-table is a list of available IFs.
 
 #figure(
   table(
-    columns: (1fr, auto),
+    columns: (auto, auto, 1fr),
     inset: 10pt,
     align: center,
     fill: (_, y) =>
       if calc.odd(y) { luma(250) }
       else { white },
     table.header(
-      [*Name* (pg. no.)], [*Description*]
+      [*Name* (pg. no.)], [*Command Token*], [*Description*]
     ),
     [`CALL` (#ref(<if-call>, form: "page"))],
+    [`$00`],
     [Call a resident routine in the MPU's address space.],
     [`HELP` (#ref(<if-help>, form: "page"))],
+    [`$01`],
     [Display a summary of known commands.],
     [`PEEK` (#ref(<if-peek>, form: "page"))],
+    [`$02`],
     [Dumps memory from the MPU's address space to the terminal.],
     [`POKE` (#ref(<if-poke>, form: "page"))],
+    [`$03`],
     [Overwrites memory in the MPU's address space.],
     [`SREC` (#ref(<if-srec>, form: "page"))],
+    [`$04`],
     [Switches into Motorola S-Record receive mode.],
   ),
   caption: [Table of IFs],
@@ -75,8 +80,7 @@ listed in alphabetical order. Below in @if-table is a list of available IFs.
 In the following pages these IFs are described in specific.
 
 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.
+bytecode is described in @internals.
 
 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
@@ -147,12 +151,12 @@ BIOS routine.
   syntax: [`PEEK <BASE> [<HIGH>]`],
   params: (
     base: [
-      The address of the byte to dump or the base (lower bound) address of the
-      byte to start dumping from if `<HIGH>` is specified.
+      The address (two bytes) of the byte to dump or the base (lower bound)
+      address of the byte to start dumping from if `<HIGH>` is specified.
     ],
     high: [
       An optional operand given as the upper bound of the range to dump. Forms
-      a range together with `<BASE>`.
+      a range together with `<BASE>`. (two bytes)
     ],
   )
 )
@@ -160,8 +164,6 @@ BIOS routine.
 Peeking memory causes the MPU to read the requested bytes and dump them to the
 screen.
 
-#lorem(120)
-
 #pagebreak()
 
 === IF: `POKE` <if-poke>
@@ -170,12 +172,13 @@ screen.
   desc: "Writes values to the MPU's address space.",
   syntax: [`POKE <ADDR> <BYTES>`],
   params: (
-    addr: "The base (low) address to start writing bytes from.",
+    addr: "The base (low) address (two bytes) to start writing bytes from.",
     bytes: "The bytes to write into memory separated by whitespace.",
   )
 )
 
-#lorem(120)
+Poking memory causes the MPU to overwrite the bytes at `<ADDR>` with the bytes
+given in `<BYTES>`.
 
 #pagebreak()
 
@@ -187,7 +190,7 @@ screen.
   params: (),
 )
 
-#lorem(120)
+Motorola S-Record mode is currently a stub.
 
 #pagebreak()
 
@@ -273,7 +276,9 @@ Building the documentation can also be accomplished using `make docs`, provided
 = BUZBEE Internals and Modding <internals>
 
 BUZBEE's interpreter works by "compiling" textual user commands into bytecode
-for more simply passing parameters to IFs (see @if-top).
+for more simply passing parameters to IFs (see @if-top). The way that works is
+the implementation dependent, but each hash is one byte (1B) in size, and
+corresponds to an IF token, which is the index of the hash.
 
 BUZBEE's source, and the surrounding BIOS source is well commented, but a
 general summary of the control flow is provided here.