JOVE port
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.
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.
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).
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.
Well.. character input does not work, Ctrl+X Ctrl+C does not work... but it opens.
It displays the text ok too:
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.
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.
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.
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.
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.
About alarm() problem in large memory-model using watcom, should I write a simple alarm() code using watcom to check if the problem persists?
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;
}