Goals for KallistiOS (Dreamcast light-weight OS)

- Thread support (within a single "process")
- Synchronization support
- Dreamcast hardware control with some (compile time?) configuration,
  e.g., printf() goes to the video screen or to the serial port, etc.
  More on this below.
- Simple libc that interfaces to the hardware layer so that things
  like printf() work as expected. The libc would include file functions
  (that access the GD-ROM) in both open() and fopen() forms, malloc() and
  free() with a basic bucket algorithm, and other standard ANSI C functions
  such as the ones in string.h, stdarg.h, etc.
- Compile-time controls for many of the above, so that you can turn off
  what you don't need. This would especially apply to the threading, as 
  we'd need synchronization in the access of things like sound and video.
- Support for loading elf binaries from a file system, relocating them,
  and running them in "immidate mode" or in a new thread.


Non-goals for KallistiOS
Most of these are things Linux-SH would provide that we don't care about
in simple games and demos.

- MMU support. We don't care about address protection at this point. This
  may change eventually, but it's kind of irrelevant really. Even the
  binaries won't change if we implement it.
- Process support. This is only going to support one main process, potentially
  with multiple threads of execution. Now on the other hand, it would be 
  possible for that one main process to load up others...
- A lot of other things that UNIX would provide -- like pipes, real tty's,
  etc.


Hardware Control Layer

- Provides synchronization for high-level primitives if thread support is
  compiled into KallistiOS.
- Basic initialization -- initializes all known system components for you
  to reasonable defaults. Some init parameters can be determined at 
  compile time (like default video mode), and potentially init can be
  disabled if you want to do it manually for some reason.
* Video
  - Init to any of the three modes (RGB555/565/888) and handle being hooked
    up to a VGA box, an S-Video or a Composite output, or RGB cable.
  - Basic screen writing functions for doing pixels, boxes, fonts, etc.
  - Hardware control functions for moving start address, changing border
    color, and getting a pointer to the frame buffer.
  - More advanced 3D functions that do things like allocate memory for
    the PowerVR textures, load those textures, and do 3D display lists;
    additionally, functions for creating and using stacked windows (using
    3D accel).
  - Page flipping / 3D pipeline assistance if you want it.
* Sound
  - Init the sound chip with a sound control program that implements a 
    basic MIDI-style system. In reality, this is a MikMod-type abstracted
    Protracker player.
  - Provide wavetable primitives -- loading patches, play, stop, vol/freq/pan
    controls.
  - Provide players for various "tracker" formats -- S3M, MOD, XM, all
    of which interface to the MIDI-style interface.
  - Provide a more advanced direct output mechanism that lets you output
    buffers of raw sound data at a given sample rate, blocking your program
    until it's ready for a new buffer. Should also provide double buffering
    support.
  - Allow for uploading custom sound programs, and provide some abstraction
    mechanisms for getting the address of sound RAM.
* Maple Bus
  - Init that enumerates devices
  - Polling primitives for the known device types, mainly keyboard and
    controllers.
  - Thread-based polling mechanism to regularly scan the maple bus for
    controller/keyboard states, and changes to config (i.e., add/remove
    peripherals)
  - Callbacks for when buttons are pressed or keys are pressed on the
    keyboard
* VMU
  - Functions to load/save VMU files
  - Display VMU graphics (on the VMU display)
  - VMU sound
* Serial port
  - kernel stdin and stdout/stderr map to the serial port or debug
    stub output
  - printf() and similar functions point to that stdio
  - getchar() and similar read from that stdin
* Virtualized file system
  - Like Neutrino -- delegated path spaces
  - Default drivers will include:
    + Built-ins (linked into the program)
    + CDFS (reads from a CDR)
    + PC Debug (reads over a debug cable [ethernet, etc])
* GD-ROM
  - Basic init that uses the BIOS to access the GD
  - Access to the ISO file system on a CDR/CDROM
  - Playing audio tracks on music CDs
* Debug support (optional)
  - Interfaces to GDB over the serial port
  - stdout gets redirected to debug stub output functions
* Expansion port
  - Modem
  - Ethernet
  - Zip drive
* TCP/IP stack?
