Inject low level key codes

Is there any way of injecting the low level key numbers in to the system to be able to test the effect of *FX4 on cursor keys and *FX221-228 on the function keys?

All the methods of inserting in to buffers I know of work at the character code level.

KeyV?

https://www.riscosopen.org/wiki/documentation/show/KeyV

I had tried that and didn’t get it to work. I recoded it just now and did get a character out corresponding to a low level key code – but only as I got press and release reasons the wrong way around, and it kept generating characters. I’ve put it the right way around, and back to nothing. I’ve tried delays of 0 to greater than the keyboard autorepeat, but still nothing.

This iswhat I’ve tried.

   10SYS"OS_CallAVector",2,39,,,,,,,,19
   20T%=TIME:REPEAT:UNTILTIME-T%<0.1
   30SYS"OS_CallAVector",1,39,,,,,,,,19
   40PRINT"Waiting"
   50A%=GET
   60C$=" "
   70IF A%>=32 AND A%<128 THEN C$=" '"+CHR$A%+"'"
   80PRINT"Key ";A%;" &";~A%;C$

BTW: I’m sure there was an easy way of converting BASIC to plain text using ZAP. But changing to BASTXT mode no longer works.

BTW: I’m sure there was an easy way of converting BASIC to plain text using ZAP. But changing to BASTXT mode no longer works.

I seem to remember a “Dump” menu entry somewhere, that produces a plain text equivalent of the currently shown data. Also works for the Disassembler view, the Hex view etc.

I seem to remember a “Dump” menu entry somewhere

Ah! Thanks for the reminder.

Has anyone got a working example of using KeyV?

Your example works for me (producing a ‘q’).

However, there’s one obvious bug: your delay loop is broken.

T%=TIME:REPEAT:UNTILTIME-T%>10

What machine are you running the code on? On early versions of RISC OS the kernel performed key debouncing, so KeyV had to see that the key was down for a certain amount of time before it would generate any character codes. On newer versions (Select & 5) this was made optional (via the magic “NoKd” argument to KeyV 0), since more modern keyboard hardware/drivers (e.g. USB) handle debounce themselves.

For RISC OS 5, I think IOMD is the only platform where the kernel will be doing key debouncing, so if you were running your test code with a broken delay loop on RPCEmu then that should hopefully explain why it wasn’t working for you (I tested on Titanium with USB keyboard).

Also note that I don’t think there’s a way for software to check if the kernel is doing key debouncing (or how long the debounce timer is).

Thanks Jeffery!

Its always the simplest thing that is wrong!

I’m running on a Pi4B, so it looks like some delay is still necessary, I’ll have a play with NoKd.

But now I can insert key presses programmatically, it will mean I test things properly without an insane amount of manually pressing various key combinations.