Observation of odd behaviour of paddles

[gurcei]

While working on sea wolf, I've been trying two paddle pairs in both control ports 1 and 2 (giving 4 paddles).

The game behaves fine on the c64-core with these 4 paddles, and also on a real c64.

However, on the mega65-core (I'm on cia_oneshot,20240820.05,4f64494, which was branched from development branch from commit#0b5312c0a8).

• On some (rare?) power ons, feel like there's a mixup in which button in the paddle pair is for which paddle. E.g. paddleA can't fire, but paddleB seems to fire on behalf of paddleA.
• For most other power-ons, the fire button mixup isn't a problem
• But on every power-up, I see:
  • 1st pair on control port 1: paddleA works fine, but paddleB's movement is a bit haphazardous. Sometimes it listens to the paddle movements, sometimes it doesn't, or only goes halfway across the screen even though the paddle is fully steered one direction
  • 2nd pair on control port 2: both paddleA and paddleB work fine here

[gurcei]

Ok, seem to have gotten a work-around for the glitchy paddle B on control port1 playing sea-wolf with MEGA65 core.

Going to m65 config, if I turn off the "1351 de-jitter" settings here, the problem goes away:

Ok, nice, I'm happy to let this be a temporary workaround for now and save me any further digging... 😄

A more ideal solution would be to dive deeper into the logic within "mouse_input.vhdl" and understand why this hysteresis/de-jitter stuff is screwing up this paddle...

...but I'm out of steam 😄

[gurcei]

Another observation on this point:

On some (rare?) power ons, feel like there's a mixup in which button in the paddle pair is for which paddle. E.g. paddleA can't fire, but paddleB seems to fire on behalf of paddleA.

The mixup I observed today was interesting and differed from the explanation above:

• While playing original sea wolf on the MEGA65, the fire buttons for the paddle-pair on port1 seem to have been mixed up with the fire buttons of the paddle-pair on port2
• I then noticed that if I played my 4-player paddle version of sea-wolf, the problem seemed to go away...

Strange... On a real C64, both versions work normally. Feel like something might be amiss on powerup in relation to the paddles (maybe my 4-player version toggles between paddle settings so frequently, it cleans up the problem in some way I haven't fathomed yet).

[ki-bo]

I think if you change the DDR or port pins of a CIA it takes some time until those changes take effect. Can it be that in 40MHz mode the CPU is just much faster and configuration is too close to reading the data pins? Can you try adding some delay between those?

All this is assuming that you do change the DDR/port configuration of the CIA, though. If that is not the case, then this is probably some other issue.

[lydon42]

The problem with the paddle on port 1 is most likely fixed by #828

Will you debug the fire button issue further?

[gurcei]

Okidoke, will test the paddle port 1 misbehaviour matter today.

As for the fire button issue, not sure when I can look into it, but I hope to at some stage.

[gurcei]

Ok, I've given build development#125 for the https://github.com/MEGA65/mega65-core/issues/828 fix a try now.

I've turned de-jitter settings back on in config, and yes, it has repaired my issue on port 1 - paddle B, it now moves smoothly with the de-jitter config setting turned on, thanks :)

So yep, the only remaining part of this ticket is that fire button issue, will try assess that next

[gurcei]

Ah ok, in the original sea wolf, I've noticed that if I tweak this line, I can make paddle movement work properly:

read_paddle_fire_button:

[$E783] TAX ; a = 0 always, so x = 0 [$E784] LDA #$FF #$7F [$E786] STA $DC00 ; Data Port A

So according to the C64 ref manual (and I'll attach a screenshot of a related slide from sea wolf disassembly video):

• When DC00.7 = 0 and DC00.6 = 1, then we've connected port1 paddles to the ADCs
• When DC00.7 = 1 and DC00.6 = 0, then we've connected port2 paddles to the ADCs
• When DC00.7 = 1 and DC00.6 = 1, this behaviour hasn't been defined...

Aah, but while playing sea wolf on a real C64 (with original game, without my tweak above), I noticed the following:

• The game plays fine with paddles plugged into port 1
• If I plug in paddles into port 2, I can move the submarines, but I can't fire any missiles

So this is giving me the impression that when DC00.7 = 1 and DC00.6 = 1, then both port1 and port2 paddles have been connected to the ADCs at the same time :D

So to me, this seems to be an oversight (mild bug) in the original game. Hmm, whether we want to replicate such an odd use-case for DC00.7 and DC00.6 in the MEGA65, I'm unsure.

Part of me feels like folks that want to preserve such quirks can rely on the C64 core. Then again, if this matter impacts many paddle games (I don't think there are many), then perhaps that might provide some incentive to add logic like this into our mega65 core too.

Perhaps other paddle games worth checking in relation to this might be other early release titles from HAL Laboratory like "Le Mans" and "Pinball Spectacular"... I'll see if they suffer similar problems...

[gurcei]

Had a quick play of Pinball Spectacular on my c64:

• Doesn't have this problem. It only works with paddles on port1. I tried switching to paddles on port2 midway in a game, it ignored any paddle input from port2.

I tried "Le Mans" next on my c64:

• Doesn't have this problem. It only works with paddles on port1. I tried switching to paddles on port2 midway in a game, it ignored any paddle input from port2.

Ok, so this problem seems to be unique to sea wolf only...

I also tried both games on the MEGA65 core, they ran fine with paddles in port 1...

So on the whole, don't feel like we should change the MEGA65 core to suit this game.

At the very least, the failure cause is documented here. If we later discover many other paddle games are affected, we can revisit this. If not, leave things as they are.

[gurcei]

Closing this as "Won't fix".