how to read the keyboard (Emulator)

[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?

 

 

[SlithyMatt]

I use this reference as a baseline: https://style64.org/petscii/

Plus, the X16 programmer's guide has some modifications to the control codes: https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#new-control-characters

[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).

 

[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?

1. 
   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.
   


2. 
   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).
   

[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.

[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.

[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.