Commodore64C, mouSTer, 1351 in JoyPort2, Cabal Game by Nostalgia

[radius75]

https://csdb.dk/release/?id=161560

The mouSTer mouse behaves erratically in Joyport 2, Commodore64C.

To run 1351 in-game: -mouse in joyport2 -in trainer menu enable 1351 -YES -in game menu press 2. to enable mouse

In other programs/games (Geos, Operation Wolf, Supremacy) mouSTer works fine.

(emulated 1351 works fine in Cabal on Vice emulator and PC mouse, unfortunately I don't have a real 1351 mouse to test on my C64C)

[radius75]

And in joyport 1, mouse movement across the screen works fine, but buttons don't work. The left button does nothing and the right button does quit to the game menu.

But it's exactly the same when testing joyport 1 on Vice emulator and PC mouse in the Cabal game.

It may not matter.

[Jumpman64]

@radius75 i tested Cabal on my U64 and the mouse worked fine on both ports. mouSTer latest firmware 3.16.2600 The crosshair movement acts like a "joystick mouse", same with a real 1351, but it works.

edit:

The left button does nothing and the right button does quit to the game menu. buttons on port 1 act the same with a 1351 too.

[radius75]

https://www.lemon64.com/forum/viewtopic.php?t=66805&highlight=cabal

Same problem, forum lemon64. I have soft 3.16.2600. Maybe the problem could only be with the real C64 with the original parts. And other adapters, not only mouSTer.

Edit quote from the forum: ` Finally, game can be started with pressing "4" or mouse left button. If mouse adapter is properly adjusted for PORT2, there won't be any issues at all. Below is quoted from configuration of Micromys v4 :

"C64 or C128 in joystick port 2: This is a rather unusual port for a proportional mouse. However, the popular music programs MSSIAH and Prophet64 use the mouse in that port, so it must be covered. If the user wants to use joystick port 2, then Micromys must be attached to port 2 after power-up and after the program has been started. ..."`

[Jumpman64]

Tested it on my real C64C now. The 1351 acts unstable too, not as trembling as it is with mouSTer, but bad enough to quit playing. I would say this issue can be handed over to Nostalgia. :)

edit: if you unplug the 1351 and plug in the mouster the graphic gets totally corrupted but the game continues and the crosshair moves soft and nicely.

[radius75]

inserting a mouSTer on a powered C64always causes a crash or reboot :/

[Jumpman64]

Oh, I haven't noticed that before (on the U64). Tried to replug a second time on the C64, grfx ok, mouster movement for a short period ok too till it get's jumping and trembling again here and there. It's a mess. Let's play something else. ; )

[radius75]

I keep playing in Vice emulator, PC mouse as 1351 in joyport2 works fine :)

[willyvmm]

I'll try to test that issue on the weekend. Likely seems like a Broken SID.

HOT-Plugging anything to C64 is the best way to get it broken. Don't do that for your C64.

[radius75]

I hope my SID is undamaged :/ Joysticks works, mouse works, double paddles works, audio sounds ok.

[Jumpman64]

Hot-plugging a regular joystick shouldn't be a big thing normally, we did that a thousand times back then and the C64 and SID is still alive. We are aware of not to use MegaDrive pads and not to short circuit the 5 volt line. If you say not to hot-plug the mouSTer we won't do that anymore. Crashing the graphics and resetting the C64 when plugging it in is a bad sign indeed.

SID is (still) fine over here too, otherwise all the other mouse stuff wouldn't work either.

[radius75]

@Jumpman64 I was doing an experiment. By connecting the mouster at a certain angle. For pin 8 GND to contact earlier than pin 7 +5V (‽) Several attempts at port 1 and port 2. Then there is no crash. But I do not recommend checking this out to other users

[Jumpman64]

@radius75 Thanks, cool investigation! I also thought about what the difference was in the two attempts and assumed something like that. But the crashed graphics and reset gimme the creeps. Won't try that again on the real C64 anymore.

[radius75]

I was given the opportunity to perform a full (the test harness) diagnostic test. There are no errors.

[willyvmm]

Please try the latest firmware: https://github.com/willyvmm/mouSTer/releases/tag/3.17.3377

[radius75]

Checked 3.17.3377 Still the same erratic behavior of the pointer in the game "Cabal". Default config and: [mouster] mode=mouse [mouse] type=c1351

I'll show you what it looks like. Link to download .mp4 Video: https://mega.nz/file/qYJ2QR5Q#4SidKl7KpfzhQo3knOpMWv_IDiNATlnAjluZcPpyrVQ

[radius75]

3.17.3377 introduced a similar pointer bug, now on Joyport1 (tested Supremacy game from Excess and Geos). After reverting to 3.16.2600 the mouse on Joyport1 is OK. .. (Cabal uses mouse in Joyport2)

[willyvmm]

This game does not support SD2IEC ... so I'm unable to check anything. BUT. I have an idea of what could be the issue. (it's just a guess) Please try this Firmware. https://we.tl/t-OWCWFTjwRB It is already configured for C1351, so flash and try, you don't need to touch the config.

[radius75]

I will check it soon. Maybe if you have sd2iec it will be possible to load the freeze version. I prepared it on the emulator with an ActionReplay cartridge. Image of a d64 floppy disk. The first file when run loads the next one. Otherwise it won't work, try it. cabal freeze on menu.zip

[radius75]

I tested the FW from the link. I don't see any improvement.

[radius75]

It occurred to me that this strange behavior could be caused by some interference generated by the Mouster that affects the joyports in the C64. Hmm.. Might be worth trying to reduce the clock speed of the CPU in the Mouster to the necessary minimum. If I find a DB9 M/F cable, I'll try to put ferrite cores on it.

[willyvmm]

Hi @radius75 The image is working.

I made some improvements in the code. But the issue still exists. and now is more like As I'm not a C64 GURU, you may disagree with me. But in my opinion mouse code for a mouse in port2 is simply broken.

When I connected mouse to port1, everything moves smoothly, (but fire does not work, rmb exits the game, guess its because of port2 game config)

I have used https://csdb.dk/release/?id=198968 to test functionality, and it works very stably in both ports. No shaking is observed.

Regarding the CPU clock, it's not the case. You may try, but it will not change anything. The CPU clock is already clocked at minimum freq allowing proper USB handling.

Some more details: I can see 2 major issues here.

1. Too high sensitivity - This has been resolved/improved in the new firmware. (attached), may be also adjusted in config by changing the (microstep=02) value.
2. Broken code. Not to be fixed by me.

For me, it looks like interference with the keyboard or/and mux, and i can see that on the oscilloscope...

I made a quick google research found this: https://www.reddit.com/r/c64/comments/kc7yyh/comment/gfplgpy/?utm_source=share&utm_medium=web2x&context=3

That could explain the problem.

The improved firmware is here: https://we.tl/t-NqNx1OknEs

[radius75]

Thanks, I will test and report back.

The author of the Mouse Driver for Cabal indicated on the Lemon64 forum that he chose Joyport2. The fact that the mouse in Joyport1 is also read may not matter. The PotX and PotY registers are common to both ports, I'm guessing that modding this game was technically limited, and it didn't manage to disable mouse reading nicely in Jp1. In order not to interfere with other functions of the game, related to reading keys, etc. In the same thread, a problem with several mouse adapters was reported. My guess is that the author used a real 1351 and therefore had no such problems. https://www.lemon64.com/forum/viewtopic.php?t=66805

I've looked at a lot of threads about mouse adapters and I suspect that correct 1351 emulation cannot be 100% guaranteed. It's a mouse designed specifically for the SID chip and I don't think this design was used for anything else. There is no one universal Driver for 1351. The "sampling" of values read from Pots may depend individually on the program/game.

I found interesting material about 1351. A lot of information about its operation with SID, there is also an oscilloscope video showing how the voltage plot on Pots runs over time. This is the blog of the author of the mouse adapter software. http://sensi.org/~svo/%5Bm%5Douse/

Maybe for Cabal only Vice emulator with 1351 mouse emulation. I played this game on emulator and mouse in Joyport2 works fine. In the emulator, the mouse in Jp1 behaves the same as you described.

[radius75]

I tested on several programs.

Geos 2.0 Joy1 - NOK EoTB Joy2 - OK Supremacy Joy1 - NOK Cabal Joy2 - NOK Operation Wolf Joy2 - OK

I'm posting a link to Video with Geos2.0 and Supremacy. https://mega.nz/file/2NhCXBKb#BWyT0rjORr5hJkTwzoTjTm5GPfjECptErjPjJs1O3I0 https://mega.nz/file/iB4EWCgT#ab2nbYsGtf7xMHYvQ42-SfO7RXnY2f56grbBZ7Wx6_g

I upload freezed Geos2.0 for testing. Mouse movements can be tested ;) geos20.zip

Supremacy is only a cartridge version. It cannot be freezed with the ActionReplay cartridge.

[Jumpman64]

Tested Cabal with fw 3.17.3377 again today on U64 + FPGASID (paddle override disabled), wireless mouse 1000dpi in port 2 type=c1351 microstep=8

The crosshair is moving fine, no jumping or twitching. Though the movement acts different compared to normal pointer movement but that's an issue of the game. The crosshair moves faster on the x-axis and slower on the y-axis so it still feels a bit like "8 way joystick mouse" control. Left button fires gun, right button grenade. My verdict: Cabal plays ok on my U64 hardware setup with the actual MouSTer version.

[willyvmm]

As the c1351 engine has been rebuilt once again (merged the new engine with the old 2600 build) please test the latest release: https://github.com/willyvmm/mouSTer/releases/tag/3.17.3455

[radius75]

Mysz zaczęła działać poprawnie we wszystkich grach i programach wymienionych w tym wątku, tak jak wcześniej w FW 3.16.2600. Działają przycisk MB i pokrętło Roll. Problem z grą Cabal niestety nadal występuje. :\ Nie mam prawdziwej myszy 1351 żeby mieć porównanie. Możliwe że to problem źle zaimplementowanego sterownika w grze, przerwań IRQ, jakiś sztuczek programowych itp. i jest technicznie tu nie do obejścia. Jest jedna rzecz która zastanawia. Podczas grania w Cabal gdy odepniemy mysz przewodową lub transmiter BT, (pozostawimy podpiętego Moustera), wskaźnik myszy też sporadycznie skacze po ekranie. Problem nie występuje na emulatorze Vice, i podobnież na Ultimate64 (emulacja na FPGA).

-- The mouse started working properly in all the games and programs mentioned in this thread as it did before in FW 3.16.2600. The MB button and Roll knob work. The problem with the game Cabal unfortunately still persists. :\ I don't have a real 1351 mouse to compare. It's possible that it's a problem of a poorly implemented driver in the game, IRQ interrupts, some software tricks etc. and is technically unavoidable here. There is one thing that is puzzling. When playing Cabal, when we unplug the wired mouse or BT transmitter (leave the Mouster plugged in), the mouse pointer also occasionally jumps on the screen. The problem does not occur on the Vice emulator, and neither does the Ultimate64 (FPGA emulation).

[willyvmm]

So ...

Tested it on my real C64C now. The C1351 acts unstable too, not as trembling as it is with mouSTer, but bad enough to quit playing. I would say this issue can be handed over to Nostalgia. :)

So, the emulator either FPGA clone does not emulate the physical cap charging process 100% correctly. In the real Hardware, it is chopped by the keyboard interrupt. That behaviour causes trouble to get the emulation to work 100% as in real hardware and has been simplified. Nothing wrong here. Just better implementation. But the Real hardware has this issue and needs to be handled in the driver software. Fx. Joyride implementation seems to be correct, but for sure takes a lot more precious CPU cycles.

I did a dummy test on real Hw. Just connected a potentiometer - exactly as in a paddle controller which C1351 emulates. And ... the pointer jumps and slowly migrates...

It is basically unavoidable in this game due to a poorly implemented driver - or maybe more adequate - The driver was implemented on the Emulator and does not handle the real C1351 issues.

A final word: I did my best to emulate the C1351 as best as possible. My whole work is based on the patent papers and my own investigation where I even haven't seen a real C1351 :) So, maybe it may be done better, but I do need a REAL C1351 to improve the emulation beyond this point.

Best Willy.