Kestrel-3

Check-in [985c171204]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:More refinements; done for this evening though.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256:985c1712040e6009c2137edb64a0be7a81a67d2f496047edcb4caf1040d19ca6
User & Date: kc5tja 2019-09-09 05:06:37
Context
2019-09-10
04:30
Switch methods of tracking which steps need refinement. This seems to be an easier approach, and I can track progress in an automated manner with clever use of grep. check-in: 01899c8062 user: kc5tja tags: trunk
2019-09-09
05:06
More refinements; done for this evening though. check-in: 985c171204 user: kc5tja tags: trunk
04:35
More stepwise refinements to flesh out more boot loader behavioral details, menu item structure, etc. check-in: a903a4c39f user: kc5tja tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to REPORT.org.

57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
...
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
...
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
...
200
201
202
203
204
205
206

207
208
209
210
211
212
213
...
223
224
225
226
227
228
229











230
231
232
233
234
235
236
...
727
728
729
730
731
732
733




734
735
736
737
738
739
740
...
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
One such candidate is a port of the Tripos operating system,
tentatively called VertigOS.[fn::This name was chosen back in 2018
through an informally conducted on-line poll between both Twitter and
Mastodon social media sites.  VertigOS was suggested as a joke on my
furry character's name, Vertigo; nonetheless, it won in both
communities without much competition.]

Given some secondary storage device with a properly installed VertigOS
image, the Kestrel-3 should support a mechanism to automate
bootstrapping it.  Currently, I envision the user typing a command at
the Forth OK prompt, such as ~go-vertigos~ to boot directly into it,
or ~boot-menu~ to bring up a built-in boot manager, through which the
user can then select the VertigOS image desired.  However, this might
change in the future, especially post-media.  In this configuration,
the user might need to press a key combination during the boot
sequence to /force/ the computer to drop into ROM-resident Forth if an
external OS is available to bootstrap automatically.  While this is
more inline with how other computers work, it remains to be seen if
this is a preferred approach.  I'll cross that bridge when I get
there.

* Hard Reset/Power-On ("Cold") Bootstrap Process
When powering on the Kestrel-3, the computer will present a boot menu
to the operator.  The operator should type the letter or number
corresponding to the boot option desired.  In the absence of any
attached storage, only two items should appear:

1. Forth with auto-boot
................................................................................
Since the system's flash ROM is a serial device, the processor will
need to wait hundreds of clock cycles for each instruction it executes
out of ROM.  This is why we relocate the software image in ROM into
RAM before executing the rest of the bootstrap process.

Initializing the Forth binary interface involves determining
(statically or dynamically) where to place the data and return stacks,
any user variables, and of course the dictionary itself.

Once the VM has been established, we can then "cold boot" the Forth
environment.  It is here that the boot menu is built and presented to
the user.

#+BEGIN_SRC
TO cold-boot the Forth interpreter DO
................................................................................
Boot menu items are described using a collection of menu item
descriptors.  Each descriptor binds a key that a user can press on the
keyboard to a particular boot action.  See the data structures chapter
for a complete description.

#+BEGIN_SRC
TO Configure the Forth bootmenu items DO
  Create a menu item descriptor that binds key 0 to Forth w/out Auto-Load.
  Create a menu item descriptor that binds key 1 to Forth with Auto-Load.
END
#+END_SRC

Assuming that the user's console is 80x25 characters in size, we can
reasonably display up to 16 items on a single screen.  If there are
more than 16 items to display, we'll need a mechanism for paging the
display.  Up to 36 items should be easily supported, being keyed to
................................................................................
  Skip to the item which is to appear first.
  Start menu item counter at 0.
  DO WHILE fewer than 16 items have been shown AND more items are left to print
    Print the menu key and item description.
    Count the menu item.
  END
  Print page up/down menu items.

END
#+END_SRC

When booting into the Forth environment, the following sequence of
code can be performed.  Note that the decision of whether or not to
auto-load was made when the user selected the appropriate menu
selection in the boot screen.
................................................................................
    END
  ELSE
    Report that auto-start was skipped on user request.
  END
  Quit into Forth interpreter.
END
#+END_SRC












* Forth Interpreter
** Interpreter
I probably won't delve as deeply into the innards of the Forth
environment as I will other components of the firmware, if only
because of how fluid Forth's implementation details can be.  However,
I think it's useful to sketch something out if only to have a crude
................................................................................
        Create a mount-list descriptor.
      END
    END
    Create device descriptor of type "Storage Emulator" as device 0.
  END
END
#+END_SRC





I'm of two minds when it comes to deciding whether or not to parse out
partitions from the storage media.  On one hand, we don't wish for
erroneous Forth software to corrupt the state of filesystems belonging
to other operating systems.  On the other, supporting partitions
introduces an extra level of complexity in the system software and
supporting data structures.  Moreover, media reserved for Forth
................................................................................
| Name      | A human-readable name for the bootable software.  This text would appear in the boot menu, for instance. |

* Unresolved Issues
These are design issues that either need resolution prior to further
refinement, or I know how to refine them but just haven't gotten
around to it yet.

- "Attempt to boot from the selected source."
- "Find valid Forth auto-start block."
- "Read one line of text."
- "Interpret the line of text received."
  - This one is going to be a heavy-weight item, since this gets into the internals of the dictionary, etc.
  - The above will necessarily be very tightly bound to the implementation of the compiler.
  - So, in a sense, we'll need to decide how the compiler will work before deciding how the outer interpreter is going to work.
- "Create an exception handling frame with the current return stack pointer and system variables."
- "Restore system variables."
- Refine format of boot block format
- Create device descriptor of type "Storage Emulator" as device 0.
- Ask emulator for its complete unit list.
- Create a unit descriptor for the unit.
- Create a mount-list record for the unit.
- "Initialize the Forth Binary Interface"
  - Devise register conventions, memory layouts, etc.
  - Sounds like an assembly language/intrinsic level function.
- How to relocate ROM image into RAM?
  - Load from hunk-format image (does not require statically linked or PIC image)
  - Copy directly from ROM address space into RAM (assumes statically linked and/or PIC image)?







<
<
<
<
<
<
<
<
<
<
<
<
<
<







 







|







 







|
|







 







>







 







>
>
>
>
>
>
>
>
>
>
>







 







>
>
>
>







 







|
|
|
|



|
|





|





57
58
59
60
61
62
63














64
65
66
67
68
69
70
..
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
...
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
...
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
...
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
...
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
...
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
One such candidate is a port of the Tripos operating system,
tentatively called VertigOS.[fn::This name was chosen back in 2018
through an informally conducted on-line poll between both Twitter and
Mastodon social media sites.  VertigOS was suggested as a joke on my
furry character's name, Vertigo; nonetheless, it won in both
communities without much competition.]















* Hard Reset/Power-On ("Cold") Bootstrap Process
When powering on the Kestrel-3, the computer will present a boot menu
to the operator.  The operator should type the letter or number
corresponding to the boot option desired.  In the absence of any
attached storage, only two items should appear:

1. Forth with auto-boot
................................................................................
Since the system's flash ROM is a serial device, the processor will
need to wait hundreds of clock cycles for each instruction it executes
out of ROM.  This is why we relocate the software image in ROM into
RAM before executing the rest of the bootstrap process.

Initializing the Forth binary interface involves determining
(statically or dynamically) where to place the data and return stacks,
any user and global variables, and of course the dictionary itself.

Once the VM has been established, we can then "cold boot" the Forth
environment.  It is here that the boot menu is built and presented to
the user.

#+BEGIN_SRC
TO cold-boot the Forth interpreter DO
................................................................................
Boot menu items are described using a collection of menu item
descriptors.  Each descriptor binds a key that a user can press on the
keyboard to a particular boot action.  See the data structures chapter
for a complete description.

#+BEGIN_SRC
TO Configure the Forth bootmenu items DO
  Create a menu item descriptor that binds key 0 to boot into Forth environment w/out Auto-Load.
  Create a menu item descriptor that binds key 1 to boot into Forth environment with Auto-Load.
END
#+END_SRC

Assuming that the user's console is 80x25 characters in size, we can
reasonably display up to 16 items on a single screen.  If there are
more than 16 items to display, we'll need a mechanism for paging the
display.  Up to 36 items should be easily supported, being keyed to
................................................................................
  Skip to the item which is to appear first.
  Start menu item counter at 0.
  DO WHILE fewer than 16 items have been shown AND more items are left to print
    Print the menu key and item description.
    Count the menu item.
  END
  Print page up/down menu items.
  Prompt user for which action to take.
END
#+END_SRC

When booting into the Forth environment, the following sequence of
code can be performed.  Note that the decision of whether or not to
auto-load was made when the user selected the appropriate menu
selection in the boot screen.
................................................................................
    END
  ELSE
    Report that auto-start was skipped on user request.
  END
  Quit into Forth interpreter.
END
#+END_SRC

We attempt to boot into a particular selection by invoking its custom
handler.  If the handler ever returns, then we can safely assume the
boot attempt failed.  It's expected that software which is
bootstrapped into will generally not return.

#+BEGIN_SRC
TO attempt to boot from the selected source DO
  Delegate control to handler specified by the selected menu item, passing the provided parameter as an argument.
END
#+END_SRC

* Forth Interpreter
** Interpreter
I probably won't delve as deeply into the innards of the Forth
environment as I will other components of the firmware, if only
because of how fluid Forth's implementation details can be.  However,
I think it's useful to sketch something out if only to have a crude
................................................................................
        Create a mount-list descriptor.
      END
    END
    Create device descriptor of type "Storage Emulator" as device 0.
  END
END
#+END_SRC

Remark: I chose to build the unit list first, since that allows me to
create the device descriptor without having to go back and patch it up
later.  However, this might not be the best approach.

I'm of two minds when it comes to deciding whether or not to parse out
partitions from the storage media.  On one hand, we don't wish for
erroneous Forth software to corrupt the state of filesystems belonging
to other operating systems.  On the other, supporting partitions
introduces an extra level of complexity in the system software and
supporting data structures.  Moreover, media reserved for Forth
................................................................................
| Name      | A human-readable name for the bootable software.  This text would appear in the boot menu, for instance. |

* Unresolved Issues
These are design issues that either need resolution prior to further
refinement, or I know how to refine them but just haven't gotten
around to it yet.

- Create boot menu item record from boot block contents.
- Find valid Forth auto-start block.
- Read one line of text.
- Interpret the line of text received.
  - This one is going to be a heavy-weight item, since this gets into the internals of the dictionary, etc.
  - The above will necessarily be very tightly bound to the implementation of the compiler.
  - So, in a sense, we'll need to decide how the compiler will work before deciding how the outer interpreter is going to work.
- Create an exception handling frame with the current return stack pointer and system variables.
- Restore system variables.
- Refine format of boot block format
- Create device descriptor of type "Storage Emulator" as device 0.
- Ask emulator for its complete unit list.
- Create a unit descriptor for the unit.
- Create a mount-list record for the unit.
- Initialize the Forth Binary Interface
  - Devise register conventions, memory layouts, etc.
  - Sounds like an assembly language/intrinsic level function.
- How to relocate ROM image into RAM?
  - Load from hunk-format image (does not require statically linked or PIC image)
  - Copy directly from ROM address space into RAM (assumes statically linked and/or PIC image)?