|
|
Post by spannernick on Sept 7, 2020 13:12:09 GMT
I will not add anything to PCU until your happy with it first..  This will be all going into c64emu-joyswap2.rgl with joystick swap, cause your will need them all in one C64 emulator file. I was thinking about a shortcut for the 8580 SID Chip and that could be CTRL+C but you would need to make the emulator reset itself so it can use the 8580 case it could be still be using 6581. |
|
|
|
Post by blackbird on Sept 7, 2020 17:25:51 GMT
Hi Gurce
I have question about your changes in "keybord.c". In youre helper methods like is_f() you check the three params row, column and value. How can you be sure that you're check CTRL+F because you always check value for is not zero. The param value is the shift flags which is used as a bit mask. Every bit has it's special function.
# File format:
# - comment lines start with '#'
# - keyword lines start with '!keyword'
# - normal line has 'keysym/scancode row column shiftflag'
#
# Keywords and their lines are:
# '!CLEAR' clear whole table
# '!INCLUDE filename' read file as mapping file
# '!LSHIFT row col' left shift keyboard row/column
# '!RSHIFT row col' right shift keyboard row/column
# '!VSHIFT shiftkey' virtual shift key (RSHIFT or LSHIFT)
# '!UNDEF keysym' remove keysym from table
#
# Shiftflag can have the values:
# 0: the key is never shifted;
# 1: the key is shifted;
# 2: the key is the left shift;
# 4: the key is the right shift;
# 8: the key can be (optionally) shifted by the user.
# 16: deshift key for this keysym/scancode
# 32: another definition for this keysym/scancode follows
# 64: key is shift-lock on emulated machine
# 128: shift modifier required on host
# 256: key is used for an alternative keyboard mapping
# 512: alt-r (alt-gr) modifier required on host
# 1024: ctrl modifier required on host
# 2048: key is combined with cbm for this keysym/scancode
# 4096: key is combined with ctrl for this keysym/scancode
# 8192: key is (left) cbm on emulated machine
# 16384: key is (left) ctrl on emulated machine
#
# Negative row values:
# 'keysym -1 n' joystick #1, direction n
# 'keysym -2 n' joystick #2, direction n
# 'keysym -3 0' first RESTORE key
# 'keysym -3 1' second RESTORE key
# 'keysym -4 0' 40/80 column key
# 'keysym -4 1' CAPS (ASCII/DIN) key
BTW: you are doing cool stuff here :-)
|
|
|
|
Post by gurce on Sept 8, 2020 14:37:21 GMT
@spannernick - Yep, happy for you to stick with the same name for the .rgl file. Perhaps one day when it's bulked up with even more shortcuts, we could just call it 'c64emu-pcu.rgl', but yeah, for now, the joyswap functionality is probably the thing of major interest Ok, I'll give the sid-swap shortcut idea some more thought in my next attempt.
blackbird - Yep, I think you're probably right and that I'm ignoring those extra bit-field flags. Everything I've attempted has been very rushed, quick and dirty. For now, I'm guessing we can get away with it, since we don't have too many shortcut keys. But perhaps in future, if things get very overloaded and we start needing 3-key combinations like ctrl+shift+something, maybe then I (or somebody else here  ) can repair things. Well, if you're superkeen, you're welcome to repair it Maybe via a fork of our repo and pull-request back into our repo?
Tonight's progress:
These 3 shortcut keys are now working well:
- CTRL-F = press freeze button (for cartridges like action-replay)
- CTRL-R = soft-reset
- CTRL-H = hard-reset
I've also cleaned up formatting problems with the debug-messaging, so it's displaying a little better now too.
Here's a video of the new shortcut keys in action.
The .rgl file for it is here. Latest commits are in the freezebtn branch.
|
|
|
|
Post by gurce on Sept 10, 2020 13:57:22 GMT
Another nibble tonight. I tried adding: CTRL-S = Switch between 6581 RESID and 8580 RESID Here's the latest .rgl file. The commit is in the sidswap branch. I tried to assure that the sid-chip gets hot-swapped without having to reset the emulator. Since Nick mentioned Jar's Revenge as an example case, I gave it a try there, seems to sound better on the 8580. But I'll leave it to his ears to judge if the hot-swap worked. I noticed that Jar's Revenge has some intro text that detect which SID chip is in use, so perhaps it tailors its music-playing accordingly. If that's the case and it detects the 6581 first, then perhaps you could work around it by doing a CTRL-S to switch to 8580, followed by a CTRL-R to do the soft-reset. If you've got the .crt version of Jar's revenge, this'll load up straight away into 8580 then. |
|
|
|
Post by spannernick on Sept 12, 2020 13:24:47 GMT
Dose this c64emu-sidswap.rgl have joystick swap in it..? I love the work your doing BTW... its brill, thanks.. I didn't know you knew C, I look at it and I can't understand some of it, most of it might as well be in Chinese.. lol When you are happy with it being added to PCU rename the rgl file "C64Emu-PCU.rgl" then I know when to add it to PCU, I will test the "c64emu-sidswap.rgl" later today and post back.. |
|
|
|
Post by gurce on Sept 13, 2020 0:30:09 GMT
No probs man, happy to chip in, you've all helped make it increasingly easier for me and others to dabble in this modding stuff :-)
Yep, this sidswap rgl contains the joyswap and freeze+reset stuff too.
Yep, I'm thinking of renaming it to c64emu-pcu.rgl soon, just one thing I'd like to figure out before that is to add some sort of "pcu version" info into our mod. I'm thinking a shortcut key like ctrl-? to show a little help window of all current shortcuts, and also display a pcu-mod version number (will probably use the git hash of the last commit).
Thought this'd be handy in-case some people run into issues with the mod, we can confirm with them which version of pcu mod they are using.
As for C, yeah, been using that for a while. I'm sure you'd get the hang of it over time man, just with incremental exposure :-)
|
|
|
|
Post by spannernick on Sept 13, 2020 16:10:45 GMT
In PCU I have managed to change directories by using the keyboard and shortcut CTRL+F7 to change folders, the idea came from you Gurce.. I got it working on my C64 Keyrah keyboard in THEC64 Maxi PI but need the key names for the TheC64 Maxi keyboard now. Will you be using anything for F7..? You will be able to change the keys in the start.sh file to whatever you like but need to know what the keys are named in evtest but everyone has the same keyboard on the C64 Maxi,that why I am doing it, they properly just called "KEY_CTRL" on the keyrah CTRL is TAB so "KEY_TAB" is my CTRL key, not sure about THEC64 Mini, most users have a c64 Maxi now anyway. and no I posted this in the right place, wanted you to know about first.. I was thinking of the next update of PCU should be called PCUv18 The GURCE Edition..  |
|
|
|
Post by gurce on Sept 13, 2020 16:15:55 GMT
Nice going man! Yep, no probs by me, go for CTRL-F7 :-)
|
|
|
|
Post by spannernick on Sept 13, 2020 16:31:55 GMT
I have 2 gamelist scripts ruining at the same time so you can use the keyboard or the buttons on thec64 Joystick to switch folders.. It CTRL+F7 then.. |
|
|
|
Post by gurce on Sept 13, 2020 16:58:51 GMT
I went off on a wild tangent this weekend when Frida from the facebook group posted a video of some weird SID-playing issues for a game called 'Lightforce'.
- Has the video footage
- More comments and thoughts from ppl, including myself on my experiences trying to update to a newer version of ReSID (the one in VICE 2.4.33), and then trying to disable RGL's audio-scaling logic.
Of my attempts, the best-sounding one, to my ears, was with newer ReSID, audio-scaling turned off and using 8580.
I'm hesitant to include such a mod in PCU, as enforcing such behaviour might make this song sound good, and other songs sound crap
Still, it was an interesting area to explore, so will preserve those efforts in the newerresid branch, and a compiled .rgl to try via PCU. Maybe if other coders/SID-lovers have a passion to explore this area further, they can pick up this branch and press on with investigation, or perhaps explore providing more sid-controls via shortcut keys, to let the user tailor the sid-behaviour to their preference.
I'll probably hang my boots up on this effort for now, it was fun, but exhausting, and feels like a very deep rabbithole that would suck a lot of energy out of me |
|
|
|
Post by gurce on Sept 16, 2020 13:08:06 GMT
Having a nibble tonight on trying to get a help menu displaying. Got a mock-up of it showing on my mac's emulator, triggered by CTRL-/:
The tricky part will be how to listen to the pressing of the run/stop key in order to exit out of the help menu.
It might have to do with me catching the action at these points inside "src/viceport/vpkeyboard.c":
void emu_key_press(signed long key) {
keyboard_key_pressed(key);
}
void emu_key_release(signed long key) {
keyboard_key_released(key);
}
I've run out of time for tonight, but will mull this over some more tomorrow...
|
|
|
|
Post by spannernick on Sept 19, 2020 0:29:17 GMT
Nice one, good idea.. |
|
|
|
Post by gurce on Sept 20, 2020 21:15:56 GMT
This weekend, struggled with how to read in the run/stop key to exit the menu.
First attempt was via vice's trap mechanism, which I saw got used when the sdl menus appear. I tried that, but then I no longer see key presses being reported into keyboard.c - keyboard_key_pressed(), which is where I was hoping to catch the run/stop key.
After looking deeper into the sdl-menus, I realisef that they needed to provide their own seperate keyboard-reading routines for the sdl menus, and they used an sdl library for reading keyboard input.
I'd like to avoid adding extra sdl libraries if I can avoid it, so I looked for alternatives. I though, maybe I could devise my own means of pausing the debugger, by skipping over the cpu emulation inside maincpu.c (the #include "6510core.c" section) whenever I want my help menu appearing.
This stalled the system upon the help menu appearing and no keyboard_key_pressed() calls were being made.
I suspected something inside redquark source (not vice source) was feeding in keypresses into vice, so that made me suspect the vsyncarch_presync() and vsyncarch_postsync() calls were needed, to keep the semaphore signalling between redquark and vice happy.
After adding that, neato, it seemed to work, so I thought I could this task off the list.
But with more usage, I realised that the longer I kept the help menu on the screen, something in the system was building up towards a crash/freeze, perhaps something about it is chewing up more and more memory as it goes along.
As of now, I'm not sure what it is. Taking a look at vsync_do_vsync(), I noticed they've got the presync and postsync steps there, but also a sound_flush in between them. Maybe I need to add that. I'll give that a try on the next attempt...
|
|
|
|
Post by gurce on Sept 21, 2020 13:47:09 GMT
Ah ok, finally had some better luck. I ditched my previous method, and have reverted back to a vice-trap technique. Instead of using sdl to read the keyboard, I learnt of this linuxy way of reading the keyboard scancodes here:
So I used a keyboard-reading mechanism like this within my debug_pause_trap() and was able to read the run/stop key successfully.
Also, the help-menu can stay visible for as long as it likes now, no freezing or crashing occurs now, whew, glad to get that out of the way
@spannernick : I've dropped a copy of the new .rgl file here. It has all the other shortcut-keys within it, so happy for you to add it into pcu.
I haven't renamed it to "c64emu-pcu.rgl", I'll leave that step for you as you add it in, as I just wanted to keep multiple copies of it on my server (with unique names), just so we preserve some history of the older versions, in-case I ever need to drop back to them to investigate anything.
Finally, a nice video to celebrate it finally working
|
|
|
|
Post by gurce on Sept 21, 2020 14:38:09 GMT
Oh, one last low-hanging fruit for the night, I added CTRL-W for warp-mode
Dropped the newer .rgl file for it here (all other shortcuts intact, fine to go into pcu).
Ok, will call it a night
|
|
|
|
Post by kugelblitz on Sept 21, 2020 15:28:43 GMT
Oh, one last low-hanging fruit for the night, I added CTRL-W for warp-mode
Dropped the newer .rgl file for it here (all other shortcuts intact, fine to go into pcu).
Ok, will call it a night
Any way I can sponsor you a free drink for all that? (Paypal?) |
|
|
|
Post by jj0 on Sept 21, 2020 18:43:53 GMT
Oh, one last low-hanging fruit for the night, I added CTRL-W for warp-mode
Dropped the newer .rgl file for it here (all other shortcuts intact, fine to go into pcu).
Ok, will call it a night
Very nice! |
|
|
|
Post by gurce on Sept 21, 2020 21:06:38 GMT
Hehe no probs guys, happy to :-) kugelblitz - Cheers man, I'll take you up on that offer, just to show my wife that all those late nights weren't for nothing! I'll send you a pm :-) |
|
|
|
Post by gurce on Sept 23, 2020 13:45:46 GMT
Ok, my first post will be the TL;DR version:
Was dabbling with the idea of 4-player support over last night and tonight. It's working ok-ish, with a few important caveats:
- If you plug in a joystick into the rear USB port, the help menu freezes again. It seems to prevent my new keycode scanning logic from working, something else seems to consume such events and my routine doesn't get them
 So if you want to try this experimental build, avoid plugging a joystick into the rear port and stick with the side ports or put your joysticks on a usb-hub. - For any 4-player game you want to try, you will need to create a .cjm file for it to assure that joystick 3 and 4 have some default joystick mappings. E.g.:
X:64,pal
J:1*:JU,JD,JL,JR,JF,JF,RS,SP,SP,RS,F1,F7,RS
J:2:JU,JD,JL,JR,JF,JF,RS,CM,SP,F1,F3,F5,RS
J:3:JU,JD,JL,JR,JF,JF,RS,CM,SP,F1,F3,F5,RS
J:4:JU,JD,JL,JR,JF,JF,RS,CM,SP,F1,F3,F5,RS
- If you plug in 4 joysticks, on initial powerup, you only seem to be able to use the first 3 joysticks to control the carousel (and also the keyboard). If you then boot to the PCU carousel, it seems to then register all 4 joysticks on the carousel, but you no longer have the keyboard input working (don't know why as yet). So none of my keyboard shortcuts work, including my CTRL-U shortcut to toggle the userport 'ExtraJoy' setting on/off. So to get around this problem, for this build, I've just turned this userport 'ExtraJoy' setting on by default, as I assume anyone that wants to have a play with this build just wants to try out 4-player games. To get the keyboard to work again, you could unplug one joystick (and then my keyboard shorcuts all come back), but alas, if you re-plug in the joystick, it won't re-register, so you'll be stuck with 3-joysticks and 1-keyboard
I'm hesitant to push this technique into the pcu-branch, as it still feels kinda experimental, and I don't like the idea of leaving that 'ExtraJoy' setting on by default, as I suspect it might adversely affect other programs/games that aren't expecting that user-port joystick adapter being attached.
You can grab the .rgl file from here.
|
|
|
|
Post by gurce on Sept 23, 2020 14:13:18 GMT
...and for those that want the sickening, gory details of all the problems and failures along the way, there's this post
Last night:
- I made a CTRL-U shortcut key to toggle this 'ExtraJoy' setting to get two extra joysticks via the user-port.
- I also set 'ExtraJoyType' to 0 (for the protovision user-port adapter emulation). This probably wasn't necessary, as I suspect it is the default.
- I also added some debug output inside "src/joystick.c" - joystick_set_value_absolute(joyport, value) to let me assess what those passed in parameters are.
- I then fired up IK+Gold (which IK+ modded for 3-player joystick support)
- I then tried moving each joystick, to assess what the debug output would reveal for those arguments
For joyport 1: joyleft value=4, joyright value=8
For joyport 2: joyleft value=4, joyright value=8
For joyport 3: joyleft value=0, joyright value=0
- So it was good to see that joystick_set_value_absolute() was being called for the 3rd joystick, but worrying that the value argument was always zero.
- At that point, I recalled Shaun recently explained in the forums how a .cjm file can be added to map a 3rd/4th joystick. In his example, he mapped the joy positions to keyboard keys. So I thought I'd instead map J3 to genuine joystick positions (JU, JD, JL, JR, etc).
" ikplus3playertest.cjm" X:64,pal
J:1*:JU,JD,JL,JR,JF,JF,RS,SP,SP,RS,F1,F7,RS
J:2:JU,JD,JL,JR,JF,JF,RS,CM,SP,F1,F3,F5,RS
J:3:JU,JD,JL,JR,JF,JF,RS,CM,SP,F1,F3,F5,RS
J:4:JU,JD,JL,JR,JF,JF,RS,CM,SP,F1,F3,F5,RS After adding this .cjm file, I tried again, and hey presto! I can now control the 3rd (blue) player in IK+Gold! Here's a link to a video I made to celebrate the moment, and share/explain the findings: CONCLUSIONS: It is possible to get 2 extra userport-based joysticks working with thec64 by: - setting the 'ExtraJoy' setting to 1 (as via my CTRL-U) shortcut key
- and by adding a .cjm fie to provide proper joystick mappings for J3 and J4
On that 1st point (ExtraJoy setting), RGL might prefer that this is an optional setting that is enabled/disabled via their .cjm file (rather than my shortcut-key approach) On that 2nd point (adding the .cjm file), seems like this step could be avoided if the redquark source were to initial J3 and J4 mappings to the same defaults as are used for J1 and J2 (e.g., JU, JD, JL, JR, etc). I just took a look at the protovision site with a list of 4-player games. Oh my, there's so many to choose from! Kinda exciting to have this many to try! www.protovision.games/hardw/4_player.php?language=en Now that 4-player gaming on thec64 is looking more and more feasible, maybe something like this could one day make for any interesting firmware update from RGL. I feel like there's a few teething issues to sort out before it can get there though. Let's see...
Today:
Noticed that my help menu was freezing again After assessing various possibilities (resetting back to earlier commits, it still froze, even my c64em-helpmenu.rgl), oddly, it seemed to relate to me plugging in a joystick port into the back USB port. I feel like it warrants further debugging on why that back USB port is so 'special', compared to the USB ports on the side, but I don't have the energy for that right now.
I scrutinised my keyboard scanning code. It seems to open "/dev/input/event1" just fine, but the device doesn't emit any keyboard events anymore (it feels like something else has now consumed those events...).
So the overall conclusion seems to be:
If a joystick is connected to the rear USB port upon booting up, then my keyboard scan-code reading logic doesn't seem to work anymore (it's like something else has consumed those events).
If I wait till after boot-up to connect the joystick to the back port, then the help menu will run fine, it won't freeze, and I can use run/stop to exit the menu
Ok then, what if I plug the usb-memory-stick into the rear usb port instead? (and joysticks plugged into the side-ports) - Aah nice, all 3 joysticks work fine, the help menu displays fine, and there are no problems exiting from the help menu either. Ok, perhaps I can share this solution as-is for now then, and just explain the odd situation with the rear-usb port, and just advise not to plug in joysticks into it, to avoid the help menu freezing. Hmm, maybe one last test for the night. Could I plug in a usb-hub and try a 4-player game? My first attempt was with usb-memory-stick in rear USB port, two joysticks in side USB ports, a usb-hub in the other side USB port, and then two more joysticks in the usb-hub. When I started up to the carousel, only 3 joysticks could initially control the carousel. The 4th joystick was being ignored. I jumped into ik+gold, tried to do CTRL-U to turn on the userport extra-joy setting, but all my shortcut keys were being ignored So I tried unplugging a joystick (from the side USB port) and then the shortcut keys were responsive once more. After plugging in the joystick again, then all joysticks could control the carousel. I tried plugging all 4 joysticks into my usb-hub: I restarted thec64 maxi Only 3 joysticks could control the carousel again After jumping into PCU's carousel, all 4 joysticks could control the carousel (aah, but the keyboard controls didn't work, so perhaps by having 4 joystick controls, it disables keyboard control?) I jumped into Protovision's Hockey Mania (I created a 4-player .cjm file for it, similar to the one I made for IK+Gold last night). Again, I was unable to press CTRL-U to turn on the userport ExtraJoy setting I tried unplugging a joystick, and then I was able to press CTRL-U to turn this setting on But the problem then was that when I tried plugging in the 4th joystick, it would no longer register (it seemed like the usb-keyboard had taken its place, as if only 4 input devices were permissable). I rebooted into PCU carousel, got all 4-joysticks working again, then jumped into classic mode. I tried typing on the keyboard at the BASIC prompt, but nothing appeared, again confirming my suspicions that the enabled 4-joystick devices prevented the usb-keyboard from being accepted as an input device Alrighty, one last thing I'll try tonight is the following. I'll try tweak the vice source to automatically turn this userport 'ExtraJoy setting on by default, hence not needing a shortcut key at all (screw the keyboard! ). I'll edit the "c64emu/c64emu.c" file, and within core_init(), I'll add: core_init()
{
resources_set_int("ExtraJoy", 1); // turn on user-port extra joysticks
resources_set_int("ExtraJoyType", 0); // for protovision user-port adapter emulation Aah nice, it worked! Ok, perhaps I could share this in pcu as an example of preliminary support for 4-joysticks. Some caveats might be: Having the userport extra-joy setting on by default may affect some programs that aren't expecting it to be there. So it's probably best for me to keep that CTRL-U toggle setting handle (assume it is on by default, and then let the PCU user turn it off, if need-be). |
|
|
|
Post by jj0 on Sept 23, 2020 14:47:58 GMT
...and for those that want the sickening, gory details of all the problems and failures along the way, there's this post
Last night:
- I made a CTRL-U shortcut key to toggle this 'ExtraJoy' setting to get two extra joysticks via the user-port.
- I also set 'ExtraJoyType' to 0 (for the protovision user-port adapter emulation). This probably wasn't necessary, as I suspect it is the default.
- I also added some debug output inside "src/joystick.c" - joystick_set_value_absolute(joyport, value) to let me assess what those passed in parameters are.
- I then fired up IK+Gold (which IK+ modded for 3-player joystick support)
- I then tried moving each joystick, to assess what the debug output would reveal for those arguments
For joyport 1: joyleft value=4, joyright value=8
For joyport 2: joyleft value=4, joyright value=8
For joyport 3: joyleft value=0, joyright value=0
- So it was good to see that joystick_set_value_absolute() was being called for the 3rd joystick, but worrying that the value argument was always zero.
- At that point, I recalled Shaun recently explained in the forums how a .cjm file can be added to map a 3rd/4th joystick. In his example, he mapped the joy positions to keyboard keys. So I thought I'd instead map J3 to genuine joystick positions (JU, JD, JL, JR, etc).
" ikplus3playertest.cjm" X:64,pal
J:1*:JU,JD,JL,JR,JF,JF,RS,SP,SP,RS,F1,F7,RS
J:2:JU,JD,JL,JR,JF,JF,RS,CM,SP,F1,F3,F5,RS
J:3:JU,JD,JL,JR,JF,JF,RS,CM,SP,F1,F3,F5,RS
J:4:JU,JD,JL,JR,JF,JF,RS,CM,SP,F1,F3,F5,RS After adding this .cjm file, I tried again, and hey presto! I can now control the 3rd (blue) player in IK+Gold! Here's a link to a video I made to celebrate the moment, and share/explain the findings: CONCLUSIONS: It is possible to get 2 extra userport-based joysticks working with thec64 by: - setting the 'ExtraJoy' setting to 1 (as via my CTRL-U) shortcut key
- and by adding a .cjm fie to provide proper joystick mappings for J3 and J4
On that 1st point (ExtraJoy setting), RGL might prefer that this is an optional setting that is enabled/disabled via their .cjm file (rather than my shortcut-key approach) On that 2nd point (adding the .cjm file), seems like this step could be avoided if the redquark source were to initial J3 and J4 mappings to the same defaults as are used for J1 and J2 (e.g., JU, JD, JL, JR, etc). I just took a look at the protovision site with a list of 4-player games. Oh my, there's so many to choose from! Kinda exciting to have this many to try! www.protovision.games/hardw/4_player.php?language=en Now that 4-player gaming on thec64 is looking more and more feasible, maybe something like this could one day make for any interesting firmware update from RGL. I feel like there's a few teething issues to sort out before it can get there though. Let's see...
Today:
Noticed that my help menu was freezing again After assessing various possibilities (resetting back to earlier commits, it still froze, even my c64em-helpmenu.rgl), oddly, it seemed to relate to me plugging in a joystick port into the back USB port. I feel like it warrants further debugging on why that back USB port is so 'special', compared to the USB ports on the side, but I don't have the energy for that right now.
I scrutinised my keyboard scanning code. It seems to open "/dev/input/event1" just fine, but the device doesn't emit any keyboard events anymore (it feels like something else has now consumed those events...).
So the overall conclusion seems to be:
If a joystick is connected to the rear USB port upon booting up, then my keyboard scan-code reading logic doesn't seem to work anymore (it's like something else has consumed those events).
If I wait till after boot-up to connect the joystick to the back port, then the help menu will run fine, it won't freeze, and I can use run/stop to exit the menu
Ok then, what if I plug the usb-memory-stick into the rear usb port instead? (and joysticks plugged into the side-ports) - Aah nice, all 3 joysticks work fine, the help menu displays fine, and there are no problems exiting from the help menu either. Ok, perhaps I can share this solution as-is for now then, and just explain the odd situation with the rear-usb port, and just advise not to plug in joysticks into it, to avoid the help menu freezing. Hmm, maybe one last test for the night. Could I plug in a usb-hub and try a 4-player game? My first attempt was with usb-memory-stick in rear USB port, two joysticks in side USB ports, a usb-hub in the other side USB port, and then two more joysticks in the usb-hub. When I started up to the carousel, only 3 joysticks could initially control the carousel. The 4th joystick was being ignored. I jumped into ik+gold, tried to do CTRL-U to turn on the userport extra-joy setting, but all my shortcut keys were being ignored So I tried unplugging a joystick (from the side USB port) and then the shortcut keys were responsive once more. After plugging in the joystick again, then all joysticks could control the carousel. I tried plugging all 4 joysticks into my usb-hub: I restarted thec64 maxi Only 3 joysticks could control the carousel again After jumping into PCU's carousel, all 4 joysticks could control the carousel (aah, but the keyboard controls didn't work, so perhaps by having 4 joystick controls, it disables keyboard control?) I jumped into Protovision's Hockey Mania (I created a 4-player .cjm file for it, similar to the one I made for IK+Gold last night). Again, I was unable to press CTRL-U to turn on the userport ExtraJoy setting I tried unplugging a joystick, and then I was able to press CTRL-U to turn this setting on But the problem then was that when I tried plugging in the 4th joystick, it would no longer register (it seemed like the usb-keyboard had taken its place, as if only 4 input devices were permissable). I rebooted into PCU carousel, got all 4-joysticks working again, then jumped into classic mode. I tried typing on the keyboard at the BASIC prompt, but nothing appeared, again confirming my suspicions that the enabled 4-joystick devices prevented the usb-keyboard from being accepted as an input device Alrighty, one last thing I'll try tonight is the following. I'll try tweak the vice source to automatically turn this userport 'ExtraJoy setting on by default, hence not needing a shortcut key at all (screw the keyboard! ). I'll edit the "c64emu/c64emu.c" file, and within core_init(), I'll add: core_init()
{
resources_set_int("ExtraJoy", 1); // turn on user-port extra joysticks
resources_set_int("ExtraJoyType", 0); // for protovision user-port adapter emulation Aah nice, it worked! Ok, perhaps I could share this in pcu as an example of preliminary support for 4-joysticks. Some caveats might be: Having the userport extra-joy setting on by default may affect some programs that aren't expecting it to be there. So it's probably best for me to keep that CTRL-U toggle setting handle (assume it is on by default, and then let the PCU user turn it off, if need-be). I wonder what happens if you leave the keyboard unplugged, and only plug in it in once the Carousel is loaded? Then /dev/input1 would not be the keyboard. |
|
|
|
Post by gurce on Sept 23, 2020 15:13:37 GMT
> I wonder what happens if you leave the keyboard unplugged, and only plug in it in once the Carousel is loaded? Then /dev/input1 would not be the keyboard.
Ah, in my case, I'm on the c64 maxi, so I just hear people refer to the keyboard as a usb keyboard, so wasn't in a good position to open it up and try what you're describing. Maybe I can try something like that on the c64 mini. Brain feeling frazzled though. Also, I'm not that cluey on the "/dev/input/event1" thingie, it was just a technique I borrowed from online. As an aside, I did notice though when I tried swapping it for "/dev/input/event0", it detected the power button presses.
I have vague memories of someone (maybe here or on fb) saying that the rear usb port on thec64maxi was special, maybe USB OTG?
Whatever it is, i get the impressive the back usb port is "special" on the maxi. Simply plugging in a single joystick into it (and nothing else, apart from usb stick) is enough to screw up my key-scanning efforts.
Ah well, throwing in the towel for the night :-)
|
|
|
|
Post by jj0 on Sept 24, 2020 7:55:58 GMT
> I wonder what happens if you leave the keyboard unplugged, and only plug in it in once the Carousel is loaded? Then /dev/input1 would not be the keyboard. Ah, in my case, I'm on the c64 maxi, so I just hear people refer to the keyboard as a usb keyboard, so wasn't in a good position to open it up and try what you're describing. Maybe I can try something like that on the c64 mini. Brain feeling frazzled though. Also, I'm not that cluey on the "/dev/input/event1" thingie, it was just a technique I borrowed from online. As an aside, I did notice though when I tried swapping it for "/dev/input/event0", it detected the power button presses. I have vague memories of someone (maybe here or on fb) saying that the rear usb port on thec64maxi was special, maybe USB OTG? Whatever it is, i get the impressive the back usb port is "special" on the maxi. Simply plugging in a single joystick into it (and nothing else, apart from usb stick) is enough to screw up my key-scanning efforts. Ah well, throwing in the towel for the night :-) The /dev/input/eventX's are dynamically assigned based on the order USB input devices are discovered. And as the side and back USB ports are on different USB controllers (because the back one is indeed OTG, you can use it for FEL mode) it could be that any device plugged in there is discovered before the ones plugged into the side ports and therefore gets assigned to /dev/event1 (with the power button thingie still being event0). You can see which one is which by running the evtest utility that is included in PCU and also XWM. |
|
|
|
Post by spannernick on Sept 24, 2020 10:06:26 GMT
This couldn't happen to PCU now its using the keyboard, cause it scans all the events until if finds a key or button press..?
The USB port on the back of thec64 Maxi is the Mini USB port on the Orange Pi PC H3 thats USB OTG only and its not for power so the mini USB port on the back of thec64 Maxi must be just for power then.
|
|
|
|
Post by jj0 on Sept 24, 2020 12:31:11 GMT
This couldn't happen to PCU now its using the keyboard, cause it scans all the events until if finds a key or button press..? The USB port on the back of thec64 Maxi is the Mini USB port on the Orange Pi PC H3 thats USB OTG only and its not for power so the mini USB port on the back of thec64 Maxi must be just for power then. Yes, the micro USB port on the back of the Maxi is just for power and the standard USB port on the back is the OTG port. They probably did it this way so to add the 4th USB port. |
|
|
|
Post by spannernick on Sept 25, 2020 11:55:13 GMT
cool
|
|
|
|
Post by spannernick on Sept 25, 2020 15:37:34 GMT
I can't test this cause I use a keyrah and the CTRL key is KEY_TAB in dev/input, is there a way you can make the code scan for 2 keys KEY_LEFTCTRL and KEY_TAB but TAB on the THEC64 Maxi is Restore key. But it don't matter, if it works on other uses THEC64 Maxi's thats fine, just wanted you to know. In PCUv1.18 Carousel Gamelist Switcher you can set which CTRL Key to use in Autostart.sh script, it can use `KGS_BT1="KEY_TAB" or KGS_BT1="KEY_LEFTCTRL" and you just mark them of with a hash(#) if you don't want that key enabled like `#KGS_BT1="KEY_TAB"` and it stops using that key as CTRL. I was wondering if you could get the code in the C64 Emulator to point to the buttons in the autostart.sh script so if it see one of them enabled it uses it as its default CTRL key, just a idea.. probably would be a lot harder to implement than me saying it.. don't mean its possible.. Maybe need Jerome's help here, he is the Master of Linux Code.. |
|
|
|
Post by wini on Sept 25, 2020 17:37:14 GMT
Hi,
where can I download PCUv1.18?
Looks very interesting!
|
|
|
|
Post by gurce on Sept 25, 2020 22:29:56 GMT
Jj, thx for the intel, I'll try look into a way where I can query what the input devices are, so that I can assure I've got the right /dev/input/eventx.
Nick, okidoke, I'll try to parse that file from within the emulator to see if I can grab the preferred ctrl key mapping from there.
Might not get much progress this weekend, crying baby, grumpy wifey :-)
|
|
|
|
Post by spannernick on Sept 26, 2020 12:14:27 GMT
Jj, thx for the intel, I'll try look into a way where I can query what the input devices are, so that I can assure I've got the right /dev/input/eventx. Nick, okidoke, I'll try to parse that file from within the emulator to see if I can grab the preferred ctrl key mapping from there. Might not get much progress this weekend, crying baby, grumpy wifey :-) Its ok My real CTRL key is Commodore key and it works ok, if I press C=+left Arrow it comes up with "JOYSTICKSWAP" on screen, be making a new video soon, when I get some time with the stuff you have added to PCU, that why I took the original video down and I didn't like the way I did it, too quick and not enough time to make it. I need to work out how to add the stuff you add to the c64emu.rgl to Carousel v1.0.5 now cause the C64 emulator is built in but still uses 2.4.. So it works on a Keyrah v1 with my Keyrah keyboard map.. Maybe change the title now to "Gurce's C64Emu PCU Mod".. just a idea.. |
|
) can repair things. Well, if you're superkeen, you're welcome to repair it 
So if you want to try this experimental build, avoid plugging a joystick into the rear port and stick with the side ports or put your joysticks on a usb-hub.