Search the Community
Showing results for tags 'input'.
What is the POKE to suppress the INPUT question mark in X16 BASIC? On C64 it is POKE 19,32, but that and POKE 19,1 doesn't work on X16 with ROM R41. The other method using OPEN works, but I would prefer a POKE to do it, because then I can have more similar programs for different BASICs. https://retrocomputing.stackexchange.com/questions/4883/c64-basic-how-to-suppress-the-sign-when-using-the-input-command
Hi everyone, in my current project, I would like to detect key releases, or at the very least if any keys are pressed, at all. The usual GETIN only returns a nonzero value one single time during a key press (except the repeated ones when the key is held down for a longer time). It doesn't provide any precise information on HOW LONG the key is held down. Are you aware of any possibilities to get more precise (and possibly more low-level) data from the keyboard? Thanks in advance. Edit I've found this thread where they mention, that keyboard input is handled by the NMI handler. Since both the ISR vector, and the routine itself are in ROM, there is no way to get the actual data from the keyboard (without modifying the ROM). I really think that the X16 would greatly benefit from a more exposed keyboard interface.
A lot of Forth's that are made to be portable have a simple model of console I/O that is oriented around three calls: KEY? KEY and EMIT. KEY? is the routine that returns either the currently available character and TRUE or else NUL and FALSE, KEY is a loop on KEY? that keeps running until there is a key, and EMIT outputs a character to the screen. In the C64, for both KEY? and KEY, the subroutine threaded DurexForth looks at $C6 to see whether there are any characters in the keyboard buffer: +BACKLINK !byte 4 !text "key?" lda $c6 ; Number of characters in keyboard buffer beq + .pushtrue lda #$ff + tay jmp pushya +BACKLINK !byte 3 !text "key" - lda $c6 beq - stx W jsr $e5b4 ; Get character from keyboard buffer ldx W ldy #0 jmp pushya Since the internal addresses for such things are not documented and not necessarily stable for the CX16, what is the Kernel call to find out whether or not the Keyboard buffer is empty? Or should SCNKEY be recycled for the kind of keyboard information that is now opaque ... like a bit vector of shift keys in A and the number of characters in the keyboard buffer in Y.