program loading, others

big kernel additions: paging, elf loading, separate kernel and user page allocation
it now properly loads and runs sd0:bin/init.elf
still need to determine which disk was booted from, and start the init on that disk

1 files changed, 42 insertions, 0 deletions

diff --git a/doc/keys.txt b/doc/keys.txt
new file mode 100644
index 0000000..a083eba
--- /dev/null
+++ b/doc/keys.txt
@@ -0,0 +1,42 @@
+keycodes are 32-bit integers.
+
+the low byte indicates the key itself. for printable characters (and keys with
+reasonable translations to ascii control codes), this is the ascii code. for
+other ones, something in the range of 0x80 to 0xff is used, seen in table 1.
+
+the top 24 bits indicate several flags. these are seen in table 2, where bit 0
+is the lowest bit of the second lowest byte of the keycode, and bit 23 is the
+highest bit of the highest byte of the keycode.
+
+the "get key" system call returns 0 if there is not a key available. it is
+recommended to make the system call and, if it returns 0, yield to the scheduler
+and then loop back to making the system call. this way your task does not block
+the cpu while waiting for keyboard input. see the "get_key_char" function in
+user.c of the "knob" library for an example of this.
+
+
+table 1:
+
+ code | key
+------|-----
+ 0x80 |
+ .... |
+ 0xff |
+
+table 2:
+
+bit  0: left shift
+bit  1: right shift
+bit  2: caps lock
+bit  3: insert
+bit  4: num lock
+bit  5: scroll lock
+bit  6: left alt
+bit  7: right alt
+bit  8: left control
+bit  9: right control
+bit 10: left meta
+bit 11: right meta
+
+bits 12-23 are reserved for future versions. in this version, they should be set
+to zero when giving a keycode, and should be ignored when recieving a keycode.
\ No newline at end of file