Closed dansanderson closed 3 months ago
does this happen at the hardware level, i.e., can it be reproduced using assembly language, instead of BASIC commands?
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
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
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
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.
No need: The problem is that it uses the generated pot value, rather than reading the pot pin directly.
Above commit is likely to fix the problem
Just tested 3fc5d40 on R3a, but still I see the button state react on vertical mouse movement (Amiga mouse, conservative mode)
Can we tag this for v0.96? (I don't have admin access to this repo.)
Can we tag this for v0.96? (I don't have admin access to this repo.)
done
@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.
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.
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.
The processed fa_out from mouse_input was not being used. Above commit attempts to remedy this.
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.
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.
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.
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.
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.
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
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).
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?
5.5 ohms.
Also check #742 and #754 against this branch!
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.
Is this fixed? It was merged into release-0.96. but the issue is still open...
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.
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 1either 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."
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: