| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|