New productivity upload: X16 Edit - a text editor

Stefan · Post by **Stefan** » Sat Apr 10, 2021 10:18 am

I've now made a pull request to include support in the emulator for Delete, Insert, End, PgUp and PgDn keys.

I've also updated X16 Edit to support those keys. This code works only if run in the current master branch of the emulator and Kernal, i.e. what will become R39.

mobluse · Post by **mobluse** » Wed Apr 21, 2021 5:09 pm

I use GNU Nano as my main editor in Linux and I noticed a disadvantage of Ctrl+U (Uncut) in X16 Edit: Ctrl+U can only paste once in X16 Edit, but several times in Nano. I hope this will change because I often use Ctrl+U several times in Nano and would like to do so in X16 Edit. I believe there is no advantage of emptying the cut-buffer after the first uncut/paste.

Stefan · Post by **Stefan** » Wed Apr 21, 2021 7:10 pm

1 hour ago, mobluse said:

I use GNU Nano as my main editor in Linux and I noticed a disadvantage of Ctrl+U (Uncut) in X16 Edit: Ctrl+U can only paste once in X16 Edit, but several times in Nano. I hope this will change because I often use Ctrl+U several times in Nano and would like to do so in X16 Edit. I believe there is no advantage of emptying the cut-buffer after the first uncut/paste.

I see what you mean.

GNU Nano empties the cut-buffer if you uncut and then cut/copy. But as you say, it's possible to do repeated uncuts.

I will look at this issue in the upcoming release for R39. Thank you for bringing this to my attention.

Stefan · Post by **Stefan** » Thu Apr 22, 2021 4:48 am

11 hours ago, mobluse said:

I use GNU Nano as my main editor in Linux and I noticed a disadvantage of Ctrl+U (Uncut) in X16 Edit: Ctrl+U can only paste once in X16 Edit, but several times in Nano. I hope this will change because I often use Ctrl+U several times in Nano and would like to do so in X16 Edit. I believe there is no advantage of emptying the cut-buffer after the first uncut/paste.

This issue is now fixed and pushed to the Github repository, branch "prepare-for-R39". This development branch of X16 Edit works with the current master branch of the emulator and Kernal, what will become R39.

Stefan · Post by **Stefan** » Fri Sep 17, 2021 6:30 pm

I've uploaded a new version of X16 Edit (0.4.0) incorporating some improvements of the program I've been working on during the summer and this autumn. It's nothing major, mostly fixing small things in the user interface not working perfectly

Stefan · Post by **Stefan** » Sat Sep 25, 2021 8:36 am

I found a bug (sort of) in the routine that writes the text buffer to disk. It wasn't critical, but at least annoying. Maybe my findings are of some general interest, so here is a short description.

X16 Edit uses the standard Kernal routines to write to disk, i.e.

SETNAM + SETLFS + OPEN to open a file

CHKOUT to set the file as standard output

CHROUT to write actual data to the file

The information on CHROUT error handling is a bit hard to grasp, at least for me. The entries in the compilation of books and manuals here https://www.pagetable.com/c64ref/kernal/ have somewhat divergent information on this topic.

This is what I believe to be true after calling CHROUT:

Carry bit set indicates that a Kernal I/O error has occurred, in this context most likely 5=Device not present. The error number is in the A register.

After each call to CHROUT you need to call READST to know if a disk side error occurred, such as a file exists error. An error occurred if READST is not 0.

To get the actual disk side error, you need to open a file to the command channel (like OPEN 15,8,15 in BASIC) and read the message

X16 Edit did previously write the whole buffer to disk without checking READST. Only then it would check the command channel status. It worked anyway, because the disk seems to ignore data sent after an error condition has occurred (such as file exists). But is wasn't beautiful.

I have also been working on a progress indicator that is shown when loading or saving files. This is useful when handling large files, so that you know the computer has not just locked up.

These changes are committed to the GitHub master branch.

I think my next task is a new code cleaning project focused on minimizing code size. The ROM version of X16 Edit is now only about 75 bytes from filling 16 kB, the size of one ROM bank. It would be nice to have some more leeway than that for future additions.

BruceMcF · Post by **BruceMcF** » Sat Sep 25, 2021 12:37 pm

4 hours ago, Stefan said:

I found a bug (sort of) in the routine that writes the text buffer to disk. It wasn't critical, but at least annoying. Maybe my findings are of some general interest, so here is a short description.

X16 Edit uses the standard Kernal routines to write to disk, i.e.

SETNAM + SETLFS + OPEN to open a file

CHKOUT to set the file as standard output

CHROUT to write actual data to the file

The information on CHROUT error handling is a bit hard to grasp, at least for me. The entries in the compilation of books and manuals here https://www.pagetable.com/c64ref/kernal/ have somewhat divergent information on this topic.

This is what I believe to be true after calling CHROUT:

Carry bit set indicates that a Kernal I/O error has occurred, in this context most likely 5=Device not present. The error number is in the A register.

After each call to CHROUT you need to call READST to know if a disk side error occurred, such as a file exists error. An error occurred if READST is not 0.

To get the actual disk side error, you need to open a file to the command channel (like OPEN 15,8,15 in BASIC) and read the message

X16 Edit did previously write the whole buffer to disk without checking READST. Only then it would check the command channel status. It worked anyway, because the disk seems to ignore data sent after an error condition has occurred (such as file exists). But is wasn't beautiful.

...

IIRC, calling READST after writing a whole string was a common{*} practice, so it would seem likely that the Commodore devices handled multiple CHROUT calls with the disk side in an error status exactly as you noted, by disregarding the additional characters and continuing to return the same error status.

{* Indeed, if "PRINT#8 NA$" in Basic worked that way, it could even be said to be a standard practice.}

Stefan · Post by **Stefan** » Sun Sep 26, 2021 7:39 am

@BruceMcF, yes I guess you could gain some performance by not checking READST every time you call CHROUT if you can trust that no harm comes from writing to the "disk" after an error condition. In X16 Edit I could try checking READST every time the program needs to change the memory page it's reading from (i.e. about every 250 bytes).

BruceMcF · Post by **BruceMcF** » Sun Sep 26, 2021 12:43 pm

On 9/26/2021 at 3:39 AM, Stefan said:

@BruceMcF, yes I guess you could gain some performance by not checking READST every time you call CHROUT if you can trust that no harm comes from writing to the "disk" after an error condition. In X16 Edit I could try checking READST every time the program needs to change the memory page it's reading from (i.e. about every 250 bytes).

Yes, a binary page of 256 bytes is a good middle point between every character and the whole buffer ... especially given that the size of buffers possible in the X16 is much larger than was possible in the Vic20/C64.

Stefan · Post by **Stefan** » Fri Oct 01, 2021 5:26 am

I've done some code cleaning the last couple of days. Very rewarding when the code becomes more compact, more readable, and more stringent. So far I've reduced the binary by almost 200 bytes.

Some time ago, I watched a few lectures on Clean Code by "Uncle Bob". Very inspiring, even though not all paradigms may be used in assembly, if you want things to fly fast.

A nice weekend to all of you!