sy2002 / QNICE-FPGA

QNICE-FPGA is a 16-bit computer system for recreational programming built as a fully-fledged System-on-a-Chip in portable VHDL.
http://qnice-fpga.com
Other
69 stars 15 forks source link

UP/DOWN keys don't work on USB keyboard #162

Closed MJoergen closed 3 years ago

MJoergen commented 3 years ago

When calling the monitor function qmon_getc, the left and right arrow keys correctly generate the return values 0x1200 and 0x1300, respectively. However, the up and down arrow keys are in-effective; the qmon_getc function does not return when pressing these keys.

I'm using an ASUS KU-0902 keyboard.

MJoergen commented 3 years ago

Actually, it turns out the monitor intercepts the up and down arrow keys to move the screen buffer.

sy2002 commented 3 years ago

Indeed: In a "textmode application" this existing behaviour (intercepting up/down and also pageup/pagedn) for the scrolling of the terminal window makes a lot of sense. (**)

But in a game for example it does not. This is why for example in Q-TRIS I directly accessed the registers using MMIO to query for the USB keyboard's keys instead of using getc.

There are a bunch of solutions thinkable. IMHO the best one would be:

Treat getc as a function for "textmode apps only" (because as said: there the behaviour makes sense) and have a second function like readkbd that is more on the level of raw keyboard reading and which might be related to issue #142 (Feature request: Add ability to poll current keyboard status).

@MJoergen What are your thoughts?

EDIT: about (**): It not only intercepts up/down for the scrolling but also pageup/pagedn AND POS1 (HOME) and END

MJoergen commented 3 years ago

I like your idea.

How about going one step further and ONLY use Issue #142? I mean, once we have a solution to poll the current keyboard status, I see no reason to have a very similar function readkbd, unless all that function does is to read the HW register IO$KBD_RT and return the value.

sy2002 commented 3 years ago

Agreed. I suggest to CLOSE this one as a duplicate of #142.