From 191ad9a35ea72ddf6eaddabc086294b71123c9ed Mon Sep 17 00:00:00 2001
From: Camden Dixie O'Brien <cdo@wip.sh>
Date: Wed, 18 Mar 2026 14:36:47 +0000
Subject: [PATCH] Update README

---
 README.md | 59 +++++++++++++++++++++++++------------------------------
 1 file changed, 27 insertions(+), 32 deletions(-)

diff --git a/README.md b/README.md
index 6cfa3fc..d5d6f6a 100644
--- a/README.md
+++ b/README.md
@@ -1,31 +1,24 @@
 # Wipforth
 
-Wipforth is a simple Forth implementation that runs in the WebAssembly
-virtual machine.  It does I/O via memory-mapped peripherals, which are
-emulated in JavaScript.
+Wipforth is a Forth implementation that runs in the WebAssembly
+virtual machine.  The system is bootstrapped from source on page load:
+the only non-text file is the favicon :)
 
-- For the Forth kernel, see [wipforth.wat](./wipforth.wat)
-- For the JavaScript emulator, see [emu.js](./emu.js)
-- For the Forth prelude, which is loaded at start-up, see
-  [prelude.f](./prelude.f)
+I/O is done via memory-mapped peripherals, which are emulated in
+JavaScript.
+
+- For the Forth kernel, see [wipforth.ws](./wipforth.ws)
+- For the emulator, see [emu.js](./emu.js)
+- For the assembler, see [asm.js](./asm.js)
+- For the prelude (Forth code loaded right after the kernel boots),
+  see [prelude.f](./prelude.f)
 - For a description of the peripherals, see the
   [Peripherals](#peripherals) section below.
 
 ## Building and Running Locally
 
-You'll need:
-
-- [WABT](https://github.com/WebAssembly/wabt) (not for long mwahaha)
-- [Guile](https://www.gnu.org/software/guile/) (or bring your own HTTP
-  server -- see note below)
-
-To run, first compile the WebAssembly module:
-
-```
-wat2wasm --enable-threads wipforth.wat
-```
-
-Then run the development server:
+There's a [Guile](https://www.gnu.org/software/guile/) script in the
+repo you can use for this:
 
 ```
 guile server.scm
@@ -34,14 +27,19 @@ guile server.scm
 You should then be able to open <http://localhost:8080> in a browser
 and use the system from there.
 
-**NOTE**: The server is very simple and just serves the files with the
-cross-origin isolation headers required for `SharedMemoryBuffer` use.
-You could use any HTTP server that sets these headers.
+However, since everything is bootstrapped on the client, you only
+*need* an appropriate HTTP server, so if you don't have Guile on your
+system you can use something else like Python's `http.server`.  The
+only requirement is that it sets the cross-origin isolation headers
+required for `SharedMemoryBuffer` use:
 
-You should **definitely not** use the development server to serve the
-application on the open internet; I just hacked it together for
-testing on localhost during development and it's probably hilariously
-insecure.
+- `Cross-Origin-Opener-Policy: same-origin`
+- `Cross-Origin-Embedder-Policy: require-corp`
+
+You should **definitely not** use `server.scm` to serve the
+application on the open internet or anything like that; I just hacked
+it together for testing on localhost during development and it's
+probably hilariously insecure.
 
 ## End-to-End Tests
 
@@ -62,16 +60,13 @@ Given that's all sorted, you should be able to run:
 guile tests.scm
 ```
 
-It will print a JUnit XML report to standard out, you can pretty-print
-it with:
+It will print a JUnit XML report to standard out.  You can
+pretty-print it with `xmllint` if you have it installed:
 
 ```
 guile tests.scm | xmllint --format -
 ```
 
-Though, of course, this will require that you have `xmllint` on your
-system.
-
 ## Peripherals
 
 ### Terminal