I may be onto something. I think for the time being I am at least able to read the command byte. I got a value of 45. That implies mouse enabled, but irq12 disabled.
I tried to enable the mouse IRQ using the same method (with the mouse not plugged in) and nothing changed.
Then I wrote A7h to port 64h, and read the command byte again and got a value of 65...but then the system seemed to lock up. A value of 65 would be consistent with mouse disabled.
I'll try running the program again with the mouse plugged in to see if it makes a difference.
*edit*
Okay, I managed to write A7h to port 64h to disable the mouse port without having the system lockup. I'm actually not sure if the system locks up, it may just be the keyboard controller locking up. The reason that this was happening was because I was running the reads and writes in my program too close together. It seems the kbc needs some kind of extra delay (in addition to the wait loops).
Unfortunately I still can't seem to write the command byte directly without locking up the kbc. I think something in my code is wobly, because I noticed that the first time I try to read from the command byte, it spits out an incorrect value of "FA". If I run the program again i get the correct value of 45. Since I'm basically using the same code for writing the command byte I would assume something similar is happening and screwing up the kbc.
Here's my code to read the command byte. (which seems flaky on the first run)
DO
i = inp(&H64)
LOOP UNTIL i AND &H1
OUT &H64, &H20
DO
i = inp(&H64)
LOOP UNTIL i AND &H2
i = inp(&H60)
PRINT hex$(i)
Here's the code I wrote to write the command byte that seems to lock up the kbc
DO
i = inp(&H64)
LOOP UNTIL i AND &H1
OUT &H64, &H60
DO
i = inp(&H64)
LOOP UNTIL i AND &H1
OUT &H60, &H(insert desired hex code here)
"Will the highways on the internets become more few?" -Gee Dubya
V'Ger XT|Upgraded AT|Ultimate 386|Super VL/EISA 486|SMP VL/EISA Pentium