R5: Joystick misbehavior witnessed in several Intro Disk games

[dansanderson]

Test Environment (required)

• Platform: MEGA65 R5 board
• Core Commit: release-0.96,20240119.17,99aeac5
• ROM Release: 920391

Compared with MEGA65 R3A board, release-0.96,20240115.22,68aabb0, ROM 920391 using the same SD card.

Describe the bug Several Intro Disk games are exhibiting joystick controller misbehavior, appearing as a "stuck" direction or fire button. Not all games are affected, and each game seems to be affected differently.

• Intro Disk 1: Blaster (port 2): Ship moves up to middle of the screen out of player control. Player can move left and right and fire, but cannot move down (as if "up" is stuck).
• Intro Disk 1: Pushem (port 2): Player can grab a piece with the cursor, but can't let go of the piece (as if "fire" is stuck).
• Intro DIsk 2: Battle Sparrow: Can start in one direction, but then ship no longer responds to movement or fire.
• Intro Disk 2: The Wall: Can change the direction once per play, but then wall can't change direction.
• Intro Disk 2: Zeha Goes Skiing: Can ski, but after crashing, can't press fire to restart game.

This does not appear to be related to Amiga mouse emulation settings. I tried both Amiga mouse mode and normal mouse mode, with no change.

I went back to the R3 board with the same SD card and the games behave correctly. I'm not using the exact same core build with the R3 board; I can try that next. They're very close though.

[gardners]

$DC00 correctly responds to joystick inputs from BASIC. Also from the title-screen of BLASTER it behaves properly. But once BLASTER is running, indeed $DC00 shows $FE instead of $FF (tested on R5 board) I'm suspecting the new bi-directional joystick port circuitry control

[dansanderson]

I found a couple of additional failing cases on Intro Disk 3: Basic65 JnR Basecode, MEGABLOCKER, and Sub Sea.

Interestingly, Sub Sea got stuck then bailed with an error, so I could inspect the BASIC program and see what it was seeing. JOY(2) returned 155, which is outside the range of promised values for JOY(). Normally JOY returns 128 for fire + a normalized cardinal direction between 0 and 8. 155 AND 15 = 11. JOY is using a lookup table for the cardinal direction, so it's easy to imagine that an unexpected value at DC00 is accessing memory outside of the lookup table.

It sounds like a core fix is prudent, but if the ROM should be masking any bits here let me know.

[gardners]

For BLASTER, the problem is that BLASTER itself writes $FE to $DC00 at $3746 - $374A. On R3 this didn't cause a problem, but it does explicitly ask for the up line of joy 2 to be held low, i.e., active.

[gardners]

To patch BLASTER while it is running: s3747 ff from the matrix monitor.

[dansanderson]

BASIC's JOY() does write FF to DC00 before reading. It does a bit of debouncing, so maybe that isn't working well with the bidi stuff, I dunno. https://github.com/MEGA65/mega65-rom/blob/073435d9855506bb3d3e2151026799b76722bb32/b65.src#L10792

[gardners]

Similar issue for PUSHEM, which writes $EF to $DC00 and $DC01. Patching it during run can be done with: s4362 ff So again, this is a real bug in the program, that was not causing problems on R3 and earlier boards.

[gardners]

Confirming the problem is not with the ROM, but with prior software not handling the joystick ports correctly.

[dansanderson]

I'll feel better about that explanation once we figure out whether the BASIC examples that are failing are doing something more unusual than just calling JOY(). If JOY() is returning unexpected values, then there's probably more the ROM needs to be doing.

[gardners]

A simple program like this works fine: 10 PRINT JOY(2): GOTO 10

I'm going through the source code of battle sparrow to understand how it goes wrong.

[gardners]

I'm suspecting the ROM does mess up the joystick lines sometimes. This line in pot routine of basic65.src is almost certainly bad: Should instead just write $FF.

stx CIA1_PRA ;restore keybd lines

Also in rmouse routine:

stz CIA1_PRA    ;restore port for Kernel

Also in system.src, in ScanStopKey

sta colm        ;watch out... .a=$7f...same as colms was...

[gardners]

Making patched ROMs with fixes for the above suspicious routines:

sta colm does not affect behaviour of battle sparrow

[gardners]

Hmm... also found that joy routine has a similar problem. Trying to fix that next.

BATTLE SPARROW can indeed be fixed by patching the joy routine.

[gardners]

This fix also works for THE WALL and ZEHA GOES SKIING

[gardners]

The MEGA65 ROM can be patched to deal with this bug for those 3 BASIC programs, but the ASM programs will either need to be patched separately, or we make bi-directional joystick port a protected feature, possibly under hardware errata register control, so that we don't have any backwards compatibility issues.

This is likely sensible, given that the need for bidirectional joystick ports is expected to be relatively rare.

[gardners]

See https://github.com/MEGA65/mega65-rom/issues/62 for proposed fix for BASIC65 programs.

[dansanderson]

ROM fix is implemented and released.

ML programs that mis-handle port directionality will stay broken in v0.96. Nothing left to do for this issue.

[dansanderson]

Closing.