Does a PS/2 mouse get detected if plugged in while the compute is on?

Does anyone know if a PS/2 mouse will be detected by the computer if it's plugged in while the computer is on? If it does then would using IRQ12 be a better choice instead of using INT 15h AX=0xC0xx?

That was meant to be instead of INT 15h AX=0xC2xx?

wolfgang kern

2023-11-12 00:05:26 UTC

Does anyone know if a PS/2 mouse will be detected by the computer if it's plugged in > while the computer is on?

depends on OS, while windoze does, old DOS may not.

If it does then would using IRQ12 be a better choice instead of using INT 15h AX=0xC0xx?
That was meant to be instead of INT 15h AX=0xC2xx?

this are two different things :) you may need both.
PS/2 mouse keyboard combination is well defined,
INT15 is there for various mouse setups
IRQ12 is the thing that shall receive mouse packets.
__
wolfgang

Robert Pengelly

2023-11-12 00:22:57 UTC

Does anyone know if a PS/2 mouse will be detected by the computer if it's plugged in > while the computer is on?

depends on OS, while windoze does, old DOS may not.

If it does then would using IRQ12 be a better choice instead of using INT 15h AX=0xC0xx?
That was meant to be instead of INT 15h AX=0xC2xx?

What do you mean it's there for various setups? http://www.ctyme.com/intr/rb-1601.htm (only need to have one as an example) says POINTING DEVICE BIOS INTERFACE (PS), does the PS at the end not mean PS/2 or is it a certain set of PS/2 mice that it supports?

wolfgang kern

2023-11-12 00:54:15 UTC

Does anyone know if a PS/2 mouse will be detected by the computer if it's plugged in > while the computer is on?

depends on OS, while windoze does, old DOS may not.

If it does then would using IRQ12 be a better choice instead of using INT 15h AX=0xC0xx?
That was meant to be instead of INT 15h AX=0xC2xx?

this are two different things :) you may need both.
PS/2 mouse keyboard combination is well defined,
INT15 is there for various mouse setups
IRQ12 is the thing that shall receive mouse packets.

behind INT15C2xx there are more mouse functions available.
C207 let you set your handler address but it doesn't save you from
enabling IRQ12.
__
wolfgang

Robert Pengelly

2023-11-12 02:07:15 UTC

Does anyone know if a PS/2 mouse will be detected by the computer if it's plugged in > while the computer is on?

depends on OS, while windoze does, old DOS may not.

If it does then would using IRQ12 be a better choice instead of using INT 15h AX=0xC0xx?
That was meant to be instead of INT 15h AX=0xC2xx?

this are two different things :) you may need both.
PS/2 mouse keyboard combination is well defined,
INT15 is there for various mouse setups
IRQ12 is the thing that shall receive mouse packets.

behind INT15C2xx there are more mouse functions available.
C207 let you set your handler address but it doesn't save you from
enabling IRQ12.
__
wolfgang

I'm having a few problems setting up IRQ12. I have the following code

mouse_initialize:

push es
push ax
push bx
push dx

;; ps2_write_command (PS2_DISABLE_PORT1)
mov al, HEX (AD)
out HEX (64), al

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Enable interrupt lines, enable translation.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ps2_write_command_read_data (PS2_READ_CONFIG)
mov al, HEX (20)
out HEX (64), al

xor ax, ax
in al, HEX (60)

;; status |= PS2_PORT1_IRQ | PS2_PORT1_TLATE
or al, HEX (01)
or al, HEX (40)
xchg bl, al

;; ps2_write_command_arg (PS2_WRITE_CONFIG, status)
mov al, HEX (60)
out HEX (64), al

xchg al, bl
out HEX (60), al

;; ps2_write_command_read_data (PS2_READ_CONFIG)
mov al, HEX (20)
out HEX (64), al

xor ax, ax
in al, HEX (60)

;; ps2_write_command_read_data (0xAE)
mov al, HEX (AE)
out HEX (64), al

xor ax, ax
in al, HEX (60)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Test PS/2 port.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ps2_write_command_read_data (0xAB)
mov al, HEX (AB)
out HEX (64), al

xor ax, ax
in al, HEX (60)

and al, al
jnz mouse_initialize.no_ps2

;; ps2_write_command (PS2_ENABLE_PORT)
mov dx, HEX (64)
mov al, HEX (AD)
out dx, al
nop

cli

xor ax, ax
mov es, ax

mov word ptr es:[HEX (74) * 4], offset ps2_handler
mov word ptr es:[HEX (74) * 4 + 2], cs

sti

;; pic_unmask_irq (1)
mov dx, HEX (20)
xor ax, ax
in al, dx

mov bl, (1 << 1)
not bl
and al, bl
out dx, al

;; pic_unmask_irq (12)
mov dx, HEX (A0)
xor ax, ax
in al, dx

mov bl, (1 << 4)
not bl
and al, bl
out dx, al

;; ps2_write_command (PS2_ENABLE_PORT1)
mov dx, HEX (64)
mov al, HEX (AE)
out dx, al

;; ps2_write_data (0xFF)
mov dx, HEX (60)
mov al, HEX (FF)
out dx, al

jmp short mouse_initialize.done

mouse_initialize.no_ps2:

pop dx
pop bx
pop ax
pop es
ret

and http://www.ctyme.com/intr/int-74.htm says it's for IRQ12 but I'm not getting an interrupt. Am I doing something wrong?

wolfgang kern

2023-11-12 03:21:37 UTC

Does anyone know if a PS/2 mouse will be detected by the computer if it's plugged in > while the computer is on?

depends on OS, while windoze does, old DOS may not.

If it does then would using IRQ12 be a better choice instead of using INT 15h AX=0xC0xx?
That was meant to be instead of INT 15h AX=0xC2xx?

this are two different things :) you may need both.
PS/2 mouse keyboard combination is well defined,
INT15 is there for various mouse setups
IRQ12 is the thing that shall receive mouse packets.

behind INT15C2xx there are more mouse functions available.
C207 let you set your handler address but it doesn't save you from
enabling IRQ12.
__
wolfgang

I'm having a few problems setting up IRQ12. I have the following code
push es
push ax
push bx
push dx
;; ps2_write_command (PS2_DISABLE_PORT1)
mov al, HEX (AD)
out HEX (64), al
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Enable interrupt lines, enable translation.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ps2_write_command_read_data (PS2_READ_CONFIG)
mov al, HEX (20)
out HEX (64), al
xor ax, ax
in al, HEX (60)
;; status |= PS2_PORT1_IRQ | PS2_PORT1_TLATE
or al, HEX (01)
or al, HEX (40)
xchg bl, al
;; ps2_write_command_arg (PS2_WRITE_CONFIG, status)
mov al, HEX (60)
out HEX (64), al
xchg al, bl
out HEX (60), al
;; ps2_write_command_read_data (PS2_READ_CONFIG)
mov al, HEX (20)
out HEX (64), al
xor ax, ax
in al, HEX (60)
;; ps2_write_command_read_data (0xAE)
mov al, HEX (AE)
out HEX (64), al
xor ax, ax
in al, HEX (60)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Test PS/2 port.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ps2_write_command_read_data (0xAB)
mov al, HEX (AB)
out HEX (64), al
xor ax, ax
in al, HEX (60)
and al, al
jnz mouse_initialize.no_ps2
;; ps2_write_command (PS2_ENABLE_PORT)
mov dx, HEX (64)
mov al, HEX (AD)
out dx, al
nop
cli
xor ax, ax
mov es, ax
mov word ptr es:[HEX (74) * 4], offset ps2_handler
mov word ptr es:[HEX (74) * 4 + 2], cs
sti

;; pic_unmask_irq (1)
: mov dx, HEX (20)
: xor ax, ax
: in al, dx
; mov bl, (1 << 1)
; not bl
; and al, bl
; out dx, al

IN AL,0x21
AND AL,0xFD reset bit1
OUT 0x21,al

;; pic_unmask_irq (12)
;mov dx, HEX (A0)
;xor ax, ax
;in al, dx
;mov bl, (1 << 4)
;not bl
;and al, bl
;out dx, al

IN AL,0xA1
AND AL,0xEF reset bit4
OUT 0xA1,AL

Post by Robert Pengelly
;; ps2_write_command (PS2_ENABLE_PORT1)
mov dx, HEX (64)
mov al, HEX (AE)
out dx, al
;; ps2_write_data (0xFF)
mov dx, HEX (60)
mov al, HEX (FF)
out dx, al
jmp short mouse_initialize.done
pop dx
pop bx
pop ax
pop es
ret
and http://www.ctyme.com/intr/int-74.htm says it's for IRQ12 but I'm not getting an interrupt. Am I doing something wrong?

see above, and when I remember my old code from 40 years ago it first
disables the PS/2 keyboard and then set mouse commands which all need
one special byte in front of to to tell "mouse" instead of Keyboard.
I think this was a 0xD4 byte.
__
wolfgang

Robert Pengelly

2023-11-12 03:59:41 UTC

Does anyone know if a PS/2 mouse will be detected by the computer if it's plugged in > while the computer is on?

depends on OS, while windoze does, old DOS may not.

If it does then would using IRQ12 be a better choice instead of using INT 15h AX=0xC0xx?
That was meant to be instead of INT 15h AX=0xC2xx?

this are two different things :) you may need both.
PS/2 mouse keyboard combination is well defined,
INT15 is there for various mouse setups
IRQ12 is the thing that shall receive mouse packets.

behind INT15C2xx there are more mouse functions available.
C207 let you set your handler address but it doesn't save you from
enabling IRQ12.
__
wolfgang

;; pic_unmask_irq (1)
: mov dx, HEX (20)
: xor ax, ax
: in al, dx
; mov bl, (1 << 1)
; not bl
; and al, bl
; out dx, al
IN AL,0x21
AND AL,0xFD reset bit1
OUT 0x21,al
;; pic_unmask_irq (12)
;mov dx, HEX (A0)
;xor ax, ax
;in al, dx
;mov bl, (1 << 4)
;not bl
;and al, bl
;out dx, al
IN AL,0xA1
AND AL,0xEF reset bit4
OUT 0xA1,AL

;; ps2_write_command (PS2_ENABLE_PORT1)
mov dx, HEX (64)
mov al, HEX (AE)
out dx, al
;; ps2_write_data (0xFF)
mov dx, HEX (60)
mov al, HEX (FF)
out dx, al
jmp short mouse_initialize.done
pop dx
pop bx
pop ax
pop es
ret
and http://www.ctyme.com/intr/int-74.htm says it's for IRQ12 but I'm not getting an interrupt. Am I doing something wrong?

I tried:

;; ps2_write_command (PS2_ENABLE_PORT1)
call ps2_wait_input

mov dx, HEX (64)
mov al, HEX (AE)
out dx, al
nop

call ps2_wait_input

mov dx, HEX (64)
mov al, HEX (D4)
out dx, al
nop

;; ps2_write_data (0xFF)
call ps2_wait_input

mov dx, HEX (60)
mov al, HEX (FF)
out dx, al
nop

but it still doesn't work or do I need to do the 0xD4 for every write?

wolfgang kern

2023-11-12 04:53:16 UTC

Does anyone know if a PS/2 mouse will be detected by the computer if it's plugged in > while the computer is on?

depends on OS, while windoze does, old DOS may not.

If it does then would using IRQ12 be a better choice instead of using INT 15h AX=0xC0xx?
That was meant to be instead of INT 15h AX=0xC2xx?

this are two different things :) you may need both.
PS/2 mouse keyboard combination is well defined,
INT15 is there for various mouse setups
IRQ12 is the thing that shall receive mouse packets.

behind INT15C2xx there are more mouse functions available.
C207 let you set your handler address but it doesn't save you from
enabling IRQ12.
__
wolfgang

;; pic_unmask_irq (1)
: mov dx, HEX (20)
: xor ax, ax
: in al, dx
; mov bl, (1 << 1)
; not bl
; and al, bl
; out dx, al
IN AL,0x21
AND AL,0xFD reset bit1
OUT 0x21,al
;; pic_unmask_irq (12)
;mov dx, HEX (A0)
;xor ax, ax
;in al, dx
;mov bl, (1 << 4)
;not bl
;and al, bl
;out dx, al
IN AL,0xA1
AND AL,0xEF reset bit4
OUT 0xA1,AL

;; ps2_write_command (PS2_ENABLE_PORT1)
call ps2_wait_input
mov dx, HEX (64)
mov al, HEX (AE)
out dx, al
nop
call ps2_wait_input
mov dx, HEX (64)
mov al, HEX (D4)
out dx, al
nop
;; ps2_write_data (0xFF)
call ps2_wait_input
mov dx, HEX (60)
mov al, HEX (FF)
out dx, al
nop

you don't need to use DX for any I/O below 0x0100
and the NOPs are redundant, a better delay is the dummy OUT 0xeb,al

Post by Robert Pengelly
but it still doesn't work or do I need to do the 0xD4 for every write?

YEP, IIRC I had this D4 in front of all data to/from 0x60.
__
wolfgang

here is the port0x64 command list from RBIL:

(Table P0401)
Values for keyboard controller commands (data goes to PORT 0060h):
Value Description
20h read read byte zero of internal RAM, this is the last KB command
sent to the 8041/8042
Compaq put current command byte on PORT 0060h (see #P0403,#P0404)
21-3F read reads the byte specified in the lower 5 bits of the command
in the 804x's internal RAM (see #P0407)
60-7F double writes the data byte to the address specified in the 5 lower
bits of the command
60h Compaq Load new command (60 to [64], command to [60]) (see #P0404)
(also general AT-class machines)
A0h AMI get ASCIZ copyright message on PORT 0060h
A1h AMI get controller version byte on PORT 0060h
A1h Compaq unknown speedfunction ??
A1h C&T CHIPS extensions (see #P0402)
A2h Compaq unknown speedfunction ??
A2h AMI set keyboard controller pins 22 and 23 low
A2h C&T turn on turbo LED
A3h Compaq Enable system speed control
A3h AMI set keyboard controller pins 22 and 23 high
A3h C&T turn off turbo LED
A4h MCA check if password installed
returns PORT 0060h code F1h if no password, FAh if installed
A4h Compaq Toggle speed
A4h AMI set internal system speed flag to low
A5h MCA load password
write successive scan codes to PORT 0060h, terminate with 00h
A5h AMI set internal system speed flag to high
A5h Compaq Special read. the 8042 places the real values of port 2
except for bits 4 and 5 wich are given a new definition in
the output buffer. No output buffer full is generated.
if bit 5 = 0, a 9-bit keyboard is in use
if bit 5 = 1, an 11-bit keyboard is in use
if bit 4 = 0, output-buff-full interrupt disabled
if bit 4 = 1, output-buffer-full interrupt enabled
A6h MCA check password
A6h AMI get internal system speed flag on PORT 0060h
A6h Compaq unknown speedfunction ??
A7h MCA disable mouse port
A7h AMI set internal flag indicating bad write cache
A8h MCA enable mouse port
A8h AMI set internal flag indicating good write cache
A9h MCA test mouse port, return test result on PORT 0060h (see #P0406)
A9h AMI get internal flag indicating cache OK to PORT 0060h
AAh sngl initiate self-test. will return 55h to data port if self-test
successful, FCh if failed
AAh Compaq initializes ports 1 and 2, disables the keyboard and clears
the buffer pointers. It then places 55h in the output buffer.
ABh sngl initiate interface test, return result value on PORT 0060h
(see #P0406)
ACh read diagnostic dump. the contents of the 804x RAM, output port,
input port, status word are sent to PORT 0060h in scan-code
format; Chips&Technologies 8042's append "CHIPS Vxxx" where
"xxx" is the controller version number
ADh sngl disable keyboard (sets bit 4 of commmand byte)
ADh Vectra HP Vectra diagnostic dump
AEh sngl enable keyboard (resets bit 4 of commmand byte)
AFh AWARD Enhanced Command: read keyboard version
AFh AMI set extended controller RAM
write address to PORT 0060h, wait for controller ready, then
write value to PORT 0060h
B1h AMI set keyboard controller P11 line low
B2h AMI set keyboard controller P12 line low
B3h AMI set keyboard controller P13 line low
B4h AMI set keyboard controller P22 line low
B5h AMI set keyboard controller P23 line low
B8h AMI set keyboard controller P10 line high
B9h AMI set keyboard controller P11 line high
BAh AMI set keyboard controller P12 line high
BBh AMI set keyboard controller P13 line high
BCh AMI set keyboard controller P22 line high
BDh AMI set keyboard controller P23 line high
C0h read read input port and place on PORT 0060h
bit 7 keyboard NOT locked
bit 6 =0 first video is CGA
=1 first video is MDA
bit 5 =0 factory testmode
=1 normal
bit 4 =0 256KB RAM, 1=512KB
bit 5,3-0 are used in Intel chipset 386sx machines with
AMI/Phoenix BIOSes for BIOS specific hardware settings
bit 2 (MCA) no keyboard power
bit 1 (MCA) current mouse serial data input state
bit 0 (MCA) current keyboard serial input state
C0h Compaq places status of input port in output buffer. Use this
command only when the output buffer is empty
C1h MCA Enhanced Command: poll input port Low nibble, continuously
place in PORT 0064h bits 7-4 until next command
C2h MCA Enhanced Command: poll input port High nibble, continuously
place in PORT 0064h bits 7-4 until next command
C8h AMI unblock keyboard controller lines P22 and P23
C9h AMI block keyboard controller lines P22 and P23
CAh AMI read keyboard mode, return in 0060 bit 0
(bit clear if ISA mode, set if PS/2 mode)
CBh AMI set keyboard mode (write back mode byte returned by CAh,
modifying only bit 0)
CCh AMI ??? (used by AMI BIOS v1.00.12.AX1T APM code)
D0h read read output port and place on PORT 0060h (see #P0405)
D0h Compaq places byte in output port in output buffer. Use this command
only when the output buffer is empty
D1h double write output port. The next byte written to PORT 0060h will
be written to the 804x output port; the original IBM AT and
many compatibles such as the OPTi 82C392 use bit 1 of the
output port to control the A20 gate.
Important: bit 0 (system reset) should always be set here, as
the system may hang constantly; use pulse output port
(FEh) instead.
D1h Compaq the system speed bits are not set by this command use
commands A1-A6 (!) for speed functions.
D2h MCA Enhanced Command: write keyboard output buffer
D3h MCA Enhanced Command: write pointing device out.buf.
D4h MCA write to mouse/pointing device instead of to keyboard;

this controller command must precede every PORT 0060h command
directed to the mouse, otherwise it will be sent to the keyboard

D4h AWARD Enhanced Command: write to auxiliary device
DDh sngl disable address line A20 (HP Vectra only???)
default in Real Mode
DFh sngl enable address line A20 (HP Vectra only???)
E0h read read test inputs, and place in PORT 0060h
bit0 = kbd clock, bit1 = kbd data
Exxx AWARD Enhanced Command: active output port
E5h GoldStar set turbo LED color to yellow (turbo off)
E7h GoldStar set turbo LED color to yellow (turbo off)
E8h GoldStar set turbo LED color to green (turbo on)
EAh GoldStar set turbo LED color to green (turbo on)
EDh double this is a two part command to control the state of the
NumLock, CpasLock and ScrollLock LEDs
The second byte contains the state to set LEDs.
bit 7-3 reserved. should be set to 0.
bit 2 = 0 Caps Lock LED off
bit 1 = 0 Num Lock LED off
bit 0 = 0 Scroll Lock LED off
F0-FF sngl pulse output port low for 6 microseconds.
bits 0-3 contain the mask for the bits to be pulsed. A bit is
pulsed if its mask bit is zero
bit0=system reset. Don't set to zero. Pulse only!
Note: keyboard controllers are widely different from each other. You
cannot generally exchange them between different machines.
(Award) Derived from Award's Enhanced KB controller advertising sheet.
(Compaq) Derived from the Compaq Deskpro 386 Tech. Ref. Guide.
<eof>

Robert Pengelly

2023-11-12 08:13:34 UTC

Does anyone know if a PS/2 mouse will be detected by the computer if it's plugged in > while the computer is on?

depends on OS, while windoze does, old DOS may not.

If it does then would using IRQ12 be a better choice instead of using INT 15h AX=0xC0xx?
That was meant to be instead of INT 15h AX=0xC2xx?

this are two different things :) you may need both.
PS/2 mouse keyboard combination is well defined,
INT15 is there for various mouse setups
IRQ12 is the thing that shall receive mouse packets.

behind INT15C2xx there are more mouse functions available.
C207 let you set your handler address but it doesn't save you from
enabling IRQ12.
__
wolfgang

;; pic_unmask_irq (1)
: mov dx, HEX (20)
: xor ax, ax
: in al, dx
; mov bl, (1 << 1)
; not bl
; and al, bl
; out dx, al
IN AL,0x21
AND AL,0xFD reset bit1
OUT 0x21,al
;; pic_unmask_irq (12)
;mov dx, HEX (A0)
;xor ax, ax
;in al, dx
;mov bl, (1 << 4)
;not bl
;and al, bl
;out dx, al
IN AL,0xA1
AND AL,0xEF reset bit4
OUT 0xA1,AL

you don't need to use DX for any I/O below 0x0100
and the NOPs are redundant, a better delay is the dummy OUT 0xeb,al

Post by Robert Pengelly
but it still doesn't work or do I need to do the 0xD4 for every write?

YEP, IIRC I had this D4 in front of all data to/from 0x60.
__
wolfgang
(Table P0401)
Value Description
20h read read byte zero of internal RAM, this is the last KB command
sent to the 8041/8042
Compaq put current command byte on PORT 0060h (see #P0403,#P0404)
21-3F read reads the byte specified in the lower 5 bits of the command
in the 804x's internal RAM (see #P0407)
60-7F double writes the data byte to the address specified in the 5 lower
bits of the command
60h Compaq Load new command (60 to [64], command to [60]) (see #P0404)
(also general AT-class machines)
A0h AMI get ASCIZ copyright message on PORT 0060h
A1h AMI get controller version byte on PORT 0060h
A1h Compaq unknown speedfunction ??
A1h C&T CHIPS extensions (see #P0402)
A2h Compaq unknown speedfunction ??
A2h AMI set keyboard controller pins 22 and 23 low
A2h C&T turn on turbo LED
A3h Compaq Enable system speed control
A3h AMI set keyboard controller pins 22 and 23 high
A3h C&T turn off turbo LED
A4h MCA check if password installed
returns PORT 0060h code F1h if no password, FAh if installed
A4h Compaq Toggle speed
A4h AMI set internal system speed flag to low
A5h MCA load password
write successive scan codes to PORT 0060h, terminate with 00h
A5h AMI set internal system speed flag to high
A5h Compaq Special read. the 8042 places the real values of port 2
except for bits 4 and 5 wich are given a new definition in
the output buffer. No output buffer full is generated.
if bit 5 = 0, a 9-bit keyboard is in use
if bit 5 = 1, an 11-bit keyboard is in use
if bit 4 = 0, output-buff-full interrupt disabled
if bit 4 = 1, output-buffer-full interrupt enabled
A6h MCA check password
A6h AMI get internal system speed flag on PORT 0060h
A6h Compaq unknown speedfunction ??
A7h MCA disable mouse port
A7h AMI set internal flag indicating bad write cache
A8h MCA enable mouse port
A8h AMI set internal flag indicating good write cache
A9h MCA test mouse port, return test result on PORT 0060h (see #P0406)
A9h AMI get internal flag indicating cache OK to PORT 0060h
AAh sngl initiate self-test. will return 55h to data port if self-test
successful, FCh if failed
AAh Compaq initializes ports 1 and 2, disables the keyboard and clears
the buffer pointers. It then places 55h in the output buffer.
ABh sngl initiate interface test, return result value on PORT 0060h
(see #P0406)
ACh read diagnostic dump. the contents of the 804x RAM, output port,
input port, status word are sent to PORT 0060h in scan-code
format; Chips&Technologies 8042's append "CHIPS Vxxx" where
"xxx" is the controller version number
ADh sngl disable keyboard (sets bit 4 of commmand byte)
ADh Vectra HP Vectra diagnostic dump
AEh sngl enable keyboard (resets bit 4 of commmand byte)
AFh AWARD Enhanced Command: read keyboard version
AFh AMI set extended controller RAM
write address to PORT 0060h, wait for controller ready, then
write value to PORT 0060h
B1h AMI set keyboard controller P11 line low
B2h AMI set keyboard controller P12 line low
B3h AMI set keyboard controller P13 line low
B4h AMI set keyboard controller P22 line low
B5h AMI set keyboard controller P23 line low
B8h AMI set keyboard controller P10 line high
B9h AMI set keyboard controller P11 line high
BAh AMI set keyboard controller P12 line high
BBh AMI set keyboard controller P13 line high
BCh AMI set keyboard controller P22 line high
BDh AMI set keyboard controller P23 line high
C0h read read input port and place on PORT 0060h
bit 7 keyboard NOT locked
bit 6 =0 first video is CGA
=1 first video is MDA
bit 5 =0 factory testmode
=1 normal
bit 4 =0 256KB RAM, 1=512KB
bit 5,3-0 are used in Intel chipset 386sx machines with
AMI/Phoenix BIOSes for BIOS specific hardware settings
bit 2 (MCA) no keyboard power
bit 1 (MCA) current mouse serial data input state
bit 0 (MCA) current keyboard serial input state
C0h Compaq places status of input port in output buffer. Use this
command only when the output buffer is empty
C1h MCA Enhanced Command: poll input port Low nibble, continuously
place in PORT 0064h bits 7-4 until next command
C2h MCA Enhanced Command: poll input port High nibble, continuously
place in PORT 0064h bits 7-4 until next command
C8h AMI unblock keyboard controller lines P22 and P23
C9h AMI block keyboard controller lines P22 and P23
CAh AMI read keyboard mode, return in 0060 bit 0
(bit clear if ISA mode, set if PS/2 mode)
CBh AMI set keyboard mode (write back mode byte returned by CAh,
modifying only bit 0)
CCh AMI ??? (used by AMI BIOS v1.00.12.AX1T APM code)
D0h read read output port and place on PORT 0060h (see #P0405)
D0h Compaq places byte in output port in output buffer. Use this command
only when the output buffer is empty
D1h double write output port. The next byte written to PORT 0060h will
be written to the 804x output port; the original IBM AT and
many compatibles such as the OPTi 82C392 use bit 1 of the
output port to control the A20 gate.
Important: bit 0 (system reset) should always be set here, as
the system may hang constantly; use pulse output port
(FEh) instead.
D1h Compaq the system speed bits are not set by this command use
commands A1-A6 (!) for speed functions.
D2h MCA Enhanced Command: write keyboard output buffer
D3h MCA Enhanced Command: write pointing device out.buf.
D4h MCA write to mouse/pointing device instead of to keyboard;
this controller command must precede every PORT 0060h command
directed to the mouse, otherwise it will be sent to the keyboard
D4h AWARD Enhanced Command: write to auxiliary device
DDh sngl disable address line A20 (HP Vectra only???)
default in Real Mode
DFh sngl enable address line A20 (HP Vectra only???)
E0h read read test inputs, and place in PORT 0060h
bit0 = kbd clock, bit1 = kbd data
Exxx AWARD Enhanced Command: active output port
E5h GoldStar set turbo LED color to yellow (turbo off)
E7h GoldStar set turbo LED color to yellow (turbo off)
E8h GoldStar set turbo LED color to green (turbo on)
EAh GoldStar set turbo LED color to green (turbo on)
EDh double this is a two part command to control the state of the
NumLock, CpasLock and ScrollLock LEDs
The second byte contains the state to set LEDs.
bit 7-3 reserved. should be set to 0.
bit 2 = 0 Caps Lock LED off
bit 1 = 0 Num Lock LED off
bit 0 = 0 Scroll Lock LED off
F0-FF sngl pulse output port low for 6 microseconds.
bits 0-3 contain the mask for the bits to be pulsed. A bit is
pulsed if its mask bit is zero
bit0=system reset. Don't set to zero. Pulse only!
Note: keyboard controllers are widely different from each other. You
cannot generally exchange them between different machines.
(Award) Derived from Award's Enhanced KB controller advertising sheet.
(Compaq) Derived from the Compaq Deskpro 386 Tech. Ref. Guide.
<eof>

Here's the changes:

;; ps2_write_command (PS2_DISABLE_PORT1)
call ps2_wait_input

mov al, HEX (AD)
out HEX (64), al
nop

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Enable interrupt lines, enable translation.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ps2_write_command_read_data (PS2_READ_CONFIG)
call ps2_wait_input

mov al, HEX (20)
out HEX (64), al
nop

call ps2_wait_input

mov al, HEX (D4)
out HEX (64), al
nop

call ps2_wait_output

xor ax, ax
in al, HEX (60)
nop

;; status |= PS2_PORT1_IRQ | PS2_PORT1_TLATE
or al, HEX (01)
or al, HEX (40)
xchg bl, al

;; ps2_write_command_arg (PS2_WRITE_CONFIG, status)
call ps2_wait_input

mov al, HEX (60)
out HEX (64), al
nop

call ps2_wait_input

mov al, HEX (D4)
out HEX (64), al
nop

call ps2_wait_input

xchg al, bl
out HEX (60), al
nop

;; ps2_write_command_read_data (PS2_READ_CONFIG)
call ps2_wait_input

mov al, HEX (20)
out HEX (64), al
nop

call ps2_wait_input

mov al, HEX (D4)
out HEX (64), al
nop

call ps2_wait_output

xor ax, ax
in al, HEX (60)
nop

;; ps2_write_command_read_data (0xAE)
call ps2_wait_input

mov al, HEX (AE)
out HEX (64), al
nop

call ps2_wait_input

mov al, HEX (D4)
out HEX (64), al
nop

call ps2_wait_output

xor ax, ax
in al, HEX (60)
nop

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Test PS/2 port.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ps2_write_command_read_data (0xAB)
call ps2_wait_input

mov al, HEX (AB)
out HEX (64), al
nop

call ps2_wait_input

mov al, HEX (D4)
out HEX (64), al
nop

call ps2_wait_output

xor ax, ax
in al, HEX (60)
nop

and al, al
jnz mouse_initialize.no_ps2

call ps2_wait_input

mov al, HEX (AD)
out HEX (64), al
nop

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Clear interrupts while we set other up.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
cli

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; We'll use the extra segment to offset the correct positions
;; so make sure it is zero.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
xor ax, ax
mov es, ax

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Setup INT 74h.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
mov word ptr es:[HEX (74) * 4], offset ps2_handler
mov word ptr es:[HEX (74) * 4 + 2], cs

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Restore interrupts.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
sti

;; pic_unmask_irq (1)
xor ax, ax
in al, HEX (21)
nop

and al, HEX (FD)
out HEX (21), al
nop

;; pic_unmask_irq (12)
xor ax, ax
in al, HEX (A1)
nop

and al, HEX (EF)
out HEX (A1), al
nop

;; ps2_write_command (PS2_ENABLE_PORT1)
call ps2_wait_input

mov al, HEX (AE)
out HEX (64), al
nop

call ps2_wait_input

mov al, HEX (D4)
out HEX (64), al
nop

;; ps2_write_data (0xFF)
call ps2_wait_input

mov al, HEX (FF)
out HEX (60), al
nop

but it still doesn't work. As for "a better delay is the dummy OUT 0xeb,al" does it matter what al is or should I just set it to zero or something else?

wolfgang kern

2023-11-12 12:27:34 UTC

Does anyone know if a PS/2 mouse will be detected by the computer if it's plugged in > while the computer is on?

depends on OS, while windoze does, old DOS may not.

If it does then would using IRQ12 be a better choice instead of using INT 15h AX=0xC0xx?
That was meant to be instead of INT 15h AX=0xC2xx?

this are two different things :) you may need both.
PS/2 mouse keyboard combination is well defined,
INT15 is there for various mouse setups
IRQ12 is the thing that shall receive mouse packets.

behind INT15C2xx there are more mouse functions available.
C207 let you set your handler address but it doesn't save you from
enabling IRQ12.
__
wolfgang

;; pic_unmask_irq (1)
: mov dx, HEX (20)
: xor ax, ax
: in al, dx
; mov bl, (1 << 1)
; not bl
; and al, bl
; out dx, al
IN AL,0x21
AND AL,0xFD reset bit1
OUT 0x21,al
;; pic_unmask_irq (12)
;mov dx, HEX (A0)
;xor ax, ax
;in al, dx
;mov bl, (1 << 4)
;not bl
;and al, bl
;out dx, al
IN AL,0xA1
AND AL,0xEF reset bit4
OUT 0xA1,AL

you don't need to use DX for any I/O below 0x0100
and the NOPs are redundant, a better delay is the dummy OUT 0xeb,al

Post by Robert Pengelly
but it still doesn't work or do I need to do the 0xD4 for every write?

;; ps2_write_command (PS2_DISABLE_PORT1)
call ps2_wait_input
mov al, HEX (AD)
out HEX (64), al
nop
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Enable interrupt lines, enable translation.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ps2_write_command_read_data (PS2_READ_CONFIG)
call ps2_wait_input
mov al, HEX (20)
out HEX (64), al
nop
call ps2_wait_input
mov al, HEX (D4)
out HEX (64), al
nop
call ps2_wait_output
xor ax, ax
in al, HEX (60)
nop
;; status |= PS2_PORT1_IRQ | PS2_PORT1_TLATE
or al, HEX (01)
or al, HEX (40)
xchg bl, al
;; ps2_write_command_arg (PS2_WRITE_CONFIG, status)
call ps2_wait_input
mov al, HEX (60)
out HEX (64), al
nop
call ps2_wait_input
mov al, HEX (D4)
out HEX (64), al
nop
call ps2_wait_input
xchg al, bl
out HEX (60), al
nop
;; ps2_write_command_read_data (PS2_READ_CONFIG)
call ps2_wait_input
mov al, HEX (20)
out HEX (64), al
nop
call ps2_wait_input
mov al, HEX (D4)
out HEX (64), al
nop
call ps2_wait_output
xor ax, ax
in al, HEX (60)
nop
;; ps2_write_command_read_data (0xAE)
call ps2_wait_input
mov al, HEX (AE)
out HEX (64), al
nop
call ps2_wait_input
mov al, HEX (D4)
out HEX (64), al
nop
call ps2_wait_output
xor ax, ax
in al, HEX (60)
nop
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Test PS/2 port.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ps2_write_command_read_data (0xAB)
call ps2_wait_input
mov al, HEX (AB)
out HEX (64), al
nop
call ps2_wait_input
mov al, HEX (D4)
out HEX (64), al
nop
call ps2_wait_output
xor ax, ax
in al, HEX (60)
nop
and al, al
jnz mouse_initialize.no_ps2
call ps2_wait_input
mov al, HEX (AD)
out HEX (64), al
nop
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Clear interrupts while we set other up.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
cli
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; We'll use the extra segment to offset the correct positions
;; so make sure it is zero.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
xor ax, ax
mov es, ax
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Setup INT 74h.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
mov word ptr es:[HEX (74) * 4], offset ps2_handler
mov word ptr es:[HEX (74) * 4 + 2], cs
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Restore interrupts.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
sti

the STI should be after the two pic_unmask!

Post by Robert Pengelly
;; pic_unmask_irq (1)
xor ax, ax
in al, HEX (21)
nop

XOR ax,ax and NOP aren't required,
if you want AH to be zero all the time then make it once ahead of this.

Post by Robert Pengelly
and al, HEX (FD)
out HEX (21), al
nop
;; pic_unmask_irq (12)
xor ax, ax
in al, HEX (A1)
nop
and al, HEX (EF)
out HEX (A1), al
nop
;; ps2_write_command (PS2_ENABLE_PORT1)
call ps2_wait_input
mov al, HEX (AE)
out HEX (64), al
nop
call ps2_wait_input
mov al, HEX (D4)
out HEX (64), al
nop
;; ps2_write_data (0xFF)
call ps2_wait_input
mov al, HEX (FF)
out HEX (60), al
nop
but it still doesn't work. As for "a better delay is the dummy OUT 0xeb,al" does it matter what al is or should I just set it to zero or something else?

No, as long 0x00eb isn't an existing port (haven't seen any) AL can be
any value.
can you show what your wait-input does?
__
wolfgang

Robert Pengelly

2023-11-12 13:08:50 UTC

Does anyone know if a PS/2 mouse will be detected by the computer if it's plugged in > while the computer is on?

depends on OS, while windoze does, old DOS may not.

If it does then would using IRQ12 be a better choice instead of using INT 15h AX=0xC0xx?
That was meant to be instead of INT 15h AX=0xC2xx?

this are two different things :) you may need both.
PS/2 mouse keyboard combination is well defined,
INT15 is there for various mouse setups
IRQ12 is the thing that shall receive mouse packets.

behind INT15C2xx there are more mouse functions available.
C207 let you set your handler address but it doesn't save you from
enabling IRQ12.
__
wolfgang

;; pic_unmask_irq (1)
: mov dx, HEX (20)
: xor ax, ax
: in al, dx
; mov bl, (1 << 1)
; not bl
; and al, bl
; out dx, al
IN AL,0x21
AND AL,0xFD reset bit1
OUT 0x21,al
;; pic_unmask_irq (12)
;mov dx, HEX (A0)
;xor ax, ax
;in al, dx
;mov bl, (1 << 4)
;not bl
;and al, bl
;out dx, al
IN AL,0xA1
AND AL,0xEF reset bit4
OUT 0xA1,AL

you don't need to use DX for any I/O below 0x0100
and the NOPs are redundant, a better delay is the dummy OUT 0xeb,al

Post by Robert Pengelly
but it still doesn't work or do I need to do the 0xD4 for every write?

the STI should be after the two pic_unmask!

Post by Robert Pengelly
;; pic_unmask_irq (1)
xor ax, ax
in al, HEX (21)
nop

XOR ax,ax and NOP aren't required,
if you want AH to be zero all the time then make it once ahead of this.

No, as long 0x00eb isn't an existing port (haven't seen any) AL can be
any value.
can you show what your wait-input does?
__
wolfgang

ps2_wait_input:

push ax
mov cx, HEX (FFFF)

ps2_wait_input.loop:

xor ax, ax
in al, HEX (64)

and al, 0b00000010
jz ps2_wait_input.done

loop ps2_wait_input.loop

ps2_wait_input.done:

pop ax
ret

wolfgang kern

2023-11-12 14:07:02 UTC

On 12/11/2023 14:08, Robert Pengelly wrote:
...

Post by Robert Pengelly
push ax
mov cx, HEX (FFFF)
xor ax, ax

this isn't needed at all

Post by Robert Pengelly
in al, HEX (64)
and al, 0b00000010
jz ps2_wait_input.done
loop ps2_wait_input.loop
pop ax
ret

it may return too early if your PC is faster than 12MHZ :)
I'd use the DOS timer variable (can't remember it's at 40:xxxx ?)

push ax
push cx
push es
push 0x40 ;or use the longer MOV AX,0x0040 |MOV ES,AX
pop es
mov cx,[es:dostick]
add cx,2
L1:
IN AL,0x64
TEST AL,2
jz DONE
cmp cx,[es:dostick]
jb L1
done:
pop,,,, ret
__
wolfgang

Robert Pengelly

2023-11-12 14:41:27 UTC

push ax
mov cx, HEX (FFFF)
xor ax, ax

this isn't needed at all

in al, HEX (64)
and al, 0b00000010
jz ps2_wait_input.done
loop ps2_wait_input.loop
pop ax
ret

it may return too early if your PC is faster than 12MHZ :)
I'd use the DOS timer variable (can't remember it's at 40:xxxx ?)
push ax
push cx
push es
push 0x40 ;or use the longer MOV AX,0x0040 |MOV ES,AX
pop es
mov cx,[es:dostick]
add cx,2
IN AL,0x64
TEST AL,2
jz DONE
cmp cx,[es:dostick]
jb L1
pop,,,, ret
__
wolfgang

Most of the "xor ax, ax" are left over from me zeroing it out ready for printing to make things a little easier to read. And that's a good idea. I may need the longer version as I'm targeting 8086.

Robert Pengelly

2023-11-12 14:44:43 UTC

push ax
mov cx, HEX (FFFF)
xor ax, ax

this isn't needed at all

in al, HEX (64)
and al, 0b00000010
jz ps2_wait_input.done
loop ps2_wait_input.loop
pop ax
ret

it may return too early if your PC is faster than 12MHZ :)
I'd use the DOS timer variable (can't remember it's at 40:xxxx ?)
push ax
push cx
push es
push 0x40 ;or use the longer MOV AX,0x0040 |MOV ES,AX
pop es
mov cx,[es:dostick]
add cx,2
IN AL,0x64
TEST AL,2
jz DONE
cmp cx,[es:dostick]
jb L1
pop,,,, ret
__
wolfgang

Most of the "xor ax, ax" are left over from me zeroing it out ready for printing to make things a little easier to read. And that's a good idea. I may need the longer version as I'm targeting 8086.

What is dostick though?

wolfgang kern

2023-11-12 14:46:54 UTC

push ax
mov cx, HEX (FFFF)
xor ax, ax

this isn't needed at all

in al, HEX (64)
and al, 0b00000010
jz ps2_wait_input.done
loop ps2_wait_input.loop
pop ax
ret

it may return too early if your PC is faster than 12MHZ :)
I'd use the DOS timer variable (can't remember it's at 40:xxxx ?)
push ax
push cx
push es
push 0x40 ;or use the longer MOV AX,0x0040 |MOV ES,AX
pop es
mov cx,[es:dostick]
add cx,2
IN AL,0x64
TEST AL,2
jz DONE
cmp cx,[es:dostick]
jb L1
pop,,,, ret

Most of the "xor ax, ax" are left over from me zeroing it out ready for printing to make things a little easier to read. And that's a good idea.

how about MOV AH.00 upfront once ?

Post by Robert Pengelly
I may need the longer version as I'm targeting 8086.

oh you work in a museum ? :)
__
wolfgang

Robert Pengelly

2023-11-12 14:53:48 UTC

push ax
mov cx, HEX (FFFF)
xor ax, ax

this isn't needed at all

in al, HEX (64)
and al, 0b00000010
jz ps2_wait_input.done
loop ps2_wait_input.loop
pop ax
ret

it may return too early if your PC is faster than 12MHZ :)
I'd use the DOS timer variable (can't remember it's at 40:xxxx ?)
push ax
push cx
push es
push 0x40 ;or use the longer MOV AX,0x0040 |MOV ES,AX
pop es
mov cx,[es:dostick]
add cx,2
IN AL,0x64
TEST AL,2
jz DONE
cmp cx,[es:dostick]
jb L1
pop,,,, ret

Most of the "xor ax, ax" are left over from me zeroing it out ready for printing to make things a little easier to read. And that's a good idea.

how about MOV AH.00 upfront once ?

I may need the longer version as I'm targeting 8086.

oh you work in a museum ? :)
__
wolfgang

No, I'm just interested in the while 8086 stuff. Once I get a 8086 compatible OS working then maybe I'll move on to 386. I hate that most OS's are 64-bit only nowadays cause that leaves a lot of historical machines on outdated and unsecure OS's.

Robert Pengelly

2023-11-12 15:01:03 UTC

push ax
mov cx, HEX (FFFF)
xor ax, ax

this isn't needed at all

in al, HEX (64)
and al, 0b00000010
jz ps2_wait_input.done
loop ps2_wait_input.loop
pop ax
ret

it may return too early if your PC is faster than 12MHZ :)
I'd use the DOS timer variable (can't remember it's at 40:xxxx ?)
push ax
push cx
push es
push 0x40 ;or use the longer MOV AX,0x0040 |MOV ES,AX
pop es
mov cx,[es:dostick]
add cx,2
IN AL,0x64
TEST AL,2
jz DONE
cmp cx,[es:dostick]
jb L1
pop,,,, ret

Most of the "xor ax, ax" are left over from me zeroing it out ready for printing to make things a little easier to read. And that's a good idea.

how about MOV AH.00 upfront once ?

I may need the longer version as I'm targeting 8086.

oh you work in a museum ? :)
__
wolfgang

Made the changes to ps2_read_port and ps2_write_port along with using "out 0xEB, al" but it still doesn't work.

Robert Pengelly

2023-11-15 08:27:07 UTC

push ax
mov cx, HEX (FFFF)
xor ax, ax

this isn't needed at all

in al, HEX (64)
and al, 0b00000010
jz ps2_wait_input.done
loop ps2_wait_input.loop
pop ax
ret

it may return too early if your PC is faster than 12MHZ :)
I'd use the DOS timer variable (can't remember it's at 40:xxxx ?)
push ax
push cx
push es
push 0x40 ;or use the longer MOV AX,0x0040 |MOV ES,AX
pop es
mov cx,[es:dostick]
add cx,2
IN AL,0x64
TEST AL,2
jz DONE
cmp cx,[es:dostick]
jb L1
pop,,,, ret

Most of the "xor ax, ax" are left over from me zeroing it out ready for printing to make things a little easier to read. And that's a good idea.

how about MOV AH.00 upfront once ?

I may need the longer version as I'm targeting 8086.

oh you work in a museum ? :)
__
wolfgang

Made the changes to ps2_read_port and ps2_write_port along with using "out 0xEB, al" but it still doesn't work.

Right, I rewrite all the IRQ12 related stuff and it seems to work as I get an A printed in the handler when I capture the mouse with qemu, how do I tell the controller that I've got the data? I've tried:

in al, 0x20
out 0x20, al

in al, 0x60
out 0x60, al

and

in al 0x64
out 0x64, al

and nothing happens as I only get the A printed once

wolfgang kern

2023-11-16 06:35:54 UTC

On 15/11/2023 09:27, Robert Pengelly wrote:
...

Post by Robert Pengelly
in al, 0x20
out 0x20, al
in al, 0x60
out 0x60, al
and
in al 0x64
out 0x64, al
and nothing happens as I only get the A printed once

END of INTERRUPT(IRQ12):
MOV AL, 0xA0
OUT 0xA0,AL ;release IRQ 12
OUT 0x20,AL ;and the cascaded IRQ0..7

END OF INTERRUPT(IRQ4):
MOV AL,0x20
OUT 0x20,AL

but if the mouse is out of sync it may need a reset
__
wolfgang

Robert Pengelly

2023-11-16 13:39:34 UTC

Post by Robert Pengelly
in al, 0x20
out 0x20, al
in al, 0x60
out 0x60, al
and
in al 0x64
out 0x64, al
and nothing happens as I only get the A printed once

MOV AL, 0xA0
OUT 0xA0,AL ;release IRQ 12
OUT 0x20,AL ;and the cascaded IRQ0..7
MOV AL,0x20
OUT 0x20,AL
but if the mouse is out of sync it may need a reset
__
wolfgang

Right, I have:

ps2_handler:

push ax
in al, HEX (60)

mov al, 'A'
call writechr

mov al, HEX (A0)
out HEX (A0), al

mov al, HEX (20)
out HEX (20), al

pop ax
iret

and I get three A's printed every time I move the mouse so that's a good sign. Looking at the PS/2 packets on https://roborooter.com/post/serial-mice/ it has:

D7 D6 D5 D4 D3 D2 D1 D0
Byte 1 XV XV YS XS 1 M R L
Byte 2 X7 X6 X5 X4 X3 X2 X1 X0
Byte 3 Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0

L Left button state (1 = pressed down)
M Middle button state (1 = pressed down)
R Right button state (1 = pressed down)
X0-X7 Movement in X direction
Y0-Y7 Movement in Y direction
XS,YS Movement data sign bits (1 = negative)
XV,YV Movement data overflow bits (1 = overflow has occurred)

Is the D3 the status bit? Also, what is the XV/YV for? It says overflow bit but I'm a little confused as to what I do with it.

wolfgang kern

2023-11-17 03:37:03 UTC

Post by Robert Pengelly
in al, 0x20
out 0x20, al
in al, 0x60
out 0x60, al
and
in al 0x64
out 0x64, al
and nothing happens as I only get the A printed once

MOV AL, 0xA0
OUT 0xA0,AL ;release IRQ 12
OUT 0x20,AL ;and the cascaded IRQ0..7
MOV AL,0x20
OUT 0x20,AL
but if the mouse is out of sync it may need a reset
__
wolfgang

push ax
in al, HEX (60)

OK this releases the IRQ-pin

Post by Robert Pengelly
mov al, 'A'
call writechr

hope this call doesn't alter any SEGreg, IE-bit or rely on PIC timer.

**; mov al, HEX (A0)

MOV AL,0x20

Post by Robert Pengelly
out HEX (A0), al

**; mov al, HEX (20)

it is still 0x20

Post by Robert Pengelly
out HEX (20), al
pop ax
iret
D7 D6 D5 D4 D3 D2 D1 D0
Byte 1 XV XV YS XS 1 M R L
Byte 2 X7 X6 X5 X4 X3 X2 X1 X0
Byte 3 Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0
L Left button state (1 = pressed down)
M Middle button state (1 = pressed down)
R Right button state (1 = pressed down)
X0-X7 Movement in X direction
Y0-Y7 Movement in Y direction
XS,YS Movement data sign bits (1 = negative)
XV,YV Movement data overflow bits (1 = overflow has occurred)
Is the D3 the status bit? Also, what is the XV/YV for? It says overflow bit but I'm a little confused as to what I do with it.

in case of overflow discard movement data and read again.
someone tried to use OV-bits for movement expansion but worked rare.
__
wolfgang

Robert Pengelly

2023-11-17 06:37:10 UTC

Post by Robert Pengelly
in al, 0x20
out 0x20, al
in al, 0x60
out 0x60, al
and
in al 0x64
out 0x64, al
and nothing happens as I only get the A printed once

MOV AL, 0xA0
OUT 0xA0,AL ;release IRQ 12
OUT 0x20,AL ;and the cascaded IRQ0..7
MOV AL,0x20
OUT 0x20,AL
but if the mouse is out of sync it may need a reset
__
wolfgang

push ax
in al, HEX (60)

OK this releases the IRQ-pin

mov al, 'A'
call writechr

hope this call doesn't alter any SEGreg, IE-bit or rely on PIC timer.
**; mov al, HEX (A0)
MOV AL,0x20

out HEX (A0), al

**; mov al, HEX (20)
it is still 0x20

out HEX (20), al
pop ax
iret
D7 D6 D5 D4 D3 D2 D1 D0
Byte 1 XV XV YS XS 1 M R L
Byte 2 X7 X6 X5 X4 X3 X2 X1 X0
Byte 3 Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0
L Left button state (1 = pressed down)
M Middle button state (1 = pressed down)
R Right button state (1 = pressed down)
X0-X7 Movement in X direction
Y0-Y7 Movement in Y direction
XS,YS Movement data sign bits (1 = negative)
XV,YV Movement data overflow bits (1 = overflow has occurred)
Is the D3 the status bit? Also, what is the XV/YV for? It says overflow bit but I'm a little confused as to what I do with it.

in case of overflow discard movement data and read again.
someone tried to use OV-bits for movement expansion but worked rare.
__
wolfgang

Okay, I have:

ps2_handler:

push ds
push ax
push bx
push cx
push dx

mov ax, cs
mov ds, ax

in al, HEX (60)

test al, HEX (08)
jz ps2_handler.skip_init

xor bx, bx
mov cx, 3

mov [count], cl
mov [index], bx

ps2_handler.skip_init:

mov bx, offset buffer
add bx, [index]

mov [bx], al

inc word ptr [index]
dec byte ptr [count]

mov al, HEX (20)
out HEX (A0), al
jnz ps2_handler.done

ps2_handler.got_all:

xor ax, ax
xor dx, dx
xor cx, cx

mov bx, offset buffer
mov al, [bx]

test al, HEX (08)
jz ps2_handler.done

mov cl, 3
shl al, cl

sbb dh, dh
cbw

mov dl, [bx + 2]
neg dx
add [mouse_y], dx

mov al, [bx + 1]
add [mouse_x], ax

ps2_handler.done:

mov al, HEX (20)
out HEX (20), al

pop dx
pop cx
pop bx
pop ax
pop ds
iret

which works but the mouse can be a little jumpy sometimes, am I doing something wrong? Also, where would I disregard the movement if there's overflow? I'm guessing in ps2_handler.got_all but let me know if I'm mistaken.

wolfgang kern

2023-11-17 10:37:51 UTC

Post by Robert Pengelly
in al, 0x20
out 0x20, al
in al, 0x60
out 0x60, al
and
in al 0x64
out 0x64, al
and nothing happens as I only get the A printed once

MOV AL, 0xA0
OUT 0xA0,AL ;release IRQ 12
OUT 0x20,AL ;and the cascaded IRQ0..7
MOV AL,0x20
OUT 0x20,AL
but if the mouse is out of sync it may need a reset
__
wolfgang

push ax
in al, HEX (60)

OK this releases the IRQ-pin

mov al, 'A'
call writechr

hope this call doesn't alter any SEGreg, IE-bit or rely on PIC timer.
**; mov al, HEX (A0)
MOV AL,0x20

out HEX (A0), al

**; mov al, HEX (20)
it is still 0x20

in case of overflow discard movement data and read again.
someone tried to use OV-bits for movement expansion but worked rare.
__
wolfgang

push ds
push ax
push bx
push cx
push dx
mov ax, cs
mov ds, ax
in al, HEX (60)
test al, HEX (08)
jz ps2_handler.skip_init
xor bx, bx
mov cx, 3
mov [count], cl
mov [index], bx
mov bx, offset buffer
add bx, [index]
mov [bx], al
inc word ptr [index]
dec byte ptr [count]
mov al, HEX (20)
out HEX (A0), al
jnz ps2_handler.done
xor ax, ax
xor dx, dx
xor cx, cx
mov bx, offset buffer
mov al, [bx]
test al, HEX (08)
jz ps2_handler.done
mov cl, 3
shl al, cl
sbb dh, dh
cbw
mov dl, [bx + 2]
neg dx
add [mouse_y], dx
mov al, [bx + 1]
add [mouse_x], ax
mov al, HEX (20)
out HEX (20), al
pop dx
pop cx
pop bx
pop ax
pop ds
iret
which works but the mouse can be a little jumpy sometimes, am I doing something wrong? Also, where would I disregard the movement if there's overflow? I'm guessing in ps2_handler.got_all but let me know if I'm mistaken.

Yeah, something in got_all seems to be odd, any reason for SBB and NEG ?
CBW works on AL->AX only, it wont alter anything on DX.
Carry-flag is always clear after SHL.
I'd have mouse-position update apart from IRQ-handler because we get
only one byte per interrupt and IRQ-routines should be as short/fast as
possible. And avoid updates in case of overflow (just keep previous).
__
wolfgang

Robert Pengelly

2023-11-17 11:37:50 UTC

Post by Robert Pengelly
in al, 0x20
out 0x20, al
in al, 0x60
out 0x60, al
and
in al 0x64
out 0x64, al
and nothing happens as I only get the A printed once

MOV AL, 0xA0
OUT 0xA0,AL ;release IRQ 12
OUT 0x20,AL ;and the cascaded IRQ0..7
MOV AL,0x20
OUT 0x20,AL
but if the mouse is out of sync it may need a reset
__
wolfgang

push ax
in al, HEX (60)

OK this releases the IRQ-pin

mov al, 'A'
call writechr

hope this call doesn't alter any SEGreg, IE-bit or rely on PIC timer.
**; mov al, HEX (A0)
MOV AL,0x20

out HEX (A0), al

**; mov al, HEX (20)
it is still 0x20

in case of overflow discard movement data and read again.
someone tried to use OV-bits for movement expansion but worked rare.
__
wolfgang

Looking at https://c9x.me/x86/html/file_module_x86_id_285.html it says:

Bits shifted beyond the destination operand boundary are first shifted into the CF flag, then discarded. At the end of the shift operation, the CF flag contains the last bit shifted out of the destination operand.

So that would mean that the carry flag would either have 0 or 1 (maybe -1 and 1) according to the PS/2 section on https://roborooter.com/post/serial-mice/. As for the neg, without it moving the mouse up moves the cursor down and moving the mouse down moves the cursor up.

wolfgang kern

2023-11-17 13:50:39 UTC

Post by Robert Pengelly
in al, 0x20
out 0x20, al
in al, 0x60
out 0x60, al
and
in al 0x64
out 0x64, al
and nothing happens as I only get the A printed once

MOV AL, 0xA0
OUT 0xA0,AL ;release IRQ 12
OUT 0x20,AL ;and the cascaded IRQ0..7
MOV AL,0x20
OUT 0x20,AL
but if the mouse is out of sync it may need a reset
__
wolfgang

push ax
in al, HEX (60)

OK this releases the IRQ-pin

mov al, 'A'
call writechr

hope this call doesn't alter any SEGreg, IE-bit or rely on PIC timer.
**; mov al, HEX (A0)
MOV AL,0x20

out HEX (A0), al

**; mov al, HEX (20)
it is still 0x20

in case of overflow discard movement data and read again.
someone tried to use OV-bits for movement expansion but worked rare.
__
wolfgang

Bits shifted beyond the destination operand boundary are first shifted into the CF flag, then discarded. At the end of the shift operation, the CF flag contains the last bit shifted out of the destination operand.

Yes you are right here, I meant to tell SHL will put a zero into bit 0.

Post by Robert Pengelly
So that would mean that the carry flag would either have 0 or 1 (maybe -1 and 1) according to the PS/2 section on https://roborooter.com/post/serial-mice/. As for the neg, without it moving the mouse up moves the cursor down and moving the mouse down moves the cursor up.

rotate your mouse? :)
just kidding.
but my mouse variables are (except motions) unsigned.
So when I setup or change screen resolution I store the X/Y limits to be
used as bottom/right mouse limits (but I sub 8 for keeping the image
visible) and also use half of these X/Y values for screen center start.

then I only SUB motions and easy clip to top left by making any negative
Zero and replace any larger than limit with the limit.

If you SUB a negative it will result in an ADD w/o need for extra job.
__
wolfgang

Robert Pengelly

2023-11-17 14:24:17 UTC

Post by Robert Pengelly
in al, 0x20
out 0x20, al
in al, 0x60
out 0x60, al
and
in al 0x64
out 0x64, al
and nothing happens as I only get the A printed once

MOV AL, 0xA0
OUT 0xA0,AL ;release IRQ 12
OUT 0x20,AL ;and the cascaded IRQ0..7
MOV AL,0x20
OUT 0x20,AL
but if the mouse is out of sync it may need a reset
__
wolfgang

push ax
in al, HEX (60)

OK this releases the IRQ-pin

mov al, 'A'
call writechr

hope this call doesn't alter any SEGreg, IE-bit or rely on PIC timer.
**; mov al, HEX (A0)
MOV AL,0x20

out HEX (A0), al

**; mov al, HEX (20)
it is still 0x20

in case of overflow discard movement data and read again.
someone tried to use OV-bits for movement expansion but worked rare.
__
wolfgang

Yes you are right here, I meant to tell SHL will put a zero into bit 0.

rotate your mouse? :)
just kidding.
but my mouse variables are (except motions) unsigned.
So when I setup or change screen resolution I store the X/Y limits to be
used as bottom/right mouse limits (but I sub 8 for keeping the image
visible) and also use half of these X/Y values for screen center start.
then I only SUB motions and easy clip to top left by making any negative
Zero and replace any larger than limit with the limit.
If you SUB a negative it will result in an ADD w/o need for extra job.
__
wolfgang

"I store the X/Y limits to be used as bottom/right mouse limits"

Yeah that is the plan eventually, I'm just testing things at the moment. Am I right by checking bit 4? If I am then how do I know that it's not byte 2 or 3 that has bit 4 set?

wolfgang kern

2023-11-17 15:10:33 UTC

On 17/11/2023 15:24, Robert Pengelly wrote:
...

Post by Robert Pengelly
"I store the X/Y limits to be used as bottom/right mouse limits"
Yeah that is the plan eventually, I'm just testing things at the moment. Am I right by checking bit 4? If I am then how do I know that it's not byte 2 or 3 that has bit 4 set?

on PS/2 you check bit3 with TEST AL,8
but b3 would only show up set in byte2&3 when a motion is reported,
so there is a good chance to see only 1st byte have b3 set.

But it is a crap design anyway, if you move your mouse fast it may jump
because of false indication of the sync bit.
__
wolfgang

Robert Pengelly

2023-11-17 15:28:07 UTC

on PS/2 you check bit3 with TEST AL,8
but b3 would only show up set in byte2&3 when a motion is reported,
so there is a good chance to see only 1st byte have b3 set.
But it is a crap design anyway, if you move your mouse fast it may jump
because of false indication of the sync bit.
__
wolfgang

That's what I'm doing. Is there not anything I can do to stop false detections?

wolfgang kern

2023-11-17 15:56:49 UTC

Post by Robert Pengelly
...
"I store the X/Y limits to be used as bottom/right mouse limits"
Yeah that is the plan eventually, I'm just testing things at the moment. Am I right by checking bit 4? If I am then how do I know that it's not byte 2 or 3 that has bit 4 set?

on PS/2 you check bit3 with TEST AL,8
but b3 would only show up set in byte2&3 when a motion is reported,
so there is a good chance to see only 1st byte have b3 set.
But it is a crap design anyway, if you move your mouse fast it may jump
because of false indication of the sync bit.

That's what I'm doing. Is there not anything I can do to stop false detections?

I once checked and the only halfway working solution was to have all
IRQ-routines (especially IRQ_0 PIT) as short and fast as possible with
all event handlers apart (not within IRQ handlers) in an idle queue.
So the mouse packets will rare to never be split to fall out of sync.

I used this method for all interrupts and it sped up my whole OS by
magnitudes.
__
wolfgang

Robert Pengelly

2023-11-17 17:06:14 UTC

on PS/2 you check bit3 with TEST AL,8
but b3 would only show up set in byte2&3 when a motion is reported,
so there is a good chance to see only 1st byte have b3 set.
But it is a crap design anyway, if you move your mouse fast it may jump
because of false indication of the sync bit.

That's what I'm doing. Is there not anything I can do to stop false detections?

I once checked and the only halfway working solution was to have all
IRQ-routines (especially IRQ_0 PIT) as short and fast as possible with
all event handlers apart (not within IRQ handlers) in an idle queue.
So the mouse packets will rare to never be split to fall out of sync.
I used this method for all interrupts and it sped up my whole OS by
magnitudes.
__
wolfgang

I changed to:

ps2_handler:

push ds
push ax
push bx
push cx
push dx

mov ax, cs
mov ds, ax

in al, HEX (60)

test al, HEX (08)
jz ps2_handler.skip_init

mov byte ptr [ps2_updated], 0

xor bx, bx
mov cx, 3

mov [count], cl
mov [index], bx

ps2_handler.skip_init:

mov bx, offset ps2_buffer
add bx, [index]

mov [bx], al

inc word ptr [index]
dec byte ptr [count]

mov al, HEX (20)
out HEX (A0), al

mov al, HEX (20)
out HEX (20), al

jnz ps2_handler.done

ps2_handler.got_all:

mov byte ptr [ps2_updated], 1

ps2_handler.done:

pop dx
pop cx
pop bx
pop ax
pop ds
iret

and

update_mouse:

push ax
push bx
push cx
push dx
push ds

mov ax, cs
mov ds, ax

cmp byte ptr [ps2_updated], 1
jne update_mouse.serial

xor ax, ax
xor dx, dx
xor cx, cx

mov bx, offset ps2_buffer
mov al, [bx]

test al, HEX (08)
jz update_mouse.done

mov cl, 3
shl al, cl

sbb dh, dh
cbw

mov dl, [bx + 2]
neg dx
add [mouse_y], dx

mov al, [bx + 1]
add [mouse_x], ax

update_mouse.serial:

mov bx, [mouse_x]
shr bx
shr bx
shr bx

mov cx, [mouse_y]
shr cx
shr cx
shr cx
shr cx

update_mouse.move:

mov ah, HEX (02)
xor bh, bh
mov dh, cl
mov dl, bl
int HEX (10)

update_mouse.done:

pop ds
pop dx
pop cx
pop bx
pop ax
ret

Just for testing and the mouse detection is even worse. The update mouse is called from my INT 1Ch handler.

wolfgang kern

2023-11-17 22:13:16 UTC

on PS/2 you check bit3 with TEST AL,8
but b3 would only show up set in byte2&3 when a motion is reported,
so there is a good chance to see only 1st byte have b3 set.
But it is a crap design anyway, if you move your mouse fast it may jump
because of false indication of the sync bit.

That's what I'm doing. Is there not anything I can do to stop false detections?

I once checked and the only halfway working solution was to have all
IRQ-routines (especially IRQ_0 PIT) as short and fast as possible with
all event handlers apart (not within IRQ handlers) in an idle queue.
So the mouse packets will rare to never be split to fall out of sync.
I used this method for all interrupts and it sped up my whole OS by
magnitudes.
__
wolfgang

push ds
push ax
push bx
push cx
push dx
mov ax, cs
mov ds, ax
in al, HEX (60)
test al, HEX (08)
jz ps2_handler.skip_init
mov byte ptr [ps2_updated], 0
xor bx, bx
mov cx, 3
mov [count], cl
mov [index], bx
mov bx, offset ps2_buffer
add bx, [index]
mov [bx], al
inc word ptr [index]
dec byte ptr [count]
mov al, HEX (20)
out HEX (A0), al
mov al, HEX (20)
out HEX (20), al
jnz ps2_handler.done
mov byte ptr [ps2_updated], 1
pop dx
pop cx
pop bx
pop ax
pop ds
iret
and

*> push ax
*> push bx
*> push cx
*> push dx
*> push ds
*>
*> mov ax, cs
*> mov ds, ax
*>
*> cmp byte ptr [ps2_updated], 1
*> jne update_mouse.serial

I'd use instead of the above:
update_ mouse:
cmp byte ptr [cs:ps2_updated],1
jne update
ret
update:
push ...

Post by Robert Pengelly
xor ax, ax
xor dx, dx
xor cx, cx
mov bx, offset ps2_buffer
mov al, [bx]
test al, HEX (08)
jz update_mouse.done
mov cl, 3
shl al, cl
sbb dh, dh
cbw
mov dl, [bx + 2]
neg dx
add [mouse_y], dx
mov al, [bx + 1]
add [mouse_x], ax
mov bx, [mouse_x]
shr bx
shr bx
shr bx
mov cx, [mouse_y]
shr cx
shr cx
shr cx
shr cx
mov ah, HEX (02)
xor bh, bh
mov dh, cl
mov dl, bl
int HEX (10)
pop ds
pop dx
pop cx
pop bx
pop ax
ret
Just for testing and the mouse detection is even worse.

save time by using less registers (DS AX CX) in IRQ12 and
perhaps replace 'updated' by [count]==0 as packet complete indicator
(save on one memory access).

Post by Robert Pengelly
The update mouse is called from my INT 1Ch handler.

this is the main problem, INT 1C is called by the IRQ_0 handler which
slows all IRQ-response that way.

my main idle code contains almost nothing:

MAIN_IDLE:
STI
TEST,dword [SS:global_flags],-1 ;I have all variables on stack bottom
;and can check 32 event flags at once
JE MAIN_IDLE ;loop as long no event reported
... here I check for keys, mouse moves, buttons pressed/released
... act on it (fast and short) reset parameters if required
JMP MAIN_IDLE
__
wolfgang

Robert Pengelly

2023-11-18 18:53:32 UTC

on PS/2 you check bit3 with TEST AL,8
but b3 would only show up set in byte2&3 when a motion is reported,
so there is a good chance to see only 1st byte have b3 set.
But it is a crap design anyway, if you move your mouse fast it may jump
because of false indication of the sync bit.

That's what I'm doing. Is there not anything I can do to stop false detections?

I once checked and the only halfway working solution was to have all
IRQ-routines (especially IRQ_0 PIT) as short and fast as possible with
all event handlers apart (not within IRQ handlers) in an idle queue.
So the mouse packets will rare to never be split to fall out of sync.
I used this method for all interrupts and it sped up my whole OS by
magnitudes.
__
wolfgang

*> push ax
*> push bx
*> push cx
*> push dx
*> push ds
*>
*> mov ax, cs
*> mov ds, ax
*>
*> cmp byte ptr [ps2_updated], 1
*> jne update_mouse.serial
cmp byte ptr [cs:ps2_updated],1
jne update
ret
push ...

xor ax, ax
xor dx, dx
xor cx, cx
mov bx, offset ps2_buffer
mov al, [bx]
test al, HEX (08)
jz update_mouse.done
mov cl, 3
shl al, cl
sbb dh, dh
cbw
mov dl, [bx + 2]
neg dx
add [mouse_y], dx
mov al, [bx + 1]
add [mouse_x], ax
mov bx, [mouse_x]
shr bx
shr bx
shr bx
mov cx, [mouse_y]
shr cx
shr cx
shr cx
shr cx
mov ah, HEX (02)
xor bh, bh
mov dh, cl
mov dl, bl
int HEX (10)
pop ds
pop dx
pop cx
pop bx
pop ax
ret
Just for testing and the mouse detection is even worse.

save time by using less registers (DS AX CX) in IRQ12 and
perhaps replace 'updated' by [count]==0 as packet complete indicator
(save on one memory access).

The update mouse is called from my INT 1Ch handler.

this is the main problem, INT 1C is called by the IRQ_0 handler which
slows all IRQ-response that way.
STI
TEST,dword [SS:global_flags],-1 ;I have all variables on stack bottom
;and can check 32 event flags at once
JE MAIN_IDLE ;loop as long no event reported
... here I check for keys, mouse moves, buttons pressed/released
... act on it (fast and short) reset parameters if required
JMP MAIN_IDLE
__
wolfgang

After I do:

mov al, HEX (AB)
call ps2_write_command_read_data

on real hardware, I get 0x9C in al. Any ideas what the 9C means? I've tried googling it but I can't seem to find anything.

wolfgang kern

2023-11-19 02:35:49 UTC

on PS/2 you check bit3 with TEST AL,8
but b3 would only show up set in byte2&3 when a motion is reported,
so there is a good chance to see only 1st byte have b3 set.
But it is a crap design anyway, if you move your mouse fast it may jump
because of false indication of the sync bit.

That's what I'm doing. Is there not anything I can do to stop false detections?

I once checked and the only halfway working solution was to have all
IRQ-routines (especially IRQ_0 PIT) as short and fast as possible with
all event handlers apart (not within IRQ handlers) in an idle queue.
So the mouse packets will rare to never be split to fall out of sync.
I used this method for all interrupts and it sped up my whole OS by
magnitudes.
__
wolfgang

save time by using less registers (DS AX CX) in IRQ12 and
perhaps replace 'updated' by [count]==0 as packet complete indicator
(save on one memory access).

The update mouse is called from my INT 1Ch handler.

mov al, HEX (AB)
call ps2_write_command_read_data
on real hardware, I get 0x9C in al. Any ideas what the 9C means? I've tried googling it but I can't seem to find anything.

you might read from keyboard instead of mouse, but as long I don't know
what this call does in detail I can only guess.
how about the other issues? are mice still jumping around ? :)
__
wolfgang

Robert Pengelly

2023-11-19 07:14:24 UTC

on PS/2 you check bit3 with TEST AL,8
but b3 would only show up set in byte2&3 when a motion is reported,
so there is a good chance to see only 1st byte have b3 set.
But it is a crap design anyway, if you move your mouse fast it may jump
because of false indication of the sync bit.

That's what I'm doing. Is there not anything I can do to stop false detections?

I once checked and the only halfway working solution was to have all
IRQ-routines (especially IRQ_0 PIT) as short and fast as possible with
all event handlers apart (not within IRQ handlers) in an idle queue.
So the mouse packets will rare to never be split to fall out of sync.
I used this method for all interrupts and it sped up my whole OS by
magnitudes.
__
wolfgang

save time by using less registers (DS AX CX) in IRQ12 and
perhaps replace 'updated' by [count]==0 as packet complete indicator
(save on one memory access).

The update mouse is called from my INT 1Ch handler.

mov al, HEX (AB)
call ps2_write_command_read_data
on real hardware, I get 0x9C in al. Any ideas what the 9C means? I've tried googling it but I can't seem to find anything.

you might read from keyboard instead of mouse, but as long I don't know
what this call does in detail I can only guess.
how about the other issues? are mice still jumping around ? :)
__
wolfgang

No I got slightly different code now:

ps2_handler:

push ax
push bx
push cx
push dx
push si

mov si, cs:[ps2_index]
in al, HEX (64)

test al, HEX (20)
jz ps2_handler.done

in al, HEX (60)

mov cs:[ps2_buffer + si], al
inc word ptr cs:[ps2_index]

cmp si, 2
jb ps2_handler.done

ps2_handler.got_all:

mov word ptr cs:[ps2_index], 0

xor ax, ax
xor dx, dx
xor cx, cx

mov bx, offset ps2_buffer
mov al, cs:[bx]

test al, HEX (08)
jz ps2_handler.done

mov cl, 3
shl al, cl

sbb dh, dh
cbw

mov dl, cs:[bx + 2]
neg dx
add cs:[mouse_y], dx

mov al, cs:[bx + 1]
add cs:[mouse_x], ax

ps2_handler.done:

mov al, HEX (20)
out HEX (A0), al
out HEX (20), al

pop si
pop dx
pop cx
pop bx
pop ax
iret

and it's been working great so far just can't get IRQ12 working on a laptop due to that 0x9C issue. Forgot to add that even:

mov al, HEX (A9)
call ps2_write_command_read_data

gives me 0x9C. So both keyboard and mouse aren't detected but they were working when I had the INT 15h stuff implemented.

Robert Pengelly

2023-11-19 07:30:02 UTC

on PS/2 you check bit3 with TEST AL,8
but b3 would only show up set in byte2&3 when a motion is reported,
so there is a good chance to see only 1st byte have b3 set.
But it is a crap design anyway, if you move your mouse fast it may jump
because of false indication of the sync bit.

That's what I'm doing. Is there not anything I can do to stop false detections?

I once checked and the only halfway working solution was to have all
IRQ-routines (especially IRQ_0 PIT) as short and fast as possible with
all event handlers apart (not within IRQ handlers) in an idle queue.
So the mouse packets will rare to never be split to fall out of sync.
I used this method for all interrupts and it sped up my whole OS by
magnitudes.
__
wolfgang

save time by using less registers (DS AX CX) in IRQ12 and
perhaps replace 'updated' by [count]==0 as packet complete indicator
(save on one memory access).

The update mouse is called from my INT 1Ch handler.

mov al, HEX (AB)
call ps2_write_command_read_data
on real hardware, I get 0x9C in al. Any ideas what the 9C means? I've tried googling it but I can't seem to find anything.

you might read from keyboard instead of mouse, but as long I don't know
what this call does in detail I can only guess.
how about the other issues? are mice still jumping around ? :)
__
wolfgang

push ax
push bx
push cx
push dx
push si
mov si, cs:[ps2_index]
in al, HEX (64)
test al, HEX (20)
jz ps2_handler.done
in al, HEX (60)
mov cs:[ps2_buffer + si], al
inc word ptr cs:[ps2_index]
cmp si, 2
jb ps2_handler.done
mov word ptr cs:[ps2_index], 0
xor ax, ax
xor dx, dx
xor cx, cx
mov bx, offset ps2_buffer
mov al, cs:[bx]
test al, HEX (08)
jz ps2_handler.done
mov cl, 3
shl al, cl
sbb dh, dh
cbw
mov dl, cs:[bx + 2]
neg dx
add cs:[mouse_y], dx
mov al, cs:[bx + 1]
add cs:[mouse_x], ax
mov al, HEX (20)
out HEX (A0), al
out HEX (20), al
pop si
pop dx
pop cx
pop bx
pop ax
iret
mov al, HEX (A9)
call ps2_write_command_read_data
gives me 0x9C. So both keyboard and mouse aren't detected but they were working when I had the INT 15h stuff implemented.

I messed that last part up sorry. I meant the keyboard works with int 16h which I'm still using and the mouse worked with the int 15h stuff implemented but for some reason neither the mouse nor keyboard are getting detected for the IRQ's.

wolfgang kern

2023-11-19 09:28:47 UTC

On 19/11/2023 08:30, Robert Pengelly wrote:
...

mov al, HEX (AB)
call ps2_write_command_read_data
on real hardware, I get 0x9C in al. Any ideas what the 9C means? I've tried googling it but I can't seem to find anything.

you might read from keyboard instead of mouse, but as long I don't know
what this call does in detail I can only guess.
how about the other issues? are mice still jumping around ? :)

IRQ_12 handler: or else

push ax
push bx
push cx
push dx
push si ;what's wrong with using BX ?
mov si, cs:[ps2_index]
in al, HEX (64)
test al, HEX (20)
jz ps2_handler.done

this three above are somehow redundant because when IRQ_12 occur then
port 60 holds data ready to read.

in al, HEX (60)

TEST AL,8
jz skip_init
...

mov cs:[ps2_buffer + si], al
inc word ptr cs:[ps2_index]
cmp si, 2
jb ps2_handler.done

so you again have the mouse-update within the IRQ, not best choice.
you get there only when the packet is complete ***

mov word ptr cs:[ps2_index], 0
xor ax, ax
xor dx, dx
xor cx, cx
mov bx, offset ps2_buffer
mov al, cs:[bx]

***

test al, HEX (08)
jz ps2_handler.done

***

mov cl, 3
shl al, cl

something went wrong down there, no my trousers aren't wet.
PS/2 reports 9 bit signed X/Y movement values

sbb dh, dh

when did DX get data apart from zero?

cbw
mov dl, cs:[bx + 2]
neg dx
add cs:[mouse_y], dx
mov al, cs:[bx + 1]
add cs:[mouse_x], ax
mov al, HEX (20)
out HEX (A0), al
out HEX (20), al
pop si
pop dx
pop cx
pop bx
pop ax
iret
and it's been working great so far

I don't believe that this code above work at all.

mov al, HEX (A9)
call ps2_write_command_read_data
gives me 0x9C. So both keyboard and mouse aren't detected but they were working when I had the INT 15h stuff implemented.

show us the code in "ps2_write_command_read_data"
__
wolfgang

Robert Pengelly

2023-11-19 09:40:56 UTC

...

mov al, HEX (AB)
call ps2_write_command_read_data
on real hardware, I get 0x9C in al. Any ideas what the 9C means? I've tried googling it but I can't seem to find anything.

you might read from keyboard instead of mouse, but as long I don't know
what this call does in detail I can only guess.
how about the other issues? are mice still jumping around ? :)

IRQ_12 handler: or else

push ax
push bx
push cx
push dx
push si ;what's wrong with using BX ?
mov si, cs:[ps2_index]
in al, HEX (64)
test al, HEX (20)
jz ps2_handler.done

this three above are somehow redundant because when IRQ_12 occur then
port 60 holds data ready to read.

in al, HEX (60)

TEST AL,8
jz skip_init
...

mov cs:[ps2_buffer + si], al
inc word ptr cs:[ps2_index]
cmp si, 2
jb ps2_handler.done

so you again have the mouse-update within the IRQ, not best choice.
you get there only when the packet is complete ***

mov word ptr cs:[ps2_index], 0
xor ax, ax
xor dx, dx
xor cx, cx
mov bx, offset ps2_buffer
mov al, cs:[bx]

***

test al, HEX (08)
jz ps2_handler.done

***

mov cl, 3
shl al, cl

something went wrong down there, no my trousers aren't wet.
PS/2 reports 9 bit signed X/Y movement values

sbb dh, dh

when did DX get data apart from zero?

I don't believe that this code above work at all.

mov al, HEX (A9)
call ps2_write_command_read_data
gives me 0x9C. So both keyboard and mouse aren't detected but they were working when I had the INT 15h stuff implemented.

show us the code in "ps2_write_command_read_data"
__
wolfgang

That code works, at least in qemu. I haven't been able to test on real hardware due to the 0x9C thing:

ps2_write_command:

call ps2_disable
call ps2_wait_input

out HEX (64), al
call ps2_enable

ret

ps2_write_command_read_data:

call ps2_write_command
call ps2_read_data

ret

ps2_read_data:

call ps2_wait_output

in al, HEX (60)
ret

That's the three main functions (besides the disable and enable ones). You already helped me with ps2_wait input and I used some of the changes to fix ps2_wait_output.

wolfgang kern

2023-11-19 10:32:41 UTC

...

mov al, HEX (AB)
call ps2_write_command_read_data
on real hardware, I get 0x9C in al. Any ideas what the 9C means? I've tried googling it but I can't seem to find anything.

you might read from keyboard instead of mouse, but as long I don't know
what this call does in detail I can only guess.
how about the other issues? are mice still jumping around ? :)

IRQ_12 handler: or else

push ax
push bx
push cx
push dx
push si ;what's wrong with using BX ?
mov si, cs:[ps2_index]
in al, HEX (64)
test al, HEX (20)
jz ps2_handler.done

this three above are somehow redundant because when IRQ_12 occur then
port 60 holds data ready to read.

in al, HEX (60)

TEST AL,8
jz skip_init
...

mov cs:[ps2_buffer + si], al
inc word ptr cs:[ps2_index]
cmp si, 2
jb ps2_handler.done

so you again have the mouse-update within the IRQ, not best choice.
you get there only when the packet is complete ***

mov word ptr cs:[ps2_index], 0
xor ax, ax
xor dx, dx
xor cx, cx
mov bx, offset ps2_buffer
mov al, cs:[bx]

***

test al, HEX (08)
jz ps2_handler.done

***

mov cl, 3
shl al, cl

something went wrong down there, no my trousers aren't wet.
PS/2 reports 9 bit signed X/Y movement values

sbb dh, dh

when did DX get data apart from zero?

I don't believe that this code above work at all.

mov al, HEX (A9)
call ps2_write_command_read_data

WHY use A9 at all ? (see below)

gives me 0x9C. So both keyboard and mouse aren't detected but they were working when I had the INT 15h stuff implemented.

show us the code in "ps2_write_command_read_data"

That code works, at least in qemu.

QEMU may just ignore your code and work it's own instead.

Post by Robert Pengelly
call ps2_disable
call ps2_wait_input
out HEX (64), al
call ps2_enable
ret

(Table P0406)
Values for keyboard/mouse test result on PORT 0060h:
00h no error
01h keyboard clock line stuck low
02h keyboard clock line stuck high
03h keyboard data line is stuck low
04h keyboard data line stuck high
05h (Compaq only) diagnostic feature

A7 Disable mouse port
A8 Enable mouse port
A9 MCA test mouse port see Table P0406.
A9 AMI set internal flag "good write cache"
AD Disable keybd port
AE Enable keybd port

D4 F4 enable mouse (stream mode)
D4 F5 disable mouse (default after reset)

Post by Robert Pengelly
call ps2_write_command
call ps2_read_data
ret
call ps2_wait_output
in al, HEX (60)
ret
That's the three main functions (besides the disable and enable ones). You already helped me with ps2_wait input and I used some of the changes to fix ps2_wait_output.

for early tests, I'd inline these few bytes and avoid calls.
__
wolfgang

Robert Pengelly

2023-11-19 10:42:34 UTC

...

mov al, HEX (AB)
call ps2_write_command_read_data
on real hardware, I get 0x9C in al. Any ideas what the 9C means? I've tried googling it but I can't seem to find anything.

you might read from keyboard instead of mouse, but as long I don't know
what this call does in detail I can only guess.
how about the other issues? are mice still jumping around ? :)

IRQ_12 handler: or else

push ax
push bx
push cx
push dx
push si ;what's wrong with using BX ?
mov si, cs:[ps2_index]
in al, HEX (64)
test al, HEX (20)
jz ps2_handler.done

this three above are somehow redundant because when IRQ_12 occur then
port 60 holds data ready to read.

in al, HEX (60)

TEST AL,8
jz skip_init
...

mov cs:[ps2_buffer + si], al
inc word ptr cs:[ps2_index]
cmp si, 2
jb ps2_handler.done

so you again have the mouse-update within the IRQ, not best choice.
you get there only when the packet is complete ***

mov word ptr cs:[ps2_index], 0
xor ax, ax
xor dx, dx
xor cx, cx
mov bx, offset ps2_buffer
mov al, cs:[bx]

***

test al, HEX (08)
jz ps2_handler.done

***

mov cl, 3
shl al, cl

something went wrong down there, no my trousers aren't wet.
PS/2 reports 9 bit signed X/Y movement values

sbb dh, dh

when did DX get data apart from zero?

I don't believe that this code above work at all.

mov al, HEX (A9)
call ps2_write_command_read_data

WHY use A9 at all ? (see below)

gives me 0x9C. So both keyboard and mouse aren't detected but they were working when I had the INT 15h stuff implemented.

show us the code in "ps2_write_command_read_data"

That code works, at least in qemu.

QEMU may just ignore your code and work it's own instead.

Post by Robert Pengelly
call ps2_disable
call ps2_wait_input
out HEX (64), al
call ps2_enable
ret

(Table P0406)
00h no error
01h keyboard clock line stuck low
02h keyboard clock line stuck high
03h keyboard data line is stuck low
04h keyboard data line stuck high
05h (Compaq only) diagnostic feature
A7 Disable mouse port
A8 Enable mouse port
A9 MCA test mouse port see Table P0406.
A9 AMI set internal flag "good write cache"
AD Disable keybd port
AE Enable keybd port
D4 F4 enable mouse (stream mode)
D4 F5 disable mouse (default after reset)

for early tests, I'd inline these few bytes and avoid calls.
__
wolfgang

Just re-ran the test on the laptop and I'm definitely getting 0x9C instead of any of the ones you sent but I have no idea what 9C means.

Robert Pengelly

2023-11-19 10:45:39 UTC

...

mov al, HEX (AB)
call ps2_write_command_read_data
on real hardware, I get 0x9C in al. Any ideas what the 9C means? I've tried googling it but I can't seem to find anything.

you might read from keyboard instead of mouse, but as long I don't know
what this call does in detail I can only guess.
how about the other issues? are mice still jumping around ? :)

IRQ_12 handler: or else

push ax
push bx
push cx
push dx
push si ;what's wrong with using BX ?
mov si, cs:[ps2_index]
in al, HEX (64)
test al, HEX (20)
jz ps2_handler.done

this three above are somehow redundant because when IRQ_12 occur then
port 60 holds data ready to read.

in al, HEX (60)

TEST AL,8
jz skip_init
...

mov cs:[ps2_buffer + si], al
inc word ptr cs:[ps2_index]
cmp si, 2
jb ps2_handler.done

so you again have the mouse-update within the IRQ, not best choice.
you get there only when the packet is complete ***

mov word ptr cs:[ps2_index], 0
xor ax, ax
xor dx, dx
xor cx, cx
mov bx, offset ps2_buffer
mov al, cs:[bx]

***

test al, HEX (08)
jz ps2_handler.done

***

mov cl, 3
shl al, cl

something went wrong down there, no my trousers aren't wet.
PS/2 reports 9 bit signed X/Y movement values

sbb dh, dh

when did DX get data apart from zero?

I don't believe that this code above work at all.

mov al, HEX (A9)
call ps2_write_command_read_data

WHY use A9 at all ? (see below)

gives me 0x9C. So both keyboard and mouse aren't detected but they were working when I had the INT 15h stuff implemented.

show us the code in "ps2_write_command_read_data"

That code works, at least in qemu.

QEMU may just ignore your code and work it's own instead.

Post by Robert Pengelly
call ps2_disable
call ps2_wait_input
out HEX (64), al
call ps2_enable
ret

for early tests, I'd inline these few bytes and avoid calls.
__
wolfgang

Just re-ran the test on the laptop and I'm definitely getting 0x9C instead of any of the ones you sent but I have no idea what 9C means.

Just noticed you asked "WHY use A9 at all?". Looking at https://wiki.osdev.org/%228042%22_PS/2_Controller it has "0xA9 Test second PS/2 port (only if 2 PS/2 ports supported)" so that's what I'm doing, I'm testing the port.

wolfgang kern

2023-11-19 12:04:15 UTC

On 19/11/2023 11:45, Robert Pengelly wrote:
...

Post by Robert Pengelly
Just noticed you asked "WHY use A9 at all?". Looking at https://wiki.osdev.org/%228042%22_PS/2_Controller it has "0xA9 Test second PS/2 port (only if 2 PS/2 ports supported)" so that's what I'm doing, I'm testing the port.

OK, it's a wiki page :) so modified by many and not all know best.
I checked on and it doesn't tell anything about 9C.
perhaps your virtual or OLD hardware haven't PS/2 mice support at all.

I'd try it again without CMD A9 and assume you have both PS/2 conns,
or look at the back of you PC and count PS/2 connectors :) :) :)

If there is non or just one for KBD then your PC isn't that old and
support/emulate PS/2 over USB (like mine show that).
__
wolfgang

wolfgang kern

2023-11-19 11:35:55 UTC

...

mov al, HEX (AB)
call ps2_write_command_read_data
on real hardware, I get 0x9C in al. Any ideas what the 9C means? I've tried googling it but I can't seem to find anything.

you might read from keyboard instead of mouse, but as long I don't know
what this call does in detail I can only guess.
how about the other issues? are mice still jumping around ? :)

IRQ_12 handler: or else

push ax
push bx
push cx
push dx
push si ;what's wrong with using BX ?
mov si, cs:[ps2_index]
in al, HEX (64)
test al, HEX (20)
jz ps2_handler.done

this three above are somehow redundant because when IRQ_12 occur then
port 60 holds data ready to read.

in al, HEX (60)

TEST AL,8
jz skip_init
...

mov cs:[ps2_buffer + si], al
inc word ptr cs:[ps2_index]
cmp si, 2
jb ps2_handler.done

so you again have the mouse-update within the IRQ, not best choice.
you get there only when the packet is complete ***

mov word ptr cs:[ps2_index], 0
xor ax, ax
xor dx, dx
xor cx, cx
mov bx, offset ps2_buffer
mov al, cs:[bx]

***

test al, HEX (08)
jz ps2_handler.done

***

mov cl, 3
shl al, cl

something went wrong down there, no my trousers aren't wet.
PS/2 reports 9 bit signed X/Y movement values

sbb dh, dh

when did DX get data apart from zero?

I don't believe that this code above work at all.

mov al, HEX (A9)
call ps2_write_command_read_data

WHY use A9 at all ? (see below)

gives me 0x9C. So both keyboard and mouse aren't detected but they were working when I had the INT 15h stuff implemented.

show us the code in "ps2_write_command_read_data"

That code works, at least in qemu.

QEMU may just ignore your code and work it's own instead.

Post by Robert Pengelly
call ps2_disable
call ps2_wait_input
out HEX (64), al
call ps2_enable
ret

for early tests, I'd inline these few bytes and avoid calls.

Just re-ran the test on the laptop and I'm definitely getting 0x9C instead of any of the ones you sent but I have no idea what 9C means.

9C have the four lower bits all set. KEYBOARD stuck?? No idea wha you
get here.
WHY use cmd A9 at all ? I can't remember to have ever tried that one.
__
wolfgang

Robert Pengelly

2023-11-19 11:49:15 UTC

...

mov al, HEX (AB)
call ps2_write_command_read_data
on real hardware, I get 0x9C in al. Any ideas what the 9C means? I've tried googling it but I can't seem to find anything.

you might read from keyboard instead of mouse, but as long I don't know
what this call does in detail I can only guess.
how about the other issues? are mice still jumping around ? :)

IRQ_12 handler: or else

push ax
push bx
push cx
push dx
push si ;what's wrong with using BX ?
mov si, cs:[ps2_index]
in al, HEX (64)
test al, HEX (20)
jz ps2_handler.done

this three above are somehow redundant because when IRQ_12 occur then
port 60 holds data ready to read.

in al, HEX (60)

TEST AL,8
jz skip_init
...

mov cs:[ps2_buffer + si], al
inc word ptr cs:[ps2_index]
cmp si, 2
jb ps2_handler.done

so you again have the mouse-update within the IRQ, not best choice.
you get there only when the packet is complete ***

mov word ptr cs:[ps2_index], 0
xor ax, ax
xor dx, dx
xor cx, cx
mov bx, offset ps2_buffer
mov al, cs:[bx]

***

test al, HEX (08)
jz ps2_handler.done

***

mov cl, 3
shl al, cl

something went wrong down there, no my trousers aren't wet.
PS/2 reports 9 bit signed X/Y movement values

sbb dh, dh

when did DX get data apart from zero?

I don't believe that this code above work at all.

mov al, HEX (A9)
call ps2_write_command_read_data

WHY use A9 at all ? (see below)

gives me 0x9C. So both keyboard and mouse aren't detected but they were working when I had the INT 15h stuff implemented.

show us the code in "ps2_write_command_read_data"

That code works, at least in qemu.

QEMU may just ignore your code and work it's own instead.

Post by Robert Pengelly
call ps2_disable
call ps2_wait_input
out HEX (64), al
call ps2_enable
ret

for early tests, I'd inline these few bytes and avoid calls.

Just re-ran the test on the laptop and I'm definitely getting 0x9C instead of any of the ones you sent but I have no idea what 9C means.

9C have the four lower bits all set. KEYBOARD stuck?? No idea wha you
get here.
WHY use cmd A9 at all ? I can't remember to have ever tried that one.
__
wolfgang

I'm a little confused by "9C have the four lower bits all set." 9C as binary is 1001 1100 so how are all the lower bits set?

wolfgang kern

2023-11-19 12:07:21 UTC

On 19/11/2023 12:49, Robert Pengelly wrote:
...

Post by Robert Pengelly
I'm a little confused by "9C have the four lower bits all set." 9C as binary is 1001 1100 so how are all the lower bits set?

got me :) sorry I just tested your attention.
__
wolfgang

wolfgang kern

2023-11-19 12:10:40 UTC

Post by Robert Pengelly
I'm a little confused by "9C have the four lower bits all set." 9C as
binary is 1001 1100 so how are all the lower bits set?

got me :) sorry I just tested your attention.

BUT it still may mean KEYBD lines are stuck

Post by wolfgang kern
__
wolfgang

Robert Pengelly

2023-11-19 12:25:53 UTC

Post by Robert Pengelly
I'm a little confused by "9C have the four lower bits all set." 9C as
binary is 1001 1100 so how are all the lower bits set?

got me :) sorry I just tested your attention.

BUT it still may mean KEYBD lines are stuck

Post by wolfgang kern
__
wolfgang

I commented out the stuff related to A9 and mouse still doesn't work. I'm a little confused cause the int 15h stuff was PS/2 mouse so how did that work but the IRQ doesn't? What exactly does "KEYBD lines are stuck" mean?

wolfgang kern

2023-11-19 14:29:21 UTC

On 19/11/2023 13:25, Robert Pengelly wrote:
...

Post by Robert Pengelly
I commented out the stuff related to A9 and mouse still doesn't work. I'm a little confused cause the int 15h stuff was PS/2 mouse so how did that work but the IRQ doesn't?
What exactly does "KEYBD lines are stuck" mean?

it mean that it's disabled or there is nothing connected to the port.

what OS runs on your laptop ?
if it's not DOS or a very OLD windoze then it will ignore your code.
IRQ pointers and handling in Protected Mode is totally different to Real
Mode code. Virtual Mode may work with 16 bit code, but protect IRQs.

what type os connector is on your mouse ?
if it's not a round one then it is an USB-mouse.

PS/2 emulation for USB mice is possible on some machines but need to be
told to do so in the motherboard's chips-set.

sorry for I haven't asked all this earlier.
__
wolfgang

Robert Pengelly

2023-11-19 17:54:42 UTC

it mean that it's disabled or there is nothing connected to the port.
what OS runs on your laptop ?
if it's not DOS or a very OLD windoze then it will ignore your code.
IRQ pointers and handling in Protected Mode is totally different to Real
Mode code. Virtual Mode may work with 16 bit code, but protect IRQs.
what type os connector is on your mouse ?
if it's not a round one then it is an USB-mouse.
PS/2 emulation for USB mice is possible on some machines but need to be
told to do so in the motherboard's chips-set.
sorry for I haven't asked all this earlier.
__
wolfgang

I'm still a little confused as to how int 15h works but the IRQ stuff is returning 0x9C (I've checked an it's happening earlier than the 0xA9 stuff as well). As for the OS I'm dual booting Windows 8.1 and Ubuntu but I'm not using it inside either of them as I'm writing an OS's so it's booting from a USB. As for the connector I've tried the touchpad and a USB mouse and neither seen to work (again with int 15h they both work).

wolfgang kern

2023-11-20 01:07:18 UTC

it mean that it's disabled or there is nothing connected to the port.
what OS runs on your laptop ?
if it's not DOS or a very OLD windoze then it will ignore your code.
IRQ pointers and handling in Protected Mode is totally different to Real
Mode code. Virtual Mode may work with 16 bit code, but protect IRQs.
what type os connector is on your mouse ?
if it's not a round one then it is an USB-mouse.
PS/2 emulation for USB mice is possible on some machines but need to be
told to do so in the motherboard's chips-set.
sorry for I haven't asked all this earlier.

windoze 8.1 ?

OK if your own 16-bit OS booted from USB.
I'm just curious for which tool you used to put it there ?

INT15h is a BIOS function and the BIOS knows its hardware well.
Your laptop have neither keyboard nor mouse as PS/2 implemented,
both will be USB devices.
__
wolfgang

Robert Pengelly

2023-11-20 07:52:03 UTC

it mean that it's disabled or there is nothing connected to the port.
what OS runs on your laptop ?
if it's not DOS or a very OLD windoze then it will ignore your code.
IRQ pointers and handling in Protected Mode is totally different to Real
Mode code. Virtual Mode may work with 16 bit code, but protect IRQs.
what type os connector is on your mouse ?
if it's not a round one then it is an USB-mouse.
PS/2 emulation for USB mice is possible on some machines but need to be
told to do so in the motherboard's chips-set.
sorry for I haven't asked all this earlier.

windoze 8.1 ?
OK if your own 16-bit OS booted from USB.
I'm just curious for which tool you used to put it there ?
INT15h is a BIOS function and the BIOS knows its hardware well.
Your laptop have neither keyboard nor mouse as PS/2 implemented,
both will be USB devices.
__
wolfgang

I used dd on Linux to write an image to the USB. I know that INT 15h is a BIOS function but the 0xC2xx calls are for a PS/2 mouse aren't they? As I'm only focused on a 16-bit (real mode) OS at the moment would it be better if I just go back to INT 15h?

wolfgang kern

2023-11-20 09:36:28 UTC

Post by wolfgang kern
OK if your own 16-bit OS booted from USB.
I'm just curious for which tool you used to put it there ?
INT15h is a BIOS function and the BIOS knows its hardware well.
Your laptop have neither keyboard nor mouse as PS/2 implemented,
both will be USB devices.

I used dd on Linux to write an image to the USB. I know that INT 15h is a BIOS function but the 0xC2xx calls are for a PS/2 mouse aren't they?

RBIL name them PS w/o "/2", the BIOS may support all hardware it got.

Post by Robert Pengelly
As I'm only focused on a 16-bit (real mode) OS at the moment would it be better if I just go back to INT 15h?

You should, but when your 16bit RM OS once can control everything
possible it may become capable to detect USB devices and handle them.

But this needs switching forth and back to PM32 so it's a long way to go
(been there many years ago).
__
wolfgang

Scott Lurndal

2023-11-20 17:45:37 UTC

On 19/11/2023 18:54, Robert Pengelly wrote:=20

On Sunday, 19 November 2023 at 14:29:27 UTC, wolfgang kern wrote:=20

On 19/11/2023 13:25, Robert Pengelly wrote:=20
...=20

I commented out the stuff related to A9 and mouse still doesn't work.=

I'm a little confused cause the int 15h stuff was PS/2 mouse so how did th=
at work but the IRQ doesn't?=20

=20

What exactly does "KEYBD lines are stuck" mean?=20

it mean that it's disabled or there is nothing connected to the port.=

=20

=20
what OS runs on your laptop ?=20
if it's not DOS or a very OLD windoze then it will ignore your code.=

=20

IRQ pointers and handling in Protected Mode is totally different to Re=

al=20

Mode code. Virtual Mode may work with 16 bit code, but protect IRQs.=

=20

=20
what type os connector is on your mouse ?=20
if it's not a round one then it is an USB-mouse.=20
=20
PS/2 emulation for USB mice is possible on some machines but need to b=

e=20

told to do so in the motherboard's chips-set.=20
=20
sorry for I haven't asked all this earlier.

I'm still a little confused as to how int 15h works but the IRQ stuff i=

s returning 0x9C (I've checked an it's happening earlier than the 0xA9 stuf=
f as well). As for the OS I'm dual booting Windows 8.1 and Ubuntu but I'm n=
ot using it inside either of them as I'm writing an OS's so it's booting fr=
om a USB. As for the connector I've tried the touchpad and a USB mouse and =
neither seen to work (again with int 15h they both work).

windoze 8.1 ?=20
=20
OK if your own 16-bit OS booted from USB.=20
I'm just curious for which tool you used to put it there ?=20
=20
INT15h is a BIOS function and the BIOS knows its hardware well.=20
Your laptop have neither keyboard nor mouse as PS/2 implemented,=20
both will be USB devices.=20
__=20
wolfgang

I used dd on Linux to write an image to the USB. I know that INT 15h is a =
BIOS function but the 0xC2xx calls are for a PS/2 mouse aren't they? As I'=
m only focused on a 16-bit (real mode) OS at the moment would it be better =
if I just go back to INT 15h?

INT 15h Func C2h is the Mouse interface for PS/2 and subsequent systems.

According to _The Undocumented PC_, the subfunction 07h sets the mouse
handler address (a far pointer). The BIOS interrupt handler will call
the handler whenever a new mouse report is made.

If the INT call fails, carry will be set.

wolfgang kern

2023-11-21 04:16:16 UTC