Mirror of CollapseOS
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

158 lines
6.0KB

  1. # Collapse OS usage guide
  2. If you already know Forth, start here. Otherwise, read primer
  3. first.
  4. We begin with a few oddities in Collapse OS compared to tradi-
  5. tional forths, then cover higher level operations.
  6. # Signed-ness
  7. For simplicity purposes, numbers are generally considered
  8. unsigned. For convenience, decimal parsing and formatting
  9. support the "-" prefix, but under the hood, it's all unsigned.
  10. This leads to some oddities. For example, "-1 0 <" is false.
  11. To compare whether something is negative, use the "0<" word
  12. which is the equivalent to "0x7fff >".
  13. # Branching
  14. Branching in Collapse OS is limited to 8-bit. This represents
  15. 64 word references forward or backward. While this might seem
  16. a bit tight at first, having this limit saves us a non-
  17. negligible amount of resource usage.
  18. The reasoning behind this intentional limit is that huge
  19. branches are generally an indicator that a logic ought to be
  20. simplified. So here's one more constraint for you to help you
  21. towards simplicity.
  22. # Interpreter I/O
  23. The INTERPRET loop, the heart of Collapse OS, feeds itself
  24. from the C< word, which yields a character every time it is
  25. called. If no character is available to interpret, it blocks.
  26. During normal operations, C< is simply a buffered layer over
  27. KEY, which has the same behavior (but unbuffered). Before
  28. yielding any character, the C< routine fetches a whole line
  29. from KEY, puts it in a buffer, then yields the buffered line,
  30. one character at a time.
  31. Both C< and KEY can be overridden by setting an alternate
  32. routine at the proper RAM offset (see impl.txt). For example,
  33. C< overrides are used during LOAD so that input comes from disk
  34. blocks instead of keyboard.
  35. KEY overrides can be used to, for example, temporarily give
  36. prompt control to a RS-232 device instead of the keyboard.
  37. Interpreter output is unbuffered and only has EMIT. This
  38. word can also be overriden, mostly as a companion to the
  39. raison d'etre of your KEY override.
  40. # Aliases
  41. A common pattern in Forth is to add an indirection layer with
  42. a pointer word. For example, if you have a word "FOO" for
  43. which you would like to add an indirection layer, you would
  44. rename "FOO" to "_FOO", add a variable "FOO*" pointing to
  45. "_FOO" and re-defining "FOO" as ": FOO FOO* @ EXECUTE".
  46. This is all well and good, but it is resource intensive and
  47. verbose, which make us want to avoid this pattern for words
  48. that are often used.
  49. For this purpose, Collapse OS has two special word types:
  50. alias and ialiases (indirect alias).
  51. An alias is a variable that contains a pointer to another word.
  52. When invoked, we invoke the specified pointer with minimal over-
  53. head. Using our FOO example above, we would create an alias
  54. with "' _FOO :* FOO". Invoking FOO will then invoke "_FOO". You
  55. can change the alias' pointer with "*!" like this:
  56. "' BAR ' FOO *!". FOO now invokes BAR.
  57. A ialias is like an alias, but with a second level of indi-
  58. rection. The variable points to a cell pointing to our word.
  59. It works like an alias, except you have to use ":**" and "**!".
  60. Ialiases are used by core code which point to hardcoded
  61. addresses in RAM (because the core code is designed to run from
  62. ROM, we can't have regular variables). You are unlikely to
  63. need ialiases in regular code.
  64. Aliases and ialiases generally have their name end with "*".
  65. Core words such as KEY and EMIT, which are ialiases, are
  66. exceptions.
  67. # Indirect memory access
  68. C@*, C!*, and C,* are the indirect versions of C@, C! and C,.
  69. They are ialias words and initially point to C@, C! and C,.
  70. Indirect memory access words can be useful to "pipe" processing
  71. to places outside of regular memory.
  72. Many core words, such as MOVE, use indirect memory access. This
  73. gives a lot of flexibility to those words, allowing for complex
  74. data transfers. The cost of the indirection is small because of
  75. the optimized ways aliases are built.
  76. # Disk blocks
  77. Disk blocks are Collapse OS' main access to permanent storage.
  78. The system is exceedingly simple: blocks are contiguous
  79. chunks of 1024 bytes each living on some permanent media such
  80. as floppy disks or SD cards. They are mostly used for text,
  81. either informational or source code, which is organized into
  82. 16 lines of 64 characters each.
  83. Blocks are referred to by number, 0-indexed. They are read
  84. through BLK@ and written through BLK!. When a block is read,
  85. its 1024 bytes content is copied to an in-memory buffer
  86. starting at BLK( and ending at BLK). Those read/write
  87. operations are often implicit. For example, LIST calls BLK@.
  88. When a word modifies the buffer, it sets the buffer as dirty
  89. by calling BLK!!. BLK@ checks, before it reads its buffer,
  90. whether the current buffer is dirty and implicitly calls BLK!
  91. when it is.
  92. The index of the block currently in memory is kept in BLK>.
  93. Many blocks contain code. That code can be interpreted through
  94. LOAD. Programs stored in blocks frequently have "loader blocks"
  95. that take care of loading all blocks relevant to the program.
  96. Blocks spanning multiple disks are tricky. If your media isn't
  97. large enough to hold all Collapse OS blocks in one unit, you'll
  98. have to make it span multiple disks. Block reference in
  99. informational texts aren't a problem: When you swap your disk,
  100. you mentally adjust the block number you fetch.
  101. However, absolute LOAD operations in Collapse OS aren't aware
  102. of disk spanning and will not work properly in your spanned
  103. system.
  104. Although the usage of absolute LOAD calls are minimally used
  105. (relative LOADs are preferred), they are sometimes unavoidable.
  106. When you span Collapse OS over multiple disks, don't forget to
  107. adjust those absolute LOADs.
  108. # How blocks are organized
  109. Organization of contiguous blocks is an ongoing challenge and
  110. Collapse OS' blocks are never as tidy as they should, but we
  111. try to strive towards a few goals:
  112. 1. Block 0 contains documentation discovery core keys to the
  113. uninitiated.
  114. 2. B1-B4 are for a master index of blocks.
  115. 3. B5-B259 are for programs loaded at runtime.
  116. 4. B260-B599 are for bootstrapping a new core.
  117. 5. B600-B650 are for recipes.
  118. Recipes blocks do not live in the main blkfs, but each recipe
  119. has its own blkfs overlay, with blocks beginning at 600.