Replies: 16 comments 121 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @ghaerr
Is there a chance we can port the Nano-X window manager you mentioned before? |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
Maybe if GEM could be ported to Elks? |
Beta Was this translation helpful? Give feedback.
-
Are these all running? Can they run concurrently? That would be fantastic and a great test of UNIX sockets on ELKS! :)
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?)
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).
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. |
Beta Was this translation helpful? Give feedback.
-
|
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.movAs 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. |
Beta Was this translation helpful? Give feedback.
-
|
You can try the new desktop based on nano-X here with this ELKS HDD image: nano_x.zip
So impressive work has been done in terms of porting to ELKS and optimizations for older computers. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @ghaerr I have noticed running meminfo on the latest nxterm in the microwindow repository draw inerasable garbage on the screen instead of scrolling. Is this one of the known limitation for the nxterm? Screencast_from_2025-08-31_00-52-43.mp4Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
The displayed color differences between IBM PC and PC-98 Nano-X can be resolved by Nano-X converting the application colors using a different palette, before sending colors to the PC-98 graphics hardware. This is probably the reason the colors are different. I don't know enough about the PC-98 graphics hardware or EGA/VGA differences, but can help you when you have time to look more into this. |
Beta Was this translation helpful? Give feedback.
-
|
Looking at the PC-98 screen sub driver in drivers/vgaplan4_pc98.c: It shows the IBM PC These four routines handle the four cases of blitting from memory to screen, screen to memory, screen to screen, and memory to memory. The screen routines are assuming VGA access and have to be rewritten for PC-98. Thus you will likely want to copy vgaplan4_mem.c to vgaplan4_mem_pc98.c and rewrite the vga access routines to be compatible with PC-98. This looks quite tedious, unfortunately. The nxterm emulator now uses vga screen-to-screen blit in order to speed up scrolling, rather than copying to a memory block internally, which is both slow and uses excessive memory for ELKS. That is the reason for the bug we are seeing. |
Beta Was this translation helpful? Give feedback.
-
This seems overly complicated but essentially packs the bytes such that the high nibble corresponds to the left-most X pixel, and the low nibble the next pixel to the right, etc. Look at drivers/fblin4.c to see the 4-bit frame buffer driver, which uses the same format. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @ghaerr , Thank you. I will test the mem to screen when I have another time. I have tested the nxterm on PC-9801RX. Looks good. I notice a couple of minor issue. (I don't think we need to fix these before the 0.9.0 release.)
Thank you. |
Beta Was this translation helpful? Give feedback.
-
I am reading up a bit on the PC-98 color hardware, it seems that it is different based on model, PC-9801 (8-color) vs PC-9801VX (16-colors from 4096 palette) and PC-9821 (256-color). Which system are you thinking of modeling after, the PC-9801VX? |
Beta Was this translation helpful? Give feedback.
-
|
@ghaerr @tyama501 Can you please complete this page: https://github.com/ghaerr/elks/wiki/Nano%E2%80%90X |
Beta Was this translation helpful? Give feedback.
-
|
Hello @toncho11 I haven't been watching at microwindow repository for a few month and it seems that there are so many updates from you :) Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
So I started this thread 15 Feb 2024 with the idea of having a graphical desktop environment for ELKS. And now this dream has come true! I am happy to announce the release of NXDSKTOP: #2593. Thank you @ghaerr and @tyama501! Without you work this would not have been possible! |
Beta Was this translation helpful? Give feedback.












Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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 ?
Beta Was this translation helpful? Give feedback.
All reactions