Text editor

[Stefan 77]

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 14]

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 77]

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.

Edited January 20 by Stefan

[TomXP411 311]

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. 

 

 

 

 

 

Edited January 20 by TomXP411

[Stefan 77]

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

Edited January 21 by Stefan

[kktos 14]

On 1/20/2021 at 8:33 PM, Stefan said:

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.

After turning the problem in many ways, I simply realize there is no way for the emulator to use the keyboard without affecting the emulated machine.
Pretty obvious afterwards..... Not enough coffee, I presume ;oD
Therefore, I did what other emulators are doing, I enhanced the UI to handle buttons.

[TomXP411 311]

On 1/20/2021 at 11:33 AM, Stefan said:

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.

It sure would be nice if we could get any CONTROL hotkeys removed and switch them to either Control-Alt keystrokes, or put them in a menu bar.

I really like kktos's solution, since that space is dead anyway on most systems. We could enhance that area quite a bit, with buttons to dismount and mount a disk image, reset the emulator, break into the debugger, trigger an NMI (Run/Stop-Restore), and see the state of the registers and critical system variables in real time. 

 

[kktos 14]

I think I will have to do a proper post here but meanwhile, if you wanna try the slightly enhanced version of the debugger, I've uploaded the binaries. You can also compile it, of course.
Here are the windows binaries: Release 20210122

ps: that's the 64bits version so you'll need the 64bits version of SDL2.dll

Edited January 22 by kktos

[pzembrod 33]

On 1/21/2021 at 6:26 PM, Stefan said:

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.

Actually, it's only  {|}~ where there's a problem, \^_ are at their usual ASCII codes for cc64. And even {|}~ get printed correctly under their usual ASCII code. The problem comes from the duplication of $60-$7f at $c0-$df in the PETSCII charset, or rather, the other way around, because shift-A on the C64 keyboard will give you $c1, not $61, and shift-plus (that's where { lives) will give you $db, not $7b, though both print as { (with my patched charset).
I could change the mapping in my ascii2petscii and petscii2ascii tools such that {|}~ are left at $7b-$7e (just like [\]^_ are left at $5b-$5f) instead of mapping them to $db-$de, and for me who writes most code on Linux in ASCII, everything would work, and { would look like {, but natively on a C64 no-one could type { anymore.
It's a bit of a catch.

On 1/21/2021 at 6:26 PM, Stefan said:

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

An ISO cc64 version would certainly be a good thing. For that an ISO X16 VolksForth would be needed, built on an ISO or ASCII target compiler. Playing around with other VolksForth platforms (Z80 or MSDOS or AtariST or generic 6502, all of which are ASCII-based) is one of my plans for the future, anyway, so I'll see what is possible.

[pzembrod 33]

Incidentally, I have now also made a tool for easy patching of an X16 ROM: https://github.com/pzembrod/cc64/blob/master/Usage.md#patch-c-charset

[Stefan 77]

I'm in the process of cleaning the X16 Edit code. I still have some work to do, but I think it's very stable now.

I couldn't resist implementing a new feature, as this was only about 20 lines of assembly - a prompt to execute DOS commands, for instance if you would like to rename or delete a file or create or rename a directory. This feature is not, however, not yet published.

There are two issues that are a bit more complicated to solve

• One is the keyboard repeat rate. X16 Edit uses the Kernal keyboard routines, and it's sometimes painfully slow to wait for the cursor to move while you hold down an arrow key. The speed is the same as in the built-in BASIC editor, I would say. Is there anything you could do? If not, I might have to include more cursor movement features, maybe move one word back or forth.
• The other is the word-wrap feature. It is very simplified at the moment, and the feature I'm least satisfied with. Making it better is a large undertaking, though. Any thoughts on how to make it better without complicating the code base too much would be very appreciated.

[desertfish 277]

I vaguely recall that the C64 had a memory location that influenced the cursor movement (and blink) rate. I don't know if this is a variable in memory for the Cx16

[Stefan 77]

1 hour ago, desertfish said:

I vaguely recall that the C64 had a memory location that influenced the cursor movement (and blink) rate. I don't know if this is a variable in memory for the Cx16

I think you're right about that. This is said about the KOUNT variable ($028B) on https://www.pagetable.com/c64ref/c64mem/

Quote

 

Counter for Timing the Delay Between Key Repeats 

This location is used as a delay counter to determine how long to wait while a key is being held down until the next repeat printing of that key.

The value here starts at 6. If location 652 ($028C) contains a 0, the value in this location is counted down once every 1/60 second, so long as the same key is held down. When this counter gets to 0, and if the repeat flag at 650 ($028A) allows that key to repeat, its ASCII equivalent will once again be placed in the keyboard buffer. A value of 4 is then placed in location 651, allowing subsequent repeats to occur at a rate of 15 per second.

 

I can't find that the KOUNT variable or any other similar variable is used by the X16 Kernal. Of coarse it could be there anyway.

I have read somewhere that PS/2 keyboards managed key repeats themselves (generating multiple key down/up events I guess). Maybe the X16 Kernal is expecting that, which would make the keyboard repeat rate untweakable on the computer side.

EDIT:

I now realized that if you change the keyboard repeat settings in the host system, that also affects the repeat rating in the emulator. At least on MacOS.

Am I right to assume that keyboard repeat rate is not handled by the Kernal?

How would you set the repeat rate on the real machine? I searched a little for PS/2 keyboard hardware repeat rate, and found that there seems to be commands that you can send to the keyboard to change its default repeat rate setting. Maybe that's the answer.

Edited February 7 by Stefan

[BruceMcF 248]

15 hours ago, Stefan said:

One is the keyboard repeat rate. X16 Edit uses the Kernal keyboard routines, and it's sometimes painfully slow to wait for the cursor to move while you hold down an arrow key. The speed is the same as in the built-in BASIC editor, I would say. Is there anything you could do? If not, I might have to include more cursor movement features, maybe move one word back or forth.

I know that jump to the next word is often done is find the next white space, then find the next non-white space, but I kind of liked the hop I had in my ANS Forth file editor, which looked to see if the current and next positions where both white space. If not, it went to the next white space, while if it was, it went to the last white space in the string of white space (and similar going back looking at the cursor location and the previous location).