   Thoughts on an ideal lightweight OS for games on small, embedded systems.
  The Thread title sort of says it all, so let me explain my motivation --In a couple months time, I'll be taking an extension certificate program through the local state university in Embedded System Development. As part of this course, we will eventually come to write our own lightwieght operating system running directly on the hardware.For hardware, we have a 60Mhz ARM7TDMI microcontroller (just like the GBA, but ~4X faster) with 32K SRAM, 512K flash, an LCD and several other inputs/peripherals.Being a game developer at heart, of course I'd like to design my system to be a very low overhead, small-footprint, gaming-friendly OS.Mind you, now, that we're talking about an Embedded Operating System -- not a desktop OS like Windows or Linux, or even DOS. In fact, much like the cartridge-based consoles of yore, its likely that the "OS" will be compiled into the game/application binary, rather than being resident on the hardware system and hosting outside applications -- but rather a sort of statically-linked, hardware specific runtime, if you will.Even back in the single-tasking DOS days, many game engines implemented simplified kernels of their own for multi-tasking and driver-like modular device support (gamepads, sound devices), and it wasn't unheard of for a game to fire up a TSR program and hook into the keyboard IRQ channel to get fast, asynchronous key-state information.With all that in mind, what features, design goals, and pie-in-the-sky ideas would you suggest? -- Particularly any of you grizzled DOS, NES, Gameboy, Genesis, SNES, GBA or arcade developers.   
  Windows, at least, is not going to let you get at the actual hardware. It's not clear to me what your OS is going to provide that 1) Windows doesn't already offer and 2) Windows will let you have.It's a great exercise, but in practical terms I see difficulties.   ;Quote:Original post by ScottMayoWindows, at least, is not going to let you get at the actual hardware. It's not clear to me what your OS is going to provide that 1) Windows doesn't already offer and 2) Windows will let you have.Last I checked, Windows doesn't run on 60MHz ARM microcontrollers with 32K of RAM...   ;  I'd just go with a BIOS-only system similar to the GBA/DS, but with functions for loading/switching programs and handling memory allocations. Also if your microcontroller has extra programmable interrupts, you may want to use them to call the BIOS(like in DOS) rather than pushing arguments and jumping.   ;  If you want to explore more than a BIOS-only solution, look at what Micro-C OS/II and eCOS do. The former is related to a pretty good book on embedded (real-time) OSes that might also be of interest (µC/OS The Real-Time Kernel by Jean J. Labrosse).Some ideas for things to implement: handle bring-up of the HW obviously, maybe provide some threading primitives and scheduling, memory management (although with 32K whats there to manage really), driving any complex hardware (the LCD). All of this you can do by providing an API via SWIs, even the scheduling (via a timer to fire an interrupt at the end of each time slice).Sounds like a lot of fun, I wish I could find an excuse to play with hardware. [lol]   ;Quote:Original post by ScottMayoWindows, at least, is not going to let you get at the actual hardware. It's not clear to me what your OS is going to provide that 1) Windows doesn't already offer and 2) Windows will let you have.Lol, sorry to say, but Windows sounds like the most impossible option out there ^^In the old Amiga days, most games switched off the OS and ran directly on the hardware. This was of course essential for the games to run well. A big advancement is if you already have set the hardware and just write software for that particular hardware (like you seem to be going to do). This is the best way to get the maximal performance.Take a look at AmigaOS, it's a desktop OS but they might go for embedded systems as well I've heard. Anyways, the OS has just one target hardware, and is really really fast. It's faster in response then this AMD quad core 2.5 GHz WindowsXP I'm using now (the Amiga has a 800Hz singe core, PPC processor). Sure, for graphics it's no match, but for 90% of all computer work it's lighting fast.   ;Quote:Original post by CodekaQuote:Original post by ScottMayoWindows, at least, is not going to let you get at the actual hardware. It's not clear to me what your OS is going to provide that 1) Windows doesn't already offer and 2) Windows will let you have.Last I checked, Windows doesn't run on 60MHz ARM microcontrollers with 32K of RAM...Geh. I'd spent part of the day with Windows CE, and did a very incomplete job of  switching mental gears. Windows in 32K.. yeah. I don't think the Windows 7 *animated logo* fits in 32K...You can write a nice little scheduler in a K or so, if you stick to simple stuff like round robin scheduling and a very simple priority scheme with inversion protection. But you aren't going to be managing very many threads if you want each thread to have any sort of stack, unless you want to swap idle threads out to the flash, and you probably don't. I think I'd focus on wrappers for the hardware devices, and see how much you have left after that. 32K. Wow. I just had a flashback to Javelin programming. I taught a pair of Javelins to be a realtime controller for a home theater, and while it worked, I beat those little guys to death and still recall finding things somewhat tight. Good luck!;Quote:Original post by ScetI'd just go with a BIOS-only system similar to the GBA/DS, but with functions for loading/switching programs and handling memory allocations. Also if your microcontroller has extra programmable interrupts, you may want to use them to call the BIOS(like in DOS) rather than pushing arguments and jumping.Since that section of the course is about developing an operating system from scratch, I probably can't get away with simply a BIOS-level project -- but adding extras like you suggest, along with modular peripheral support, would probably be ok. I'll have to read up on interrupts vs function calls -- I know the microcontroller has both hardware and software interrupts in spades.Quote:Original post by outRiderIf you want to explore more than a BIOS-only solution, look at what Micro-C OS/II and eCOS do. The former is related to a pretty good book on embedded (real-time) OSes that might also be of interest (µC/OS The Real-Time Kernel by Jean J. Labrosse).Some ideas for things to implement: handle bring-up of the HW obviously, maybe provide some threading primitives and scheduling, memory management (although with 32K whats there to manage really), driving any complex hardware (the LCD). All of this you can do by providing an API via SWIs, even the scheduling (via a timer to fire an interrupt at the end of each time slice).Sounds like a lot of fun, I wish I could find an excuse to play with hardware. [lol]Its funny you should mention that -- We're actually studying Micro-C OS/II in the second course, and porting it to our hardware board. Also, the book is already on its way to my door, even though the first class is 2 months away.I've been thinking about the multi-processing/multi-threading issue -- trying to decide if supporting multiple processes is worthwhile vs a single-process-multi-threaded system like the xbox had -- then again, at such a low level that may be little more than semantics anyhow.It does sound like its going to be a lot of fun, and work, but I'm glad I found my excuse[lol]Quote:Original post by DecriusIn the old Amiga days, most games switched off the OS and ran directly on the hardware. This was of course essential for the games to run well. A big advancement is if you already have set the hardware and just write software for that particular hardware (like you seem to be going to do). This is the best way to get the maximal performance.That brings up a fairly interesting possibility for the design where an application might place the OS into a "lean and mean" mode of operation, or might request direct access to some resources -- definitely a train of thought I'll have to keep in mind.---So far, my initial thoughts are:lightweight, monolithic, but modular kernel.Minimal switching to kernel-mode code -- e.g. largely user mode "drivers""Lean and mean" mode, or ability to disable unnecessary services.Possibly Single-Process-multi-threadingleightweight threads / proto-threads   ;Quote:Original post by RavyneMinimal switching to kernel-mode code -- e.g. largely user mode "drivers"I wouldn't bother with that, just have everything in kernel mode (does the ARM even differentiate between "user" and "kernel"?) There's only one process, so there's no point not giving it full access to everything.