- The operating system is being written in C. Although I am still evaluating 16 bit compilers the one chosen will either support or will be modified to support segmented calls and jumps, segmented returns (retf), and interrupt service returns (iret).
- The project is based on an old 8 bit OS. The behavior and overall structure of the OS is fairly well defined and documented. I have included a portion of the summary from the spec draft that I am currently working on.
- I am predominately interested in the amount of code required to support 8086 specific platforms, portability issues, and it's usability on other x86 platforms.
- While most references to a non 16 bit version will likely be to the 80386 CPU. This does not automatically eliminate other CPUs and is done so only to reduce unnecessary clutter.
- I am not new to system level development. I have previously worked on kernels and written device drivers for various embedded operating systems.
- The interrupt vector table (IVT). Significantly different between on the x86 and will definitely require target specific implementations to initialize and provide redirects into the kernel.
- Programmable Interrupt Controller. Vastly different than the APIC. The potential amount of code required has yet to be determined.
- Programmable Interrupt Timer (PIT). Can be handled with only a few lines of code on the 8086.
- Keyboard controller (KBC). As with the PIT the amount of code to deal with the KBC is fairly insignificant.
- Memory mapped vs. ported IO. Obviously this is something that needs to be taken into account. I don't foresee any significant amount of additional code to make most drivers work with both when necessary.
- Video. The text driver should usable on all intended targets with little to no modification. I believe the same would likely apply to just about any ISA based card slapped in an x86 machine.
- ATA and FDC controllers. I intend on using the BIOS for early development but drivers for these devices are related to memory mapped vs ported IO.
- Task switching. I don't foresee the actual switch as being more than 20-30 lines of 8086 assembly code triggered by the PIT handler
- System calls. This will likely require the most amount of 8086 specific code although how much will depend on how the IVT is handled.
Futility/X Specification
Introduction
Futility/X is an open implementation of the OS-9 operating system originally created for the Motorola 6809 CPU. By following the original OS-9 architectural and functional specifications Futility/X provides services suitable enough to be usable in both embedded systems and general computing environments.
The primary target platform for Futility/X is the Intel x86 family of CPUs including 16 bit, 32 bit and 64 bit architectures. The 16 bit architecture is important as it provides a suitable reference platform for legacy embedded systems. Additionally it also allows primary development efforts to be focused on a single family of CPUs where test hardware is inexpensive and plentiful.
Architectural Overview
The overall functionality of Futility/X is based on the OS-9 /6809 operating system, specifically the "Level II" version. To that effect the general behavior, available services and interaction between system components are already well defined.
Futility/X utilizes a modular kernel design. This provides an inherent flexibility for use across multiple target architectures while isolating platform specific constraints away from the core system. The following diagram shows the basic hierarchy of kernel based modules.
http://imageshack.us/photo/my-images/204/os9.png/
The kernel resides at the top level and is responsible for task allocation, task and context switching, interrupt handling, event/signal dispatching and memory management. It also provides additional services to system components such as drivers and file system managers. The kernel performs only minimal interaction with the hardware and relies on additional modules to trigger specific tasks. For instance an external “clock” module is typically supplied to instruct the kernel when it shold switch between tasks. If a programmable timer is not available or a single task environment is desired this module can be excluded.
The IO Manager is primarily responsible for routing system calls to the appropriate file system handlers. It maintains a list of all devices available to the system and provides a unified interface for performing IO related tasks. It makes no assumptions about the underlying file system or devices and does not communicate directly with hardware.
Underneath the IO manager resides components known as File Managers. They are responsible for providing interaction with various types of data access points. For instance a file manager may be provided for FAT12, FAT16, NTFS or any number of block based file systems. Likewise a file manager may also be provided for communicating with stream devices such as serial ports and keyboards. File managers rely on device drivers for access to specific hardware.
At the bottom level are device drivers. These modules typically communicate directly with the hardware but are not required to. For instance a device driver for hard drives may communicate with the hardware or perform calls to the BIOS if available. Alternatively a RAM drive will simply use system memory or may communicate with a memory expansion card.
[More TBD]
