v0.96: Amiga mouse toggles right mouse button signal on mouse move

[dansanderson]

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: MEGA65
• Core Commit: development core near 20231014
• ROM Release: 920377 / 920390

Describe the bug
The BASIC command RMOUSE reports right mouse button presses during mouse movement when an Amiga mouse is connected to port 1 either port, and the port is correctly configured in Amiga mouse mode.

This can only be reproduced with the latest dev core and not release v0.95. It appears to be a regression since the last stable core release. It can be reproduced in both v0.95 stable ROM 920377 and latest ROM beta 920390, so it is specific to the core.

To Reproduce
Amiga mouse in port 1, Configuration set to Amiga mouse for port 1, "aggressive."

10 MOUSE ON,1
20 RMOUSE MX,MY,MB
30 PRINT MX,MY,MB
40 GOTO 20

Move the mouse, click the buttons.

Expected: third column stays 0 during mouse movement, adds 128 for left button and 1 for right button.

Actual: third column flickers 1 during mouse movement. Adds 128 for left button (correct) but does not notice right button (incorrect).

Can repro in port 2 also: make sure config for port 2 is set correctly, then change line 10 to MOUSE ON,2.

Additional context
Originally reported as ROM bug, but does not appear to be a ROM issue: MEGA65/mega65-rom-public#90

As noted by @johnwayner:

A key difference between the wiring of an Amiga mouse vs a 1351 is that the vertical pulse is connected to the same pin that a 1351's right mouse button is connected to. So it's not surprising that the right mouse button would appear to change when moving vertically.

[gardners]

does this happen at the hardware level, i.e., can it be reproduced using assembly language, instead of BASIC commands?

[dansanderson]

I concluded this was hardware based on the ROM code for RMOUSE, which is reading the buttons straight off of $DC00. My CIA-foo is weak but I believe it's storing $FF to $DC00, then reading $DC00 bit 0 (inverted) for right mouse button in port 1.

https://github.com/MEGA65/mega65-rom/blob/073435d9855506bb3d3e2151026799b76722bb32/b65.src#L17648

[gardners]

It would be great if we can write a minimal assembly test for this, so that I can work against that. I'm also curious how long the transient is

[dansanderson]

This does the trick:

!cpu m65
!to "rmouse.prg", cbm

bsout = $ffd2
CIA1_PRA   = $DC00

* = $2001

!8 $12,$20,$0a,$00,$fe,$02,$20,$30,$3a,$9e,$20
!pet "$2014"
!8 $00,$00,$00

    lda #147
    jsr bsout

loop:
    sei
    ldz CIA1_PRA    ;Set up port & read buttons
    lda #$ff        ;save kybd output lines (IRQ already disabled)
    sta CIA1_PRA    ;set to not read any kybd inputs
    lda CIA1_PRA+1
    and #%00010001  ;want left, right buttons only
    eor #%00010001  ;(invert, since low means button down)
    stz CIA1_PRA
    cli

    jsr write_hex
    lda #13
    jsr bsout
    jmp loop

write_hex:
    ; Writes A as two hex digits and a space
    ; Restores A
    pha
    lsr
    lsr
    lsr
    lsr
    and #15
    cmp #10
    bcc +
    adc #6
+   adc #'0'
    jsr bsout

    pla
    pha
    and #15
    cmp #10
    bcc +
    adc #6
+   adc #'0'
    jsr bsout

    lda #' '
    jsr bsout

    pla
    rts

rmouse.prg.zip

[gardners]

Is someone able to test bitstreams to determine at which commit it began happening? That would help to narrow it down.

Meanwhile, I am trying to look at mouse_input.vhdl to understand the root-cause.

[gardners]

No need: The problem is that it uses the generated pot value, rather than reading the pot pin directly.

[gardners]

Above commit is likely to fix the problem

[ki-bo]

Just tested 3fc5d40 on R3a, but still I see the button state react on vertical mouse movement (Amiga mouse, conservative mode)

[dansanderson]

Can we tag this for v0.96? (I don't have admin access to this repo.)

[ki-bo]

Can we tag this for v0.96? (I don't have admin access to this repo.)

done

[johnwayner]

@gardners Perhaps I'm just missing something, but I don't see where fa_up_out (and friends) are actually mapped to anything outside of mouse_input. pota_x (and friends) are used in iomapper, for example.

[dansanderson]

This erroneous effect is no longer limited to port 1 now that the v0.96 core has repaired paddle/mouse movement on port 2. I can reproduce the right mouse button flicker on vertical movement in both ports. Hopefully that clarifies the issue.

[gardners]

Confirmed that I can reproduce the problem using MouSTer set to Amiga mouse mode:
left button works as expected, but right button doesn't work, and instead responds to (I think) vertical motion of the Amiga-mode mouse.

[gardners]

The processed fa_out from mouse_input was not being used. Above commit attempts to remedy this.

[gardners]

That commit has changed the behaviour of the right button detect, but not fixed it: It no longer changes with movement, but it also doesn't report the state of the right button.

[gardners]

That commit stops the joy direction lines showing the raw Amiga mouse stuff on UP, DOWN, LEFT and RIGHT. But the 2nd mouse button is permanently stuck low, i.e., bit 0 for UP is 0, instead of floating at 1.

This means the problem is with reading the fx_potx line in mouse_input.

[gardners]

So, the Amiga mouse doesn't have a pull-up on the right-button line. This means that it will read as always active on a C64, and a MEGA65 as well, since both implement the POT inputs without a pull-up. Apparently a work-around is to add a pull-up to the mouse.

See:

https://www.mssiah-forum.com/viewtopic.php?pid=13749

In terms of how we fix this in the MEGA65, there is no immediately clear solution. This also explains why the right button always appears to be active on the Amiga mouse when plugged into a MEGA65.

[gardners]

Work-around for now is to check for POT AX going low and high at some point. Only after we have seen both values on the POT AX line, do we make fa_up try to follow amiga right button on POT AX.

[dansanderson]

I got ahold of a friend's Amiga mouse, the later Escom Amiga 1900. Works on original Amiga hardware, tested on an A3000.

On both cartflash-683 build #64 (without newer fixes) and latest 751-amiga-mouse-right-button-glitching: no X/Y movement, right mouse signal flickers on Y movement, clicking the right mouse button registers as X movement.

New discovery: mouSTer X/Y works on port 1 but not on port 2. On port 2, mouSTer is same as Amiga 1900 mouse on both ports.

I'll dig out a vintage tank mouse to compare.

[gardners]

Meanwhile, I filed an issue on the MouSTer repo asking for optional pull-up on Amiga right and middle buttons, that would allow C64s and MEGA65s to read those buttons without requiring a special cable with pullup in it. willyvmm/mouSTer#38

[dansanderson]

Results of testing the #751 fix build 11, R5 board, core slot 1:

• 1351, ports in 1351 mode: fully functional; both ports
• Vintage Amiga mouse, ports in Amiga mode (aggressive): x/y works, both left and right buttons broken (no signal; RMOUSE reports 0); both ports
• mouSTer in Amiga mode, ports in Amiga mode (aggressive): x/y works, left button works (RMOUSE reports 128), right button broken (RMOUSE reports 0); both ports

Right button flicker fixed, no interference between x/y and buttons.

It sounds like vintage Amiga mouse left button not working is unexpected. I confirmed that the Amiga mouse's buttons are working with a continuity tester across pins 6 and 8 (left button) and 9 and 8 (right button).

[gardners]

Thanks. The vintage Amiga mouse left button is a mystery, as connecting pins 6 and 8 should indeed cause it to trigger. What resistance do you see between pins 6 and 8 with left button pressed?

[dansanderson]

5.5 ohms.

[lydon42]

Also check #742 and #754 against this branch!

[gurcei]

I'm a little late to this party, trying to catch up with the thread above. Ok getting the sense this missing pull-up resister is a factor

Last night tried testing build #14, not sure if gardners wanted this one to be tested or he was still midway with changes. Anyway, will report back my results with it on my amiga-mode mouster. It was still behaving the same:

• left mouse button works fine
• right mouse button not working

I'm getting curious about this "adding a pull up resistor" approach. Wondering if I could solder up such a pull-up between two db9's (one female the other male) to be a "repair" dongle of sorts.

[lydon42]

Is this fixed? It was merged into release-0.96. but the issue is still open...

[dansanderson]

The original right button flicker on mouse movement issue has been fixed and is in v0.96. Maybe we can open a new issue for the right mouse button not working, if that's also something we can fix. Resolving.