3

Recently, I have been experimenting with things like arch Linux and this raised a few questions. I constantly see the use of graphics in very low level parts of an OS(things like the GRUB or almost all boot menus). Some of these even feature images. I can also see graphical manipulation in things like the "pacman" command, where the loading bar will change with out disturbing the text above it. Another example would be a program like cfdisk. I would just like to know how these types of features are programmed?

Edit: By this I mean what system calls are used to make this possible?

Boot menu

bobby
  • 57
  • 3

2 Answers2

4

This kind of thing was very common in MSDOS back when I was learning to code. There were a set of basic hardware screen modes that could be accessed through simple assembly instructions.

For those supporting ASCII character sets, it was possible to modify the actual glyph images for the characters in memory. Each available character was a simple bitmap, which could be modified in memory to look however you want.

For example, in colour screen modes (e.g. CGA, EGA), the text could be rendered via a specific memory area where one byte specified the character and the other byte specified a colour (foreground and background as 4-bits each for EGA). You just write the values in there and they show on screen. If you had modified your character table, then the modified characters would show.

I can't believe I remembered this just now, but the memory address A000 is apparently burned into my brain. You can read more at https://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter

Of course, there are higher screen modes that support writing actual pixels, and that's how we used to write games. Famously the 320x200 VGA mode was super easy and fast to get "realistic" and smooth animated graphics in mind-blowing 256 colours without worrying about bit planes or anything.

And this is essentially what's happening at the low level. BIOS support for these forgotten graphics modes has existed for a very long time, but modern hardware has abstracted us away from such modes and we now tend to communicate directly with graphics cards via a driver or OS abstractions.

paddy
  • 60,864
  • 6
  • 61
  • 103
  • Do you have any idea how I would go about this in C? I do know a fair amount of assembly but I know that Linux is primary programmed in C. – bobby Feb 15 '16 at 00:22
  • Have a look for old code dealing with setting screen modes, modifying the ASCII glyph tables, or general legacy DMA screen addressing / graphics memory segment. Probably requires a tiny amount of assembly. Should be kicking around in plenty of books from the 80s. Don't know about portability or relevance to modern hardware. Probably not an issue for you. – paddy Feb 15 '16 at 00:48
  • Maybe [this will get you started](http://assemblytutorial.blogspot.co.nz/2010/09/interrupt-10h-service-0-set-screen-mode.html). That seems familiar. Then you just find out the base address and memory layout for the specific screen mode you want, and go from there. Make a simple function in C with an inline asm block to set the interrupt. – paddy Feb 15 '16 at 00:50
  • I should add that I don't know whether this will cause any memory protection errors in Linux. I never tried. Messing around with the console TTY in a normal runlevel might not be a good idea. – paddy Feb 15 '16 at 00:56
  • I don't think any PCs or MS-DOS versions supported ASCII itself as a character set. Any tables that you would find would be CP 437, CP 850 or the [like](https://msdn.microsoft.com/en-us/library/cc195051.aspx). You would have to use one specific character set/encoding at a time so it could never be ASCII. – Tom Blodget Feb 15 '16 at 02:03
  • you probably need to run this in a dos emulator program, the bios calls were 16 bit I think and long ago they stopped thunking down to them if at all, and simply replaced them. they are likely still used for generic booting of an x86, but then the operating system takes over and has its own system calls and doesnt use the bios/dos calls after that. – old_timer Feb 15 '16 at 05:17
  • 1
    search for ralf brown's interrupt list for a full list of bios calls. look up Michael Abrash for lots of low level graphics stuff. mode x may be interesting. and the VESA stuff to try to make a more generic interface across video card vendors for the higher res video modes, you could sometimes have vesa in the bios rom or a vesa driver that was loaded later (autoexec.bat/config.sys) that basically gave you the same thing. – old_timer Feb 15 '16 at 05:20
  • the ascii character set was definitely around and known to bios and dos calls. – old_timer Feb 16 '16 at 05:29
  • @dwelch No, I think [chcp 20127](https://msdn.microsoft.com/en-us/library/windows/desktop/dd317756(v=vs.85).aspx) would give you an error on every version of MS-DOS. – Tom Blodget Feb 17 '16 at 04:26
0

I learned quite a bit on how to initialise and operate on low-level direct memory access graphics modes from the venerable Fractint (original ran on DOS). All the goodies are in a file called video.asm. In addition to EGA/VESA et. al., it also handled some of the available graphics cards at the time, like Hercules.

They chose X server to port it to linux as XFractint. Much of the original look and feel and spirit of the application remains the same. This is probably a good and safe way to start with.

For lower level may be try SVGAlib (I haven't tried this). Most of the Linux low-level graphics from kernel seems to be using VESA BIOS Extensions.

hkrish
  • 1,259
  • 1
  • 10
  • 11