The Kernel

The Kernel

The kernel, as stated in the previous chapter, is the true core of NitrOS-9. All resource management and services, from memory allocation to the creation and destruction of processes, are supervised by this very important software component.

The kernel is actually split into two parts: Krn (which holds core system calls that must be present during the boot process) and KrnP2 (which handles additional system calls). These two modules complete the concept of the NitrOS-9 kernel.

The kernel modules for NitrOS-9 Level 1 are smaller than those of NitrOS-9 Level 2, and are small enough to reside on the boot track. Under NitrOS-9 Level 2, Krn resides in the boot track while KrnP2 is part of the OS9Boot file, a file that is loaded into RAM with the other NitrOS-9 modules at bootstrap time.

Here’s a look at the kernel’s main responsibilities:

• System initialization after reset
• Service request processing
• Memory management
• Multiprogramming management
• Interrupt processing

I/O functions are not included in the list because the kernel does not directly process them. Instead, it passes I/O system calls to the I/O Manager, IOMan, for processing.

We will now explore the kernel’s responsibilities in more detail.

System Initialization

After a hardware reset, the kernel initializes the system. This involves:

1. Locating modules loaded into memory from the NitrOS-9 boot file.
2. Determining the amount of available RAM.
3. Loading any required modules that were not loaded from the NitrOS-9 boot file.

NitrOS-9 also adds the ability to install new system calls through the F$SSvc system service call. Under NitrOS-9 Level 1, user state programs can directly call this system call. However, NitrOS-9 Level 2 user processes cannot call this system call directly because it is privileged. Instead, new system calls are added through special kernel extension modules, named KrnP3, KrnP4, KrnP5, etc. These kernel modules must be present in the OS9Boot file. The cold start routine in KrnP2 performs a link to KrnP3, and if it exists in the boot file, it will be branched to. If KrnP3 does not exist in the boot file, KrnP2 continues with a normal cold start.

System Call Processing

System Calls are used to communicate between NitrOS-9 and programs for such functions as memory allocation and process creation. In addition to I/O and memory management functions, system calls have other functions. These include inter-process control and timekeeping.

System calls use the 6809 microprocessor’s SWI2 instruction followed by a constant byte representing the code. You usually pass parameters for system calls in the 6809 registers.

OS9Defs and Symbolic Names

A system-wide assembly language equate file, called OS9Defs, defines symbolic names for all system calls. This file is normally included when assembling hand-written or compiler-generated code. The NitrOS-9 assembler has a built-in macro to generate system calls. For example:

os9 I$Read

is recognized and assembled as equivalent to:

swi2
fcb I$Read

The NitrOS-9 assembler macro OS9 generates an SWI2 instruction. The label I$Read is the label for the system call code $89.

Types of System Calls

System calls are divided into two categories: I/O calls and function calls.

I/O calls perform various input/output functions. The kernel passes calls of this type to the I/O manager for processing. The symbolic names for I/O calls begin with I$ instead of F$. For example, the Read system call is called I$Read.

Function calls perform memory management, multi-programming and other functions, with most being processed by the kernel. The symbolic names for function calls begin with F$. For example, the Link function call is called F$Link.

The function calls include user calls and privileged system mode calls. (See Chapter 8, “System Calls,” for more information.)

Memory Management

Memory management is an important operating system function. Using memory and modules, NitrOS-9 manages the logical contents of memory and the physical assignment of memory to programs.

An important concept in memory management is the memory module. The memory module is a format in which programs must reside. NitrOS-9 maintains a module directory that points to the modules that occupy memory. This module directory contains information about each module, including its name and address and the number of processes using it. The number of processes using a module is reflected in the module’s link count.

When a module’s link count reaches zero, NitrOS-9 releases the module, returns the memory it held back to the free pool, and removes its name from the module directory.

Memory modules are the foundation of NitrOS-9’s modular software environment, and have several advantages:

• Automatic runtime linking of programs to libraries of utility modules
• Automatic sharing of re-entrant programs
• Replacement of small sections of large programs into memory for update or correction.

Memory Use in NitrOS-9

NitrOS-9 automatically allocates memory when any of the following occurs:

• Program modules are loaded into RAM
• Processes are created
• Processes execute system calls to request additional RAM
• NitrOS-9 needs I/O buffers or larger tables

NitrOS-9 also has inverse functions to deallocate memory allocated to program modules, new processes, buffers, and tables.

In general, memory for program modules and buffers is allocated from high addresses downward. Memory for process data areas is allocated from low addresses upward.

NitrOS-9 Level 1 Memory Specifics

Under NitrOS-9 Level 1, a maximum of 64K of RAM is supported. The operating system and all processes must share this memory. In the 64K address map, NitrOS-9 reserves some space at the top and bottom of RAM for its own use. The amount depends on the sizes of system tables that are specified in the Init module.

NitrOS-9 pools all other RAM into a free memory space. As the system allocates or deallocates memory, it dynamically takes it from or returns it to this pool. Under NitrOS-9 Level 2, RAM does not need to be contiguous because the memory management unit can dynamically rearrange memory addresses.

The basic unit of memory allocation is the 256-byte page. NitrOS-9 Level 1 always allocates memory in whole numbers of pages.

The data structure that NitrOS-9 uses to keep track of memory allocation is a 256-byte bitmap. Each bit in this table is associated with a specific page of memory. A cleared bit indicates that the page is free and available for assignment. A set bit indicates that the page is in use (that no RAM is free at that address).

NitrOS-9 Level 2 Memory Specifics

Because NitrOS-9 Level 2 utilizes the Memory Management Unit (MMU) component of the Color Computer 3, up to 2MB of memory can be supported. However, each process is still limited to a maximum of 64K of RAM.

Even with this limitation, there is a significant advantage over NitrOS-9 Level 2. Every process has its own 64K “playground.” Even the operating system itself has its own 64K area. This means that programs do not have to share a single 64K block with each other or the system. Consequently, larger programs are possible under NitrOS-9 Level 2.

These 64K areas are made up of 8K blocks, the size that is imposed by the MMU found in the Color Computer 3. NitrOS-9 Level 2 assembles a number of these 8K blocks to provide every process (including the system) its own 64K working area.

Within the system’s 64K address map, memory is still allocated in 256-byte pages, just like NitrOS-9 Level 1.

Color Computer 3 Memory Management Hardware

As mentioned previously, the 8-bit CPU in the Color Computer 3 can directly address only 64K of memory. This limitation is imposed by the 6809, which has only 16 address lines (A0-A15). The Color Computer 3’s Memory Management Unit (MMU) extends the addressing capability of the computer by increasing the address lines to 19 (A0-A18). This lets the computer address up to 512K of memory ($0-$7FFFF), or up to 2MB of memory ($0-$1FFFFF) when enhanced with certain memory upgrades. In this document we will discuss the more common 512K configuration.

The 512K address space is called the physical address space. The physical address space is subdivided into 8K blocks. The six high order address bits (A13-A18) define a block number.

NitrOS-9 creates a logical address space of up to 64K for each task by using the F$Fork system call. Even though the memory within a logical address space appears to be contiguous, it might not be—the MMU translates the physical addresses to access available memory. Address spaces can also contain blocks of memory that are common to more than one map.

The MMU consists of a multiplexer and a 16 by 6-bit RAM array. Each of the 6-bit elements in this array is an MMU task register. The computer uses these task registers to determine the proper 8-kilobyte memory segment to address.

The MMU task registers are loaded with addressing data by the CPU. This data indicates the actual location of each 8-kilobyte segment of the current system memory. The task register are divided into two sets consisting of eight registers each. Whether the task register select bit (TR bit) is set or reset determines which of the two sets is to be used.

The relation between the data in the task register and the generated addresses is as follows:

Bit	D5	D4	D3	D2	D1	D0
Corresponding Memory Address	A18	A17	A16	A15	A14	A13

When the CPU accesses any memory outside the I/O and control range (FF00-FFFF), the CPU address lines (A13-A15) and the TR bit determine what segment of memory to address. This is done through the multiplexer when SELECT is low (See the following table.)

When the CPU writes data to the MMU, A0-A3 determine the location of the MMU register to receive the incoming data when SELECT is high. The following diagram illustrates the operation of the Color Computer 3’s memory management.

The system uses the data from the MMU registers to determine the block of memory to be accessed, according to the following table:

TR Bit	A15	A14	A13	Address Range	MMU Address
0	0	0	0	0000-1FFF	FFA0
0	0	0	1	2000-3FFF	FFA1
0	0	1	0	4000-5FFF	FFA2
0	0	1	1	6000-7FFF	FFA3
0	1	0	0	8000-9FFF	FFA4
0	1	0	1	A000-BFFF	FFA5
0	1	1	0	C000-DFFF	FFA6
0	1	1	1	E000-FFFF	FFA7
1	0	0	0	0000-1FFF	FFA8
1	0	0	1	2000-3FFF	FFA9
1	0	1	0	4000-5FFF	FFAA
1	0	1	1	6000-7FFF	FFAB
1	1	0	0	8000-9FFF	FFAC
1	1	0	1	A000-BFFF	FFAD
1	1	1	0	C000-DFFF	FFAE
1	1	1	1	E000-FFFF	FFAF

The translation of physical addresses to 8K blocks is as follows:

Range		Block Number		Range		Block Number
From	To			From	To
00000	01FFF	00		40000	41FFF	20
02000	02FFF	01		42000	43FFF	21
04000	05FFF	02		44000	45FFF	22
06000	07FFF	03		46000	47FFF	23
08000	09FFF	04		48000	49FFF	24
0A000	0BFFF	05		4A000	4BFFF	25
0C000	0DFFF	06		4C000	4DFFF	26
0E000	0FFFF	07		4E000	4FFFF	27
10000	11FFF	08		50000	51FFF	28
12000	13FFF	09		52000	53FFF	29
14000	15FFF	0A		54000	55FFF	2A
16000	17FFF	0B		56000	57FFF	2B
18000	19FFF	0C		58000	59FFF	2C
1A000	1BFFF	0D		5A000	5BFFF	2D
1C000	1DFFF	0E		5C000	5DFFF	2E
1E000	1FFFF	0F		5E000	5FFFF	2F
20000	21FFF	10		60000	61FFF	30
22000	23FFF	11		62000	63FFF	31
24000	25FFF	12		64000	65FFF	32
26000	27FFF	13		66000	67FFF	33
28000	29FFF	14		68000	69FFF	34
2A000	2BFFF	15		6A000	6BFFF	35
2C000	2DFFF	16		6C000	6DFFF	36
2E000	2FFFF	17		6E000	6FFFF	37
30000	31FFF	18		70000	71FFF	38
32000	33FFF	19		72000	73FFF	39
34000	35FFF	1A		74000	75FFF	3A
36000	37FFF	1B		76000	77FFF	3B
38000	39FFF	1C		78000	79FFF	3C
3A000	3BFFF	1D		7A000	7BFFF	3D
3C000	3DFFF	1E		7C000	7DFFF	3E
3E000	3FFFF	1F		7E000	7FFFF	3F

In order for the MMU to function, the TR bit at $FF90 must be cleared and the MMU must be enabled. However, before doing this, the address data for each memory segment must be loaded into the designated set of task registers. For example, to select a standard 64K map in the top range of the Color Computer 3’s 512K RAM, with the TR bit set to 0, the following values must be preloaded into the MMU’s registers:

MMU Location Address	Data (Hex)	Data (Binary)	Address Range
FFA0	38	111000	70000-71FFF
FFA1	39	111001	72000-73FFF
FFA2	3A	111010	74000-75FFF
FFA3	3B	111011	76000-77FFF
FFA4	3C	111100	78000-79FFF
FFA5	3D	111101	7A000-7BFFF
FFA6	3E	111110	7C000-7DFFF
FFA7	3F	111111	7E000-7FFFF

Although this table shows MMU data in the range $38 to $3F, any data between $00 and $3F can be loaded into the MMU registers to select memory addresses in the range 0 to $7FFFF.

Normally, the blocks containing I/O devices are kept in the system map, but not in the user map. This is appropriate for timesharing applications, but not for process control. To directly access I/O devices, use the F$MapBlk system call. This call takes a starting block number and block count, and maps them into unallocated spaces of the process’ address space. The system call returns the logical address at which the blocks were inserted.

For example, suppose a display screen in your system is allocated at extended addresses $7A000-$7DFFF (blocks $3D and $3E). The following system call maps them into your address space:

          ldb  #$02      number of blocks
          ldx  #$3D      starting block number
          os9  F$MapBlk  call MapBlk
          stu  IOPorts   save address where mapped

On return, the U register contains the starting address at which the blocks were switched. For example, suppose that the call returned $4000. To access extended address $7A020, write to $4020.

Other system calls that copy data to or from one task’s map to another are available, such as F$STABX and F$Move. Some of these calls are system mode privileged. You can unprotect them by changing the appropriate bit in the corresponding entry of the system service request table and then making a new system boot with the patched table.

Multiprogramming

NitrOS-9 is a multiprogramming operating system. This means that several independent programs called processes can be executed at the same time. By issuing the appropriate system call to NitrOS-9, each process can have access to any system resource.

Multiprogramming functions use a hardware real-time clock. The clock generates interrupts 60 times per second, or one every 16.67 milliseconds. These interrupts are called ticks.

Processes that are not waiting for some event are called active processes. NitrOS-9 runs active processes for a specific system-assigned period called a time slice. The number of time slices per minute during which a process is allowed to execute depends on a process’ priority relative to all other active processes. Many NitrOS-9 system calls are available to create, terminate and control processes.

Process Creation

A process is created when an existing process executes the F$Fork system call. This call’s main argument is the name of the program module that the new process is to execute first (the primary module).

Finding the Module. NitrOS-9 first attempts to find the module in the module directory. If it does not find the module, NitrOS-9 usually attempts to load into a memory a mass-storage file in the execution directory, with the requested module name as a filename.

Assigning a Process Descriptor. Once OS-9 finds the module, it assigns the process a data structure called a process descriptor. This is a 64-byte package that contains information about the process, its state (see the following section, “Process States”), memory allocations, priority, queue pointers, and so on. NitrOS-9 automatically initializes and maintains the process descriptor.

Allocate RAM. The next step is to allocate RAM for the process. The primary module’s header contains a storage size, which NitrOS-9 uses, unless a larger one was requested at fork time. The memory is allocated from the free memory space and given to that process.

Assign Process ID and User ID. NitrOS-9 assigns the new process a unique number called a process ID. Other processes can communicate with the process by referring to its ID in various system calls.

The process also has a user ID, which is used to identify all processes and files that belong to a particular user. The user ID is inherited from the parent process.

Process Termination. A process terminates when it executes the F$Exit system call, or when it receives a fatal signal. The termination closes any open paths, deallocates memory used by the process, and unlinks its primary module.

Process States

At any instant a process can be in one of three states:

• Active – The process is ready for execution.
• Waiting – The process is suspended until a child process terminates or until it receives a signal. A child process is a process that is started by another process known as the parent process.
• Sleeping – The process is suspended for a specific period of time or until it receives a signal.

Each state has its own queue, a linked list of descriptors of processes in that state. To change a process’ state, NitrOS-9 moves its descriptor to another queue.

The Active State. Each active process is given a time slice for execution, according to its priority. The scheduler in the kernel ensures that all active processes, even those of low priority, get some CPU time.

The Wait State. This state is entered when a process executes the F$Wait system call. The process remains suspended until one of its child processes terminates or until it receives a signal. (See the “Signals” section later in this chapter.)

The Sleep State. This state is entered when a process executes the F$Sleep system call, which expects the number of ticks for which the process is to remain in the sleep queue. The process will remain until the specified time has elapsed, or until it receives a wakeup signal.

Execution Scheduling

The NitrOS-9 scheduler uses an algorithm that ensures that all active processes get some amount of execution time.

All active processes are members of the active process queue, which is kept sorted by process age. Age is the number of process switches that have occurred since the process’ last time slice. When a process is moved to the active process queue from another queue, its age is set according to its priority—the higher the priority, the higher the age.

Whenever a new process becomes active, the ages of all other active processes increase by one time slice count. When the executing process’ time slice has elapsed, the scheduler selects the next process to be executed (the one with the next highest age, the first one in the queue). At this time, the ages of all other active processes increase by one. Ages never go beyond 255.

A new active process that was terminated while in the system state is an exception. The process is given high priority because it is usually executing critical routines that affect shared system resources.

When there are no active processes, the kernel handles the next interrupt and then executes a CWAI instruction. This procedure decreases interrupt latency time (the time it takes the system to process an interrupt).

Signals

A signal is an asynchronous control mechanism used for interprocess communication and control. It behaves like a software interrupt, and can cause a process to suspend a program, execute a specific routine, and then return to the interrupted program.

Signals can be sent from one process to another by the F$Send system call. Or, they can be sent from NitrOS-9 service routines to a process.

A signal can convey status information in the form of a 1-byte numeric value. Some signal codes (values) are predefined, but you can define most. Those already defined by NitrOS-9 are:

0	S$Kill	Kill (terminates the process, is non-interceptable)
1	S$Wake	Wakeup (wakes up a sleeping process)
2	S$Abort	Keyboard terminate
3	S$Intrpt	Keyboard interrupt
4	S$Window	Window change (CoWin/CoGrf)
4	S$HUP	Hang-up (DriveWire 4)
5	S$Alarm	Alarm
128-255		User defined

When a signal is sent to a process, the signal is saved in the process descriptor. If the process is in the sleeping or waiting state, it is changed to the active state. When the process gets its next time slice, the signal is processed.

What happens next depends on whether or not the process has set up a signal intercept trap (also known as a signal service routine) by executing the F$Icpt system call.

If the process has set up a signal intercept trap, the process resumes execution at the address given in the system call. The signal code passes to this routine. Terminate the routine with an RTI instruction to resume normal execution of the process.

Note: A wakeup signal activates a sleeping process. It sets a flag but ignores the call to branch to the intercept routine.

If it has not set up a signal intercept trap, the process is terminated immediately. It is also terminated if the signal code is zero. If the process is in the system mode, NitrOS-9 defers the termination. The process dies upon return to the user state.

A process can have a signal pending (usually because the process has not been assigned a time slice since receiving the signal). If it does, and another process tries to send it another signal, the new signal is terminated, and the F$Send system call returns an error. To give the destination process time to process the pending signal, the sender needs to execute an F$Sleep system call for a few ticks before trying to send the signal again.

Interrupt Processing

Interrupt processing is another important function of the kernel. OS-9 sends each hardware interrupt to a specific address. This address, in turn, specifies the address of the device service routine to be executed. This is called vectoring the interrupt. The address that points to the routine is called the vector. It has the same name as the interrupt.

The SWI, SWI2, and SWI3 vectors point to routines that read the corresponding pseudo vector from the process’ descriptor and dispatch to it. This is why the F$SSWI system call is local to a process; it only changes a pseudo vector in the process descriptor.

Vector	Address
SWI3	$FFF2
SWI2	$FFF4
FIRQ	$FFF6
IRQ	$FFF8
SWI	$FFFA
NMI	$FFFC
RESTART	$FFFE

FIRQ Interrupt. The system uses the FIRQ interrupt. The FIRQ vector is not available to you. The FIRQ vector is reserved for future use. Only one FIRQ generating device can be in the system at a time.

Logical Interrupt Polling System

Because most NitrOS-9 I/O devices use IRQ interrupts, NitrOS-9 includes a sophisticated polling system. The IRQ polling system automatically identifies the source of the interrupt, and then executes its associated user- or system-defined service routine.

IRQ Interrupt. Most NitrOS-9 I/O devices generate IRQ interrupts. The IRQ vector points to the real-time clock and the keyboard scanner routines. These routines, in turn, jump to a special IRQ polling system that determines the source of the interrupt. The polling system is discussed in an upcoming paragraph.

NMI Interrupt. The system uses the NMI interrupt. The NMI vector, which points to the disk driver interrupt service routine, is not available to you.

The Polling Table. The information required for IRQ polling is maintained in a data structure called the IRQ polling table. The table has an entry for each device that might generate an IRQ interrupt. The table size is permanent and is defined by an initialization constant in the Init module. Each entry in the polling table is given a number from 0 (lowest priority) to 255 (highest priority). In this way, the more important devices (those that have a higher interrupt frequency) can be polled before the less important ones.

Each entry has six variables:

Polling Address	Points to the status register of the device. The register must have a bit or bits that indicate if it is the source of an interrupt.
Flip byte	Selects whether the bits in the device status register indicate active when set or active when cleared. If a bit in the flip byte is set, it indicates that the task is active whenever the corresponding bit in the status register is clear.
Mask Byte	Selects one or more interrupt request flag bits within the device status register. The bits identify the active task or device.
Service Routine Address	Points to the interrupt service routine for the device. You supply this address.
Static Storage Address	Points to the permanent storage area required by the device service routine. You supply this address.
Priority	Sets the order in which the devices are polled (a number from 0 to 255).

Polling the Entries. When an IRQ interrupt occurs, NitrOS-9 enters the polling system via the corresponding RAM interrupt vector. It starts polling the devices in order of priority. NitrOS-9 loads the status register address of each entry into Accumulator A, using the device address from the table.

NitrOS-9 performs an exclusive-OR operation using the flip byte, followed by a logical-AND operation using the mask byte. If the result is non-zero, NitrOS-9 assumes that the device is the source of the interrupt.

NitrOS-9 reads the device memory address and service routine address from the table, and performs the interrupt service routine.

Note: If you are writing your own device driver, terminate the interrupt service routine with an RTS instruction, not an RTI instruction.

Adding Entries to the Table. You can make entries to the IRQ (interrupt request) polling table by using the F$IRQ system call. This call is a privileged system call, and can only be executed in system mode. NitrOS-9 is in system mode whenever it is running a device driver.

Note: The code for the interrupt polling system is located in the I/O Manager module. The Krn and KrnP2 modules contain the physical interrupt processing routines.

Virtual Interrupt Processing

A virtual IRQ, or VIRQ, is useful with devices in Multi-Pak expansion slots. Because of the absence of an IRQ line from the Multi-Pak interface, these devices cannot initiate physical interrupts. VIRQ enables these devices to act as if they were interrupt driven. Use VIRQ only with device driver and pseudo device driver modules. VIRQ is handled in the Clock module, which handles the VIRQ polling table and installs the F$VIRQ system call. Since the F$VIRQ system call is dependent on clock initialization, the SysGo module forces the clock to start.

The virtual interrupt is set up so that a device can be interrupted at a given number of clock ticks. The interrupt can occur one time, or can be repeated as long as the device is used.

The F$VIRQ system call installs VIRQ in a table. This call requires specification of a 5-byte packet for use in the VIRQ table. This packet contains:

• Bytes for an actual counter
• A reset value for the counter
• A status byte that indicates whether a virtual interrupt has occurred and whether the VIRQ is to be reinstalled in the table after being issued

F$VIRQ also specifies an initial tick count for the interrupt. The actual call is summarized here and is described in detail in Chapter 8.

Call:	os9 F$VIRQ
Input:	(Y) = address of 5-byte packet (X) = 0 to delete entry, 1 to install entry (D) = initial count value
Output:	None
Error output:	(CC) carry set on error (B) appropriate error code

The 5-byte packet is defined as follows:

Name	Offset	Function
Vi.Cnt	$0	Actual counter
Vi.Rst	$2	Reset value for counter
Vi.Stat	$4	Status byte

Two of the bits in the status byte are used. These are:

Bit 0 – set if a VIRQ occurs

Bit 7 – set if a count reset is required

When making an F$VIRQ call, the packet might require initialization with a reset value. Bit 7 of the status byte must be either set or cleared to signify a reset of the counter or a one-time VIRQ call. The reset value does not need to be the same as the initial counter value. When NitrOS-9 processes the call, it writes the packet address into the VIRQ table.

At each clock tick, NitrOS-9 scans the VIRQ table and subtracts one from each timer value. When a timer count reaches zero, NitrOS-9 performs the following actions:

1. Sets bit 0 in the status byte. This specifies a Virtual IRQ.
2. Checks bit 7 of the status byte for a count reset request.
3. If bit 7 is set, resets the count using the reset value. If bit 7 is reset, deletes the packet address from the VIRQ table.

When a counter reaches zero and makes a virtual interrupt request, NitrOS-9 runs the standard interrupt polling routine and services the interrupt. Because of this, you must install entries on both the VIRQ and IRQ polling tables whenever you are using a VIRQ.

Unless the device has an actual physical interrupt, install the device on the IRQ polling table via the F$IRQ system call before placing it on the VIRQ table.

If the device has a physical interrupt, use the interrupt’s hardware register address as the polling address for the F$IRQ call. After setting the polling address, set the flip and mask bytes for the device and make the F$IRQ call.

If the device is totally VIRQ-driven, and has no interrupts, use the status byte from the VIRQ packet as the status byte. Use a mask byte of %00000001, defined as Vi.IFlag in the os9defs file. Use a flip byte value of 0.

See the appendix for example code using the VIRQ feature of NitrOS-9.