VGA mode in libc

[toncho11]

@ghaerr

Is it possible to add the inline asm code from:
https://github.com/ghaerr/elks/wiki/Coding-games-for-ELKS#2-using-direct-access-to-the-vga-memory that initializes the VGA mode to libc?

It could be a header "vgalib.h" with 1 function and several defines:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define VGA_256_COLOR_MODE  0x13      /* use to set 256-color mode. */
#define TEXT_MODE           0x03      /* use to set 80x25 text mode. */

typedef unsigned char  byte;

byte __far *VGA=(byte __far *)0xA0000000L;

void set_mode(byte mode);

This could be used by the new 8086 tool-chain, elksdoom developed by @FrenkelS and our basic interpreter for example. It will give common ground for future VGA development. The VGA will be set differently if needed - for PC98 for example, but will not require changing the program that uses the header.

[ghaerr]

Is it possible to add the inline asm code from:

It is possible I suppose, but I don't think it necessarily a good idea, for the following reasons:

• The code doesn't really do much, and is only compatible with VGA (not EGA or CGA or PC-98). Very many ELKS systems don't have a VGA adaptor, and this code doesn't manage between the display types. The actual drawing capability is limited to drawing single points, no line, circle, rectangle, fill or other basic graphics functions.
• Doom doesn't actually use this code; it uses a much larger assembly-only source file for implementing extremely fast screen access.
• Our Basic interpreter uses separate graphics functions for IBM PC and PC-98; vgalib.h won't help with an compatibility for what is expected in a library routine, which would be expected to work for all systems. Also, both our IBM and PC-98 graphics routines, although considerably more complicated than this, are frankly too slow for anything usable in but the most graphics or games.
• Plotting a pixel is an extremely basic operation, much more is needed. For this we already have Nano-X, which seamlessly handles much more complex graphics. I would suggest that we push for programmers to use Nano-X for building graphical applications for ELKS, rather than starting from scratch rebuilding (slowly) what Nano-X already does. We could add Nano-X capability into libc, for instance, if this sort of thing mattered in libc.

In summary, Vgalib.h can't be used by our new toolchain, as it doesn't support __far pointers, and this code can't be used in our Basic interpreter nor is it usable in Doom.

Further discussion points might be: what real usefulness does adding a super-simple vgalib.h add? What types of actual programs would be written, and why would we want them to use vgalib.h rather than Nano-X? For instance, ported games will always use their already-existing routines written for speed, which is very necessary on legacy non-framebuffer systems. New graphical applications should probably be pushed into the direction of Nano-X, especially with the new work allowing for multiple graphical applications to run concurrently.

[toncho11]

The idea of this post was actually to only switch to graphical mode and back. It was not to create an entire graphical library. So it could be called "vgamode.h" instead.

The target of this post is this code:

void set_mode(byte mode)
{
   // SI, DI, BP, ES and probably DS are to be saved
   // cli and sti are used to make a proper BIOS call from ELKS
   __asm__(
  "push %%si;"
  "push %%di;"
  "push %%bp;"
  "push %%es;"
  "cli;"
  "mov %%ah,0;" 
  "mov %%al,%0;" 
  "int $0x10;"
  "sti;"
  "pop %%es;"
  "pop %%bp;"
  "pop %%di;"
  "pop %%si;"
     : /* no outputs */
     : "r" (mode)
     : ); //list of modified registers
}

that I remember providing to Doom.

So what I wanted is to play with VGA with the new 8086-toolchian. But now I need the above assembly code to do it. So how do I do that? I suppose an assembler .as file can be created that I can link against. That we will leave only the problem with (byte __far *) pointer? Or maybe there is a simpler way to access the video memory compatible with the 8086-toolchain?
So let's focus on how to add VGA access to the toolchain. If you think that porting Nano-X to the 8086-toolchain is better, then it is OK for me. But it looks like a big project.

[ghaerr]

The idea of this post was actually to only switch to graphical mode and back

Ok. Lets start with the C86 toolchain, since that's what you're interested in and each compiler would need a special implementation anyways. C86 has an asm directive, but I've never tested or used it. Nonetheless, switching modes is the simple part; accessing video ram at A000 will likely require a function call. C86 supposedly supports inline functions, but they were discussed as possibly buggy by BYU. The hard part will be making this anywhere near fast enough to be useful for other than experimentation.

I'll look further into this and respond with something you can play with, rather than adding immediately to libc, thank you!

[rafael2k]

If you implement this function, I can test in the image viewer I plan to develop.