Keyboard adapter v2?

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Keyboard adapter v2?

Post by uze6666 »

D3thAdd3r wrote: Sat Mar 25, 2023 8:28 pm Ultimately I think emulator support is critical, and would be way more convenient to develop/update such things.
Can't agree more. I don't know if Artcfox had time to add support otherwise I guess I will have to bite the bullet. Without it I find pointless to release the project I've been working on forever because it need at the very least the keyboard. If someone could just indicate me where to start and in which file it should be added.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Keyboard adapter v2?

Post by D3thAdd3r »

Cuzebox internals have proven difficult for me to follow versus Uzem, likely as my code scanning is so used to tabs it slows to a crawl/gets lazy otherwise. It's doing some pretty clever tricks spread over many files, if I understand how it handles hardware events. But as I see it you would want to put what's in Uzem to cu_ctr.c? In particular

Code: Select all

auint cu_ctr_process(auint prev, auint curr);
That said, it doesn't appear completely obvious how to do it. It would also have to tie in somehow with host controller selection inginput.c. The would seem necessary in partucular:

Code: Select all

void  ginput_sendevent(SDL_Event const* ev);
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Keyboard adapter v2?

Post by Artcfox »

Sorry, I promise I have not forgotten! I have just been super slammed with work lately and have been dealing with extreme fatigue in the evenings/night. I am normally a night owl, so it sucks not being able to have time for myself when everyone else is sleeping.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Keyboard adapter v2?

Post by D3thAdd3r »

@Artcfox

Please checkout https://github.com/weber21w/cuzebox-keyboard-mouse It's pretty well functional for keyboard passthrough(with escape sequence/breakout support), though the integration could probably be done better. I'd like to figure out what multitaps look like logically, and find the right way for a keyboard to be left in a multitap while working as expected.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Keyboard adapter v2?

Post by Artcfox »

D3thAdd3r wrote: Thu Apr 13, 2023 5:26 pm @Artcfox

Please checkout https://github.com/weber21w/cuzebox-keyboard-mouse It's pretty well functional for keyboard passthrough(with escape sequence/breakout support), though the integration could probably be done better. I'd like to figure out what multitaps look like logically, and find the right way for a keyboard to be left in a multitap while working as expected.
Awesome, I should finally have some time to check it out this weekend.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Keyboard adapter v2?

Post by Artcfox »

I just tried it out, and looked over the code. It works great, the only "cleanup" type stuff that jumps out at me is the variables that are declared extern in order to access from other files.

Code: Select all

extern uint8 cu_kbd_enabled;
extern uint8 cu_mouse_enabled;
I think the pattern used elsewhere in cuzebox is to have getter functions

Code: Select all

uint8 cu_kbd_enabled = cu_kbd_get_enabled();
uint8 cu_mouse_enabled = cu_mouse_get_enabled();
That way there is no chance of those variables getting written to unless you call the corresponding set functions.

I'm not sure if compiling the keyboard and mouse files with $(CFSIZ) or $(CFSPD) is the best, but if I had to guess I think CFSIZ might be the best for cache purposes. (you'd want as much of the code to fit into the processor's cache as possible).

It looks like some tabs slipped into the files rather than spaces. (You can see that in the comparison diff between your change and upstream.)

Other than those nits, I think it's awesome. The Keyboard Demo runs great for me. I haven't been able to test the mouse support. I thought that ESD Attack supports the mouse, but I've never gotten that demo to work.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Keyboard adapter v2?

Post by D3thAdd3r »

Artcfox wrote: Sun Apr 16, 2023 6:41 pm I think the pattern used elsewhere in cuzebox is to have getter functions
Fixed the tabs, will update with setter/getter and put that up. Mouse isn't currently working, and doing it the current method would be a bit nasty, I just don't see the way to do it yet. Ideally there would be something in front of controller reads to call the correct function, instead of overriding parts of controller reads based on the state of external modules.
Artcfox wrote: Sun Apr 16, 2023 6:41 pm I'm not sure if compiling the keyboard and mouse files with $(CFSIZ) or $(CFSPD) is the best, but if I had to guess I think CFSIZ might be the best for cache purposes. (you'd want as much of the code to fit into the processor's cache as possible).
Huh, I hadn't really looked at that. Changed keyobard/mouse to CFSIZ to match cu_ctr.c

Will get this posted tonight with the changes above. I'll wait on mouse until I have a better understanding of what the multitap will be. Otherwise I could take a stab at what a hypothetical "Uzebus" might look like. Mainly I just don't want call controller reads and then override them, I'd much rather have some ideal multitap that can pass through devices in a logical manner for unaware ROMs and model that as "the ultimate complexity" which dictates how such things get laid out.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Keyboard adapter v2?

Post by D3thAdd3r »

@uze6666

So I started to integrate keyboard support for in game chat, and I will say it's quite easy to use for that. I have 2 questions on it, first is the intended goal to be able to read a joypad followed by the keyboard at some point? I noticed in KeyboardDemo it seems to do this, which I think is just as an example to handle one *or* the other, but not both? This also seems to support hot plugging then, nice!

Code: Select all

void VsyncHandler(){

	if(readKeys){
		ReadButtons2();		//read the snes controllers

		u8 key=GetKey(KB_SEND_END);
		if(key!=0){			
			decode(key);
		}
	}
}
However, in emulation(even on real hardware) if I am using a keyboard I don't want to change to a gamepad. Maybe there is already an idea here? Currently it seems the program could process the make/break codes manually, and use that to model a virtual gamepad out of it, or to convert to ASCII depending on the expected input for the game sequence. This would work with the emulator too(which assumes any keyboard access attempt means enter into keyboard passthrough mode), unless there is some limitation I can't see.

I looked at the firmware on GitHub(not sure if that's latest), and it seems there is still space even on an AtTiny25. I'm assuming it would be quite difficult to add a "joypad emulation mode" which can be turned on/off with a command from Uzebox. Then I think handling make/break is the way to go, unless I'm overlooking something. Just wanted to make sure I had this halfway understood before I went too far down the wrong path.

Ok more than 2 questions, but is there a way to read more than 1 scancode per sequence? If I don't send KB_SEND_END, would this work?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Keyboard adapter v2?

Post by uze6666 »

Hi Lee, sorry for the later reply! Quite overworked on other stuff for the past two weeks.

I realized I didn't push the latest firmware. Both are supported at once if -DCONTROLLERS_VSYNC_READ is no set to zero, as was the case in the demo. I'll cleanup and post the latest firmware by week's end
However, in emulation(even on real hardware) if I am using a keyboard I don't want to change to a gamepad. Maybe there is already an idea here? Currently it seems the program could process the make/break codes manually, and use that to model a virtual gamepad out of it, or to convert to ASCII depending on the expected input for the game sequence. This would work with the emulator too(which assumes any keyboard access attempt means enter into keyboard passthrough mode), unless there is some limitation I can't see.

I looked at the firmware on GitHub(not sure if that's latest), and it seems there is still space even on an AtTiny25. I'm assuming it would be quite difficult to add a "joypad emulation mode" which can be turned on/off with a command from Uzebox. Then I think handling make/break is the way to go, unless I'm overlooking something. Just wanted to make sure I had this halfway understood before I went too far down the wrong path.
Not sure I understand this bit, can you perhaps rephrase it?

Ok more than 2 questions, but is there a way to read more than 1 scancode per sequence? If I don't send KB_SEND_END, would this work?
The code seems to support to keep the transaction open if you don't send KB_SEND_END. But I can say for sure if it worked (can't recall). would have to test and improve the documentation about it. I guess I never got the need for more for my use case. Moreover I though that one would have to type quite fast to overrun 60 make/break scan codes per second. :P
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Keyboard adapter v2?

Post by D3thAdd3r »

uze6666 wrote: Wed May 10, 2023 1:22 am Moreover I though that one would have to type quite fast to overrun 60 make/break scan codes per second. :P
:lol: I did try to overrun it, and I concur I can't come close.
uze6666 wrote: Wed May 10, 2023 1:22 am Both are supported at once if -DCONTROLLERS_VSYNC_READ is no set to zero, as was the case in the demo.
I'll check this out when you get a chance to update. Trying to see a way to make joypad+keyboard mode work in emulation, without requiring a USB joypad. I hate to add emulator specific hacks, but I also think most emulator players are using the keyboard for joypad emulation as well. The manual switch hotkey method isn't obvious, so I think there could be a way for a ROM to signal "if you could only have one right now...use this one" depending on the game section.


So maybe easiest to imagine joining a Megatris match with an opponent, once both players are in the same networked game it first stops on the options menu so players can set their stuff up before playing. Ideally they would be able to move around and change stuff, and also message, talk smack, or whatever with the keyboard before the onslaught of back-to-back triple t-spins! So they are using the keyboard, which means menu options as well. Problem is with the current implementation, the emulator player would need to Ctrl+F1 back and forth each time which isn't intuitive. Hard to explain, here's a hypothetical diagram of a networked game:
mue-kb-flow.jpg
mue-kb-flow.jpg (260.6 KiB) Viewed 958 times
Basically to fully use the keyboard would require several changes back and forth. If the keyboard could send multiple makes per frame, it could emulate a joypad with multiple buttons pressed. Then on hardware there is the option of keyboard only or switch at will. In the emulator, no need to switch with Ctrl+F1 each time, since the emulated keyboard...emulating a joypad...is almost equivalent to not being in keyboard passthrough mode. :lol: I don't know how to word it.
Post Reply