commit 53fcf840cc1df53246b8270ab70cabc21d8b7ddd
parent 5032416fd67e854f98a6dabe7ad4d80487aab769
Author: Virgil Dupras <hsoft@hardcoded.net>
Date: Thu, 29 Dec 2022 08:32:50 -0500
doc: typo fixes
Diffstat:
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/doc/deploy.txt b/fs/doc/deploy.txt
@@ -7,7 +7,7 @@ using the existing build scripts, maybe tweak the init.fs a bit.
If you're deploying hardware that isn't supported yet, then you'll need to craft
those build scripts yourself.
-To understand thise document, you should have read doc/usage and doc/arch.
+To understand this document, you should have read doc/usage and doc/arch.
## The general steps
@@ -40,9 +40,9 @@ trial and errors. Maybe these little guidelines can help you.
The first thing you have to do is to write your bootloader. I don't know your
platform, so I can't tell you how, but what I can tell you is that it has to
load both the kernel and the boot "stream" in memory. By "stream", I mean that
-the source of all the source files that compose the boot sequence (see doc/arch)
-are lined up one after the other so that the Forth interpreter can just consume
-it all from memory.
+the content of all the source files that compose the boot sequence (see
+doc/arch) are lined up one after the other so that the Forth interpreter can
+consume it all from memory.
You have to place your boot stream so that the "boot<" word reads from it. It's
generally going to be right after the kernel in memory, but it doesn't have to.
@@ -52,11 +52,11 @@ generally going to be right after the kernel in memory, but it doesn't have to.
Writing the kernel is pretty hard. You will probably want to do this in an
emulator. My advice is to try to find a way to test each word as you write it,
however hacked up that way is. For the PC, my trick was to write stuff to memory
-at $b8000 (the vga text mode buffer) because I didn't have a function "emit"
-yet. If you're in an emulator, you have access to machine state, so you can
-debug through that too.
+at $b8000 (the vga text mode buffer) because I didn't have a word "emit" yet. If
+you're in an emulator, you have access to machine state, so you can debug
+through that too.
-### Testing boolo
+### Testing bootlo
Compiling and testing the "bootlo" layer is the best way to iron kinks out of
the kernel. Even though all your words were tested in isolation as you built the
@@ -70,7 +70,7 @@ results of your tests. A blinking LED maybe?
So, what you do is that you begin with a dummy test right at "boot<". Something
like "blink my LED and loop forever". We're good? alright. Now copy the first
few lines of bootlo (those that handle ":" and ";") and copy that into your
-bootloader stream. Then, create word definition that blinks your LED. Still
+bootloader stream. Then, create a word definition that blinks your LED. Still
good? The hard part's over! Now let's get those other lines of code wiggling!
So, you have instantiated that dummy struct? It's working? Seriously, the hard
@@ -100,9 +100,9 @@ init.fs, again blinking your LED. Working? good!
Did you try a f<< call? Working too? You're on a roll!
You have a working Dusk system. The rest is up to you. You probably want a
-prompt right? To have that, you need to set ConsoleIn and ConsoleOut. So, write
+prompt, right? To have that, you need to set ConsoleIn and ConsoleOut. So, write
your drivers for input and output (a serial console is usually the quickest way
-to this) and have those drivers conform create structure that extends IO (see
+to this) and have those drivers create structures that extend IO (see
doc/sys/io). You'll want your input driver to implement :readbuf and your output
driver to implement :writebuf. I recommend looking at PC drivers for
inspiration.
