CPU

Initially, the RCOS.java CPU will be based on the P-Code machine used in the original RCOS. The intention is to reuse the existing RCOS PLL compiled code. The operation of the CPU has been modified slightly to support the concept of pages.

The PLL/2 compiler which was included in the original version is being replaced by a full C/C++ compiler. This compiler produces P-Code and may be modified from the Java version to compile itself which opens the possibility of being able to compile programs from within RCOS.java.

For the truly keen, it may be possible in the future to use the Java Virtual Machine (JVM) as the CPU and the other features of a Java Virtual Machine. This would not only allow people to understand basic concepts of OS design but also the workings of the Java Virtual Machine.

Disk

The disk sub-system was written by Brett Carter and modified by Andrew Newman.

The disk sub-system is fairly small because of the desire to produce a graphical represenation of the allocation/deallocation of disk blocks by the file system.

Terminal and Memory (RAM)

The Terminal provides the physical interface to the user including the keyboard and the visual display unit.

Memory consists of two sections. The first is the CPU cache. This is dynamically adjusted to fit the current program into it. The main reason is to increase speed and reduce complexity. Secondary RAM holds all loaded programs and stores them in two sections: process code and stack.

Kernel

RCOS.java uses a micro-kernel based, message passing structure. The kernel is responsible solely for a number of platform specific functions including:

• handling interrupts,
• saving/retrieving context, and
• generating messages to appropriate operating system component as a result of system calls

Message passing

Standard operating system functions are divided into a number of components. All communication between these components must be in the form of messages. All messages pass through the Post Office component that is responsible for delivering messages to the correct destinations.

Intention is that theoretically that different components could be located on different computers.

The Post Office may also be able to be used to hide the animation from the rest of the operating system classes. All the important OS events take the form of messages that pass through the Post Office. Rather than litter the implmentation of the OS components with messages to the Animator the Post Office has been written automatically to forward all messages it receives to the Animator (as well as the actual recipent).

The Animator class can then decide whether or not it wants to do anything as a result of the message.

Other OS Functions

Remaining operating system responsibilites are divided into seperate components (each a Java class in RCOS.java) including:

• Disk Scheduler
  Responsible for managing disk buffering, scheduling disk requests, translating logical block numbers into drive specific sector, cylinder and surface. There is one Disk Scheduler for each disk. Close equivalent to a disk device driver.
• File System
  Responsible for implementing a particular file system (MS-DOS, CP/M, UNIX, NTFS etc). Handles standard messages like open file, close file, read file, write file, open directory, get file attributes etc. It is possible for one RCOS.java instance to have multiple file system objects providing the ability to support more than one file system at a time.
• Process Scheduler
  Responsible for managing process creation, termination and scheduling. Handles messages such as fork process, exec process, kill process, schedule new process, block process, etc. Maintains all disk queues and includes methods such as "running to ready", "running to blocked", "get next running process", etc.
• Memory Manager
  Responsible for managing memory, allocating, deallocating memory for processes, reading, writing memory for various other components.
• Terminals
  Provide mechanism for writing/reading to/from a terminal.

• drawing the main overview screen,
• handling input events for this main screen and initiating new threads to handle the animation of the various OS components, and
• deciding which messages are interesting to the animation system and distributing them to the approriate threads (if they exist).