New productivity upload: X16 Edit - a text editor

Stefan · Post by **Stefan** » Thu Feb 24, 2022 7:59 pm

I did not have a lot of success with Ed's word method.

All words occurring more than once were included in the test, even one-letter words. These words were replaced by a byte code. The blank space preceding a byte code was stripped. The list of words was added to the end of the text block, as this list is needed for decompression. The resulting file was actually somewhat increased in size from 1,818 to 1,895 bytes.

Ignoring one-letter words was a bit better, resulting in a file of 1,650 bytes. But compressing this with lzsa resulted in 1,298 bytes, still not better than just using lzsa.

The effectiveness might rely on the characteristics of the text, especially how often the same words are repeated. Or maybe I'm doing something wrong...

Stefan · Post by **Stefan** » Sat Mar 12, 2022 6:18 pm

I uploaded a new version of X16 Edit today (0.4.4).

It uses lzsa to compress the help text. It is decompressed during program initialization using the built-in Kernal function. Version 0.4.3 was 15,532 bytes, and the new version 0.4.4 is 14,897 bytes, a difference of 635 bytes. There are also some other savings from my ongoing code cleaning. I really want the program not to go over the 16 kB boundary, as this would cause a serious problem for the ROM version.

Apart from that, the new version is mostly bug fixes:

The old code that read a file into the text buffer did not work properly in all circumstances. As discussed in another thread here, the Kernal function OPEN does not return an error even if the file is not found. That error is thrown not until you try to read the first byte. If the file does not exist, bit 2 of READST (read timeout) is set. The old code did work in most cases, but would fail if the file contained just one character.

In the previous version, the ROM based X16 Edit could not read the custom keyboard shortcut config file (X16EDITRC). This was caused by the name of the config file being stored within the executable. The config file name was not available after switching to the Kernal ROM bank when trying to open it. There was a similar problem in the function reading directory listings. The "file name" = "$" was stored within the executable, but was no longer available after switching to the Kernal ROM when opening it. Both these problems were solved by copying the file names to RAM before calling Kernal OPEN.

Stefan · Post by **Stefan** » Mon Mar 28, 2022 4:05 pm

The VERA memory layout used by the Kernal was updated earlier today.

https://github.com/commanderx16/x16-rom/issues/185

The update will break programs writing directly to the VERA screen buffer, such as X16 Edit.

I have committed a fix for this in the X16 Edit Github master branch. It is not yet thoroughly tested, but seems to be working OK.

AndyMt · Post by **AndyMt** » Mon Mar 28, 2022 6:01 pm

On 3/28/2022 at 6:05 PM, Stefan said:

The VERA memory layout used by the Kernal was updated earlier today.

Yes, but that's just the default addresses for the different locations of bitmaps, tilesets, charset, sprite data etc for mode 128. It's always better to read those base addresses from the VERA registers at F9C0 and use those instead of hard-coding screen access. Then software will then adapt automatically, no rewrite needed.

I prefer to define my VERA layout myself anyway, this way my software always knows where all the stuff is located.

desertfish · Post by **desertfish** » Mon Mar 28, 2022 7:07 pm

I'm the pleb that just uses kernal CHROUT to write stuff to the screen ?

Stefan · Post by **Stefan** » Wed Mar 30, 2022 2:42 pm

Version 0.5.0 uploaded to the download page with support for the new official R39 Kernal.

Versions 0.4.0-0.4.5 do not work in the final R39 due to change of VERA memory layout.

Stefan · Post by **Stefan** » Sat Apr 02, 2022 11:53 am

Tested the new fast loader Kernal function ("MACPTR") in X16Edit.

Haven't done any optimization, just getting it to work.

Results (manual timing) opening/reading a file of 169 kB in size:

Old byte by byte reading: 10.8 seconds => 15.6 kB/s

New MACPTR block reading: 2.5 seconds => 67.6 kB/s

Quite significant a difference.

mobluse · Post by **mobluse** » Sat Jun 04, 2022 8:35 pm

If you use this editor for editing in X16 you might be using nano normally to edit BASIC. In that case there is nano syntax coloring etc. in this project: https://github.com/thwill1000/mmb4l/releases (I would use the latest.)

There are install instructions if you unpack the tgz file, but beware not to overwrite your own settings.

Stefan · Post by **Stefan** » Sun Jul 31, 2022 8:03 am

Version 0.5.2 released today. Mostly bug fixes.

The built-in file browser would crash if you pressed a key that had no function in the browser. This bug was observed by @desertfish, and he also helped me with debugging.

The editor will now select screen mode 80x60 on startup. If you compile the editor yourself, it's easy to select another screen mode. Just edit the source file "common.inc" and change the row ".define SCREEN_TEXTMODE 0". This was also request from @desertfish.

Finally, @Wavicle helped me find a bug in the utility function that converts a value in BCD format to a string. The function did not terminate the string with a NULL character as advertised. It still worked in the emulator, as the memory location was initialized to zero anyway. But in would not work on a real machine where you cannot assume that memory is initialized to a specific value. Quite a nasty bug, with the potential of locking up the program completely.

Many thanks to @desertfish and @Wavicle for helping me out with these issues!

Stefan · Post by **Stefan** » Sat Oct 29, 2022 6:07 pm

I've been working on an updated user manual for X16 Edit.

https://github.com/stefan-b-jakobsson/x16-edit/blob/master/docs/newmanual.pdf

As English is not my native language, I just want to reach out asking if someone would like to help me convert it to proper English.