Text editor

[Stefan]

I've been working on a simple text editor for some time, and uploaded it to Github today.

The editor is heavily inspired by GNU Nano, but not intended to have all its functions. It's just too much work in 65c02 assembly, at least for me ?

At this moment basic editing works more or less, and the program is fairly stable.

Text entered by the user is stored in banked RAM.

File handling waits until the emulator supports reading and writing sequential files.

Check it out on github

https://github.com/stefan-b-jakobsson/x16-edit

I also include the binary for my 0.0.1 release. It's tested in emulator version r37.


x16edit-0.0.1.prg

[Stefan]

A couple of things I've been thinking about.

• 
  How can you reliably determine if the CTRL key is pressed? For now the I'm reading the keyboard with the KERNAL routine GETIN. It mostly works fine, but there are some overlaps. For instance, CTRL+s is the same as HOME.
  


• 
  Is there any way to determine the current character mode (PETSCII OR ISO)?
  


• 
  And, is it somehow possible to get the screen width (in columns)?
  

[Stefan]

Here is a small demo showing what the 0.0.1 version is capable of.

[SlithyMatt]

7 hours ago, Stefan said:

A couple of things I've been thinking about.

• 
  How can you reliably determine if the CTRL key is pressed? For now the I'm reading the keyboard with the KERNAL routine GETIN. It mostly works fine, but there are some overlaps. For instance, CTRL+s is the same as HOME.
  


• 
  Is there any way to determine the current character mode (PETSCII OR ISO)?
  


• 
  And, is it somehow possible to get the screen width (in columns)?
  

If you don't have anything plugged into the joystick 1 port, you can use the joystick driver to look for the A button, which will map to Ctrl.

If you inspect VRAM, you should be able to check the character map, looking for one of the characters that are different.

That's a simple VERA setting. DC_HSCALE is 128 for 80 column mode, and 64 for 40 column

[rje]

This is very clever, thanks!   Hmmm and it might be useful for creating banked data....

Would it make sense to use the function keys in addition to control-keys?   Do you always save starting at bank 1, or is the page command used to flip through banks?

[Stefan]

@SlithyMatt Thank you for your tips. I will try them out.

@rje Good idea to use function keys as alternatives.

The program uses all of banked RAM, for now starting at bank 1 page $a0. Bank 0 may be used by the KERNAL if I understand the Programmer's Reference Guide correctly (emulator r37).

Text entered by the user is, however, not organized as one continuous string. Instead each memory page is dealt with as a separate string. The memory pages are dynamically linked to each other. To make this possible each memory page also contains some metadata. Consequently, the program isn't suitable for directly creating raw data in banked RAM. For clarity, when I'm talking about memory pages, I mean for instance the address interval $a000-$a0ff or $bf00-$bfff, i.e. 256 bytes.

I chose this memory model in order to be able to handle large texts. Otherwise you could end up in a situation where the text is 1 MB and the user inserts new text at the top. If the text was stored as a continuous string, such an operation would demand that the program copies/moves 1 MB of data one step forward in the memory before inserting the new text. I think that would be too slow.

Every memory page used by the program contains the following fields:

Offset   Content

00          Previous memory page / Bank number

01          Previous memory page / AddressH

02          Next memory page / Bank number

03          Next memory page / AddressH

04          Length of text stored in this memory page (0-251)

05-ff      Text data (max 251 bytes)

It is a bit hard to describe the memory model in a short and easy way. You may run the program and hit restore. Inspect the memory usage with the built-in monitor.

In the monitor you need to type the letter O01 to select RAM bank 1.

The aim of the program is to store pure text files in the filesystem. It would be quite easy to write a tool that loads data from a file into banked RAM in the way I think you would like to do.

[rje]

I think I understand.  You’ve implemented a doubly-linked list of dynamic strings.  Instead of “pure” memory addressing, you use bank number.

Do you need an extra byte for address low?  Ah maybe you assume 256 byte blocks so that you have an easier time with managing the memory!   On overflow, you allocate and insert a new block.  Got it!

You’re using a linked list, not unlike Commodore disk blocks... which are also 256 bytes.  With them, the first two bytes form the pointer to the next block, so they’re only singly-linked, whereas yours are doubly linked.  The final block in a disk file holds the final block’s character count and a zero.  Your design is more flexible, in that each “block” (your “page”) is essentially a dynamic string with its own length.

 

Hmmm, your addressing is like a virtual “diskette image” of up to 256 “tracks” of 32 “blocks”... with track zero off limits, used as end of file or similar...     or if you looked at it sideways, 32 tracks of 256 blocks...

[Stefan]

You got it! And was able to describe it more clearly than me I think.

Actually the 1541 disk format was my initial inspiration.

[Main Administrator]

Oh, I love this project! A good text editor is a fantastic addition!

[Perifractic]

Great work @Stefan and don't forget you can upload even alpha versions to our software library too.