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.
- Realtime features (thread priorities, event-based rescheduling, etc)
- Process support. This has moved from the "non-goal" list onto the goal
  list due to a number of considerations (mainly centering around memory
  allocation).
- Maybe eventually, MMU support. As a general rule we don't care much about
  address relocation and protection, but during debugging this could be a
  big life saver.


Non-goals for KallistiOS

- A lot of 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.
* G2 bus module
  - Provide interrupt multiplexing for any module that wants to hook an
    IRQ9 event.
  - DMA handling
* 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.
  - BIOS font interface
  - 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.
  - G2 interrupt and DMA support to TA and/or VRAM
* 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. (MAYBE, on this one and the next few)
  - 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.
  - G2 interrupt and DMA support
* Maple Bus
  - Init that enumerates devices
  - Polling primitives for the known device types, mainly keyboard and
    controllers.
  - Unified enumeration system to let you figure out what's on the
    bus and potentially use it.
  - G2 interrupt support for device activity and addition/removal.
* 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)
    + ROMFS (linked into the program or perhaps tacked onto
      the end of the BIN)
    + CDFS (reads from a CDR)
    + PC Debug (reads over a debug cable [ethernet, etc])
* GD-ROM
  - Hardware driver that accesses the GD-ROM directly, uses
    G2 interrupts, etc.
  - 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
  - Ethernet
  - Bitmaster bus device?
* TCP/IP stack


KOS Version Id: $Id: goals.txt,v 1.1.1.1 2001/09/26 07:05:00 bardtx Exp $

