7684 - baremetal will have no mouse

I spent a week on trying to support it, and I am now past the five
stages of grief.

-- Important things I read
https://web.archive.org/web/20040604041507/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/keyboard/atkeyboard.html
https://web.archive.org/web/20040604043149/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/mouse/mouse.html

https://wiki.osdev.org/index.php?title=Mouse_Input&oldid=23086#Waiting_to_Send_Bytes_to_Port_0x60_and_0x64
  says command 0xa8 is optional

SaniK: https://forum.osdev.org/viewtopic.php?t=10247
  recommends command 0xa8 before setting Compaq Status byte

Setting Compaq status byte before 0xa8: https://forum.osdev.org/viewtopic.php?f=1&t=19873
  This thread also suggests that keeping reads from keyboard vs mouse straight
  is non-trivial.

-- Where I got stuck
Following SaniK's recipe doesn't seem to work. It seems like not sending
the 0xa8 command gets us a little closer. I saw the mouse handler
trigger, but it seems to not actually happen in response to mouse
events (vector 0x74 in the interrupt descriptor table).

-- Other options that may be worth considering
USB mouse
Serial mouse

Implementing a PS/2 handler in SubX
  would require somehow referring to SubX labels in this file

It seems clear that a mouse driver is complex enough to need a
higher-level language than just hex bytes. But it's _not_ clear how to
_explain_ a mouse driver. There's just a lot of random rules, historical
anecdotes, just-so stories and sheer black magic here. I'm going to try
to do without it all. Mu will be a keyboard-only computer for the
foreseeable future.

1 files changed, 7 insertions, 6 deletions

diff --git a/baremetal/boot.hex b/baremetal/boot.hex
index deccff9d..47e56425 100644
--- a/baremetal/boot.hex
+++ b/baremetal/boot.hex
@@ -21,11 +21,11 @@
 #
 # Since we start out in 16-bit mode, we need instructions SubX doesn't
 # support.
-# This file contains just lowercase hex bytes and comments. It makes liberal
-# use of:
+# This file contains just lowercase hex bytes and comments. Programming it
+# requires liberal use of:
 #   - comments documenting expected offsets
 #   - size checks on the emitted file (currently: 6144 bytes)
-#   - xxd to eyeball that offsets contain expected bytes
+#   - xxd to spot-check contents of specific offsets in the generated output
 #
 # Programs using this initialization:
 #   - can't use any syscalls
@@ -40,6 +40,8 @@
 # a few magic constants:
 #   Video memory: start is stored at 0x8128
 #   Keyboard buffer: starts at 0x8028
+#
+# No mouse support. _That_ would require panicking.
 
 # Outline of this file with offsets and the addresses they map to at run-time:
 # -- 16-bit mode code
@@ -63,7 +65,7 @@
 #   offset 1800 (address 9400): entrypoint for applications (don't forget to adjust survey_baremetal if this changes)
 
 # Other details of the current memory map:
-#   code: first two default-sized disk tracks into [0x00007c00, 0x00017800)
+#   code: first two default-sized disk tracks get loaded to [0x00007c00, 0x00017800)
 #   stack grows down from 0x00070000
 #     see below
 #   heap: [0x01000000, 0x02000000)
@@ -76,7 +78,6 @@
 #   - loads the first sector (512 bytes)
 #     from some bootable image (see the boot sector marker at the end of this file)
 #     to the address range [0x7c00, 0x7e00)
-#     call this disk read #0
 #   - starts executing code at address 0x7c00
 
 # offset 00 (address 0x7c00):
@@ -100,7 +101,7 @@
   bc 00 00  # sp <- 0x0000
 
 # 14:
-  # disk read #1: load remaining sectors from first two tracks of disk into addresses [0x7e00, 0x17800)
+  # load remaining sectors from first two tracks of disk into addresses [0x7e00, 0x17800)
   b4 02  # ah <- 2  # read sectors from disk
   # dl comes conveniently initialized at boot time with the index of the device being booted
   b5 00  # ch <- 0  # cylinder 0