Joystick_get not working for me

[ch4rl3sb]

That makes me worried that it's not actually working still.
...without any other C code in between, then A should be getting set to 1,

Of course, there could also be another problem in the code somewhere else,

It was largely my fault.
These things are often me overlooking some glitch in my code. I took part of your code and used an assembly function I already had.
I called the function from C after setting A, and obviously A was changed between.

But, the fact that it only returns Y as some unknown value that is not $0 and not $FF for controller present.
I don't know what that is.
The fact that it swaps the controllers. No clue.
The fact that it applied controller key presses to which ever player was created first? That really seems weird and doesn't seem like it should happen. But, that one isn't happening any more. the first two still are, but I can work around them.

[ch4rl3sb]

I didn't know you could embed asm code in C before this. I have asm code and C code and they get compiled together.
My asm code was largely what you showed first, but Y never went to zero and when it did become non $FF, it was for
the wrong controller, so I never saw any behavior from it. And I quit looking at it for months. Until now when I wanted
the extra functionality. And just brute forced tried a lot of values and different ways to access the return variables.

Thank you very much for your help.

Next, I may want to get the keyboard keyup/keydown codes working. That would allow me to remap keys.
When I was using just keyboard _getin before even using the keyboard controller keys, it would start an action, then
stop and wait for the key repeat.

[desertfish]

I know you're using C but I struggled a bit in Prog8 as well to read the joystick. The kernal routine returns 3 byte values but Prog8 only knows about 1 return value from a subroutine call. So I chose to add a second definition for the kernal routine that "seems" to return the A+X registers as one 16 bit value, and the Y register is ignored.

[DragWx]

You're welcome, and I'm sorry for being a little pushy; I'm the kind of programmer who always wants to know exactly why something does or doesn't work, and that can make me get too into it sometimes.

The docs has an explanation on how to write a custom keycode handler, but I'm not sure if there's a specific way to do it using C.

[ch4rl3sb]

You pushing got me through it. I'm thankful. I just feel a little silly I didn't spot the issue earlier.

Now, looking at that keyboard page gives me more questions. The keynum shows several layouts. I sort of assume it's using the first IBM layout, but it doesn't actually say. The others use multiple bytes or codes above 128 that would interfere with the keyup/down code being bit 7. But I know keyboards generally send multiple byte codes... so it takes some interpretation that could have been saved with just a little more documentation. Why show those extra code layouts?

And to verify it, I kind of have to write a key handler that tests that assumption and send me back some data to verify before I write the key handler that actually uses it for my game. Extra work.

[DragWx]

Oops, yes, the keycodes in use are the ones in the "IBM keynumber" column. I made a diagram of them to help out, actually.

The SMC on the CX16 is what's actually handling the physical communications with the keyboard, and part of what it does is convert the keyboard's standard Set 2 codes into the "keynums" used by the CX16, and those keynums are what programs (including the Kernal) see. The reason all of those different codesets are shown is probably just for reference purposes, but I agree that we could make it clearer.