Text editor

Stefan · Post by **Stefan** » Thu Nov 26, 2020 6:56 pm

Version 0.3.0 of X16 Edit released.

Major rework to make the program romable. I have included a pre-built ROM image. There are, however, some steps, if you want to test the ROM version. The steps are described in more detail on the download page, and on my Github page.

Change of line break encoding. If in PETSCII mode line breaks are now marked with a single CR. In ISO mode line breaks are marked with a single LF.

don bright · Post by **don bright** » Sun Dec 13, 2020 9:30 am

its very very impressive....

i tried some very basic modifications (attached) to make it act more like nano. (ctrl-n = next line, ctrl-p = prev, meta-g = go to line, ctrl-w = find, ctrl-o = save) this is not intended for anyone to use, its just to get an idea of how hard/easy it would be. (obviously requires modifying main.asm to change the .inc files to the ones attached here)

it would take quite a bit more work to really convert it to act like nano...

there are also some issues with the emulator on linux.

1. the emulator has apparently chosen ctrl-f to be 'fullscreen' apparently. this kind of breaks the ctrl-f thing (which in nano is actually 'move cursor forward one character')

2. the emulator apparently thinks ctrl-c is the same thing as escape. i dont know if thats how things are on the c64 or.....

anyways really cool project.

screen.nano.inc keyboard.nano.inc cmd.nano.inc

Stefan · Post by **Stefan** » Sun Dec 13, 2020 9:47 am

8 minutes ago, don bright said:

its very very impressive....

i tried some very basic modifications (attached) to make it act more like nano. (ctrl-n = next line, ctrl-p = prev, meta-g = go to line, ctrl-w = find, ctrl-o = save) this is not ready for anyone to use, its just to get an idea of how hard/easy it would be. (obviously requires modifying main.asm to change the .inc files to the ones attached here)

it would take quite a bit more work to really convert it to act like nano

there are also some issues with the emulator on linux.

1. the emulator has apparently chosen ctrl-f to be 'fullscreen' apparently. this kind of breaks the ctrl-f thing (which in nano is actually 'move cursor forward one character')

2. the emulator apparently thinks ctrl-c is the same thing as escape. i dont know if thats how things are on the c64 or.....

anyways really cool project.

screen.nano.inc 31.17 kB · 1 download keyboard.nano.inc 23.57 kB · 2 downloads cmd.nano.inc 43.44 kB · 2 downloads

Thanks!

It would certainly be nice to follow Nano's shortcuts more closely. As you said, some Ctrl+key sequences are wired to other keys at least as the Kernal keyboard scan routine works. Ctrl+c=Esc and Ctrl+M=Enter are two examples.

I will look at the files you attached.

In the meantime, all commands should be available if you press and release Esc and then the command key (without Ctrl). I put in that option as a fallback.

don bright · Post by **don bright** » Sun Dec 13, 2020 9:59 am

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.

Stefan · Post by **Stefan** » Sun Dec 13, 2020 11:59 am

I totally agree that the editor should use the same shortcuts as Nano, if possible.

I think the solution is to get Ctrl and Alt key status separately. That probably requires low level reading of the VIAs.

Maybe such a function could be "bolted on" in parallel to using the Kernal keyboard scan routine. Otherwise, you need to write custom keyboard scan code from scratch, which I wouldn't like to do if there are other options.

The X16 joystick_scan and joystick_get Kernal functions read Ctrl and Alt key status for you separately, according to the PRG. But it is said to work only if no joystick is attached. I wouldn't like to create a text editor that requires you to unplug the joystick every time...

I will look more closely on this, as it's an important part of the user interface. If anyone else has a solution, please tell me.

Stefan · Post by **Stefan** » Sun Dec 13, 2020 7:43 pm

I have looked at little at the Kernal keyboard driver code:

x16-rom/kernal/drivers/x16/ps2kbd.s

I first tried to read the value of shflag ($a00c), but it seems that the value is cleared before the Kernal scan routine returns.

However, if I understand correctly (far from certain), the _kbd_scan routine stores a 16 bit key pressed value in "ckbtab" ($84-85).

I did try that. Results:

First byte ($84) seems to indicate modifier key

Value if no modifier key = $c5

Value if Shift pressed = $38

Value if Control pressed = $93

Value if Alt pressed = $c1

The other byte ($85) seems to indicate non-modifier key

When trying this, I first called the Kernal GETIN as normal. Then I read the content of $84-85.

There is a table of what I believe is modifier key values, ten bytes from $a017. Content: $38, $c1, $ee, $c1, $93, $c1, $ee, $c1, $c5, $c0

It looks promising. Have to keep digging, though.

If I get this working reliably, I will make the keyboard shortcuts the same as in GNU Nano, as far that's possible to do.

Greg King · Post by **Greg King** » Sun Dec 13, 2020 9:35 pm

That idea can't work. The data at $A017 looks like an array of ROM addresses. They probably point to key-code decoder tables. On the C64, that array is in ROM. But, on the X16, it's in RAM because it can change! We can choose different keyboard layouts (the F9 function key cycles through them). And, we can choose between PetSCII and ISO character encodings.

Stefan · Post by **Stefan** » Mon Dec 14, 2020 5:07 am

@Greg King

Hello Greg.

You're right, those 16 bit values are pointers to keyboard layout tables, and the values might change as you switch keyboard layout.

You could still compare $84-85 to each entry in the $a017 table. From the position in the table where there is a match you can conclude the modifier key.

But it's a hack. The solution is depending on the internal workings of the Kernal keyboard scan routine, leaving $84-85 in this state when done.

Do you have a better solution? Or should we kindly ask @Michael Steil to modify the Kernal to store a copy of shflag for us?

Stefan · Post by **Stefan** » Wed Dec 16, 2020 5:57 am

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.

Perifractic · Post by **Perifractic** » Wed Dec 16, 2020 6:46 am

Michael is usually way ahead of most of us [emoji6]