Desktop app (X server + Window manager)

[toncho11]

I looked into https://github.com/ghaerr/elks/blob/master/elkscmd/nano-X/demos/nterm.c
Is it possible to have a simple "desktop" on ELKS where we start X server with a Window manager and a few icons to click on. The icons will be some simple applications. It will be cool even if it will require 286 or 386 to be fast enough. The idea is to have a single executable for that "Dekstop".

I was inspired by:

What are you thoughts @ghaerr ?

[toncho11]

It is like xterm application, but instead of showing a terminal, 2 icons are visualized - one for xterm and one for nxtetris. Once an icon is clicked the app should appear in a window that can be resized, minimized or closed.

[toncho11]

And the NX server and "UNIX/Nano-X sockets" are very different from the standard X11 ones?

I suppose it will be very difficult to port this Window Manager to run on NX server:
https://github.com/jcs/progman

It just looks cool and it will be fun (and impressive) to see it run on ELKS.

[Oichkatzelesfrettschen]

If one has an ISA graphics card like the ATI Mach32 or Mach64 and the "Rage Pro and Derivatives Handbook" could there be reasonable 2D framebuffer acceleration with an appropriate VESA driver? (If I'm talking nonsense I'm sorry I'm just trying to brainstorm)

• Xfree86 has a driver that will work with all cards except the earliest Mach8 and Mach32. So I suppose it's possible to get those going.

But anyway, I digress. Could this driver (or the relevant portions for the specific compatible graphics cards) be ported to 16-bit and For microwindows X support?

I've found some technical docs while digging deep into these, but without knowing what I'm doing, it's useless to me. But I'm feeling like I should link everything here about these cards. Just in case. Is that OK?

But at least for a proof-of-concept it would be super neat to get a 4MB ISA Mach64 or a 2MB Mach32 performing a fully hardware-accelerated 2D WindowMaker desktop environment for example with an 8086 and an 80286 setup. Dual-booting Windows 3.1 on the 286 with 287 FPU? Epic.

Other GPUs? Quite a few seem to have Xfree86/Xorg drivers that could be ported by the appropriate individual for the task.

Would also need an active tester or two...

[ghaerr]

Hello @Oichkatzelesfrettschen,

But I'm feeling like I should link everything here about these cards. Just in case. Is that OK?

Sure, thank you for your thoughts!

Could this driver (or the relevant portions for the specific compatible graphics cards) be ported to 16-bit and For microwindows X support?

it would be super neat to get a 4MB ISA Mach64 or a 2MB Mach32 performing a fully hardware-accelerated

In general, there are two huge problems with getting a framebuffer-style driver running on a 16-bit only system: the first is that the driver code, even using far pointers, is still limited to accessing a mere 64k of bitmap/display data at a time, so most low-level draw code will need refactoring. I'm not actually aware of a single framebuffer-based video card that can run on less than a 386 (or 286 in protected mode) system. The other problem is that the 8086 systems are super slow when it comes to moving data around. So even if a GPU is processing stuff (other than triangles), just getting the data to/from the GPU isn't fast enough.

Here's a recent comment about how slow even an ASCII-based graphical mandelbrot generator is on an 8088.

I'd be interested to hear about any high-res graphics card that works on an ISA or similar memory bus or early IBM PC.

[Randrianasulu]

this thread on vogons contains some benchmarks for fast 286 + isa accelerators in windows:

https://www.vogons.org/viewtopic.php?f=46&t=77885&hilit=mach8+286&start=40

according to this link XGA and earlier 8514/A has isa variants (not by IBM) and XGA manual mentions real-mode 64 kb window for single-card real-mode operation:

https://www.os2museum.com/wp/the-8514a-graphics-accelerator/

https://www.os2museum.com/wp/the-xga-graphics-chip/

"Unlike the 8514/A, the entire XGA framebuffer could be directly accessed by the host CPU. There were three options: a 4MB aperture could be mapped anywhere in the 4GB address space, ideal for 32-bit operating systems and any number of XGAs; a 1MB aperture could be mapped below 16MB for 16-bit protected-mode operating systems; and a 64KB window was optionally available for a single XGA at the VGA A000h or B000h segment (real-mode accessible)."

I think I saw quite a lot of activity in 86box git for those cards (and I ran some OS/2 1.2 for 286 specifically with XGA 1024786256 once - not much to do while in there ...)

[Randrianasulu]

and here is demo of Windows 3.0 on upgraded Tandy 1000 SL machine, showing (slow) 1024768256c graphics:

https://forum.vcfed.org/index.php?threads/windows-3-0-on-the-tandy-1000-sl.56172/

[tyama501]

Hello @ghaerr

Nano-X window manager from the newer Microwindows source, and port that to ELKS, along with using "UNIX/Nano-X sockets", which are coded in the kernel but untested.

Is there a chance we can port the Nano-X window manager you mentioned before?
I may try it before the memorial ELKS 1.0.0 near future if there is a chance :)

[ghaerr]

Hello @tyama501,

It should be pretty straightforward to port the Nano-X window manager from later sources, as it is written using the "Gr" Nano-X API. It was initially written as a separate program but since has been added into the Nano-X server code; the same could be done for ELKS.

Of course, having a window manager but no support for separate processes doesn't do much - so having UNIX/Nano-X sockets would be good to port too. I can't recall if we ever tested Nano-X socket support in ELKS, but that also should be fairly straightforward.

I can help you with both when you want to get more involved. It may be easier to start with porting the Nano-X WM first, or even combined with a particular application program and all linked with the server.

While this all sounds fun, there are very big issues with trying to build a window-based graphical environment on ELKS - it will likely be very slow on all but faster 386 machines, due to the EGA and VGA hardware requiring lots of bit fiddling for display. Also, sending the draw commands through a UNIX socket will be very much slower than linked with server, especially on non-386 machines. The Nano-X EGA/VGA driver isn't really built for speed, and may need to be rewritten in ASM language, much like Doom did. A typical is that a basic window display looks good, but when dragging a window to a new location, or scrolling text, the display is very slow.

Thank you!

[toncho11]

=

After this is done, we should be able to proceed with getting the original issue working - creating a small graphical desktop with a terminal application and a few other graphics applications running on ELKS.

Awesome job both of you! Having this dekstop app will be impressive on my Amstrad for example!

[tyama501]

I could build nxclock, nxlandmine, nxterm, nxworld without modification.
It looks only missing function is GrGetNextEventTimeout in nxtetris.

demos/ntetris.o:function run_game: error: undefined reference to 'GrGetNextEventTimeout'

I will see if I can add this.

Thanks.

[tyama501]

I confirmed nxclock, nxlandmine, nxterm, nxworld are working on qemu with minixfs.

[tyama501]

It seems only the difference of the GrGetNextEvent and the GrGetNextEventTimeout in the stubs.c is that the GsCheckNextEvent is called with fixed GR_TIMEOUT_BLOCK or the argument timeout.

int GrGetNextEvent(GR_EVENT *ep)
{
GsCheckNextEvent(ep, GR_TIMEOUT_BLOCK);
return 0;
}

int GrGetNextEventTimeout(GR_EVENT *ep, GR_TIMEOUT timeout)
{
GsCheckNextEvent(ep, timeout);
return 0;
}

serv.h
#define GrNumGetNextEvent 22
#define GrNumCheckNextEvent 23
#define GrNumPeekEvent 24
...
#define GrNumMoveCursor 45
#define GrTotalNumCalls 46

We can add GrNumCheckNextEventTimeout at the end of the number list or insert it after the GrNumCheckNextEvent and shift the numbers. Is it ok to add at the end? I assume GrTotalNumCalls will be 47.

srvnet.c
GrNumCheckNextEventTimeout should also be added in GrFunctions[].
It seems Gs*Wrapper is called so GsGetNextEventTimeoutWrapper need to be added,
but here is another question.

Current existing
GsGetNextEventWrapper already calls GsCheckNextEvent with GR_TIMEOUT_POLL instead of GR_TIMEOUT_BLOCK.
(Because I have modified before)

Do we need the GsGetNextEventTimeoutWrapper?
If we need it, how can I get the timeout value? (Can we add argument in the Wrapper function?)

void GsGetNextEventWrapper(void)
{
GR_EVENT evt;

    // Temporary
    //GR_TIMEOUT timeout = GR_TIMEOUT_BLOCK;
    GR_TIMEOUT timeout = GR_TIMEOUT_POLL;

    /* first check if any event ready*/
    //GsCheckNextEvent(&evt);
    GsCheckNextEvent(&evt, timeout);
    if(evt.type == GR_EVENT_TYPE_NONE) {
            /* tell main loop to call Finish routine on event*/
            curclient->waiting_for_event = TRUE;
            return;
    }

    GsPutCh(current_fd, GrRetDataFollows);

    GsWrite(current_fd, (void *) &evt, sizeof(evt));

}

Thank you.

[tyama501]

In nxtetris the timout is timeout_delay(state) so it is not BLOCK or POLL.
GrGetNextEventTimeout(&state->event, timeout_delay(state));

[toncho11]

Maybe if GEM could be ported to Elks?
There is some open source version here: https://github.com/shanecoughlan/OpenGEM/tree/master/source
Not sure everything is there though.
And another one: https://sourceforge.net/projects/opengem/

[tyama501]

Thanks @toncho11 but it seems that is SDK. Also I don't think there is PC-98 graphic driver.

[ghaerr]

I could build nxclock, nxlandmine, nxterm, nxworld without modification.

Are these all running? Can they run concurrently? That would be fantastic and a great test of UNIX sockets on ELKS! :)

We can add GrNumCheckNextEventTimeout at the end of the number list or insert it after the GrNumCheckNextEvent and shift the numbers. Is it ok to add at the end?

Yes, it is OK to add at the end. You might want to check the main Microwindows repo for GrGetNextEventTimeout in both client.c and srvnet.c, just to see how it might be implemented. It could be easy as you suggested, or complications so better to look first at the working version over there. Of course, the difference between the functions is that the GrGetNextEvent function will never return until it gets an event, whereas GrGetNextEventTimeout allows for a faked-up timeout event to be returned (which allows nxtetris to continue to move blocks while waiting for the user input). IIRC the faked out timeout is prepared in the main GsSelect() function, so you might want to look there also. I am not looking at the sources, so it depends on whether the non-client/server GrGetNextEventTimeout function is already working (which I would guess it is, since nxtetris works, right?)

In nxtetris the timout is timeout_delay(state) so it is not BLOCK or POLL.
GrGetNextEventTimeout(&state->event, timeout_delay(state));

The timeout parameter to GrGetNextEventTimeout is an 'int', which is either BLOCK (wait forever), POLL (don't wait for any event, but return one if present else timeout), or the number of msecs to wait. So all timeout_delay() is doing is calling a function to determine the timeout, which essentially determines how fast nxtetris runs (per level, faster=harder).

If we need it, how can I get the timeout value? (Can we add argument in the Wrapper function?)

Yes, the passed timeout value will have to be added to the wrapper function and passed along in the packet traveling between the UNIX sockets. Take a close look and you can determine whether a single function can always be used, which either passes BLOCK, POLL or timeout as the "timeout" value, or whether a separate function is needed. I would think a single function should work.

[tyama501]

Thank you.
I will check that later.
( and maybe I will make a first PR )

[ghaerr]

Another possible way to debug the new GrGetNextEventTimeout routine would be to call a routine that writes to the serial port when the client or server has an error returning -1. In this way, you can see whether errors on client.c lines 415, 418 or srvnet.c lines 470 are occurring.

It is also likely that srvnet.c lines 475-478 should be deleted and replaced with a faked-up GR_TIMEOUT result and returned instead of returning to the main loop like GrGetNextEvent does. This is because when there is a timeout, the client needs to continue, not wait like it does for GrGetNextEvent.

In order to write to the debug to the serial port easily, you can either configure for serial console, or run "console /dev/tty2" or something like that which sets the console to other than the /dev/tty1 which /bin/nano-X is running on. Then, using __dprintf you can debug printf to /dev/console, where it will be automatically redirected. This function is in malloc.h. You won't be able to see debug output until you exit nano-X and switch consoles, unless PC-98 supports serial port under emulation, which is much easier.

Thank you!

[tyama501]

Actually I am not using PC-98 since current unix socket does not work on FAT.
I am using ibm elks with mininxfs on qemu.

Usual printf to the text vram can be used if PC-98 can be used.

I have tried using GrGetNextEvent instead of GrGetNextEventTimeout on the tetris.
I think d/f/j/k/sp are working and the blocks only moves when these are occurred as you mentioned.

nxtetris_2025-02-02_22-03-45.mp4

I haven't removed 475-478 yet
but I will make a first PR before further debugging.

Thank you.

[tyama501]

#2213

[ghaerr]

All the above issues should be fixed with #2215.

[ghaerr]

Full Nano-X is now running on ELKS!

After spending all Sunday getting our 25-year-old Nano-X on ELKS barely running in client/server mode with 1-2 applications, I started looking into what became an even bigger problem of how to back-integrate the current Microwindows repo's Nano-X window manager into our tiny version of Nano-X. And that turned out to have major issues.

Long story short, after spending at least a full day trying to hack that in along with our version not having lots of required server features needed for it, I started looking into the idea of getting the current Microwindows repo (32/64-bit only) back running in 16-bits for ELKS.

That proved a deep rabbit hole, but after another full day working on it, we now have the current Microwindows/Nano-X running on ELKS, running in client/server with multiple clients! Writing the speedy C86 VGA ASM routine and speeding up our Nano-X was a good starter task because the full version definitely needs it!

Here's a sneak preview:

Nano-X.on.ELKS.mov

As you can see, doing full window moves is very slow even on an emulator - this will likely be unusable on real hardware. There's another option that XORs a fuzzy rectangle around the window like Windows 2.0 did, but that's just not very sexy for all the work getting this working. Another seemingly simple problem, trying to get a window manager to look modern when running in only 16 colors is an ongoing issue. The current window/desktop colors were quickly hacked from the 24-bit color version.

I'm still considering exactly what the best path forward is, but ultimately even though there's a ton more overhead in the new Nano-X for the time being, there's been another decade of work put into it. So I'm thinking of possible internal strip-downs and some redesigns that will make it a lot smaller and faster (74k right now for server and 18-20k for each client). Those with a keen eye will still see paint errors on window moves above, but I think we're better off running the modern version if we're trying to get a usable desktop. It's currently being built out of the Microwindows repo, and I haven't committed any changes there yet.

This version should be fully compatible with PC-98, but we may need some small screen driver adjustments.

[jhhoward]

I guess it depends on what you are trying to use your windowing system for, but 640x200 monochrome could still work well for some applications. Windows 3.0 and Geoworks spring to mind. The Apple IIgs desktop ran in 640x200 with colour so that is a good reference if aiming to support the EGA 640x200 16 colour mode.

I would say that the biggest pain point for those resolutions is the aspect ratio as the 'tall' pixels require you to use a different font / icons if displaying on a 4:3 monitor. However, there are a number of portable devices that use a wide LCD display with CGA modes so use square pixels. E.g. the HP 200LX and some Toshiba laptops.

A while ago I was developing a classic Mac style desktop interface for DOS that looked like this:

I ended up abandoning the project as I went down a bit of a rabbit hole creating a multitasking kernel to sit on top of DOS. Maybe I could think of reviving some of it for ELKS instead 😀

And just for fun, here is a desktop environment I made for the Arduboy that runs in 128x64 monochrome 😁

[toncho11]

Looks beautiful! A long term project of porting it to ELKS sounds good :). Now you have a multi-tasking kernel and the vga routines can be reused. And there is an example code in MicroWindows and even a native VGA small library that compiles inside ELKS with the new native toolchain for ELKS. So there is a support for a project like that :) (besides OWC C)

[ghaerr]

A while ago I was developing a classic Mac style desktop interface for DOS that looked like this:

Wow, very cool!! I love the look of the original Classic Mac and your rendition looks really nice. And good points about requiring a font change because of the physical pixel size on the monitors. I can see now that's what I need to do for lower-res Nano-X to look better. In fact, the entire window frame design needs to change too for monochrome and/or lower res uses. The good news is the window frame drawing and hot spot management is separated nicely for such a change, should it be desired.

And just for fun, here is a desktop environment I made for the Arduboy

Wow again, scrolling text with clipping, impressive! I can see you've put a lot of work into this. Are these projects published, I'd like to take a deeper look into them :) If you're interested in reviving your "graphical FreeDOS" implementation for Nano-X and ELKS, let me know how I can help. Did you use your own API for drawing, or start from Mac's QuickDraw, or something else?

[jhhoward]

The Arduboy desktop program was part of a game jam (themed 'not a game') so it was thrown together quite quickly but the source is uploaded here if you're interested. I haven't published the source for my DOS desktop environment as I didn't get too far with it. I reused some of the drawing functions from MicroWeb and then built a windowing system around that.

[toncho11]

So which one will be better for ELKS - converting an Arduino C code to gcc x86 from Arduboy or your unpublished code with window manager for x86?

[toncho11]

You can try the new desktop based on nano-X here with this ELKS HDD image: nano_x.zip

./nano-X & ./nxpanel

So impressive work has been done in terms of porting to ELKS and optimizations for older computers.