elks
elks copied to clipboard
ghaerr
Games development on ELKS
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,soundandnosoundare 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,clrscrandgetchare 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
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).
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").
I remember the times when porting from Turbo C++ was all about getting rid of '#include <conio.h>' :)
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!
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.
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
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.
@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.
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.
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.
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.
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.
@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.
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.
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.
If this is the correct disassembly: DEMO3.txt
then it means that there are 19 int $0x21 DOS calls ... more than I have hoped.
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.
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.
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 .
This is a direct example of Alfonso:
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 ?
@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.
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.
Interesting ... I tried to contact Alfonso ... but there is no working email ... nor any other contact information ...
@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?
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.
I made progress. The first step is specific to Turbo C: integrate the BGI driver into the executable. This is to avoid the insertion of a code that searches for the BGI driver on the filesystem and thus requiring a lot of DOS 21 calls.
- one needs
bgiobj egavga.bgito produce egavga.obj - change the code to use registerbgidriver(EGAVGA_driver);
- build script that uses graphics.lib and egavga.obj
Here is the code:
#include<graphics.h>
#include<conio.h>
void main()
{
int gm , gd ;
int er;
gd = VGA;
gm = VGAHI;
er = registerbgidriver(EGAVGA_driver);
if( er < 0)
{
printf(" Graphics sys error :%s" , grapherrormsg(er));
getch();
exit(0);
}
initgraph(&gd , &gm , "");
outtext("hi");
getch();
closegraph();
}
And build script:
tcc demo4.c c:\tc\lib\graphics.lib c:\tc\egavga.obj
I reached a new error.
Code with minimal commands:
#include<graphics.h>
void main()
{
int gm , gd ;
int er;
gd = VGA;
gm = VGAHI;
er = registerbgidriver(EGAVGA_driver);
initgraph(&gd , &gm , "");
outtext("hi");
closegraph();
}
Next the compilation to object file is:
tcc -c -M -O -Z -a- -d -w -ms -r- -Ic:\tcc4elks\smallibc c:\tc\demo4.c
but I skipped the '-A' option that does not allow it compile (that my problem). I do not know what is it?
next is:
tlink /n /s /d demo4, demo4, demo4, c:\tcc4elks\smallibc\smallibc c:\tc\lib\graphics c:\tc\egavga.obj
And it gives error:
Turbo Link Version 2.0 Copyright (c) 1987, 1988 Borland International
Undefined symbol '_REGISTERBGIDRIVER' in module DEMO4.C
Undefined symbol '__GRAPHEXIT' in module GRAPHC
Undefined symbol '__GRAPHGETMEM' in module GRAPHC
Undefined symbol '__GRAPHFREEMEM' in module GRAPHC
Undefined symbol 'SCOPY@' in module GRAPHC
Undefined symbol 'LXMUL@' in module GRAPHC
Undefined symbol 'LDIV@' in module GRAPHC
Undefined symbol 'DGROUP@' in module GRAPH
Warning: no stack
Ok, now I can see what you're after. Sadly, back then I deliberately avoided BGI graphics as I rather preferred mode 13h and direct writes to the video memory.
@toncho11,
Does the graphics program link and run on DOS, when not linking with the tcc4elks smalllibc? It is important that everything compile, link, and run perfectly on DOS before adding the additional complexity of a substitute libc.
tlink /n /s /d demo4, demo4, demo4, c:\tcc4elks\smallibc\smallibc c:\tc\lib\graphics c:\tc\egavga.obj
After you get it working on DOS, I think the above command line has to include c0.obj or c0noargs.obj; a quick look at the c0.S source code shows it defines DGROUP and STACK.
Yes, but how did you draw a line? You did use some library I suppose?
I didn't! They were all bitmaps :)
Hello @toncho11,
Are you still working on getting Alfonso's Turbo-C -> ELKS conversion mechanism working? I've fixed ELKS to run programs converted by his exe2elks program in #890. Despite some of your last issues with getting the BGI driver linked in to the DOS program, I still think its a potentially good idea for porting DOS graphics programs to ELKS.
Thank you!
Hi,
Is it possible to write directly to video memory in ELKS? Can you do something like int 13h in DOS ? How woud you put a pixel in the video memory under ELKS?
Is it possible to write directly to video memory in ELKS? Can you do something like int 13h in DOS ?
Are you talking text or graphics? For text mode output, BIOS int 10h works well, and it writes the video memory.
For graphical mode, you have to know the card type. ELKS really only supports EGA, which uses 4-plane memory and is a bit complicated, as each plane has to be written separately. The memory is at segment B000:0000h. To see how Nano-X writes graphical pixels, look at the driver in elkscmd/nano-X/drivers/scr_bios.c, vgaplan4.c and mempl4.c.
Thank you!