Structure Design

Introduction

This design document's purpose is to well design the structure of the core operating system concepts, meaning that there is a larger picture and that future problems can be seen. This is in turn quite difficult and will require solving of various problems in order to make sure a smooth development process.

Modules

The entire system is broken down into multiple modules, meaning that in theory each section can be individually modified, but remain compatible, through a well defined interface. Here we will discuss the function of each module and in a later section the discussion will move towards module interfaces.

Bootloader

Responsibilities

The following are the responsibilities for this section:

  • Boots the system
  • Sets up the positioning in RAM
  • Loads the disk table
  • Loads the kernel from the disk

Features Offered

The following features are offered as a result of this module's responsibilities:

  • Disk utilities (load, read, save, run, search)
  • Command prompt for custom user interaction
  • Full functionality (some wrap to error)
  • Single limited program execution at a time

Kernel

Responsibilities

The following are the responsibilities for this section:

  • Override jumps in the boot header to jump to overriding functions in the kernel
  • Multitasking of programs
  • Program memory space handling (Setting the RAM positions for each program on switch)
  • Load a program named auto if it exists

Features Offered

  • Basic program capabilities
  • Ability to multi-task programs using the kernel
  • Command prompt that allows multiple programs to execute at a time
  • Program interactive switching (likely F1..F8 keys)

GUI

NOTE: The GUI will be named auto in order for the kernel to load this in on initialisation.

Responsibilities

  • Override jumps in the kernel header to jump to overriding functions in the GUI
  • Program display
  • Masked GUI drawing
  • Store information about the current Window's graphical state and store this information (likely in fixed size tiles, in compressed text RAM) ^

^: With the design of having 8 displays, to fill the display the windows ought to be at least 200 x 200 (40k bytes) pixels in size. This is simply not possible. Even as binary this is is 5k bytes. The text buffer is only 80 x 25 bytes, which is half the size required for one window. It is fully expected that a program may want to draw graphics to the display on the pixel level to achieve some desired effect.

The solution to this problem will likely come in the following forms:

  • Smaller window sizes
  • Limited window buffer that can be used, handled by the GUI program
  • Having two modes of GUI, text and pixel - as the text version will be easier to store.

Features Offered

TODO: Write this section.

Programs

Responsibilities

TODO: Write this section.

Features Offered

TODO: Write this section.

Interfaces

TODO: Write this section.