Actually, the keyboard management in ugBASIC is oriented to arcade games, so it is not designed to handle string input or, in general, data entry. In recent times efforts was made to introduce a real "driver" for the keyboard, which however still has some gaps. On some chipsets, such as Thomson and Olivetti Prodest, I had to leave the old behavior as default, because the new one is lower in performance. The thing we should suggest in the manual is to use, where possible, KEY STATE(KEY ...) instead of INKEY$. Alternatively, the best thing is not to "mix them" because on some targets they might not give the expected result. So: either you always use INPUT / INKEY (asynchronous mode) or you always use KEY STATE / SCANCODE (synchronous mode).
Actually, the keyboard management in ugBASIC is oriented to arcade games, so it is not designed to handle string input or, in general, data entry. In recent times efforts was made to introduce a real "driver" for the keyboard, which however still has some gaps. On some chipsets, such as Thomson and Olivetti Prodest, I had to leave the old behavior as default, because the new one is lower in performance. The thing we should suggest in the manual is to use, where possible,
KEY STATE(KEY ...)instead ofINKEY$. Alternatively, the best thing is not to "mix them" because on some targets they might not give the expected result. So: either you always useINPUT / INKEY(asynchronous mode) or you always useKEY STATE / SCANCODE(synchronous mode).