MEGA65 / mega65-core

MEGA65 FPGA core
Other
238 stars 84 forks source link

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

Open dansanderson opened 7 months ago

dansanderson commented 7 months ago

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

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: https://github.com/MEGA65/mega65-rom-public/issues/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 commented 5 months ago

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

dansanderson commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

gardners commented 5 months ago

Above commit is likely to fix the problem

ki-bo commented 5 months ago

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

dansanderson commented 5 months ago

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

ki-bo commented 5 months ago

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

done

johnwayner commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

gardners commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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. https://github.com/willyvmm/mouSTer/issues/38

dansanderson commented 5 months ago

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

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 commented 5 months ago

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 commented 5 months ago

5.5 ohms.

lydon42 commented 5 months ago

Also check #742 and #754 against this branch!

gurcei commented 5 months ago

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:

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.