Jump to content
Stefan

Text editor

Recommended Posts

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.

Edited by Stefan

Share this post


Link to post
Share on other sites

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

Edited by don bright
  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Edited by Greg King

Share this post


Link to post
Share on other sites

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

Edited by Stefan

Share this post


Link to post
Share on other sites

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.

  • Like 3

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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

Edited by Stefan

Share this post


Link to post
Share on other sites

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 🙂

Share this post


Link to post
Share on other sites

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:

image.png.41feb9108e3b3ec614d9baa378e7f380.png

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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:

image.png.41feb9108e3b3ec614d9baa378e7f380.png

 

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

Skärmavbild 2020-12-19 kl. 10.55.32.png

Edited by Stefan

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Hi @Stefan,

I just tried out the ROM variant of your X16Edit 0.3.3, and it works like a charm! The directory listing view is super convenient, I love it. The only usability issue I noticed is that in x16emu I can't use ctrl-R for opening a file, because the emulator then issues a reset, so the only way is via F5. Not sure if that is worth changing ...

Invoking the editor was also straightforward and worked at first attempt, thanks to your sample assembler snippets. Also, I realized that the r0/r1 parameters at $02/03 and $04 for the file name not only follow the X16 Kernal calling conventions, but are also easy to set from Forth - very handy.

One thing I was pondering today: I could use the jmp opcodes $4c at $c000 and $c003 as signature for the X16Edit ROM being present, and not call X16Edit otherwise; this could likely prevent a crash in most cases where someone would type xed in cc64 on a machine without the X16Edit ROM. Should we do that?

Cheers

/Philip

  • Thanks 1

Share this post


Link to post
Share on other sites

Thanks a lot @pzembrod

It's a nuisance, that Ctrl+R resets the emulator on Windows and Linux. It doesn't in the MacOS version. I have assumed that Ctrl+R will not reset the real X16, but assumptions are dangerous 🙂

I would really like to use GNU Nano's shortcuts as much as possible. But I cannot anyway follow that all the way, as Alt+key combinations may not reliably be detected.

A side note is that I have made a pull request in the Github repository for the X16 ROM to get finer control of key press and key release events, making it possible, amongst other, to detect Alt+key combinations. You may read about the pull request here:

https://github.com/commanderx16/x16-rom/pull/187

If you have a suggestion, I'm all ears. In the meantime you get to file open in the Windows and Linux emulators by F5, as you write, or by pressing and releasing Esc and then R.

Checking for the presence of X16 ROM by the signatures of the two leading jmp instructions sounds like a good idea. I intend to do my very best to never change the op codes at $c000 and $c003.

If you would like another form of verification, I would be happy to provide that as well, for instance a short text string or byte sequence. That could be placed before the vectors at $fffa, for instance.

Have to dash. I'm off to do some cross country skiing, as we finally have got snow where I live.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use