Update sys

[floriangit]

• fix positioning of the "Installing" prompt when providing more than one parameter to this script
• enhance the prompt by adding the version to be installed
• enhance the prompt with a confirmation

[floriangit]

Main issue was that when you call "sys -M /dev/hda1" the script will say "Installing....on -M".

Tested on qemu and my 286, where ELKS on git/main still runs very well! (except frequent floppy disks issues due to wearing).

[ghaerr]

Thanks @floriangit!

[ghaerr]

Also thank you @floriangit for testing ELKS on your real hardware. There were some bigger mods when work was being done reducing the size of the idle task structure and the associated rewrite of the kernel startup. It is nice to hear the system is still running well.

Are you finding that 40+ year old floppies aren't wearing very well? I must admit that even on my real hardware machines, I'm using a floppy emulator...

I hope to get a v0.9 release out soon.

[floriangit]

I do remember few months ago, I git pulled, built a-new image and booted, it hang at some time. But I don't have so much time, just sometimes look what kind of under-the-hood changes you made but not in any detail.

Real floppies and their sounds, real spinning disks, a real "beep" program (remember the author, haha?): all that is what motivates me in this project: to run on real, ancient hardware which specs matches my own "first computer" roughly.

I was about to try nano-x/nxdesktop despite I don't have a connection left for a mouse right now! I see nano-x in the build process is always skipped despite being enabled in the .config (i.e. selected (by default) in make menuconfig). Any quick pointers?

Thanks!

[ghaerr]

You can still try starting up nano-x by running export MOUSE_PORT=none; nxstart to see what it looks like. Unfortunately there are no keyboard shortcuts for mouse operation at the moment.

The entire Nano-X build has been moved out of elkscmd/nano-X/ and is now built directly from the ghaerr/microwindows.git repository. This is because the ELKS nano-x was very ancient and we're now using the full client/server capabilities from the main repo. You can build the ELKS version over there using:

$ cd microwindows/src
$ make -f Makefile.elks clean
$ make -f Makefile.elks
$ ls bin
(copy bin/* executables to ELKS image /bin directory)

Another option would be to use the "automatic" build of microwindows using the new buildext.sh method. This will only copy nano-x for 1440k images and larger:

$ ./buildext.sh microwindows
$ ls extapps/microwindows/src/bin
$ cd image
$ make fd1440-minix

I have been meaning to remove the elkscmd/nano-x directory for some time, but kept it around for reference. I suppose I should remove it to reduce confusion along with CONFIG_APP_NANOX.

[tyama501]

Also ps/2 mouse capability has been added.

[floriangit]

Thanks all, I got nxstart working fine. All pixels shine! :) And I even found an old serial mouse and connected it, but when not doing export MOUSE_PORT=none, nxstart always fails to start for me (I deleted the socket in /tmp/ before attempting). When starting it takes some cycles and then just returns to the shell with a blank screen and the prompt being at the bottom of the screen (so it did something).

[ghaerr]

it takes some cycles and then just returns to the shell with a blank screen and the prompt

Currently, due to complexities within the NX startup code, error messages go to the serial port by default, which may be the mouse in your case. This was primarily done for use with QEMU, where /dev/ttyS0 is easily mapped to the terminal session QEMU was started on, which is very convenient. The particular code to sort through all this is libc/malloc/dprintf.c:

/*
 * Open /dev/console for debug messages. On real hardware, this can
 * be setup using serial console so that the console is /dev/ttyS0,
 * and messages will be seen when Nano-X is running, or use
 * DEBUG_PORT= to specify an alternative device or 'none'.
 *
 * On QEMU, check if /dev/tty1 and /dev/console are the same,
 * and if so open /dev/ttyS0 instead for terminal output assuming
 * QEMU has been run with -serial stdio option which maps /devttyS0 to it.
 */
static int open_debug_terminal(void)
{
    int fd = -1;
    char *debug, *mouse;

    debug = getenv("DEBUG_PORT");
    if (debug) {
        if (!strcmp(debug, "none"))
            return -1;
    } else
        debug = "/dev/ttyS0";       /* preferred console but could be mouse port */

    if (!isatty(STDERR_FILENO))     /* continue piping __dprintf to redirected stderr */
        fd = STDERR_FILENO;
    else {
        mouse = getenv("MOUSE_PORT");
        if (!mouse || strcmp(mouse, debug) != 0)    /* use debug if not used by mouse */
            fd = open(debug, O_NOCTTY | O_WRONLY);
        if (fd < 0)
            fd = open(_PATH_CONSOLE, O_NOCTTY | O_WRONLY);
    }
    return fd;
}

Long story short, you can try setting export MOUSE_PORT=/dev/ttyS1 perhaps (for COM2), or perhaps set DEBUG_PORT to somewhere other than /dev/ttyS0 and have your mouse on /dev/ttyS0. I haven't figured out a totally automatic way to make all this work, unfortunately.

[tyama501]

I think the DEBUG_PORT=none
also can be used.

[floriangit]

I think the DEBUG_PORT=none also can be used.

That was it! DEBUG_PORT to none and MOUSE_PORT to /dev/ttyS0.

Thanks.

[floriangit]

Is it intended, that ALT-F1 and ALT-F2 toggles the position of the "menu" as well as the mouse cursor?

[floriangit]

Sorry for off-topic: starting nxterm and then doing a cd / ; time ls -lR on a 286 is like watching a terminal session video from the 1980s (if not 1970s). It took 3 minutes and 54 seconds and was fun to watch every second! :-)

[ghaerr]

It took 3 minutes and 54 seconds and was fun to watch every second! :-)

I'd like to see a (partial) video of that!

I would guess the speed issue is the large blit moving all those pixels every time the screen scrolls...

Is it intended, that ALT-F1 and ALT-F2 toggles the position of the "menu" as well as the mouse cursor?

I'm not sure what you're referring to, Nano-X doesn't use ALT-keys for itself. Certain emulators may use those keys though?

What did you do to get NX running on your system, MOUSE_PORT= or DEBUG_PORT=? I'm curious so others can learn as well.

[floriangit]

elks.mp4

Here you go.
Main churn seems on the blit part walking left to right (other languages walk the other way, also interesting how computer history is so "western"), also doing that full redraw looks expensive. After the redraw another performance lag can be seen around dirent.h (how ironic!!!) :-) which is not easily heard: it is the HDD crunching there a bit, i.e. I/O activity. It recovered after 3 more lines FWIW.

ALT-F1 and ALT-F2 changes the position of the menu and the mouse cursor with nxstart, sorry for mixing things up.
Using the cursor keys on nxterm crashes the same BTW, with an exit value of 0 (though). I'm using an Italian keyboard, but with default (US) mapping.

[ghaerr]

Thanks for the video! You're actually running the ancient version of nxterm and Nano-X. Not sure exactly how you got that, but the new one is much nicer and actually scrolls rather than repaint from the top. You should be able to get the new one from any of the recent GitHub Actions on the fd1440-minix.img. You'll want to copy nxterm and nano-x, but possibly all of /bin/nx*.

[floriangit]

I see. I just used the 1st proposal in your comment: #2611 (comment)

Copied that to floppies and copied then into my 286's HDD...

[ghaerr]

just used the 1st proposal in your comment

Hmmm... that's strange, that should have built the new version. There is only one version of nxterm on the Microwindows repo now. Here's the binaries I've built for you to try:

nanox.zip

[floriangit]

Thanks, BUT: I've seen all n* binaries got really built by your instructions after building, I'm on git/master (or main whatever) in both projects, hence I doubt any binary ZIP files copy here will solve it long term (or may rather indeed hide an underlying other issue), to be honest.

[ghaerr]

Hi @floriangit,

I agree with your point about nx* binaries - I was just suggesting you try that version of nxterm to ensure it is completely different than the one you've been running. At the very least, please just compare the nxterm filesize, it should be 15,424 bytes.

I'm pretty sure the version of nxterm you are running is the old one from elkscmd/nanox/demos/nxterm.c (very recently the entire ELKS repo nano-X was effectively deleted and moved to elkscmd/unused/nanox/). This old version is not a terminal emulator, but a very crude text display program, while the newer version in https://github.com/ghaerr/microwindows src/demos/nanox/nxterm.c is a full ANSI terminal emulator.

I just used the 1st proposal in your comment:

The first of the above methods will also work - but be sure you're actually cd'ing to the microwindows repo, not the elkscmd/nano-x/ directory.

[tyama501]

Since nano-x server is separated from the client, now the nxterm is much smaller than before.
The window title bar appears even it is executed alone.
The server nano-x should be copied.

[tyama501]

The old nxterm might remained in the elkscmd/root_template.
Now the makefile.elks in the microwindow repo does not copy files to there.
Files are only copied when making hd image.

[floriangit]

I only have 15,424 bytes nxterm files under elks.
Looking at the floppy suddenly I cannot find nxterm, instead the output is garbled in between. Running a fsck on it revealed, I better throw this disk away...
Looking at the 286 HDD, the size of nxterm is 31888 bytes, so it seems this got corrupted when copied from floppy to 286 HDD (There is no file of size 31888 in my elks directory).

Using a different floppy disk, I had success now (no more white background, but grey).
Since this one does never clear the screen (and hence redraws everything once the screen is filled), the results are not much better though. A cd / ; time ls -lR took 3 minutes 25 seconds. ;-)

[ghaerr]

The old nxterm might remained in the elkscmd/root_template.

Thanks @tyama501, that explains the mystery of how the older nxterm might have been placed on a new floppy image.

Since this one does never clear the screen (and hence redraws everything once the screen is filled), the results are not much better though.

Interesting, it sounds like the slowest issue is not scrolling, but just drawing the characters on the EGA/VGA screen. Which makes sense, given the planar rather than framebuffer nature of the video memory.

Have you tried running nxstart instead of nxterm? It would be interesting to see how fast/slow the system is with the other graphical applications.

[floriangit]

Have you tried running nxstart instead of nxterm? It would be interesting to see how fast/slow the system is with the other graphical applications.

Unfortunately, after swapping out all n* binaries to the "new" floppy and copying it over, nxstart does not show the menu anymore! I have no idea, the grey background is there and the (big) white mouse as well (and functional), but the menu is missing... any ideas?

[ghaerr]

How about nxterm, what does that look like? Send a screenshot. Either nxstart is dying or the menu is off the screen to the right?

You can try running other nx programs too to get an idea of what is happening.

[floriangit]

I am not sure, since now nxstart suddenly works. I suspect the /tmp files play a role, since now I tested all these below and made it into a habit to rm /tmp/* in between tests, since sometimes it got stuck there when there seemingly already was a nxsock temp file?

Anyhow, I'd judge performance for my CPU is OKish, most apps are usable with few seconds delays on a 286 (8 or 6 MHz? (I forgot), but TURBO is off to prolong its life) :-)

nxstart: working fine, clean exit when clicking 'Quit'
nxclock: working fine, clean exit when clicking 'X'
nxlandmine: working fine (except that clicking a box does nothing, so unplayable), clean exit when clicking 'X'
nxterm: working fine, clean exit when clicking 'X'
nxdsktop: wow, nice! but when exiting, it goes back to the console, but hangs there (cursor position is top-left, prompt position is bottom-left)
nxcalc: blitting is slow, clicking any button results in 3 seconds total due to redrawing each button
nxworld: comes back doing nothing, fails with exit code 1
nxjpeg: comes back doing nothing, fails with exit code 1 (missing error msg when not provided a file), with a jpg as argument, it does start nano-x, however comes back to the console and exit code is 141
nxmsg: comes back doing nothing (but takes a while for the same), fails with exit code 1
nxtetris: working fine, clean exit when clicking 'X'
nxmine: works, but when exiting, it goes back to the console, but hangs there (cursor position is top-left, prompt position is bottom-left)
nxselect: comes back doing nothing (but takes a while for the same), fails with exit code 1

Some photos, see also inline comments!

Normal view, but I can toggle a display shift using ALT-F1 (back to normal) and ALT-F2 (everything shifted?)

Shifted view



Shifted!

[ghaerr]

Hello @floriangit,

Thanks for all the screenshots and testing! I'll add fixing nxworld and nominee to my TODO list. I appreciate the testing.

The nxmsg, nxselect, and nxjpeg programs are all sub-programs of @toncho11's nxdsktop project, and aren't meant to be run separately. I'm not sure why it may be hanging on exit.

I suspect the /tmp files play a role, since now I tested all these below and made it into a habit to rm /tmp/* in between tests, since sometimes it got stuck there when there seemingly already was a nxsock temp file?

Yes, the auto-start mechanism for the nano-X applications uses /tmp/nxsock to determine whether they think the server is running. There's no real easy answer for this when the system crashes, other than perhaps removing /tmp/nxsock at boot. We could also have nxstart delete the /tmp/nxsock file, which would probably help.

I can toggle a display shift using ALT-F1 (back to normal) and ALT-F2 (everything shifted?)

I see what you're talking about now. It appears the ALT-F1/ALT-F2 combination is a special key combination handled by your BIOS to pan or wrap the screen horizontally? Nano-X itself doesn't have anything to do with that. I am trying to figure out exactly how this could work when ELKS itself has taken over the keyboard interrupt. Nonetheless, I think this behavior is specific to your system/video card.

on a 286 (8 or 6 MHz? (I forgot), but TURBO is off to prolong its life) :-)

Huh? TURBO mode can overheat your CPU and cause its early demise?? I wasn't aware of that problem, but could be a problem getting a replacement CPU these days, right?!

Thank you!