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.

[tyama501]

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.mp4

Thank you.

[tyama501]

[ghaerr]

I just tested on a fresh Nano-X build for IBM PC on ELKS using QEMU and it is showing nxterm working properly with meminfo.

Thus, this issue may be PC-98 only (or not) and have to do with the PC-98 screen driver, or possibly something else.

[tyama501]

Oh, I see. Thanks. I will look the driver when I have another time. Does it uses some special function for the scroll?

[ghaerr]

I think nxterm uses GrCopyArea for scrolling. I will have to look but think the copy area ends up using a driver blit call, for which the PC-98 driver may not have a working entry point.

BTW, the IBM PC version is using different background color (compiled just now from scratch):

[tyama501]

I see.

Interesting.
It looks nxterm color is dark and the start menu is bright for the IBM,
while nxterm color is bright and the start menu is dark for the PC-98.

I have also built now from the latest repository.

[ghaerr]

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.

[tyama501]

Thank you. We might talked this before but there is different for Brown(dark red?) for IBM and Yellow for PC-98. (I think that is ok for now).

I am interesting in the dark and the bright white have been reversed.
I may look where this difference come from.

[ghaerr]

I may look where this difference come from.

Start with the palette table in engine/devpal4.c, this is where the application RGB values are converted to closest colors representable by the hardware:

/*  
 * Standard palette for 16 color systems.
 */     
const MWPALENTRY mwstdpal4[16] = {
    /* 16 EGA colors, arranged in VGA standard palette order*/
    RGBDEF( 0  , 0  , 0   ),    /* black*/
    RGBDEF( 0  , 0  , 128 ),    /* blue*/
    RGBDEF( 0  , 128, 0   ),    /* green*/
    RGBDEF( 0  , 128, 128 ),    /* cyan*/
    RGBDEF( 128, 0  , 0   ),    /* red*/
    RGBDEF( 128, 0  , 128 ),    /* magenta*/
    RGBDEF( 128, 64 , 0   ),    /* adjusted brown*/
    RGBDEF( 192, 192, 192 ),    /* ltgray*/
    RGBDEF( 128, 128, 128 ),    /* gray*/
    RGBDEF( 0  , 0  , 255 ),    /* ltblue*/
    RGBDEF( 0  , 255, 0   ),    /* ltgreen*/
    RGBDEF( 0  , 255, 255 ),    /* ltcyan*/
    RGBDEF( 255, 0  , 0   ),    /* ltred*/
    RGBDEF( 255, 0  , 255 ),    /* ltmagenta*/
    RGBDEF( 255, 255, 0   ),    /* yellow*/
    RGBDEF( 255, 255, 255 ),    /* white*/
};

Then, in engine/devopen.c, GdFindNearestColor() is used to convert a color and palette table to a "pixel" value which is directly passed to the screen driver. You will want to start by possibly modifying the palette to best match the PC-98 colors. GdFindNearestColor then tries to find the closest palette index for a given color:

MWPIXELVAL
GdFindNearestColor(MWPALENTRY *pal, int size, MWCOLORVAL cr)
{   
    MWPALENTRY *    rgb;  
    int     r, g, b;
    int     R, G, B;
    int32_t     diff = 0x7fffffffL;
    int32_t     sq;
    int     best = 0;
    
    r = REDVALUE(cr);
    g = GREENVALUE(cr);
    b = BLUEVALUE(cr);
    for(rgb=pal; diff && rgb < &pal[size]; ++rgb) {
        R = rgb->r - r;
        G = rgb->g - g;
        B = rgb->b - b; 

        /* speedy linear distance method*/
        sq = MWABS(R) + MWABS(G) + MWABS(B);
    
        if(sq < diff) { 
            best = rgb - pal;
            if((diff = sq) == 0)
                return best; 
        }
    }       
    return best;
}

[ghaerr]

Looking at the PC-98 screen sub driver in drivers/vgaplan4_pc98.c:

static SUBDRIVER pc98plan4_none = {
        pc98_drawpixel,
        pc98_readpixel,
        pc98_drawhorzline,
        pc98_drawvertline,
        gen_fillrect,
        vga_blit,

It shows the IBM PC vga_blit routine in drivers/vgaplan4_mem.c is being used. This routine is a wrapper for four possible blit routines:

void                
vga_blit(PSD dstpsd, MWCOORD dstx, MWCOORD dsty, MWCOORD w, MWCOORD h,
    PSD srcpsd, MWCOORD srcx, MWCOORD srcy, int op)
{           
    MWBOOL  srcvga, dstvga;
    
    /* decide which blit algorithm to use*/
    srcvga = srcpsd->flags & PSF_SCREEN;
    dstvga = dstpsd->flags & PSF_SCREEN;
            
    if(srcvga) {
        if(dstvga)  
            vga_to_vga_blit(dstpsd, dstx, dsty, w, h, srcpsd, srcx, srcy, op);
        else        
            vga_to_mempl4_blit(dstpsd, dstx, dsty, w, h, srcpsd, srcx, srcy, op);
    } else {    
        if(dstvga)
            mempl4_to_vga_blit(dstpsd, dstx, dsty, w, h, srcpsd, srcx, srcy, op);
        else
            mempl4_to_mempl4_blit(dstpsd, dstx, dsty, w, h, srcpsd, srcx, srcy, op);
    }
}

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.

[ghaerr]

I am not sure how much blit works for PC-98 architecture

The blit routines for PC-98 will be very similar to its draw pixel and draw horizontal line routines, except blit is optimized to work quickly with a rectangular block of pixels, with the source or destination pixel format either being PC-98 hardware format, or "mem4" format (which is two 4-bit nibbles packed per byte). The mem4 read/writes will be exactly the same, with only the bit twiddling and EGA hardware code changed for the PC-98 hardware. You might be able to get it done quickly by just copying the PC-98 horizontal pixel/line read and write code into the blit functions, working a scanline at a time.

[tyama501]

Hello @ghaerr ,

I have added vgaplane4_mem_pc98.c.
https://github.com/tyama501/microwindows/blob/pc98_driver/src/drivers/vgaplan4_mem_pc98.c

At least it worked for meminfo on nxterm.

nxterm_2025-09-04_00-20-41.mp4

Thank you!

[ghaerr]

Hello @tyama501, fantastic work writing the screen-to-screen low level blit for PC-98! Very nice to see it all working properly on your system Please send a PR to Microwindows.

I don't have a diff for the changes, did you also implement the memory-to-screen blitting? I am trying to think of an application that uses that for testing, since nxterm only uses screen-to-screen, IIRC.

Thank you!

[tyama501]

Hello @ghaerr ,

Thank you.

Yes, I have also modified mempl4_to_vga_blit and vga_to_mempl4_blit but I am not sure it works,
since I haven't fully understood
color = *s >> ((1-(sx&1))<<2) & 0x0f;
...
color |= 1 << (plane + ((dx & 1) ? 0 : 4));

Are these doing some color data conversion between memory and screen?

[ghaerr]

have also modified mempl4_to_vga_blit and vga_to_mempl4_blit but I am not sure it works,

The mempl4 format is an internal packed 4-bit format, where each 16-bit color is packed into two 4-bit nibbles. This format is only used for the internal representation of EGA/VGA (and now PC-98) since the VGA itself is planar and doesn't keep colors in nibbles or bytes. The mempl4 format could also be used as a standard pixmap for other (offscreen) drawing, but this isn't usually taken advantage of too much by application programs.

color = *s >> ((1-(sx&1))<<2) & 0x0f;

This is just isolating one or the other of the 4-bit nibbles into a 16-bit color, based on the X value, which determines high or low nibble.

Are these doing some color data conversion between memory and screen?

No. There should be no color conversion in the blit routines, the same (source) 16-bit color should written to the (destination) as the same color, although of course may be a different (or the same) format: mempl4, VGA (hardware) or PC-98 (hardware).

In conclusion, the portion of the mempl4 routines that read or write the the offscreen mempl4 memory can remain the same, just the portion that used to read/write VGA needs to be changed to read/write PC-98.

These off-screen blits could be tested by writing a Nano-X program that allocates an offscreen pixmap, then uses GrCopyArea to read/write from the screen or offscreen windows/pixmaps. I can help with that if you'd like.

[ghaerr]

color = *s >> ((1-(sx&1))<<2) & 0x0f;

This is just isolating one or the other of the 4-bit nibbles into a 16-bit color, based on the X value, which determines high or low nibble.

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.

[tyama501]

I see.

It would be nice to have test codes.

allocates an offscreen pixmap

How can we do this?

Thank you.

[ghaerr]

You can create a new offscreen pixmap using GrNewPixmap (or GrNewPixmapFromData). This then returns a "window" handle just like GrNewWindow except that the drawing will be offscreen. The GrXXX draw primitives are used to draw into it, then GrCopyArea is used to blit all or a portion of it to the screen. The GrCopyArea function ends up calling the low level mempl4 if the pixmap type is 4bpp, or the low level vga blit if the pixmap type and destination matches the screen.

An example program of how this is done is nanox/demos/demo-composite.c. This would want to be slightly changed so that an image format of MWIF_PAL4 is used, rather than MWIF_RGB8888. The demo-composite program as written blits a 32bpp image to the screen, for our testing, this would be changed to create a 4bpp pixmap, draw some lines on it, then blit that to the PC-98 screen or window.

[tyama501]

Hello @ghaerr ,

I think the screen to mem and mem to screen started to work.

I wrote a test codes that draw RGB rectangles on screen then copy it to the mem, wait 5 seconds,
then copy it to screen at the bottom side,
then copy it again to the right side.

tstmemsc_2025-09-15_12-24-17.mp4

I think I will make a first PR after clean the codes.
I also found a bug in the scr_pc98.c for the 16 mode color (out of 4096) setting.
I will include the fix in the PR too.
I also need to fix elkscmd/basic/host-pc98.c for the same reason.

Thank you!

[tyama501]

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 found the color is more similar to IBM as the nxterm is dark and the start menu is bright than the emulator.
So, I will leave the color issue for now.

I notice a couple of minor issue. (I don't think we need to fix these before the 0.9.0 release.)

• The right click for nxworld is not working to show coordinate. This also occurs on qemu with IBM image.
  (I don't know it is mouse issue or display issue.)
• The sl need to hit enter key once before departure.

Thank you.

[ghaerr]

@tyama501, PR #2386 adds DEBUG_PORT=none to allow running miniterm from Nano-X without a serial mouse. DEBUG_PORT= can also be used to specify an alternate location than /dev/ttyS0 (or /dev/console) when desired.

[tyama501]

@ghaerr
Great, Thank you!

[tyama501]

Hello @ghaerr

I could open miniterm from nxterm by export DEBUG_PORT=none before nxstart.
Then, I could login to Debian 12 on PC/AT from PC-9801RX.
Thank you!

Can we set the DEBUG_PORT=none for default at least for PC-98?

[ghaerr]

Can we set the DEBUG_PORT=none for default at least for PC-98?

Yes, let me think of a good way to do that. Debugging output is of course generated by explicit __dprintf calls, but also enabled and disabled using sysctl malloc.debug={0,1,2} in the dmalloc libraries and other places. By default (without a DEBUG_PORT override), if /dev/ttyS0 is not available, then /dev/console is used. This doesn't work well with Nano-X since the graphics are running on the console, but can be handy otherwise. We also don't want to compile a specific PC-98 libc nor optionally execute DEBUG_PORT= in /etc/profile, I think.

[tyama501]

Thank you!

BTW,
I have found the reason why the bright/dark are different with IBM pc.
The intensity bit (plane) for PC-98 is the opposite of IBM pc since PC-98 has 8 color mode and 16 color is extention!

I may try adding custom palette opperation to make CGA compatible color.

[ghaerr]

The intensity bit (plane) for PC-98 is the opposite of IBM pc since PC-98 has 8 color mode and 16 color is extention!

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?

[tyama501]

Yes, currently elks pc-98 focus on PC-9801VX (16-colors from 4096 palette).
Most of PC-98 have this architecture.

[tyama501]

Hello @ghaerr ,

I have added CGA like palette setting including the brown
tyama501/microwindows@c553fd9
based on
https://en.wikipedia.org/wiki/Color_Graphics_Adapter

Looks good.
Now the nxterm brightness and the color is almost same as IBM version.
I will make a PR after testing with the real PC-98.

Thank you!

[ghaerr]

Hello @tyama501,

Wow, the colors look great. That's nice since we now won't have to worry about differences between color themes across platforms.

I have added CGA like palette setting including the brown

I am wondering with the int_A4() palette code whether it might be better to put each of the palette duple bytes together into a single array, then use a for loop calling int_A4 for each palette entry, instead of coding each out explicitly? This separates the palette itself from the code, which may come in handy for future palettes or programs?

I will make a PR after testing with the real PC-98.

Sounds good.

Thank you!

[toncho11]

@ghaerr @tyama501 Can you please complete this page: https://github.com/ghaerr/elks/wiki/Nano%E2%80%90X
Foe example I do not know what to say when EGA and CGI are configured. Actually I do not say anything about EGA. Please do not change the name of the page.

[ghaerr]

Also, CONFIG_HW_VGA=y is not required for Nano-X to run. The Nano-X screen driver is built for VGA or EGA cards. If "EGAMODE=1" is set in the environment, it will assume EGA and run in 640x350 resolution, otherwise it will assume VGA resolution and use 640x480.

Nano-X can be built to use CGA, which was done with some experimentation for IBM PC using a special driver. There is no CGA support for IBM PC using the standard build - its resolution is pretty much too low. The PC98 version of Nano-X uses a driver specific for PC98 and runs in 640x400 resolution.

[ghaerr]

nxstart is actually just another nano-X application - it will auto-start Nano-X as described above, and then just displays a menu which will then start other nano-X applications once running. Any application could be used to start nano-X, but the menu of other applications would not be displayed until nxstart is executed.

[toncho11]

Thank you! I updated the page with your comments: https://github.com/ghaerr/elks/wiki/Nano%E2%80%90X

[toncho11]

And the cursor for ELKS is 8x8 now instead of 16x16. Where was this set? And some mouse optimizations could be ported from Paint to Nano-X?

[ghaerr]

Yes, Paint can be compiled to use a variety of cursor drawing mechanisms, and the Paint cursor code has been on my list to back-port to Nano-X. Currently Nano-X only supports the original much-slower cursor drawing mechanism, and has been configured to use an 8x8 cursor with the -DUSE_SMALL_CURSOR=1 option in Makefile.elks. Most 16-bit real mode systems appear sluggish when the option is not set, but a user can experiment with it until the back-port of the faster cursor mechanisms is completed.

There may be some minor mouse optimizations other than cursor drawing, I'll look into that.

[tyama501]

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 :)
I haven't try it yet but
How does it look like now?
Could you also share here?

Thank you!

[toncho11]

Colors are correct on PC-98. Making a theme with other colors can be tricky (because of palette changes) and is for future versions.

[ghaerr]

the problem was that the image size was exactly 640 x 480
And they need to be adapted to be used by nxjpeg.

Possibly your image display code could just truncate (i.e. disregard) any dimensions of an image larger than what can be supported? This would then allow upper left portions of image display without having to convert them?

[toncho11]

the problem was that the image size was exactly 640 x 480
And they need to be adapted to be used by nxjpeg.

Possibly your image display code could just truncate (i.e. disregard) any dimensions of an image larger than what can be supported? This would then allow upper left portions of image display without having to convert them?

Could be, but it is not a real solution.
Did the 16 color EGA option render an image (the file I provided)?
Did the 8 color gray option render an image or it halted (the file I provided)?

Please test with the fastest possible CPU speed you can emulate. Currently rendering can be slow.
Thank you.

[tyama501]

Hello @toncho11

Wow! Cool!!
It is displayed.

16c

8c

4c

Thank you!

[toncho11]

Awesome! This image is not a good test example. But we can work on this later. Thank you!

[toncho11]

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!