The Navigation Computer system and the Engineering computer system provide the information to update the position of
the StarShip in space. The Position Update task in the simulation software has no direct controls, like switches
or lights. It is a task that executes in the background, but does a few important things which are quite noticable at the outside. The responsibilities for the Position Update task are:

- calculation of the position in space of the StarShip every (wall-clock) second
- update the position of the StarShip
- check if the StarShip enters a territory (Klingon, Romulan, Neutral Zone) and activate the correct Alert Status
- determine if the StarShip is on a collision course and issue a warning if it is
- calculate the new course heading and the course change angle for the DOM meter.

**Software implementation**

Whenever the Navigation Computer accepts a course change command, some (software) modules are called that process a
specific function, such as:

- CALCUTF - calculates the so-called Unit-of-Travel Factors.

These are numbers for the X-, Y- and Z-direction, UTX, UTY and UTZ. These numbers are the amount the StarShip will move in space within one second. Of course, the velocity of the StarShip has also to be taken into account. - CALCVCT - calculate the vector (course heading).

This is a calculation with some 3D geometry to determine the new course heading. The course heading is an angle X/Y (from X-axis to Y-axis) and an XY/Z angle, the angle from the X/Y plane to the Z.

Also calculated is the course change angle. This is the angle between the current course heading and the new course heading. This angle is an input variable for the "Degrees Of Movement" meter, short DOM.

**DOM - "Degrees Of Movement" meter**

The Degrees Of Movement meter is an indicator that is default turned off. Because all activities like monitoring and
having hardware on-line costs energy, DOM is not active unless specifically invoked.

Below the DOM meter there are 3 buttons. With these buttons you can allocate the meter to a specific function. The 3
functions are mutually exclusive since there is just one meter. Each of the functions is explained below.

- Navigation course change angle

- Tactical torpedo tracking monitor

- Sciences area scan indicator

When you press the left button the light in that button is turned on and indicates that the DOM meter is allocated to the Navigation Computer.

In the normal situation the DOM meter reads zero and the light is on continuously.

When the course of the StarShip changes, the Position Update task calculates the "error" angle. This error angle is the angle between the current course heading and the entered new course heading. This error angle is displayed on the DOM meter. The software moves the needle of the meter fast to the error angle value. Since there is a course deviation, the light in the first button starts to blink on and off. To simulate the course correction to the new course heading the needle of the DOM meter slowly returns to zero. When the needle is at zero, so no course deviation exists anymore, the light in the first button is lit continuously again. Whenever the button is pressed a second time the light goes off and the DOM meter is no longer allocated to the Navigation Computer. This also happens when one of the other 2 buttons is pressed.

**Tactical torpedo tracking monitor**

When you press the button in the middle the light in that button is turned on and indicates that the DOM meter is
allocated to the Tactical Computer.

In the normal situation the DOM meter reads zero and the light is on continuously.
When a photon topedo is launched the torpedo has a course heading that will intercept the target. This course heading is
displayed as an angle on the DOM meter. As long as the torpedo exists the light in the button in the middle blinks.
When the target changes its position the tracking capabilities of the photon torpedo are reflected in the adjustment of
the needle of the DOM meter.

When the torpedo no longer exists (for example detonated!) the needle returns to zero.

**Sciences area scan indicator**

When you press the right button the light in that button is turned on and indicates that the DOM meter is allocated to
the Sciences Computer.

In the normal situation the DOM meter reads zero and the light is on continuously.

When the Sciences computer runs the "Scan Area" or "Scan Random" command, the needle of the meter indicates in what
direction the scan is currently active. For the "Scan Area" command the needle sweeps through a 60 degree range back
and forth. For example, the needle moves from 120 degrees to 180 degrees, and then back from 180 degrees to 120 degrees.
As long as the "Scan Area" command is running the needle of the meter shows the 60 degree range. (Note: "Scan Area" scans
a specified area of space). The "Scan Random" command is like the "Scan Area" command but now the Sciences Computer gathers
information from everywhere. One 60 degree range is scanned and then, at random, an other 60 degree area is scanned. So,
the needle of the DOM meter now sweeps through a 60 degree range and then jumps to an other 60 degree range, and so on.

**Future developments**

At this moment all calculations are done in 16-bit integer. However, I want to add more precision, which in fact boils
down to more resolution of the StarShip's position in space. Especially at low travel speeds (impulse engines) I want
a smaller update step. Also, even at high warp velocities, I want a more realistic travel time (within limits...).

So, what I am going to implement quite soon is fixed-point arithmatic. Every number is still an integer, but 16 bits
form the "whole" number and an other 16 bits form a fixed-point fraction. The nice thing about fixed-point arithmatic
is that is a lot faster than floating pount arithmatic, because the processor still executes integer instructions.
Not on 16 bits, but now on 32 bit, which is just a very little amount slower.

Also, learned a few things since I started this project early in the 1980's. The unit of travel and distances in
general have NO dimension. That makes things a bit vague when talking about it, so I want to convert everything to the
same unit, for example "light years". However, this sounds a bit "common", so I prefer to change all dimension into
parsec's which is a bit more exotic. One parsec is equal to 3.26 light years.

If you are interested in writing your own fixed-point software, here is how it works.

Fixed point is an easy way to represent non-integer numbers with only integers in the processor. You do that by taking
a certain amount of bits in a register and dedicate them to decimal positions instead of integer values. So, if you
have a 16-bit word, you can do 8.8 fixed point by using the upper 8 bits as the "whole" portion of the number, and
the lower 8 bits as the "fractional" portion. See the table for some examples.

8.8 fixed point | |
---|---|

"whole"."fraction" | 16 bit hexadecimal |

1.0 | 0100 |

2.5 | 0280 |

3.75 | 03C0 |

4.125 | 0420 |

For Motorola 68000 processors a good choice is 16.16 fixed point numbers. A register in these CPU's are 32 bits, the CPU has many 32 bit instructions (especially the 68020 which I use in the main computer of my simulation), and a neat "SWAP" instruction that swaps the upper and lower 16 bits in a register.

Doing math in fixed point is easy.

To add and subtract fixed point numbers is just like the integer add and subtract operation.

1.50 + 1.50 = 3.0 | 0180h + 0180h = 0300h | |

2.75 - 2.25 = 0.5 | 02C0h + 0240h = 0080h |

However, with multiplication and division you must make an adjustment for the number of bits that you choose for the fractional part. Otherwise the resulting number would be too high for multiplication, and too low for division.

1.5 * 3.0 = 4.5 | 0180h * 0300h = 048000h | |

divide afterward by 100h (8 bit) --> 0480h | ||

7.5 / 2.5 = 3.0 | multiply before by 100h (8 bit) --> 078000h | |

078000h / 0280h = 0300h |

So, for multiplication you remove the number of bits that you choose for the fractional part** after **the
multiplication. For a division you multiply by the bits of the fractional parts** before ** you do the division.

Remember that you need more than 32 bits for 16.16 fixed point numbers when using MUL or DIV.

Actually, you can choose any representation. So if you have big numbers, but do not need a large precision, why not
use 24.8 fixed point numbers?