Text editor

pzembrod · Post by **pzembrod** » Sat Jan 16, 2021 9:01 pm

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

Stefan · Post by **Stefan** » Sun Jan 17, 2021 6:26 am

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.

Stefan · Post by **Stefan** » Tue Jan 19, 2021 5:02 pm

On 1/16/2021 at 11:01 PM, pzembrod said:

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?

I've given this some more thought.

As I said, my intension is to not change the opcodes at $c000 and $c003, as they are part of the public API of the editor.

To verify with greater certainty, that a ROM bank contains X16 Edit, I have made placed the string "X16EDIT" followed by three bytes representing the application version number (major - minor - patch), a total of ten bytes, at address $fff0-$fff9. This is only available in the ROM version of the program.

It's pushed to the Github repository, and will be in the next release. Unless you have some other ideas on what would be best to do.

pzembrod · Post by **pzembrod** » Tue Jan 19, 2021 7:29 pm

2 hours ago, Stefan said:

To verify with greater certainty, that a ROM bank contains X16 Edit, I have made placed the string "X16EDIT" followed by three bytes representing the application version number (major - minor - patch), a total of ten bytes, at address $fff0-$fff9. This is only available in the ROM version of the program.

That sounds great to me. I will integrate it in my next version.

I was also thinking that we might want to open a separate thread on this and discuss with the project owners and rest of the X16 community whether some kind of recognition standard for additional ROMs might be useful and desirable.

If something like that came to be, then I could see an advantage in placing the identification string at the beginning instead of at the end of the ROM area, namely that it would allow it to be used also by ROMs which want to or need to replicate the Kernal jump table. It would also be in line with the CBM80 or CBMBASIC string at the beginning of C64 $8000 modules and the Basic ROM at $a000.

Incidentally, I have just pushed "Publish" on cc64 v0.8 which contains the X16 port; I'll upload it here later today or tomorrow.

TomXP411 · Post by **TomXP411** » Tue Jan 19, 2021 7:31 pm

Out of curiosity, why are the hotkeys based on Nano?

I'm wondering if using the more common conventions of ^O for open, shift-arrow for selecting text, and ^X^C^V for cut, copy, paste would make things easier on new users.

Also, I'm looking at cc64, and your editor is currently the only option for editing text. However, the { and } keys on the PC don't map to the same codes on the CX16, even with the cc64 character set loaded. Is there a possibility of getting a "C" mode, where pressing those two keys outputs 123 and 125?

Stefan · Post by **Stefan** » Wed Jan 20, 2021 5:39 am

9 hours ago, TomXP411 said:

Out of curiosity, why are the hotkeys based on Nano?

I'm wondering if using the more common conventions of ^O for open, shift-arrow for selecting text, and ^X^C^V for cut, copy, paste would make things easier on new users.

Also, I'm looking at cc64, and your editor is currently the only option for editing text. However, the { and } keys on the PC don't map to the same codes on the CX16, even with the cc64 character set loaded. Is there a possibility of getting a "C" mode, where pressing those two keys outputs 123 and 125?

There are several reasons.

It's a personal preference: I've used Nano a lot and come to like it.

The X16 environment mostly resembles a keyboard controlled command line in a modern OS. I wanted to build upon a tried and tested solution for the such an environment.

Nano is generally recognized to be very user friendly without the learning curve of other options such as Vi or Emacs.

Nano comes pre-installed in MacOS and in most Linux distributions. It's also available to Windows users. It's hard to say how many active users there are, but I would guess that we still are quite a few.

However, I'm not religious about it, and do certainly not intend to start an editor war. If there are usability issues, I will try to sort them out.

I'm very excited to try the C compiler @pzembrod published yesterday. I have not yet had a chance to do that. I will look at integration issues and key mappings.

Have a nice day!

kktos · Post by **kktos** » Wed Jan 20, 2021 6:38 pm

I read at some point someone was having troubles with the emulator shortcuts, right ?

Because I'm still working on my PR, Debugger enhancements v2 and I plan to add some parameterization for the keys. So I can add the same kind of feature to the whole emulator.

I'll keep you posted.

Stefan · Post by **Stefan** » Wed Jan 20, 2021 7:33 pm

55 minutes ago, kktos said:

I read at some point someone was having troubles with the emulator shortcuts, right ?

Because I'm still working on my PR, Debugger enhancements v2 and I plan to add some parameterization for the keys. So I can add the same kind of feature to the whole emulator.

I'll keep you posted.

Yes, I think Windows and Linux users have trouble at least with Ctrl+R, that resets the emulator instead of the intended function, reading a file. On MacOS reset is Cmd+R, which is not a problem for X16 Edit.

TomXP411 · Post by **TomXP411** » Wed Jan 20, 2021 11:28 pm

17 hours ago, Stefan said:

I'm very excited to try the C compiler @pzembrod published yesterday. I have not yet had a chance to do that. I will look at integration issues and key mappings.

It certainly worked well for my trivial examples. The biggest problem I had was just being able to get text into the machine... the good news there is that ISO mode has all of the missing characters and maps the keyboard to the characters you'd expect on a PC.

So really, we just need a way to switch the editor to ISO and back to PETSCII mode while the editor is running. I should probably also suggest to @pzembrod that he invoke ISO mode when starting his Forth environment for the compiler; that also gives users all of the correct characters without the need to load alternate character sets.

Stefan · Post by **Stefan** » Thu Jan 21, 2021 5:26 pm

18 hours ago, TomXP411 said:

It certainly worked well for my trivial examples. The biggest problem I had was just being able to get text into the machine... the good news there is that ISO mode has all of the missing characters and maps the keyboard to the characters you'd expect on a PC.

So really, we just need a way to switch the editor to ISO and back to PETSCII mode while the editor is running. I should probably also suggest to @pzembrod that he invoke ISO mode when starting his Forth environment for the compiler; that also gives users all of the correct characters without the need to load alternate character sets.

Hi,

You can change the character set while running X16 Edit (Ctrl+E).

However, the special characters in cc64, such as { and }, are not mapped to the ASCII values of those characters. So it will not work to just change character mode in the editor.

To make this more user friendly, either cc64 can be changed to support ISO character mode (I don't know how hard that would be). Or X16 Edit could be changed to support a special cc64 mode (I don't know how hard that would be either).