Navigation Computer - Position Update

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:


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


DOM - "Degrees Of Movement" meter
"Degrees Of Movement" meter and function buttons 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.

  1. Navigation course change angle
  2. Tactical torpedo tracking monitor
  3. Sciences area scan indicator
Navigation course change angle
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.00100
2.50280
3.7503C0
4.1250420
All that you do is using the high byte for whole numbers, and the low byte for the fraction. Since the fraction is 8 bits the precision is 1/256. The more bits you use for the fractional part the better the precision gets.
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?