Games development on ELKS

[toncho11]

Let's take this example of Snake compiled by Turbo C:

https://github.com/ashmew2/snake-game/blob/master/Final.cpp

• One needs to replace DOS.h calls with ELKS libc or syscalls. Here it looks like only delay, sound and nosound are used. We can omit sound for now.
• One needs to compile conio.h. An implementation exists based on ncurses, but then one needs to port ncusrses too. But actually only kbhit, clrscr and getch are used in this game! So 3 out 8 functions from conio.h.
• And finally one needs to rewrite the needed functions from graphics.h. Functions needed for this game are: fillpoly, drawpoly, settextstyle, outtextstyle, outtextxy, setfillstyle, floodfill, setcolor, rectangle

@ghaerr Maybe graphics.h can be mapped to Nano-X? But on 8086 computers Naxo-X looks slow for games. For example

• outtextxy -> GrText
• rectangle -> GrRect

[pawosm-arm]

The topic of porting graphic libraries and 90's games to ELKS should be preceded by a more substantial discussion regarding the graphics in ELKS in general. I never had occasion to work with nx before meeting ELKS (my past experience with NuttX from which nx originated never went beyond the nsh command line sessions), so I can't really say how good or bad this library is. I just have impression that I already saw things more mature than nx, like Photon on QNX or DirectFB on Linux. Even things like GUILib for multiplatform SDL library seemed more mature despite all of its limitations. And there is also John Elliott's SdSDL library for SDL which emulates GSX and VDI graphics that originates from CP/M and DOS (before MS Windows). And that was the direction I was looking for: John Elliot's fork of GSX/VDI-based GEM (the mighty FreeGEM) works really lovely on both of my XT machines (one 8088, one 8086 based), far better than nx on ELKS on the same machines, though I suspect the secret is in the underlying OS: there's no multitasking in DOS, hence GEM can consume all of the CPU time for handling mouse-driven graphics operations. Yet anyway, it only shows that doing GUI on XT is possible and the user experience does not need to suffer. BTW, Windows 3.0 was the last version of MS Windows that could be installed on 8086 and it offered some kind of multitasking, still being capable of providing good enough user experience.

One more thing I remember from the past. My very first Linux back in the 90s (some very early version of RedHat) was installed on some very low end i386 machine equipped with ISA 8-bit VGA graphics card (probably the same I've installed during ELKS times into my Turbo XT to replace Hercules mono graphics card that was installed into it originally). Running X at 640x480x16 offered terrible user experience and 16-color palette looked awful. Yet I managed to force X server to run with 320x200x256 mode and it really started to fly! The user experience was amazing. I guess two factors were playing their role here: lower resolution and a whole byte per pixel which simplified all of the graphic operations. I think it's one of the possible directions nx on ELKS could also explore. In the end, those demos don't really display much of the content on screen. See how GEOS looks like on C64, it's low resolution and it's still really cool (speaking of GEOS, it was ported to 8086 XT's too, yet to my disappointment its final XT-compatible version was working much slower than FreeGEM).

[tkchia]

Hello @toncho11, hello @pawosm-arm,

Well, the graphics stuff aside --- I think @ghaerr can comment further on that --- it is obvious that porting Turbo C++ specific code to, well, anything that is not Turbo C++, is going to take some effort. I do not see this as a bug per se: there is no real urgent need for ELKS to be compatible with a non-standard programming interface (even if it will be a "nice thing to have").

[pawosm-arm]

I remember the times when porting from Turbo C++ was all about getting rid of '#include <conio.h>' :)

[tkchia]

Hello @toncho11 , hello @pawosm-arm,

I remember the times when porting from Turbo C++ was all about getting rid of '#include <conio.h>' :)

Well, I guess there are different ways of doing the porting task. :-|

In case you missed it: on the MS-DOS front, I have been working on a libi86 project. It aims to implement, for gcc-ia16, non-standard C library extensions that are present in the Open Watcom C runtime and (to some degree) the Turbo C++ runtime.

I am currently keeping this library separate from the underlying C library (newlib-ia16) that implements the core C99 and POSIX functionality.

(<conio.h> support is mostly complete (for MS-DOS, that is). As for graphics, both Open Watcom and Turbo C++ have very rich graphics libraries, and it is not very easy to "just reimplement" them. And that is even without having to worry about multi-tasking or multi-window interfaces...)

If there is real demand, perhaps I can look into extending the scope of libi86 to also work on ELKS, in addition to MS-DOS.

Thank you!

[pawosm-arm]

I wonder how far we can go with this... It's like with Fuzix for Z80 machines where ability to run CP/M programs was considered.

[Mellvik]

 I wonder how far we can go with this... It's like with Fuzix for Z80 machines where ability to run CP/M programs was considered.

Interesting digression @pawosm-arm, I'm curious: anything in particular from cp/m you're interested in? It may be worthwhile remembering that cp/m and fuzix ran on a different and incompatible architecture (from x86), and most programs were written in assembler. Still, I have 3 operating cp/m machines...

…

-Mellvik

[toncho11]

Nice digression. We need that 👍

By the way is it possible to change the priority of a process in ELKS? There is a nice sys call, but no nice command? Maybe this will make a game run a bit faster.

While we wait for @ghaerr I think making a layer that allows for quick porting of turbo C programs and games will be interesting. I mean I want to use ELKS and have software for it. Ok some people are focused only on the kernel and they do not care about userland, but not me.

[pawosm-arm]

@toncho11 I think the 'bug' label here is slightly misleading.

@Mellvik,

Interesting digression @pawosm-arm, I'm curious: anything in particular from cp/m you're interested in?

Although interesting, this digression should not grow here as it barely touches the matter of this ticket.
As for CP/M, having beefed up Spectrum +3 in a workable condition I've got a native machine to run CP/M Plus with all of the stuff I remember from the 80s. I also have Spectrum Next that also can boot CP/M Plus yet comparing to +3, the support for on-board peripherals isn't complete which leaves me with a sense of disappointment.

It may be worthwhile remembering that cp/m and fuzix ran on a different and incompatible architecture (from x86), and most programs were written in assembler. Still, I have 3 operating cp/m machines...

I'm slightly confused here. Both Fuzix and CP/M were originally targeting Z80 machines hence the idea of running CP/M software in Fuzix wasn't that terrible (considering simplicity of CP/M). And this simplicity was a key here: I suspect providing similar compatibility layer in ELKS to enable running 8088/8086 DOS programs would be more difficult.

In case of CP/M, attempts to support other architectures (e.g. CP/M-86 or CP/M-68k) never gained popularity due to competition from the natively developed operating systems that were better suited to those machines.

Anyway, there is some trace of the feature I've mentioned here in Fuzix's git repo: https://github.com/EtchedPixels/FUZIX/blob/master/Applications/cpm/runcpm.c

EOOT.

[ghaerr]

Hello everyone,

Well, there's a lot that got discussed today, here's a few of my thoughts...

one needs to rewrite the needed functions from graphics.h. Functions needed for this game are: fillpoly, drawpoly, settextstyle, outtextstyle, outtextxy, setfillstyle, floodfill, setcolor, rectangle

Yes, defining a distinct set of graphics functions, preferably across more than just one game, is a great way to start. Then, the entire function-set can be analyzed a bit and a graphics engine/library used as an API-bridge. Having done a heck of a lot of graphics engine programming, I also highly recommend keeping things simple in the beginning, and adding complexity only after getting the initial game(s) initially drawing. For instance, fill, draw poly and rectangle are pretty basic, but floodfill can get complicated. Text output is a whole 'nother discussion, but if a fixed-size font can be used, things are simplified considerably.

Maybe graphics.h can be mapped to Nano-X? But on 8086 computers Naxo-X looks slow for games.

Yes, a lot of the graphics could be mapped to Nano-X, but it will likely be too slow. The biggest reasons for this (to be covered in more detail later) are 1) the lower level routines are written in C, not ASM, and 2) Nano-X has an additional layer of overlapping window management and clipping support.

I have a number of graphics translation libraries for various embedded systems like Arduino, but what is really needed here is an (older) 8086 graphics library with direct, fast EGA support.

I never had occasion to work with nx before meeting ELKS (my past experience with NuttX from which nx originated never went beyond the nsh command line sessions), so I can't really say how good or bad this library is. I just have impression that I already saw things more mature than nx, like Photon on QNX or DirectFB on Linux. Even things like GUILib for multiplatform SDL library seemed more mature.

Actually, Nano-X originated from NanoGUI, which itself was based on some very early code by David I. Bell, the same guy that interestingly enough wrote sash and a lot of the basic command line utilities used in ELKS. I took that code back in the 1990's and started the Microwindows Project, whose original goal was to implement the Win32 GDI as well as an Xlib-like API onto Linux framebuffer systems (those with video cards implementing a flat frame buffer rather than the complicated and slow original EGA/VGA card hardware). Back in 1999, version 0.86 was the last version small enough to run on 8086 systems, and I ported it to ELKS. So we're running a code snapshot from 21 years ago. The landmine game is particularly old-fashioned looking; it was written by David Bell himself and a contributed port to Microwindows was made over 20 years ago. There are lots of other much better-looking Nano-X graphics, but most all are too big to run on ELKS,. The name was changed from Microwindows to Nano-X when Microsoft sent a cease and desist letter. Check out what Nano-X looks like today; unfortunately its all way too big for ELKS.

But I digress. Back to @pawosm-arm's points, SDL, DirectFB, etc - are all too large for ELKS. Since the ELKS applications (not the kernel) will be writing directly to the EGA, what we should seriously consider would be an older, fast EGA library. Those libraries would likely use a different assembler than ia16-gcc-as (which is gcc compatible and AT&T syntax). Another option would be to use the EGA draw routines from Nano-X written in ASM (elkcmd/nano-X/drivers/asmplan4.s), but they would need to be ported from the BCC/AS86 assembler, and the speed would likely improve considerably. Nano-X is written as three layers (driver, engine and API), and the driver and engine could be used without the window-management API overhead, which would help. Its all a bit complicated, but doable.

By the way is it possible to change the priority of a process in ELKS? There is a nice sys call, but no nice command? Maybe this will make a game run a bit faster.

There's no way to change the priority of a process in ELKS (yet); but when a single program is running, which is usually the case, there's no need for it - the system runs the single process as fast as can be, only taking timer interrupts, which increment a few counters, and then the interrupted process is immediately continued.

[toncho11]

There is another solution:

Alfonso Martone found a way to convert DOS Turbo-C programs to enable these to run with ELKS. For this he developed the exe2elks DOS utility program and a small libc without DOS system calls. You compile your C program with this small libc library instead of the standard Turbo-C libc. Then you use the exe2elks utility to convert the generated executable in the DOS EXE format to a 16bit OMAGIC aout file as required by ELKS.

So if we accept that the Turbo C graphics.h is not using DOS system calls (I actually do not know) then we could compile a game with Turbo C and:

• either use implementations of all the I/O libraries that do not use DOS calls as Alfonso does
• the game comes as an object file from Turbo C that does not contain the IO libraries and we continue with ia16 gcc compiler on Linux which links the implementations

So again:

• custom script that compiles the game core and links the graphics.h to an object file using Turbo C
• link the rest from ia16 gcc using @tkchia versions of conio.h and dos.h.

printf should come from ia16 gcc I suppose.

What do you think? Are the differences in compiling linking and function parameters handling so different ?
This solution can solve the problem of speed because I believe Turbo C routines are already optimized.

[pawosm-arm]

Actually, Nano-X originated from NanoGUI, which itself was based on some very early code by David I.

Argh, this name reuse, so common in Open Source world. Indeed nx graphics in NuttX and nx graphics in ELKS are completely different things of completely different origins. Both had the same purpose in common which is being lightweight, and that confused me. So porting nx from NuttX may be one more path to follow or avoid.

Anyway, ability to change resolution (and bytes per pixel) would be a great addition to current graphics layer in ELKS, but only if it doesn't overcomplicate the current codebase.

[pawosm-arm]

Speaking of Turbo C++, it brings me some of my late school days memories, you can have a glimpse here, https://www.youtube.com/watch?v=N8z5kQFhJ9A yet note I'll probably pull it down soon, there's too much cringe in this :)

Anyway, looking forward, if you're serious about DOS compatibility in ELKS, IPX would be a nice addition, we had a lot of fun playing those early multiplayer games back in the 90's.

[ghaerr]

@toncho11,

Alfonso Martone found a way to convert DOS Turbo-C programs to enable these to run with ELKS. For this he developed the exe2elks DOS utility program and a small libc without DOS system calls. You compile your C program with this small libc library instead of the standard Turbo-C libc.

I have to say, somewhat amazing piece of work by Alfonso. He's definitely provided the basics, that should, possibly without modifications, work today (we upgraded the ELKS a.out format slightly earlier this year, but still support the original a.out format, calling it "v0").

The bigger issue with this approach is that the development is all done on DOS, right? So TurboC is run on DOS to compile and link any TC program, along with the TC graphics library, and Alfonso's DOS-to-ELKS conversion libc which allows the program to run on ELKS without modification. It's a slick way to solve this problem. Perhaps you should try running his sample programs and see if/how they run on ELKS today, for a start.

[toncho11]

I compiled a minimal program that draws a rectangle with Turbo C and then applied exe2elks.
For the map file generated by Turbo C and required by exe2elks there are 3 options "Segments", "Publics" and "Detailed". I think I wen with "Segments".

It says "invalid argument" on ELKS.

[ghaerr]

I compiled a minimal program that draws a rectangle with Turbo C and then applied exe2elks.
It says "invalid argument" on ELKS.

This is very likely due to the exe2elks output a.out binary format not being compatible with ELKS now. We will need to make some changes to exe2elks.c. I won't be able to compile it, since I don't have access to DOS. Take a quick look at exe2elks.c, and familiarize yourself with it. Make sure you can compile it up from scratch to exe2elks.exe. Please post the non-working minimal program binary, and then I'll help determine what fields in the "elks" struct we need to change. I don't think it will be much.

[toncho11]

Here it is:
DEMO3.zip

[toncho11]

If this is the correct disassembly:
DEMO3.txt

then it means that there are 19 int $0x21 DOS calls ... more than I have hoped.

[toncho11]

OK I see now ... probably I need to use the .bat file provided by Alfonso to set the proper options of tcc and tlink ... to generate a better executable ... I was using the IDE with .map file generation enabled.

[ghaerr]

probably I need to use the .bat file provided by Alfonso to set the proper options of tcc and tlink ... to generate a better executable

Yes, the idea is to compile with TC but link with Alfonso's special library that replaces all the TC libc calls to int 21h with ELKS system calls, and then rewrite the .EXE MZ format to ELKS a.out format.

[toncho11]

Ok it is going to take much more time.
Turbo C loads a graphical driver. So that is why there were many int 21 calls I suppose. It access the disk and it loads the driver - a EGAVGA.BGI file in my case as I am using VGA card. The good news is that I can convert the .bgi to .obj with bgiobj.exe and use it while linking .

[toncho11]

This is a direct example of Alfonso:

HELLO.zip

It says "invalid argument". We need to fix that first before going deeper into the graphics library.

How do you disassemble it?
objdump -s -x -D -b binary -m i8086 hello
It does not print all the lines I think ?

[ghaerr]

@toncho11,

I'm not exactly sure what the problem is with ELKS running that (v0 format a.out header) executable, but I have a workaround that works:

chmem -h can be run on the executable, setting the same heap size as the program says it wanted originally; chmem will then set the header to type v1 and it will run. This should work on any executables produced by Alfonso's tools for the time being. I'll look into and fix either ELKS or your elks2exec.c so this won't be required after v0.4.0.

How do you disassemble it?

It appears we don't have a way to disassemble linked binaries... the objdump86 program should be able to work, but it seems to want to work on .o files only. I'll look into that later also, unless you can find a decent 8086 disassembler on the net somewhere. I would like to add disassembly capability directly into an ELKS command.

[toncho11]

It is far more complicated ... I can not even compile a normal exe with the integrated bgi driver.

@pawosm-arm Do you know how to do that? How to compile from command line with graphics.lib, egavga.obj and registerbgidriver(EGAVGA_driver) ? I can not make it to work.

[toncho11]

Interesting ... I tried to contact Alfonso ... but there is no working email ... nor any other contact information ...

[pawosm-arm]

@pawosm-arm Do you know how to do that? How to compile from command line with graphics.lib, egavga.obj and registerbgidriver(EGAVGA_driver) ? I can not make it to work.

Can you specify more details? Which 'command line': DOS, Linux, ELKS? (well, ELKS command line doesn't seem to have a linker). What kind of binary do you want to have in effect?

[ghaerr]

I can not even compile a normal exe with the integrated bgi driver.

Compile or link error? You're using TC on DOS so there should be no issues having TC compiling TC programs, including those with graphics.h. Alfonso's trickery is all at the link stage, linking with additional libraries, right? You'll probably need to study TC a bit and understand what options it has for graphics programs, should there be compilation issues with it.

[ghaerr]

@Vutshi - I tried the ta2as conversion program above, and once I got it to compile on macOS (strlwr is missing) it seemed to convert your mandelbrot source semi-kind-of-well, for the instructions it will convert. The major problem(s) you might run into is that NASM is using macros and those aren't converted or aren't available.

FYI here's the patch I used to get ta2as to compile in case you're interested:

diff --git a/make.sh b/make.sh
old mode 100644
new mode 100755
diff --git a/src/main.c b/src/main.c
index 7410ca2..30b91d8 100644
--- a/src/main.c
+++ b/src/main.c
@@ -83,3 +83,17 @@ int main(int argc, char *argv[])
        fclose(out);
        return 0;
 }
+
+#include <ctype.h>
+
+char *strlwr(char *str)
+{
+  unsigned char *p = (unsigned char *)str;
+
+  while (*p) {
+     *p = tolower((unsigned char)*p);
+      p++;
+  }
+
+  return str;
+}
diff --git a/src/ta2as.c b/src/ta2as.c
index 9f78fd5..6dfe20f 100644
--- a/src/ta2as.c
+++ b/src/ta2as.c
@@ -18,6 +18,8 @@
 #include <string.h>
 #include <ctype.h>
 
+extern char *strlwr(char *str);
+
 typedef void (*modfunc)(AsmLine *ln);
 
 typedef struct {

[Vutshi]

Thank you @ghaerr.

First I try to employ the newly available GPT-4o. When it doesn't work I will switch to more conventional tools :)

[Vutshi]

ChatGPT doesn't want to just do a plain conversion it tries to optimize :)

shr di,1
shr di,1

converted to:

shrw $2, %di

[Vutshi]

Well, it kind of works...

ELKS_GAS_Mandel.mov

here is the GAS code
mandel_elks.s.zip

[ghaerr]

What did you use for conversion, ta2as? I'm guessing GPT didn't do it for you...

Something to consider during Intel to AT&T conversion: input NASM syntax like

   mov ax,foo

could mean

  mov ax,[foo] ; normal access of memory contents

or instead the less likely

mov ax, foo ; foo is a constant and not a memory address

I think NASM does not require the [foo] syntax for the memory move is foo is a label, instead of an EQU.

The translator would not know the difference between them, while an assembler would. This might be an issue to check into.

[Vutshi]

What did you use for conversion, ta2as? I'm guessing GPT didn't do it for you...

Actually, I mainly used ChatGPT because it understands macros. Although it has a mind of its own and tends to reorganize functions ordering according to its liking. I cleaned up the code to match the objdump of the NASM-generated object file. Now, I have a one-to-one matching of NASM and GAS codes except for the .data section.

Essentially elf2elks forces me to introduce non empty .data otherwise it complains:

elf2elks: error: data and BSS sections overlap!

so instead of this in NASM:

section .data
absolute 0
iters:
  resb itersX*itersY
  alignb 2
aTable:
  resw itersX
bTable:
  resw itersY
yTableLower:
  resw 102 ;itersY
yTableUpper:
  resw 102 ;itersY
itersXTable:
  resw itersY
colourTable:
  resb 35
squareTableSegment:
  resw 1
video_mode:
  resb 1
stackStart:
  resb 128

I do this in GAS:

.data
.byte 0x01, 0x02

.bss
.local iters, aTable, bTable, yTableLower, yTableUpper, itersXTable, colourTable, squareTableSegment, video_mode, stackStart
.comm iters, itersX*itersY, 2
.comm aTable, itersX * 2, 2
.comm bTable, itersY * 2, 2
.comm yTableLower, 102 * 2, 2
.comm yTableUpper, 102 * 2, 2
.comm itersXTable, itersY * 2, 2
.comm colourTable, 35, 1
.comm squareTableSegment, 2, 1
.comm video_mode, 1, 1
.comm stackStart, 128, 1

and compile as follows:

./ia16-elf-gcc -melks-libc -mcmodel=small -nostdlib mandel_elks.s -o mand_els -maout-heap=0xffff

It works but the .data section reserves 16 bytes and everything is shifted because program assumes that .bss is at DS:0.
How to get rid of the .data section completely?

[ghaerr]

@Vutshi: You are indeed making great progress traveling fairly deep into an interesting linking rabbit hole :)

How to get rid of the .data section completely?

I'm thinking of two possibilities to consider: 1) remove the check for .data and .bss section overlap in elf2elks, and allow the link to proceed with a null .data segment, which should cause no problem, or 2) modify the default elks/elks-small.ld linker script to remove the requirement for the .data section.

The first option will be easiest at first, and if it works I could come up with allowing an overlap iff the size of .data == 0. It appears that elf2elks has never worked with an ELF conversion (from C) that doesn't have null .data segment. This is likely because the startup C crt0.S is always included and sets aside DS:0 to protect NULL data pointer dereferences:

    .data

// Zero data for null pointers (near & far)
// Will be linked as first section in data segment

    .section .nildata

    .word 0
    .word 0

(Section .nildata is linked first in the linker script into the data segment).

To try the elf2elks mod, edit elks/tools/elf2elks/elf2elks.c as follows:

  check_scn_overlap (text_sh, "text", ftext_sh, "far text");
  check_scn_overlap (text_sh, "text", data_sh, "data");
  check_scn_overlap (text_sh, "text", bss_sh, "BSS");
  check_scn_overlap (ftext_sh, "far text", data_sh, "data");
  check_scn_overlap (ftext_sh, "far text", bss_sh, "BSS");
  check_scn_overlap (data_sh, "data", bss_sh, "BSS"); // <--- comment out this line

Run make in the ELKS root and a new elf2elks will be created.

The possibly better way might be to modify the elks-small.ld linker script, but they are a bit of black magic. Here's the portion that may need to be renamed and/or deleted:

    .data 0x30000 : { // <--- rename this section to .olddata
        /* IA-16 segment start markers. */
        *(".nildata!*" ".nildata.*!")
        *(".rodata!*" ".rodata.*!")
...
    .bss : { // <--- change this to .bss 0x30000
        *(.bss .bss$* ".bss.*[^&]")
        *(COMMON)
...
// in the asserts that follow, change .data to .bss
        ASSERT (. + 0x100 - ADDR (.data) <= 0xfff0
            "Error: too large for a small-model ELKS a.out file.");
        /* Sanity check any -maout-total= and -maout-chmem= values */
        PROVIDE (_total = 0);
        PROVIDE (_chmem = 0);
        ASSERT (_total <= 0xfff0
            && . - ADDR (.data) + _chmem <= 0xfff0,
            "Error: total data segment size too large.");
        ASSERT ((_total == 0 || _total > . - ADDR (.data))
            && _chmem >= 0,
            "Error: total data segment size too small.");
    }

The changed linker script can then be passed to the linker as ia16-elf-gcc -T <linker_script> ... in your link command.

I mainly used ChatGPT because it understands macros. Although it has a mind of its own and tends to reorganize functions ordering according to its liking

Wow, impressive!!

Now, I have a one-to-one matching of NASM and GAS codes except for the .data section.
It works but the .data section reserves 16 bytes and everything is shifted because program assumes that .bss is at DS:0.

I see, very nice. It sounds like you're getting quite close to having this fully worked out!

[Vutshi]

It's done.

ELKS_GAS_Mandel_final.mov

The bug with stripes was due to SP reset to 0x1c00. One should not touch SP in a multitasking OS indeed. I just use cmpw $0x1c00, %ax which costs 19 bytes more than cmpw %sp, %ax.

@FrenkelS thanks for the trick, now I use it as well ;)

There is a couple of weird quirks left.

1. I tried to jump to exit if far memory is not allocated successfully:

  38:	cd 80                	int    $0x80
  3a:	85 c0                	test   %ax,%ax
  3c:	0f 85 fd 00          	jne    13d <exit>

But the CPU (or MartyPC) sees it differently:

2. GAS doesn't like this code:

.equ MULTIPLIER, 0x600
.equ maxX, 320
.equ maxY, 101
.equ initialShift, 5
.equ initialGrid, (1 << initialShift)
.equ	itersX,	((maxX + initialGrid - 1)/initialGrid)*initialGrid + 1
.equ	itersY,	((maxY + initialGrid - 1)/initialGrid)*initialGrid + 1

it complains about the last two lines as follows Error: found ' ', expected: ')

Best
code&binary_v2.zip

[Vutshi]

@ghaerr, I forgot to say that I used the first option to fix .data section problem

\\check_scn_overlap (data_sh, "data", bss_sh, "BSS"); // <--- comment out this line

[ghaerr]

This is great, well done!!

The bug with stripes was due to SP reset to 0x1c00. One should not touch SP in a multitasking OS indeed. I just use cmpw $0x1c00, %ax

I see, was this previously using SP to determine the calculation depth of the fractal?

I haven't studied your source code yet, does this final version leave SS & SP alone, or it SP still being reset to within the lower part of the data segment?

@FrenkelS thanks for the trick, now I use it as well ;)

What trick is that, I didn't see it.

0f 85 fd 00 jne 13d
But the CPU (or MartyPC) sees it differently:

In the 8086, 0x0F is an invalid opcode that in early versions of the 8086 was a "POP CS". Since that instruction, changing the code segment, but not the IP at the same time, is useless, the same instruction prefix was used in later CPUs as the beginning of a new multi-byte opcode. To fix this, either use jne short label or add ..arch i8086, nojumps to your .S file. The opcode that is being generated in your case is a "long conditional" jump, which won't actually run on real 8086 hardware.

I used the first option to fix .data section problem

I'll make a note to enhance elf2elks to allow . bss without data when .data size is 0.

it complains about the last two lines as follows Error: found ' ', expected: ')

I'm not sure what that is, perhaps rearrange the lines or add a few blank lines or spaces in each line to see whether that changes the error message.

[Vutshi]

I see, was this previously using SP to determine the calculation depth of the fractal?

Yes. The reason is probably to just save one byte. At least, I don't see any speed decrease.

does this final version leave SS & SP alone

Yes.

@FrenkelS thanks for the trick, now I use it as well ;)

What trick is that, I didn't see it.

The black and white Mandelbrot turns green in the end.

Thank you.

[ghaerr]

.equ MULTIPLIER, 0x600
.equ maxX, 320
.equ maxY, 101
.equ initialShift, 5
.equ initialGrid, (1 << initialShift)
.equ	itersX,	((maxX + initialGrid - 1)/initialGrid)*initialGrid + 1
.equ	itersY,	((maxY + initialGrid - 1)/initialGrid)*initialGrid + 1
#.equ tempX, (maxX + initialGrid - 1)//initialGrid
#.equ itersX, (tempX*initialGrid + 1)
#.equ tempY, (maxY + initialGrid - 1)//initialGrid
#.equ itersY, (tempY*initialGrid + 1)
#.equ itersX, 321
#.equ itersY, 129

Were you saying that the top 7 lines work, and the lower 7 do not, with GAS? Certainly GAS will not like the C++ // comments apparently used for division for NASM?

[Vutshi]

Were you saying that the top 7 lines work, and the lower 7 do not, with GAS? Certainly GAS will not like the C++ // comments apparently used for division for NASM?

No, here lines 6 and 7 are the problem for GAS. NASM likes them. Commented lines are my attempts to fix it with GAS.

[Vutshi]

Hi @ghaerr,
I broke something:

./ia16-elf-gcc -melks-libc -mcmodel=small -nostdlib mandel_elks.s -o mand_els88
elf2elks: error: ia16-elf-gcc: internal compiler error: Segmentation fault: 11 (program elf2elks)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

It happens after addition of the following line:

.data
.comm evil, 0x8000, 1

mandel_elks 2.s.zip

Best

[ghaerr]

I broke something

I would guess that by adding 32K bytes to .bss with the .comm directive you've overflowed .bss and / or the data section but the modified elf2elks isn't bounds/range checking anymore and an internal copy crashed it. A finally version of elf2elks will need to do more than just turn off overlap checking when sizeof .data == 0.

[toncho11]

@ghaerr is advancing the watcom support for ELKS in #1924 and so this might allow this stripped down version of Doom: https://github.com/FrenkelS/doomtd3 to be compiled on ELKS.

I see the watcom makefile for Doom: https://github.com/FrenkelS/doomtd3/blob/main/makefile.w16
The memory model is medium "mm" and set to 286 instructions I think, but can be set to 0 which means 8088.
I think the assembler is taken care by @FrenkelS in this version.

[tyama501]

It seems that at least i_ibm.c need to be modified for pc-98.

[FrenkelS]

I see the watcom makefile for Doom: https://github.com/FrenkelS/doomtd3/blob/main/makefile.w16 The memory model is medium "mm" and set to 286 instructions I think, but can be set to 0 which means 8088. I think the assembler is taken care by @FrenkelS in this version.

The Watcom build only uses C, no assembly. I didn't want to spend time on figuring out how to support assembly in both gcc-ia16 and Watcom at the same time.
For djdoom I did figure out how to support multiple compilers and assembly. So I guess something similar could be done for doomtd3.

It seems that at least i_ibm.c need to be modified for pc-98.

That's correct. The platform specific code is mostly in one file (i_amiga.c, i_hp95lx.c, i_ibm.c, i_mac.c).

[ghaerr]

so this might allow this stripped down version of Doom: https://github.com/FrenkelS/doomtd3 to be compiled on ELKS.

The Watcom build only uses C, no assembly.

Using the Watcom C-only build (but using ewcc and ewlink) should allow compilation of the required source files with very little to no modification, with the exceptions noted below. The resultant OS/2-format binary image should then load and run when #1924 is completed.

It seems that at least i_ibm.c need to be modified for pc-98.

For ELKS, all DOS-oriented routines (timer, keyboard, interrupt handlers, OS calls, but not EGA graphics) will need to be replaced by Doom source files from Linux Doom, which should then also work for both IBM PC and PC-98. After that, an alternative screen-drawing routine for PC-98 will be required, as PC-98 does not support EGA hardware graphics.

[toncho11]

There maybe still some more syscalls from ELKS that need to be mapped to Watcom?

Just having the demo https://github.com/FrenkelS/doomtd3 on ELKS will be a great progress! Doom is a AAA game in our case! :)

[tyama501]

Hello all,

As I wrote in
#1505 (comment)
I have updated ELKSmoria (Roguelike game).

This version is built with gcc-ia16, medium model.
So, this version works with ELKS 0.7.0.

I will try to build with OpenWatcom large model for next release.

Enjoy!

[tyama501]

Hello,
I have written about the modification needed when installing OpenWatcom to linux with the installer.
#1443 (comment)
Looking for more testers:)

Thank you.

[toncho11]

I am excited to announce that Doom (Doom88) has been ported to ELKS: https://github.com/FrenkelS/elksdoom
I managed to make it run in: FrenkelS/elksdoom#2 and I have provided a HDD image that you can try in an emulator.
If you do not use my HDD image you need to reduce the memory used by ELKS as much as possible to be able to enter in-game. There are several options to set in /bootopts. I even remove bash/sash and boot directly into ElksDoom. You also need the latest version of ELKS.
To test it I used a pentium class emulator https://copy.sh/v86/ and Box86 which I configured to NEC20 at 16 MHz to get an idea of the performance.

[Vutshi]

Wow!

[FrenkelS]

I've just released a new version of ElksDoom. It grabs 2 large contiguous memory blocks instead of 1.
I've managed to enter the first level in 86Box emulating a 286 at 25 MHz and it's kinda playable in a fast emulator like https://copy.sh/v86/.

[tyama501]

Wow, thank you @FrenkelS and @toncho11

I could run the image that @toncho11 posted here by the v86 emulator.
FrenkelS/elksdoom#2 (comment)

[toncho11]

Huge thanks to @ghaerr for enabling the Open Watcom compiler for ELKS and @FrenkelS for the Doom88 port to ELKS.
We have now two milestone in ELKS - an application that is iconic and the first one that uses 500kb+ memory in ELKS!!!
VGA games can be developed/ported with Open Watcom without the previous limitation of 64kb.

[ghaerr]

This screenshot looks great @toncho11!! :) It's actually higher resolution than I thought would work. Really super!

And also thank you @toncho11 for your ongoing support for ELKS and constant pushing for enhancing the platform, it is appreciated.

Thank you @FrenkelS for spending the time getting your Doom source running on ELKS. I plan on playing with it just after I finish a deep dive into a QEMU-based bug that affects the ELKS kernel. Its super that OpenWatcom is being successfully used for this large game! :) I remain a bit surprised at how/why ia16-elf-gcc won't work, since you're using medium model, but I'm actually glad you switched over to OpenWatcom as that proves the OW support for ELKS is fully working, as @toncho11 has already pointed out.

Thank you!

[ghaerr]

With regards to running large games on ELKS, I just had an idea that could be a game-changer, no pun intended, lol:

For any 286/386+ system that has more than 1M memory installed, why not put the ELKS kernel data section, normally 64K up in the first 64K bytes of that memory, otherwise known as the HMA (High Memory Area)? This would free up an extra full 64K block of memory for the game to use.

Likewise, for 8088/8086 systems that have UMB memory, the ELKS kernel data section (either full sized, or trimmed down with the new options) could be put into the UMB area. Either of these options could have the same effect of increasing contiguous main memory by up to 64K bytes - huge.

Both these options would effectively be very similar to using DOS's config.sys with the DOS=HIGH,UMB line - where DOS or its data is moved to the HMA or UMB areas.

When the kernel data segment is decreased using the new heap= and other options, the default 64 (or even just minimally 8) EXT kernel buffers could also be placed into HMA or UMB memory. If a game does lots of disk I/O, having more than 8 buffers would probably help.

There's quite a few combinations that could be worked out using a few new /bootopts options that would specify what portions of memory buffers and kernel data segment could go into that would greatly help increasing memory available for apps. Even if the extra memory wasn't required by a running game, the ability for ELKS to respond to, say FTP requests or even have ktcp run in HMA or UMB memory could be a big enhancement.

Thoughts?

[FrenkelS]

Sounds good.

BTW, ElksDoom doesn't need one contiguous block of memory anymore. It now calls fmemalloc() up to 10 times.