Commander X16

2 hours ago, Stefan said:

Seems @Michael Steil was way ahead of us.



After further studying of the Kernal sources I noticed the function "kbdbuf_get_modifiers" in kernal/kbdbuf.s.



In R38 the call address is $ca64.



I've just tested it briefly, and I think it is working properly. The function returns value of shflag in A register, where each modifier key is represented by one bit. This also makes it possible to detect combinations of several modifier keys.

Great! There's a Github issue I can take down as resolved, once I get caught up on my grading backlog (half of my courses do their final exams this week, so next week I am down from sixteen hours of lectures a week to eight).

On 12/13/2020 at 11:59 AM, don bright said:

there's nothing much in the files, its just replacing some of the key mappings as an experiment. some text editors allow keymapping to switch on the fly at runtime, but thats quite a lot of work.



yeah the escape-command is a very interesting feature.....  its just that i have been using nano commands since 1996 (as you may know, nano was based on Pico, a mail reader from the University of Washington) so its kind of hard for me to switch to a different layout.

I now have a solution for the shortcut overlaps, as you may read about above in this thread.

The next problem is to decide on the shortcuts to use:

• 
  Some shortcuts may be used as is
  


• 
  Some shortcuts must be changed as the control character does not exist in PETSCII (for instance underscore)
  


• 
  Some X16 Edit commands have no direct match in Nano
  

I attach a file listing the shortcuts.

Considering that you have been using Nano and Pico for such a long time, I would appreciate your input on the shortcut layout.

Also, if there are other commands that in your opinion are crucial for using Nano effectively, please list those too.

 


kbdshortcuts.txt

I just wanted to stop by and say "thank you" for writing this.

It's going to make writing my silly little dungeon game directly on the emulator much more pleasant, since I won't have to clutter it up with a big pile of DATA statements ?

Hello. Starting the weekend with some thoughts on the keyboard shortcuts. I would like to follow GNU Nano as closely as possible, but some differences are unavoidable. This is my first try:

Might have stumbled into another problem.

Alt+key combinations are detected fine in both PETSCII modes. But in ISO mode, neither CHRIN, nor kbdbuf_get_modifiers return anything on Alt+key. Tried the emulator on MacOS and Windows with the same result.

Detecting Ctrl+key combinations seems to work as expected both in PETSCII and ISO modes.

Is this a known behavior?

6 hours ago, Stefan said:

Hello. Starting the weekend with some thoughts on the keyboard shortcuts. I would like to follow GNU Nano as closely as possible, but some differences are unavoidable. This is my first try:

 

2 hours ago, Stefan said:

Might have stumbled into another problem.



Alt+key combinations are detected fine in both PETSCII modes. But in ISO mode, neither CHRIN, nor kbdbuf_get_modifiers return anything on Alt+key. Tried the emulator on MacOS and Windows with the same result.



Detecting Ctrl+key combinations seems to work as expected both in PETSCII and ISO modes.



Is this a known behavior?

@Michael Steil

I think I might understand part of the problem with Alt+key sequences in ISO mode.

There's a table (kbdtab) of five 16 bit addresses starting at bank0/$a017. Each address points to the keymap of the current keyboard layout, one for each modifier key in the following order: shift/alt/ctrl/altgr/unshifted.

So. If in US keyboard+PETSCII, the address in $a019-1a (Alt) is $c1ee.

The contents starting at bank1/$c1ee matches the values in keymap/asm/407.s/kbtab_407_4. This is what you would except. And in PETSCII mode the Alt+key works.

Switching to ISO mode, the address in $a019-1a (Alt) is now $d964.

The contents starting at bank1/$d964 contains almost only zeros = null. But there are some values. For instance Alt+1 (corresponding to $81 on the third row of the memory dump) consequently works in ISO mode.

The issue seems to be the content of the keyboard layout map, if I'm not mistaken.

EDIT: I think the difference between PETSCII and ISO modes this is a consequence of the script that generates the keyboard layout tables (keymap/klc_to_asm.py). I'm posting that as an issue on Github.

I now made the smallest of patches to keymap/klc_to_asm.py.

Initial testing successful.

The patch available in the Github issue:

https://github.com/commanderx16/x16-rom/issues/183

I don't think my first solution to the problem with missing Alt+key values in ISO mode is the ideal one.

Some operating systems do link Alt+key sequences to printable characters (at least MacOS), but many other do not (for example Windows). If you would go about assigning printable characters to Alt+key sequences, you would need to consider more carefully what characters to assign.

I'm now thinking about a completely different solution to the problem. This requires changing the Kernal PS/2 functions:

• 
  Add a jump vector in low RAM similar to the IRQ vector in $0314-15. For testing purposes I'm using $02BB-BC
  


• 
  At the end of the Kernal function that reads PS/2 data, that function would make an indirect jump to the address stored in the jump vector.
  


• 
  This would make it possible to write programs that catch any key or sequence of keys before they are translated to printable characters by the Kernal.
  


• 
  It would also make it possible to catch both key down and key up events, which may be interesting for those of us writing keyboard controlled games.
  

I have a working test solution.

If there is any interest for this kind of solution, I could make a pull request.

In the meantime, I think I have to put Alt+key sequences on hold in X16 Edit. I will look at what I can do with Ctrl+key sequences to come closer to the shortcuts used in GNU Nano.

I uploaded v 0.3.3 of the X16 Editor today.

New in this version:

• 
  I have implemented a directory listing view, that you can use to select files for opening or saving. The default option is still to enter the file name manually at the prompt, similar to how GNU Nano works. At the open and save file prompts you may press Ctrl+T. "To files" in GNU Nano jargon. I hope that X16 Edit will be usable for native programming on the computer. The ability to easily open different files should be valuable.
  


• 
  I have also made an alternative entry point that loads a specified text file immediately on startup. I have discussed this option with @pzembrod who also came with valuable input on the function. The idea with this function is that it may be useful when integrating X16 Edit with other programs, for instance Volksforth and the C compiler Philip is working on.
  

If this is hard to understand, the functions are described in more depth in the manual and the special notes on using the ROM version that is available on the download page.

Or you may watch this video.