Roundtable: Operating System For Game Consoles

Posted 24 Jun 2002 at 19:17 UTC by nymia Share This

I would like to solicit comments and suggestions from those interested in identifying major and minor features of an operating system suitable for a game console.

The basic items of what a game console should have are the following:

  • Boot sequence
  • Devices
  • Graphics API
Boot Sequence

Boot sequence is basically the steps required in bringing up the parts of the console to a known state. They may be stable or unstable, but in this case, it must be stable. Also, the sequence is entirely different from a desktop since the devices connected to a console are totally different from a desktop.

Consoles boot their system in order to get the players up and running within the shortest possible time. There are no OS utilities visible for one to see, once the system state is known the game is immediately loaded. That is pretty much what the role of the OS will probably be, though.

Devices

Consoles have only controllers like paddle, joystick and gamepad as primary devices. The OS is basically hardwired to poll or even respond via interrupts. Given these requirements, the next step then is to figure out how an existing kernel or operating system can be modified to handle them.

With regards to event handling, there are ways and means of handling them and one of them is by setting up a mapping scheme classifying controller events within the following areas:
  • Genre - Racing, RPG, etc
  • Event ID - RACE_LEFTBTN, RPG_SQUEEZE_TRIGGER, etc
Graphics API

In the Free Software and Open Source world, there are literally many graphics APIs that are available. Many of these are already running on different levels, example are SVGALib, OpenGL, Mesa, LibDream, SDL, Etc. One good idea for the 'open' gaming console to be useful, though, is to figure out a way of providing them the interface necessary to get them working on-the-fly.

Questions, Discussion and Comments

With all these information, some questions come to mind like Linux, *BSD, Kallistios, NewOS and other kernel and OS out there are suitable for a game console.

Also, this section is pretty much open, any input is appreciated. Thanks.


colorForth, of course, posted 24 Jun 2002 at 19:55 UTC by mslicker » (Journeyer)

colorForth immediately comes to mind. The operating system/language/development environment is about 2k x86 assembler source. It should be fairly easy to port to various game consoles given the specifications for the console.

If there is a keyboard available for the console, this is ideal since you can interactively develop code, hardware device drivers, right on the target platform. Otherwise you would need to set up a similar environment on the PC and cross-compile to the target console.

The actual language environment is state of the art. Machine code macros allow you to program directly to the metal, which is esential for game consoles. The interactive nature of the environment is unmached, especially for the general high performance you get.

Re: colorForth, posted 24 Jun 2002 at 22:50 UTC by nymia » (Master)

Just went and looked at the info in their pages and it looks like there could some issues like:

  • Not enough graphics API to support commercial quality games.
  • No support for existing graphics APIs running on Linux/BSD/BeOS/Windows
What I was thinking was about tweaking a mature kernel or OS, tailoring it in such a way it will work on PC parts available off-the-shelf. For example, let's say tweaking an OS like <insert your favorite distro> Linux, removing all the programs related to a desktop or server, replacing it and/or adding it with utilities and other code specifically for an (embedded PC) game console.

By building on the previous work of others, and probably modifying some of them to suit certain tasks, it may greatly save time and money.

If I may put it as a question, is it possible to tweak an existing OS, modifying it in such a way it will behave like a game console?

No shell, login, daemon. Anything related to a desktop or server will be taken out, what will only remain are parts necessary in loading a game. These games are basically written using C or C++ (having OpenGL or graphics API support) on a Linux, BeOS, BSD or Windows platform.

Also, are there kernels out there that already have these characteristics? Turning a PC into a game console by just booting from a CD containing game code?

colorForth, posted 24 Jun 2002 at 23:32 UTC by mslicker » (Journeyer)

Might not be right for you, but I thought I would sugest it since it really is ideal for such applications. Also note the most impressive games are usually written from scratch and are highley tuned for the specific hardware.

As for using the various Unixes, I let others comment. I's very hard for me to make sense of it all. However, I will point out, it may be more work to get these Unixes to the point you want them, instead of just starting from scratch or modifying something like colorForth. Of course the result will inferior to the latter.

Real-time scheduling, posted 25 Jun 2002 at 00:00 UTC by Pseudonym » (Journeyer)

I would have thought that two of the key features required were low latency and soft real-time scheduling. If there's one thing a game player doesn't want to see, it's sluggish response. Jerky animation would also be bad, but it would be more forgivable, because it's not so distracting when you're trying to concentrate on game play.

Given this, my choices would be (in approximate order of preference): BeOS, QNX, Linux with low-latency patches, ChorusOS and Linux with one of the many real-time patches. Eros might eventually get there, too.

Re: Real-time scheduling, posted 25 Jun 2002 at 01:50 UTC by nymia » (Master)

That's a very good point, I wonder how system events like interrupts influence framerate, though. I don't have numbers with me at the moment, but will spend some time looking for performance test results for Linux and other kernels. Although the linux kernel isn't a straight-out real-time, considering the single process nature of the game that it might just work. This is definitely a good area worth spending time on.

Minimal hardware abstraction, posted 25 Jun 2002 at 02:00 UTC by tk » (Observer)

Besides real-time scheduling, I think a feature which a good game console OS should have is minimal abstraction of the hardware -- preferably none at all. That means, a game program should be allowed to directly access hardware using machine instructions (on the x86, these'll be mov/in/outetc.), and also hook hardware interrupts to go direct to its own code, instead of always going through the OS.

Linux has limited support for the former (via the iopl() and ioperm() syscalls, and /dev/mem), but not the latter it seems.

DOS, e.g. FreeDOS, allows one to directly manipulate the bare metal of the PC, and thus I think makes a good game OS.

reply, posted 25 Jun 2002 at 02:04 UTC by nymia » (Master)

Might not be right for you, but I thought I would sugest it since it really is ideal for such applications. Also note the most impressive games are usually written from scratch and are highley tuned for the specific hardware.

I agree with this entirely, but this route will probably cost more time and money, though, in which I currently don't have. While there is no doubt about the opportunity to maximize on performance is there, the cost associated to it might just barely make it even when compared to already available ones.

re: Abstraction, posted 25 Jun 2002 at 02:16 UTC by nymia » (Master)

That's another point worth considering, at what level should the API expose the hardware while maintaining compatibility with OpenGL and other graphics APIs. Is this possible? most APIs or engines I see today seem to be abstractions of the hardware itself though. But that would defeat portability in terms of supporting existing games running on OpenGL and other graphics APIs.

Another item worth considering is the video chips driver. Questions like availability of a Data Book for these chips must be available, though. One reason I raised Linux as a candidate kernel is it wide support for video chips.

Re: Abstraction, posted 25 Jun 2002 at 02:56 UTC by tk » (Observer)

On the problem of video card support, I'd have thought that for a game console, you just choose an arbitrary video card and go with that -- there's no need to cater to the wide variety of hardware commonly used on PCs.

On game library support: I tend to see libraries more as part of the application, rather than part of the execution environment. There's actually no need for an OS to present e.g. an OpenGL interface to the rest of the world. If a game needs OpenGL, one just statically links OpenGL to it.

I mentioned DOS. A number of game libraries have already been ported to DOS. Allegro comes to mind; it runs on top of DJGPP, a port of the GNU development chain to (32-bit) DOS.

Ideally, a developer of a new game would just program directly for the hardware of the game console, instead of using existing game libraries. But the latter is still a possibility.

Kernel Space Code, posted 25 Jun 2002 at 04:05 UTC by nymia » (Master)

Regarding code, would it be possible to put all code, that is, graphics API and the game code itself in kernel space? It looks, though, that the idea tk put forward seems to be a good candidate for a single-image code burned-in the CDROM.

Since the game itself is the only user in the OS, it might as well be placed in kernel space. Code in this space can directly touch Video Ram, if I'm not mistaken.

Kernel Space Code + V2_OS, posted 25 Jun 2002 at 10:41 UTC by tk » (Observer)

Since the game itself is the only user in the OS, it might as well be placed in kernel space. Code in this space can directly touch Video Ram, if I'm not mistaken.

In other words, eliminating the OS. Actually this is what some very old games used to do. :)

Besides colorForth, FreeDOS and friends, you may also want to look at V2_OS.

Network support, posted 25 Jun 2002 at 16:46 UTC by tjansen » (Journeyer)

Don't forget that for a modern console you probably want network support, which includes a TCP/IP stack and support for modems or PPPOE for DSL.

additions, posted 25 Jun 2002 at 16:57 UTC by mslicker » (Journeyer)

Real-time scheduling is irrelevant. Games only need a single thread of execution, at least if your not too slopy. Interrupts are precisely that, they happen on their own, all you need to do is hook in your interrupt handlers. You may not even use interrupts and op for polling instead.

Most of code of an OS like Linux is going to be useless for a game. Memory management, hardware memory proection, multitasking, ect. Best to strip out the code you want instead of modifing, and removing the code you don't want.

An idea I thought of is this. Why not emulate the system calls used by the OpenGL software such that OpenGL sits right on top of the hardware? OpenGL is probably the only library you want anyway, just so you don't have to worry about every possible device if your targeting the generic PC platform.

reply, posted 25 Jun 2002 at 18:57 UTC by nymia » (Master)

Most of code of an OS like Linux is going to be useless for a game. Memory management, hardware memory proection, multitasking, ect. Best to strip out the code you want instead of modifing, and removing the code you don't want.
There is one operating system called Kallistios. Looking at their CVS files show the OS is specifically designed for a gaming system, though. It has OpenGL headers, including gl.h and glu.h. Also has vorbis support as well.

If only there is a way of drilling through the Linux layers down to the kernel level, placing one simple block and calling it something similar to a DirectX 8.0 or 9.0 module, those graphics drivers can be used for other tasks as well.

An idea I thought of is this. Why not emulate the system calls used by the OpenGL software such that OpenGL sits right on top of the hardware? OpenGL is probably the only library you want anyway, just so you don't have to worry about every possible device if your targeting the generic PC platform.
This is a good approach, similar to DirectX. Maybe putting the GL code beside libc or probably adding it into libc itself. Of course, the resulting package is specifically made for gaming. Not that it will become part of the desktop or server distribution, maybe a game distribution would probably be needed anyway for holding all these modifications.

It looks like the approach I'm trying to create is something similar to a fixer-upper. While it may be good in a certain sense, this approach might not be a good, though. Right now, I'm still 50/50 on that one whether it is good or not.

Goal?, posted 26 Jun 2002 at 03:31 UTC by tk » (Observer)

I'm not sure what exactly your goal is here. After all, GPL Doom runs happily off an unmodified (N.B.) Linux kernel. Just create an ext2 partition, throw in a stock kernel, the Doom files and a few required shared libraries, start the kernel with a boot option like init=/usr/local/bin/doom, and next you know, you're playing Doom.

But I guess you want something more than that.

Real-time, hardware etc, posted 26 Jun 2002 at 05:56 UTC by Pseudonym » (Journeyer)

Real-time scheduling is irrelevant. Games only need a single thread of execution, at least if your not too slopy.

Once upon a time that was true. Nowadays most of the higher-end games are deliberately written using a client/server architecture in order to make network play easy. When it's just you playing, the server runs on the same machine as the client. That's at least two threads of execution to begin with.

Another thing to consider is that nobody buys a console which can only play games any more. If it can't at least play CDs (even better if it plays DVDs), what's the point? Of course you don't need to do this at the same time as playing games. (Perhaps. You might reasonably pull the game's soundtrack off the audio part of a CD and/or pull cut scenes out of DVD-esque files if you're going to the trouble anyway.) You may be able to do this reasonably with a single thread of execution, but then again, you might not.

On the question of real-time scheduling: you don't really need it, no. What you really want is low latency scheduling, and the two are often found together.

nymia, in a low-latency OS, interrupt delivery doesn't interfere with other tasks (or delivery of other kinds of interrupt) because interrupts are never disabled for very long. I won't go into detail, but ideally, when you're executing an interrupt handler for a device, you should a) only block other interrupts from that device (i.e. interrupts for other devices or system events should be deliverable), and b) do only that which absolutely must be done before the interrupt handler returns, deferring other stuff to a thread which can be scheduled along with any other thread. This way if, say, you think that TCP/IP is less important than refreshing the video, you can set your TCP/IP stack threads to run at a lower priority than the video refresh threads.

Moreover, and perhaps more importantly, each game writer can make this decision for themselves. This, I think, is the most important consideration. Games are one of the most innovative areas around, and the last thing you want to do is prevent Mr Carmack from using some very cool technique just because you thought he would never need multiple threads or multiple address spaces.

Re: Real-time, hardware, posted 26 Jun 2002 at 06:09 UTC by tk » (Observer)

You're making the underlying assumption that the role of the OS is to act as a straitjacket for applications. This is not true.

single thread of execution, posted 26 Jun 2002 at 16:41 UTC by mslicker » (Journeyer)

You are quite wrong.

Given a single thread of execution unimpeded by hardware protection mechanisms, you can divide the execution space in any way you please. This could include Linux-style preemptive multitasking, but it's unlikely an intelligent programmer would choose such a thing.

You use Carmack as an example of innovation, yet he has been producing the same game for the last ten years! Hardly what I call innovation. I haven't payed attention to games as of late, there may be some who are doing innovative things. However it is quite unlikely, games are yet another entertainment industry, as such you are guaranteed to get more or less the same mindless unimaginative games repackaged every year as "new" or "innovative".

'go' game console, posted 26 Jun 2002 at 21:03 UTC by badvogato » (Master)

any one care to comment on this thread of a very primitive idea about a 'go' game console design ? Also, is anybody here familar with Joseki/Fuseki Go books? It is my opinion that Joseki/Fuseki is THE theory of parallel computing by indigenous people. The bigger question due to the constraints carried by modern computing piggy bag is how to implement a non-deterministic scheme with an arbitary deterministic language on a Von Neumann machine?

'go' game console, posted 26 Jun 2002 at 21:03 UTC by badvogato » (Master)

any one care to comment on this thread of a very primitive idea about a 'go' game console design ? Also, is anybody here familar with Joseki/Fuseki Go books? It is my opinion that Joseki/Fuseki is THE theory of parallel computing by indigenous people. The bigger question due to the constraints carried by modern computing piggy bag is how to implement a non-deterministic scheme with an arbitary deterministic language on a Von Neumann machine?

reply, posted 26 Jun 2002 at 21:17 UTC by nymia » (Master)

GPL Doom runs happily off an unmodified (N.B.) Linux kernel. Just create an ext2 partition, throw in a stock kernel, the Doom files and a few required shared libraries, start the kernel with a boot option like init=/usr/local/bin/doom, and next you know, you're playing Doom.
This is an interesting approach, I wonder how the Doom developers managed to implement them. What is ideal, in my case, is basically shop for kernels or OSes that are good candidates for console gaming. And this (Doom implementation) approach could be a good one. Using a stock off-the-shelf OS or kernel is definitely the easiest and simplest approach, though.

With the current generation of graphics processor, it would probably be OK to use non-real-time kernels, since most of the graphics work will be handled by the graphics processor. Two processors (main and graphics) handling different task will mean less work for the main CPU. While there will be penalties involved in choosing stock kernels/OSes, the savings in both time and money might justify them, in the long run. Unless, the Linux kernel team changes their mind and accomodates the game console requirement. I doubt it will happen anytime soon.

reply, posted 26 Jun 2002 at 21:54 UTC by nymia » (Master)

in a low-latency OS, interrupt delivery doesn't interfere with other tasks (or delivery of other kinds of interrupt) because interrupts are never disabled for very long. I won't go into detail, but ideally, when you're executing an interrupt handler for a device, you should a) only block other interrupts from that device (i.e. interrupts for other devices or system events should be deliverable), and b) do only that which absolutely must be done before the interrupt handler returns, deferring other stuff to a thread which can be scheduled along with any other thread. This way if, say, you think that TCP/IP is less important than refreshing the video, you can set your TCP/IP stack threads to run at a lower priority than the video refresh threads.
Agreed, that is also one issue since there is only one processor handling the interrupt. Although multi-processors might allow interrupt servicing to happen in parallel, I doubt it will become the norm anytime soon.

IMO, if framerate and buffering of vertex, texture and other data are within the bounds of acceptable performance, game experience will probably not get compromised.

What if one throws a large RAM memory into the spec? like 255Mb will definitely help in the rendering process, though. Freeing the main CPU to interrupt servicing and loading of game data.

It also shows the major differences between desktop/server against game consoles. Graphics in desktop apps like wordprocessors and spreadsheets don't cover framerate, though. And servers have no notion of rendering to local Video Ram either. Kernel and OS implementation will probably be different for game consoles in terms of priority as these items will undoubtedly fall under the programmer's list.

Role of the OS, posted 27 Jun 2002 at 00:01 UTC by Pseudonym » (Journeyer)

You're making the underlying assumption that the role of the OS is to act as a straitjacket for applications. This is not true.

It is not true that this is my underlying assumption. :-)

The role of the OS in this case is to give an appropriate abstraction of the underlying hardware. The point where we differ is in what we consider "appropriate".

For example, IMO it is appropriate for a games console to provide an environment which eases porting to other platforms and, much more importantly, to the next generation of the same platform.

Besides, requring the developer to re-implement basic services provided by any other platform is a waste of the developers' time, especially in an industry when deadlines are very tight and life cycles are very short.

Doom and stuff, posted 27 Jun 2002 at 07:03 UTC by tk » (Observer)

I wonder how the Doom developers managed to implement them.

The Doom developers achieved this through the use of clever coding techniques, as well as the use of a linear addressing screen mode (320x200x256 if I'm not wrong). This allowed Doom to run well even on a dingy old 386 running DOS.

If you just want to make a game console and get it running something as quickly as possible, using a stock kernel and throwing in loads of computing power and memory is likely a good way to go. However if you'd like to, say, reduce hardware costs, it may be worthwhile to find ways to cut down on the resources needed by your games.

Role of the OS, posted 27 Jun 2002 at 23:53 UTC by mslicker » (Journeyer)

Writing a game from scratch for the PC platform is next to impossible, I agree.

On a game console, I don't think it is nearly as hard starting from scratch. All that is needed is simple examples, "this how you read the joystick", "this is how you read from the CD", ect.. These could even be used verbatim in your game. If you actually signed up for the developer program for Nintendo or Sony, I sure that this is most likely what you would get. I really doubt games on these systems use gigantic operating systems like linux or windows.

For the PC, it's very hard to find to simple examples. Usually you have dig through a piles of source code to see how something is done, otherwise there doesn't seem to be the documentation. Hardware manufactures are reluctant to give out specs, even at the register level. This problem is compounded by the fact there are hundreds if not thousands of cards of each type. Really the PC is the nightmare of the software developer, unless isolated by layer ontop of layer of software abstraction. This only gives the devloper a new problem to deal with, albeit one of smaller magnitude.

Although nymia has not really spelled out what he wants to do, it probably is best to run on a stock operating system. I can't imagine a game that runs on the bare hardware selling on PC. You'll have hard enough time trying to sell it to a distributer.

reply, posted 28 Jun 2002 at 02:49 UTC by nymia » (Master)

Although nymia has not really spelled out what he wants to do

Check this entry to see the things I'm trying to figure out, specifically, the Open Console part.

correction, posted 28 Jun 2002 at 04:29 UTC by nymia » (Master)

Need to make a correction, the proper link to the Open Console part is here.

The idea is basically come up with a spec containing hardware and software for a game console, using standard off-the-shelf parts. Another is also figure out an SDK once the spec goes into stable design.

reply, posted 28 Jun 2002 at 04:37 UTC by nymia » (Master)

Writing a game from scratch for the PC platform is next to impossible
This is probably one point worth taking note of, definitely they must be considered since a lot of these parts are basically coming from the PC. Although they are PC parts, the end result will not look like a PC, rather it will look like a game console.

Regarding game development, since the development model will follow closely the PC, it might be also be OK to use the PC development model as a base for the developing games for the console. This goes in-line with the idea of rolling-out an SDK specifically for the Open Console spec.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page