Mouse does not work well in Monitor v11

[pablomarx]

When running a Monitor v11 application, such as SMALLTALK.OBJ, or EDITOR.OBJ, the mouse does not appear to work. The white dot lisaem cursor will move, but the native cursor rarely changes position. The times I have seen it move tend to be when I'm using the keyboard (e.g. cmd-tab to switch out of lisaem), at which point it tends to move in ~100px increments before disappearing.

SmalltalkCursor.mov

The following is from a lisaem Trace Log and may shed some light as to the problem:

src/lisa/motherboard/glue.c:check_running_lisa_os:316:Lisa ROM v1:00fe06ec v2:00fe06ec
src/lisa/motherboard/glue.c:check_running_lisa_os:406:Unknown OS Running: v1=000e7582 v2=000e758a; test1,2,3: 00000000, 00000000, 00000000
src/lisa/motherboard/glue.c:check_running_lisa_os:406:Unknown OS Running: v1=000e2980 v2=000e2ad2; test1,2,3: 00000000, 00000000, 00000000
src/lisa/motherboard/glue.c:check_running_lisa_os:406:Unknown OS Running: v1=000da930 v2=000e2ad2; test1,2,3: 00000000, 00000000, 00000000
src/lisa/motherboard/glue.c:check_running_lisa_os:406:Unknown OS Running: v1=000e2980 v2=000e2ad2; test1,2,3: 00000000, 00000000, 00000000
src/lisa/motherboard/glue.c:check_running_lisa_os:406:Unknown OS Running: v1=000e2980 v2=000e2ad2; test1,2,3: 000e7524, 000e75ba, 000e75ca

Snooping to see where v1 and v2 get plucked from:

lisaem/src/lisa/motherboard/glue.c

Lines 338 to 339 in 61d55b3

	v1 = lisa_ram_safe_getlong((uint8)1, (uint32)0x0064);
	v2 = lisa_ram_safe_getlong((uint8)1, (uint32)0x0068);

So lisaem appears to try and fingerprint the OS via entries in the exception vectors, specifically the external 1 and 2 interrupts? And one of these is from the COPS?

Some further snooping around the string mouse would seem to confirm this with the external autovector line appearing a few lines above mouse:

reg68k.c:reg68k_external_autovector:2011:Autovector:1 reg68k_pc:000e2ad2 reg68k_sr:00002200 regs.pc:000e2ad2 regs.sr:00002200, exiting setjmp land| 20:02:19.3 134115265

Looking further in the trace for the instructions executed from this address:

1/000e2ad2 (0 0/0/0) : 2f00                       : ..       :  322 : MOVE.L     D0,-(A7)  SRC:clk:000000000e7a4514 +12 clks
1/000e2ad4 (0 0/0/0) : 40e7                       : ..       :  634 : MOVEFSR.W  -(A7)  SRC:clk:000000000e7a4520 +14 clks
1/000e2ad6 (0 0/0/0) : 007c 0700                  : ....     :   25 : ORSR.W     #$0700  SRC:clk:000000000e7a452e +20 clks
1/000e2ada (0 0/0/0) : 0839 0001 00fc dd9b        : .9...... :  106 : BTST.B     #$01,$00fcdd9b  SRC:clk:000000000e7a4542 +20 clks

And searching for those hex values returns a single hit in DRIVERS.OBJ. Which is where I would guess these kb/mouse routines would reside. And remarkably / happily, this irq handler appears very similar to Level2 in the Lisa source file LIBHW-DRIVERS.TEXT.unix.txt – which makes the rest of this a breeze...

Following the nest of branches from that IRQ handler, we end up in one that looks quite similar to COPS1 in the Lisa code:

e2b90         move.b     d0, 0x10ee       ; MOVE.B  D0,MousDx           ; save mouse delta-x
e2b94         move.b     #0x2, 0x1013     ; MOVE.B  #2,COPSState        ; new state -- waiting for Dy

And right beneath it, what looks quite similar to COPS2:

e2ba8         move.b     d0, 0x10ef     ; MOVE.B  D0,MousDy           ; save mouse delta-y
e2bac         clr.b      0x1013         ; MOVE.B  #0,COPSState        ; new state -- normal wait

And according to the top of Monitor_11_Listing_Sep82.pdf, these would all be in the range 1000 17ff Data Area for DRIVERS.OBJ

After the presumable MouseDy code, it jumps to a routine that starts moving bits from memory into registers:

movem.l    d1-d5, -(a7)
move.w     0x10ea, d0
move.w     0x10ec, d1
move.b     0x10ee, d2

And the 0x10ec and 0x10ee seem similar enough to the existing Monitor values that this all seems plausibly correct:

lisaem/src/lisa/motherboard/glue.c

Lines 384 to 387 in 61d55b3

	lisa_os_mouse_x_ptr = 0x00000fec;
	lisa_os_mouse_y_ptr = 0x000000fee;
	running_lisa_os = LISA_MONITOR_RUNNING;
	DEBUG_LOG(0, "Lisa Monitor Running: v1=%08x v2=%08x", v1, v2);

Disassembling Monitor 12's DRIVERS.OBJ, all of the routines look the same, just with the low memory addresses changed. The chunk of code above maps to the following in v12:

movem.l    d1-d5, -(a7)
move.w     0xfec, d0  
move.w     0xfee, d1  
move.b     0xff0, d2

As the glue file uses 0xfec and 0xfee for the mouse x/y pointers on Monitor 12, it seems quite probable using 0x10ea and 0x10ec for Monitor 11 would resolve the issue.

[pablomarx]

I believe 839765d resolves this and am closing the issue.