Page 1 of 1
how to read the keyboard (Emulator)
Posted: Mon Mar 08, 2021 10:13 pm
by Terrel Shumway
Quote
GETIN = $FFE4 ; get character from keyboard
BASIN = $FFCF ; get character
BSOUT = $FFD2 ; write character
.import prhex_byte
.segment "INIT"
.segment "ONCE"
.segment "STARTUP"
start:
JSR GETIN
CMP #0 ; no key pressed
BEQ start
CMP #4 ; Ctrl+D EOT XXX: this doesn't work
BEQ done
JSR prhex_byte
LDA #32
JSR BSOUT
BRA start
done:
RTS
I am trying to get a simple REPL going: Read the keyboard, do something with the key, print the result.
I have never owned a Commodore machine (I grew up on Apple ][e, but the first computer I owned was a PC: a 486DX2 with a gigantic 243MB hard disk) so I have a big learning curve.
This code "works", but the emulator intercepts a lot of the keystrokes. I also noticed that GETIN definitely doesn't return ASCII.
How do I turn on/off the emulator's preprocessing of the control keys?
Where can I get a list of the scan-codes that GETIN returns?
how to read the keyboard (Emulator)
Posted: Mon Mar 08, 2021 10:30 pm
by SlithyMatt
how to read the keyboard (Emulator)
Posted: Tue Mar 09, 2021 6:58 am
by x16tial
Couple tips:
The CMP #0 after the JSR GETIN isn't necessary. The BEQ will behave correctly if there's a 0 in the accumulator.
Instead of CMP #4, you could use CMP #3 which will detect STOP (Esc in the emulator).
how to read the keyboard (Emulator)
Posted: Tue Mar 09, 2021 9:45 am
by Stefan
11 hours ago, Terrel Shumway said:
How do I turn on/off the emulator's preprocessing of the control keys?
Where can I get a list of the scan-codes that GETIN returns?
AFAIK it's not the emulator that preprocesses control keys. The PS/2 scan codes are processed by the Kernal. To change the behavior you need to change the Kernal.
The Kernal's translation from PS/2 scan code to ASCII/PETSCII is quite a complicated affair. There are tables for each supported keyboard layout in the ROM image (source code path: x16-rom/keymap).
how to read the keyboard (Emulator)
Posted: Tue Mar 09, 2021 6:37 pm
by SlithyMatt
11 hours ago, x16tial said:
The BEQ will behave correctly if there's a 0 in the accumulator.
I would not make this assumption. The Z bit is not just based on the accumulator value. If another register was loaded, incremented or decremented since A, the Z bit is subject to change. I don't think there's any explicit guarantee that A is the last register that GETIN touches. However, it IS explicitly stated in the Kernal API that GETIN may modify X and Y.
how to read the keyboard (Emulator)
Posted: Tue Mar 09, 2021 9:28 pm
by x16tial
2 hours ago, SlithyMatt said:
I would not make this assumption. The Z bit is not just based on the accumulator value. If another register was loaded, incremented or decremented since A, the Z bit is subject to change. I don't think there's any explicit guarantee that A is the last register that GETIN touches. However, it IS explicitly stated in the Kernal API that GETIN may modify X and Y.
You're right, it has just worked well for me, but we're talking about 2 bytes and 2 cycles, so yeah, it's not much savings to not do it.
how to read the keyboard (Emulator)
Posted: Wed Mar 10, 2021 1:34 am
by BruceMcF
6 hours ago, SlithyMatt said:
I would not make this assumption. The Z bit is not just based on the accumulator value. If another register was loaded, incremented or decremented since A, the Z bit is subject to change. I don't think there's any explicit guarantee that A is the last register that GETIN touches. However, it IS explicitly stated in the Kernal API that GETIN may modify X and Y.
Quite. After all, the Kernel is subject to later upgrades, and there might be a space or clock optimization somewhere along the way that modifies X or Y after A is modified. Indeed, if the setting of the flag is inherited from the underlying API routines, then since GETIN can be redirected from the Kernel routines to installed device drivers, it might not be safe to assume load order for installed device driver routines, even if the Kernel routines load A last.