OSDev.org

Hello OSDev. I am fairly new to OS development, however I have some experience with programming in general.
I've read several articles on the wiki and elsewhere and have been able to get a vague idea of how things fit together, however I still have some questions regarding the feasibility of what I want to do.

First of all, I've been exploring various options to implement a game of mine. The hardware platform is the x86 PC, and ontop of that I'm sure you know there are a myriad of available software platforms to utilize (just to name a few: Adobe Flash, Unity Engine, Java, C++, etc). After having tried some of the higher level platforms, I've found that I have a preference for more lower level environments, i.e. down to C++, then C, then usermode assembly. Now I've ventured even closer to the hardware with seeing how OS's are made.

It seems that a lot of the discussion here concerns general purpose Operating Systems, but how feasible would it be to skip all that and go straight to game code, right from the first loaded sector? Have people done it before? Would it be feasible to incorporate truecolor graphics, realtime PCM audio, etc?

At this point portability is of no concern to me, I'd only care about being able to run it on my machine or an emulator.

Thanks for any feedback.

If you are clever enough it would be possible. But you are in essence creating a full operating system for the computer. TBH, I doubt that you could write a more efficient operating system than those that are already available, so it depends upon what your motives are. And I can't think why anyone would want to do that and then constrain it to just run games.

If you want to produce a system that will run games more efficiently then forget it; life's too short. If you just want to play about for the fun of it then go ahead. But before adding the extra complication of running games I would start with just writing a simple operating system; that will keep you occupied for a while.

I heard of an OS, called DexOS. It is a megalithic operating system, aimed at running games and some multimedia applications only, just like these console OSes. If you want to write a kernel-mode game, you'll need to implement a simple OS anyway, so I'd suggest you to write something like DexOS, if you really want.

Hi,

Cinolt wrote:It seems that a lot of the discussion here concerns general purpose Operating Systems, but how feasible would it be to skip all that and go straight to game code, right from the first loaded sector?

The main problem is that for 80x86 there's a wide variety of different hardware - the video card might be an old Intel onboard thing or a recent high-end NVidia card or anything else; the networking might be gigabit ethernet or wifi or a USB device that connects to a mobile phone network; the storage devices might be PATA or SATA or SCSI or USB; etc.

So that software is able to cope with such a wide variety of different pieces of hardware you need abstractions. For example, instead of building code to support 50 different sound cards into every single game, you'd have some sort of "sound API" that's provided by the OS where the OS (and not the game) provides code to support whichever sound card/s are actually present (device drivers).

It's not just devices that need abstractions - different computers have different amounts of RAM and different physical address space layouts, different numbers of CPUs, different types of CPUs and different topologies (e.g. SMP vs. NUMA, etc). These things are all hidden behind abstractions too (e.g. virtual memory so software needn't care about all the differences in physical memory, threads so that software needn't care about the actual number of CPUs, etc).

Mostly, you'd be using abstractions to provide an execution environment that software (games) can depend on.

Of course this isn't a thin layer of abstractions - it's a hierarchical tree. For example; a device driver for a USB mouse doesn't want to have to deal with all the different types of USB hubs and USB controllers, and you'd want to provide a nice "USB controller abstraction" that USB device drivers can depend on; and a USB controller driver doesn't want to have to deal with all the different IRQ delivery schemes (PIC, IO APIC, MSI, etc) and would want to nice clean IRQ abstraction instead; and all of the device drivers are going to want something for memory management, etc.

However; that's not all - you also need other things. Tools to install/remove drivers (and find out if they're working and/or why they aren't), tools to install/remove games, tools to manage file systems, tools to backup (e.g. copy save game files onto USB flash?), configure networking, update the OS/drivers/tools/games, etc. Then you need some generic user interface that's run when nothing else is running (e.g. maybe just a pretty menu thing that lets the user select a game to play with a few smaller configuration and maintenance menus; but maybe you also want user login and different user profiles so different people unlock different parts of different games and maybe also parental controls so that little Jimmy can't play his father's adult's only games).

The only other alternative is to require a specific set of hardware, so that you don't need abstractions as much - e.g. the CPU must be a 733 MHz Pentium III, there must be 64 MiB of RAM, the GPU must be a specific NVidia chip, only one specific type of input device, etc. This is exactly what games consoles do (and why you can't upgrade a games console or run older games on a new games console). In this case, unless you're able to supply the hardware yourself (and able to get contracts from hardware supplies to ensure the hardware you depend on is still available in 6 months time), the chance of anyone having the exact same hardware is almost zero. It's not a sane option for most people.

Basically; you need an OS. The OS may be designed for games (e.g. lower level abstractions, certain things (multi-tasking?) not supported, no security, etc), but it's still an OS.

Cinolt wrote:Would it be feasible to incorporate truecolor graphics, realtime PCM audio, etc?

Possibly.

For games, end users expect a lot (full 3D acceleration) and supporting that is a massive challenge; partly because it's extremely overcomplicated (e.g. it includes writing compilers to convert "shader language" source code into the GPU's native code) and for a lot of video cards the hardware isn't documented. Even for simpler things (e.g. sound cards) it's too much work for one person to support all of them.

What this mostly means is that you need fallbacks (e.g. if there's no sound card driver maybe you can use the PC speaker as a fallback, and maybe if there's no video driver you can use software rendering as a fallback); and you will end up relying on volunteers to develop device drivers; and you need to make it possible/easy for those volunteers. This includes publishing formal specifications for all of your abstractions/APIs (e.g. so that someone writing a driver knows what they have to do and which APIs they can rely on), and providing some sort of developer toolkit (e.g. cross-compiler, libraries, whatever) that they can use to create drivers (and games), etc.


Cheers,

Brendan

It depends on the game. A simple tile based game, running at 640x480 with 16 colors and no sound and only keyboard input would be fairly simple to create using only assembly.

Anything beyond that would probably take years of work.

The key would be to treat the PC as a console system, using only hardware that is guaranteed on virtually all x86 systems. (VGA, PS2 keyboard/mouse, 640KB of system memory, PC Speaker, etc.)

Not recommended, but yes, technically, it would be possible.

Using an emulator would make things a bit easier. It essentially gives you a better "console" to work with. However, be aware that modern hardware (nvidia, ati, usb, etc.) requires a lot more work to support than older hardware (soundblaster, VGA, PS2, etc.).

Just be prepared to spend a lot of time on this project.

Thank you all for your insights.

iansjack wrote:If you are clever enough it would be possible. But you are in essence creating a full operating system for the computer. TBH, I doubt that you could write a more efficient operating system than those that are already available, so it depends upon what your motives are. And I can't think why anyone would want to do that and then constrain it to just run games.

If you want to produce a system that will run games more efficiently then forget it; life's too short. If you just want to play about for the fun of it then go ahead. But before adding the extra complication of running games I would start with just writing a simple operating system; that will keep you occupied for a while.

There seems to be many parts to a "full" operating system that I would not be interested in implementing (e.g. I wouldn't even need a filesystem), so I agree with you that I couldn't reasonably compete with operating systems like Windows or Linux, however that is not the premise. Rather than an operating system that hosts several games, it's more like the kernel itself IS the game, that has access to a very raw interface to the hardware.

Roman wrote:I heard of an OS, called DexOS. It is a megalithic operating system, aimed at running games and some multimedia applications only, just like these console OSes. If you want to write a kernel-mode game, you'll need to implement a simple OS anyway, so I'd suggest you to write something like DexOS, if you really want.

Thanks for sharing, but it seems the website for that OS is down.

Brendan wrote:The main problem is that for 80x86 there's a wide variety of different hardware - the video card might be an old Intel onboard thing or a recent high-end NVidia card or anything else; the networking might be gigabit ethernet or wifi or a USB device that connects to a mobile phone network; the storage devices might be PATA or SATA or SCSI or USB; etc.

This is a point that I've suspected with the PC platform - all sorts of devices can plug into it that have to be recognized by the OS. However my goal isn't really a distributable OS, rather just something I can play with on my local machine.

Brendan wrote:Basically; you need an OS. The OS may be designed for games (e.g. lower level abstractions, certain things (multi-tasking?) not supported, no security, etc), but it's still an OS.

I want to see how far I can push the limit for how small an "OS" can be made to achieve only one specific task, in this case a game.

Brendan wrote:What this mostly means is that you need fallbacks (e.g. if there's no sound card driver maybe you can use the PC speaker as a fallback, and maybe if there's no video driver you can use software rendering as a fallback); and you will end up relying on volunteers to develop device drivers; and you need to make it possible/easy for those volunteers. This includes publishing formal specifications for all of your abstractions/APIs (e.g. so that someone writing a driver knows what they have to do and which APIs they can rely on), and providing some sort of developer toolkit (e.g. cross-compiler, libraries, whatever) that they can use to create drivers (and games), etc.

I see. Just to get a general picture, what does a specific device driver usually entail? Like does it just implement API functions in terms of CPU in/out instructions to communicate to a controller?

SpyderTL wrote:It depends on the game. A simple tile based game, running at 640x480 with 16 colors and no sound and only keyboard input would be fairly simple to create using only assembly.

Ah, then this might be a first milestone. One of the main attractions for me doing this is to somehow hook the Vertical Reset signal to have the game logic proceed purely around that, rather than how most usermode games are based around a CPU loop. Wonder if that's possible with just BIOS/VGA/VESA.

And yes, I am aware of V-Sync on usermode, but I want something more direct and know exactly of each video frame.

Are you perhaps looking for something akin to FreeRTOS or BareMetalOS? Those are designed to be extremely small OSes designed to run a single program over them; in your case, a game. The concept of running a single program without a "big" OS running under it has been explored before. As stated, your game will be limited in performance, but to fix that you'll need to write a slew of extremely complex drivers that will take you years to finish.

It might also be fun to write something for an older system like one of the Ataris (Atari 800, Atari 2600?). The hardware is much simpler, and very geared toward games. There's a lot of fun to be had working out how to do fancy stuff with those kinds of limitations.

Cinolt wrote:Would it be feasible to incorporate truecolor graphics, realtime PCM audio, etc?

I suppose it is not feasible for one person project.

You have to use very decent resolution and no hardware acceleration, that's why there will be no really visually attractive game. To achieve a good resolution and get hardware acceleration you need to know a lot about proprietary hardware, which is not documented. The lack of documentation leads to efforts like hardware driver decompilation with the goal of reverse engineering of the hardware internals. It takes a lot of time. Another way is to reverse engineer a suitable open source linux driver. But I doubt there are such drivers for modern video hardware. So you have to reverse engineer from machine code of a driver. But a typical video driver includes a lot of code, including a compiler from a high level graphics language. So, it would take years to have support for just one modern video card.

But if you consider some non-x86 architectures, then there is a place for an attractive graphics. For example, the Raspberry-Pi has documentation for it's video hardware and you can create some visually nice things much quicker, than it would take for x86 architecture. But the performance of the Raspberry-Pi platform is very decent, so maybe it can be outperformed with a software only solution for x86 architecture, except the high resolution, which still requires a missed documentation.

Cinolt wrote:I want to see how far I can push the limit for how small an "OS" can be made to achieve only one specific task, in this case a game.

An OS can be as small as a bootloader and a keyboard driver. Or it even can be a bootloader only for some non-interactive visualization.

But what is the benefits for a game if an OS is removed? It will be slower and visually less attractive. But what can be enhanced?

Not really sure if this adds to the discussion,

I've had this sort of idea, but I failed to produce anything useful, however during my "research" I got a very interesting little project.

https://github.com/Overv/MineAssemble

It's basically an attempt to create a (limited) bootable clone of a famous PC game called Minecraft.

You'd want to check out some low level documentation on Graphics Processors,
http://renderingpipeline.com/graphics-l ... mentation/
(Although intended for those who want to escape the conventional graphics API, but I think the documents also teach you a lot about their GPUs)

Some guys here have managed to write drivers for a few old graphics cards. Although I don't seem to remember the name of the GPU in question nor I have the link with me right now.

That was probably the best I could dig out, a Google Search could provide better results.

Bender wrote:You'd want to check out some low level documentation on Graphics Processors,
http://renderingpipeline.com/graphics-l ... mentation/

Thanks for the link. For Intel graphics it has a very convenient list. Unfortunately, the AMD and Radeon links are mostly dead (404). And Nvidia has some white papers, but nothing more.

But after following the link I have spent some time reading Intel's docs and it seems that it is possible to write an OS with Intel hardware accelerated graphics and VGA fall back for other vendors. AMD's documentation seems inferior in comparison with Intel's, but still is useful enough.

And about the limits an OS creates for graphics programming. It just constrains a developer with the only development path, selected by some unclear process within the graphics industry. So if we have relatively good documentation (like Intel's), then we can determine our path by ourself. It is an interesting option. But it requires a great deal of learning and working with graphics until GPU usage familiarity will open for us some new ways of graphics development. Only if somebody already has some deep understanding of the whole graphics process, only then it is possible to improve it.

But may be the current way of doing graphics is efficient enough to challenge it with something new?

Are you thinking about a PC Booter game of the early PC days?

eryjus wrote:Are you thinking about a PC Booter game of the early PC days?

Ah, so this is what it's called. I knew I wasn't the first to think of it.

In any case, as I don't care much for compatibility and I'm on a MacBook that supports UEFI, I've decided to learn UEFI from the ground up and basically experiment with what I can do in the "pre-boot" environment once I get there.