elks icon indicating copy to clipboard operation
elks copied to clipboard

JOVE port

Open rafael2k opened this issue 9 months ago • 13 comments

I started to port Jove, as it matches our requirements for using swap, while being a pretty feature complete editor, and more importantly, an emacs clone.

https://github.com/rafael2k/jove

I already manage to compile it, already set the internal buffers appropriately, just missing are the screen functions, as I'm trying to understand the madless of termio, termios and ioctl to terminal device. I'll try to re-use the curses code again.

rafael2k avatar Mar 20 '25 08:03 rafael2k

What would be nice will be to have a shortcut that executes the Makefile using the new toochain in the folder where the file is open. But then we also need some way to present the result of the compilation.

toncho11 avatar Mar 20 '25 08:03 toncho11

Image

rafael2k avatar Mar 20 '25 09:03 rafael2k

What would be nice will be to have a shortcut that executes the Makefile using the new toochain in the folder where the file is open. But then we also need some way to present the result of the compilation.

One could just switch to another tty. The problem is memory in this case, as C86 needs as much memory as it is available. One idea could be to just exit jove (and at exit it calls make), and then call it again after "make" finished using something like jove -r (jove has a restore feature I'm still understanding how it works), be it manually or tru a jovelized make (which just calls jove -r after finish).

rafael2k avatar Mar 20 '25 09:03 rafael2k

Some nice stuff from Makefile.wat, for DOS:

# -ms (small mode) cannot be used (Jove is about 15K over the 64K code limit,
# even with -DBAREBONES, and OPTFLAGS="-os -s")
# -mm (medium mode) builds with very few I/O buffers, and 512-byte max line
# length. Might run out of tmp file space or heap memory if editing many
# files.
# -ml (large mode) is recommended, has more buffers (so should be faster
# for normal use), 2K max line length, takes advantage of all heap memory
# so can keep a very large number of files open.
# 640K ought to be enough for anyone!
MODEL = -ml
OPTFLAGS = -os	# optimize for size over speed
CFLAGS = $(MODEL) $(OPTFLAGS) -wx -zq -zt200 -dOWCDOS=1

Notice the "-zt200". I´m trying not to use "-zt", but the the data segment is in the limit.

rafael2k avatar Mar 20 '25 09:03 rafael2k

Well.. character input does not work, Ctrl+X Ctrl+C does not work... but it opens.

Image

rafael2k avatar Mar 20 '25 10:03 rafael2k

It displays the text ok too:

Image

rafael2k avatar Mar 20 '25 10:03 rafael2k

After some time running I get "Alarm call", and software quits. Weird. Jove does indeed uses alarm() for some stuff, but it can be disabled too.

rafael2k avatar Mar 20 '25 10:03 rafael2k

What is important is to not to redraw the entire screen on every change while editing. I have seen such editors before and they are unusable on a 8 or 4.77Mhz computers.

toncho11 avatar Mar 20 '25 11:03 toncho11

character input does not work, Ctrl+X Ctrl+C does not work... but it opens.

This is sometimes because the application tries to open a separate file descriptor for the terminal, like /dev/tty instead of /dev/tty1. You may also try skipping the open and just using fd 0.

I'm trying to understand the madless of termio, termios and ioctl

Use termios; that should be compatible and not require mods.

After some time running I get "Alarm call", and software quits

alarm() should also work. We can debug that after you get the keyboard working. You might check why its calling alarm in the first place, this is usually wrapped around functions that shouldn't block for too long.

ghaerr avatar Mar 20 '25 15:03 ghaerr

Thanks @ghaerr. I'll check the code and try to evolve the input I/O. Also, the swapfile routines for very large input files is failing in some read and write calls. I still need to investigate.

rafael2k avatar Mar 21 '25 08:03 rafael2k

the swapfile routines for very large input files is failing in some read and write calls.

ELKS doesn't really work with read or write counts >= 32k, even thought the count is size_t (unsigned). You may have to wrap the read/write code into a loop to limit that. I recommend a buffer of 4K or so to keep data sizes down and I/O frequency up.

ghaerr avatar Mar 21 '25 16:03 ghaerr

About alarm() problem in large memory-model using watcom, should I write a simple alarm() code using watcom to check if the problem persists?

rafael2k avatar Apr 08 '25 08:04 rafael2k

About alarm() problem in large memory-model using watcom, should I write a simple alarm() code using watcom to check if the problem persists?

Yes, please. What exactly is not working, and does it work in other models?

I suspect the problem might be in the SIGALRM callback not working. I used something like the following to test and debug signals for C86, you might try a variation of this on OWC for both SIGINT and SIGALRM:

#include <signal.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>

void catch(int sig)
{
    printf("GOT %d\n", sig);
    signal(SIGINT, catch);
}

int main(int ac, char **av)
{
    sighandler_t rv = signal(SIGINT, catch);
    printf("ret %x errno %d\n", rv, errno);

    for (;;)
        sleep(1);
    return 0;
}

ghaerr avatar Apr 08 '25 16:04 ghaerr