If you are using the screen-oriented interface, this command is suppressed; instead, a short-range scan will always be present on the screen.

The short-range scan gives you a considerable amount of information about the quadrant your starship is in. A short-range scan is best described by an example.

         1 2 3 4 5 6 7 8 9 10
      1  * . . . . R . . . .  Stardate      2516.3
      2  . . . E . . . . . .  Condition     RED  
      3  . . . . . * . B . .  Position      5 - 1, 2 - 4
      4  . . . S . . . . . .  Life Support  DAMAGED, Reserves=2.30
      5  . . . . . . . K . .  Warp Factor   5.0
      6  . K .   . . . . * .  Energy        2176.24
      7  . . . . . P . . . .  Torpedoes     3
      8  . . . . * . . . . .  Shields       UP, 42% 1050.0 units
      9  . * . . * . . . C .  Klingons Left 12
     10  . . . . . . . . . .  Time Left     3.72

In fancy mode, the display will use letters for Y coordinates.

         1 2 3 4 5 6 7 8 9 10
      a  * . . . . R . . . .  Stardate      2516.3
      b  . . . E . . . . . .  Condition     RED  
      c  . . . . . * . B . .  Position      e1, b4
      d  . . . S . . . . . .  Life Support  DAMAGED, Reserves=2.30
      e  . . . . . . . K . .  Warp Factor   5.0
      f  . K .   . . . . * .  Energy        2176.24
      g  . . . . . P . . . .  Torpedoes     3
      h  . . . . * . . . . .  Shields       UP, 42% 1050.0 units
      i  . * . . * . . . C .  Klingons Left 12
      j  . . . . . . . . . .  Time Left     3.72

The left part is a picture of the quadrant. The E at sector 2 - 4 (or b4) represents the Enterprise; the B at sector 3 - 8 (or c8) is a starbase. There are ordinary Klingons (K) at sectors 5 - 8 (e8) and 6 - 2 (f2), and a Klingon Commander (C) at 9 - 9 (i9). The (GULP) “Super-commander” (S) is occupies sector 4 - 4 (d4), and a Romulan (R) is at 1 - 6 (a6). An uninhabited planet (P) is at sector 7 - 6 (g6) (if it were inhabited, it would display as a '@'). There are also a large number of stars (*). The periods (.) are just empty space—they are printed to help you get your bearings. Sector 6 - 4 contains a black hole ( ).

The information on the right is assorted status information. You can get this alone with the STATUS command. The status information will be absent if you type “N” after SRSCAN. Otherwise status information will be presented.

If you type “C” after SRSCAN, you will be given a short-range scan and a Star Chart.

Short-range scans are free. That is, they use up no energy and no time. If you are in battle, doing a short-range scan does not give the enemies another chance to hit you. You can safely do a short-range scan anytime you like.

If your short-range sensors are damaged, this command will only show the contents of adjacent sectors.

If you are using the screen-oriented interface, this command is suppressed; instead, a full status report will always be present on the screen.

This command gives you information about the current state of your starship as follows:

Status information is free—it uses no time or energy, and if you are in battle, the Klingons are not given another chance to hit you.

Status information can also be obtained by doing a short-range scan. See the SRSCAN command for details.

Each item of information can be obtained singly by requesting it. See REQUEST command for details.

If you are using the screen-oriented interface, this command is suppressed; instead, a long-range scan will always be present on the screen.

A long-range scan gives you general information about where you are and what is around you. Here is an example output.

    Long-range scan for Quadrant 5 - 1
       -1  107  103
       -1  316    5
       -1  105 1000

This scan says that you are in row 5, column 1 of the 8 by 8 galaxy. The numbers in the scan indicate how many of each kind of thing there is in your quadrant and all adjacent quadrants. The digits are interpreted as follows.

For example, in your quadrant (5 - 1) the number is 316, which indicates 3 Klingons, 1 starbase, and 6 stars. The long-range scanner does not distinguish between ordinary Klingons and Klingon command ships. If there is a supernova, as in the quadrant below and to your right (quadrant 6 - 2), there is nothing else in the quadrant.

Romulans possess a “cloaking device” which prevents their detection by long-range scan. Because of this fact, Starfleet Command is never sure how many Romulans are “out there”. When you kill the last Klingon, the remaining Romulans surrender to the Federation.

Planets are also undetectable by long-range scan. The only way to detect a planet is to find it in your current quadrant with the short-range sensors.

Since you are in column 1, there are no quadrants to your left. The minus ones indicate the negative energy barrier at the edge of the galaxy, which you are not permitted to cross.

Long-range scans are free. They use up no energy or time, and can be done safely regardless of battle conditions.

As you proceed in the game, you learn more and more about what things are where in the galaxy. Whenever you first do a scan in a quadrant, telemetry sensors are ejected which will report any changes in the quadrant(s) back to your ship, providing the sub-space radio is working. Spock will enter this information in the chart. If the radio is not working, Spock can only enter new information discovered from scans, and information in other quadrants may be obsolete.

The chart looks like an 8 by 8 array of numbers. These numbers are interpreted exactly as they are on a long-range scan. A period (.) in place of a digit means you do not know that information yet. For example, ... means you know nothing about the quadrant, while .1. menas you know it contains a base, but an unknown number of Klingons and stars.

Looking at the star chart is a free operation. It costs neither time nor energy, and can be done safely whether in or out of battle.

At any time you may ask for a damage report to find out what devices are damaged and how long it will take to repair them. Naturally, repairs proceed faster at a starbase.

If you suffer damages while moving, it is possible that a subsequent damage report will not show any damage. This happens if the time spent on the move exceeds the repair time, since in this case the damaged devices were fixed en route.

Damage reports are free. They use no energy or time, and can be done safely even in the midst of battle.

This command is the usual way to move from one place to another within the galaxy. You move under warp drive, according to the current warp factor (see “WARP FACTOR”).

There are two command modes for movement: MANUAL and AUTOMATIC. The manual mode requires the following format:

	MOVE MANUAL <deltax> <deltay>

<deltax> and <deltay> are the horizontal and vertical displacements for your starship, in quadrants; a displacement of one sector is 0.1 quadrants. Specifying <deltax> and <deltay> causes your ship to move in a straight line to the specified destination. If <deltay> is omitted, it is assumed zero. For example, the shortest possible command to move one sector to the right would be

	M M .1

The following examples of manual movement refer to the short-range scan shown earlier.

  Destination Sector	Manual Movement command
	3 - 1			M M -.3 -.1
	2 - 1			M M -.3
	1 - 2			M M -.2 .1
	1 - 4			M M 0 .1
  (leaving quadrant)		M M 0 .2

The automatic mode is as follows:

	MOVE AUTOMATIC <qrow> <qcol> <srow> <scol>

<para>where <qrow> and <qcol> are the row and column numbers of the destination quadrant, and <srow> and <scol> are the row and column numbers of the destination sector in that quadrant. This command also moves your ship in a straight line path to the destination. For moving within a quadrant, <qrow> and <qcol> may be omitted. For example, to move to sector 2 - 9 in the current quadrant, the shortest command would be

	M A 2 9

To move to quadrant 3 - 7, sector 5 - 8, type

	M A 3 7 5 8

and it will be done. In automatic mode, either two or four numbers must be supplied.

If your game is in "fancy" mode, there ia a way to input coordinates that avoids any need to remember thet the Y coordinate comes first. Y values may be given as lowercase letters starting with a = 1. So for example:

	a1 = 1 - 1
	c5 = 3 - 5
	f2 = 6 - 2

The previous move xommand could be expressed as

	m a c7 e8

Automatic mode utilizes the ship's “battle computer.” If the computer is damaged, manual movement must be used.

If warp engines are damaged less than 10 stardates (undocked) you can still go warp 4.

It uses time and energy to move. How much time and how much energy depends on your current warp factor, the distance you move, and whether your shields are up. The higher the warp factor, the faster you move, but higher warp factors require more energy. You may move with your shields up, but this doubles the energy required.

You can move within a quadrant without being attacked if you just entered the quadrant or have been attacked since your last move command. This enables you to move and hit them before they retaliate.

Your warp factor controls the speed of your starship. The larger the warp factor, the faster you go and the more energy you use.

Your minimum warp factor is 1.0 and your maximum warp factor is 10.0 (which is 100 times as fast and uses 1000 times as much energy). At speeds above warp 6 there is some danger of causing damage to your warp engines; this damage is larger at higher warp factors and also depends on how far you go at that warp factor.

At exactly warp 10 there is some probability of entering a so-called “time warp” and being thrown foward or backward in time. The farther you go at warp 10, the greater is the probability of entering the time warp.

The impulse engines give you a way to move when your warp engines are damaged. They move you at a speed of 0.95 sectors per stardate, which is the equivalent of a warp factor of about 0.975, so they are much too slow to use except in emergencies.

Movement commands are indicated just as in the “MOVE” command.

The impulse engines require 20 units of energy to engage, plus 10 units per sector (100 units per quadrant) traveled. It does not cost extra to move with the shields up.

Your deflector shields are a defensive device to protect you from Klingon attacks (and nearby novas). As the shields protect you, they gradually weaken. A shield strength of 75%, for example, means that the next time a Klingon hits you, your shields will deflect 75% of the hit, and let 25% get through to hurt you.

It costs 50 units of energy to raise shields, nothing to lower them. You may move with your shields up; this costs nothing under impulse power, but doubles the energy required for warp drive.

Each time you raise or lower your shields, the Klingons have another chance to attack. Since shields do not raise and lower instantaneously, the hits you receive will be intermediate between what they would be if the shields were completely up or completely down.

You may not fire phasers through your shields. However you may use the “high-speed shield control” to lower shields, fire phasers, and raise the shields again before the Klingons can react. Since rapid lowering and raising of the shields requires more energy than normal speed operation, it costs you 200 units of energy to activate this control. It is automatically activated when you fire phasers while shields are up. You may fire photon torpedoes, but they may be deflected considerably from their intended course as they pass through the shields (depending on shield strength).

You may transfer energy beteen the ship's energy (given as “Energy” in the status) and the shields. The word “TRANSFER” may be abbreviated “T”. The ammount of energy to transfer is the number of units of energy you wish to take from the ship's energy and put into the shields. If you specify an negative number, energy is drained from the shields to the ship. Transfering energy constitutes a turn. If you transfer energy to the shields while you are under attack, they will be at the new energy level when you are next hit.

Enemy torpedoes hitting your ship explode on your shields (if they are up) and have essentially the same effect as phaser hits.

Phasers are energy weapons. As you fire phasers at Klingons, you specify an “amount to fire” which is drawn from your energy reserves. The amount of total hit required to kill an enemy is partly random. but also depends on skill level.

The average hit required to kill an ordinary Klingon varies from 200 units in the Novice game to 250 units in the Emeritus game. Commanders normally require from 600 (Novice) to 700 (Emeritus). The Super-commander requres from 875 (Good) to 1000 (Emeritus). Romulans require an average of 350 (Novice) to 450 (Emeritus).

Hits on enemies are cumulative, as long as you don't leave the quadrant.

In general, not all that you fire will reach the Klingons. The farther away they are, the less phaser energy will reach them. If a Klingon is adjacent to you, he will receive about 90% of the phaser energy directed at him; a Klingon 5 sectors away will receive about 60% and a Klingon 10 sectors away will receive about 35%. There is some randomness involved, so these figures are not exact. Phasers have no effect beyond the boundaries of the quadrant you are in.

Phasers may overheat (and be damaged) if you fire too large a burst at once. Firing up to 1500 units is safe. From 1500 on up the probability of overheat increases with the amount fired.

If phaser firing is automatic, the computer decides how to divide up your <amount to fire> among the Klingons present. If phaser firing is manual, you specify how much energy to fire at each Klingon present (nearest first), rather than just specifying a total amount. You can abreviate “MANUAL” and “AUTOMATIC” to one or more letters; if you mention neither, automatic fire is usually assumed.

Battle computer information is available by firing phasers manually, and allowing the computer to prompt you. If you enter zero for the amount to fire at each enemy, you will get a complete report, without cost. The battle computer will tell you how much phaser energy to fire at each enemy for a sure kill. This information appears in parentheses prior to the prompt for each enemy. Since the amount is computed from sensor data, if either the computer or the S.R. sensors are damaged, this information will be unavailable, and phasers must be fired manually.

A safety interlock prevents phasers from being fired through the shields. If this were not so, the shields would contain your fire and you would fry yourself. However, you may utilize the “high-speed shield control” to drop shields, fire phasers, and raise shields before the enemy can react. Since it takes more energy to work the shields rapidly with a shot, it costs you 200 units of energy each time you activate this control. It is automatically activated when you fire phasers while the shields are up. By specifying the <no> option, shields are not raised after firing.

Phasers have no effect on starbases (which are shielded) or on stars.

The cloaking device prevents your ship from being seen by any enemy vessels. When the cloaking device is in use, your subspace radio will not receive transmissions, torpedoes will be less accurate, you cannot dock, and you cannot use your warp engines. Enemy ships will get a chance to attack you when you turn cloaking on.

The Treaty of Algeron with the Romulans in Stardate 2311 prohibits the use of cloaking devices. If a Romulan ship observes you cloaking or uncloaking after this point in time you will be in violation, which will hurt your final score.

The Faerie Queene does not have a cloaking device.

Ask a Klingon To surrender.

The capture command provides a more humane way to end a battle than just destroying the Klingon battleship with the crew aboard. Assuming the subspace radio and transporter are working, and there is room in the brig, this command will ask the captain of the weakest Klingon ship in the quadrant to surrender. If the captain agrees, some of the crew will transport to your ship and the Klingon ship will be destroyed. This command does take time and you will be attacked by any other enemy ships if the surrender occurs.

When you dock, any captured Klingons will be transferred to the base and you will be credited with the lives you save.

This command supplies you with information about the state of the current game. Its purpose is to remind you of things that you have learned during play, but may have forgotten, and cannot otherwise retrieve if you are not playing at a hard-copy terminal.

You are told the following things:

This same information is automatically given to you when you start to play a frozen game.

This command allows using the ship's computer (if functional) to calculate travel times and energy usage.

Photon torpedoes are projectile weapons—you either hit what you aim at, or you don't. There are no “partial hits”.

One photon torpedo will usually kill one ordinary Klingon, but it usually takes about two for a Klingon Commander. Photon torpedoes can also blow up stars and starbases, if you aren't careful.

You may fire photon torpedoes singly, or in bursts of two or three. Each torpedo is individually targetable. The computer will prompt you, asking for the target sector for each torpedo. Alternately, you may specify each target in the command line.

Photon torpedoes cannot be aimed precisely—there is always some randomness involved in the direction they go. Photon torpedoes may be fired with your shields up, but as they pass through the shields they are randomly deflected from their intended course even more.

Photon torpedoes are proximity-fused. The closer they explode to the enemy, the more damage they do. There is a hit “window” about one sector wide. If the torpedo misses the hit window, it does not explode and the enemy is unaffected. Photon torpedoes are only effective within the quadrant. They have no effect on things in adjacent quadrants.

If more than one torpedo is fired and only one target sector is specified, all torpedoes are fired at that sector. For example, to fire two torpedoes at sector 3 - 4, you type

     PHO 2 3 4           (or)           PHO 2 3 4 3 4

To fire torpedoes at, consecutively, sectors 2 - 6, 1 - 10, and 4 - 7, type

     PHO 3 2 6 1 10 4 7

There is no restriction to fire directly at a sector. For example, you can enter

       PHO 1 3 2.5

to aim between two sectors. However, sector numbers must be 1 to 10 inclusive.

In fancy mode, you can write "PHO 3 2 6 1 10 4 7" as

     pho 3 b6 a10 d7

Fractional Y coordinates are not supported.

You may dock your starship whenever you are in one of the eight sector positions immediately adjacent to a starbase. When you dock, your starship is resupplied with energy, shield energy photon torpedoes, and life support reserves. Repairs also proceed faster at starbase, so if some of your devices are damaged, you may wish to stay at base (by using the “REST” command) until they are fixed. If your ship has more than its normal maximum energy (which can happen if you've loaded crystals) the ship's energy is not changed.

You may not dock while in standard orbit around a planet.

Starbases have their own deflector shields, so you are completely safe from phaser attack while docked. You are also safe from long-range tractor beams.

Starbases also have both short and long range sensors, which you can use if yours are broken. There's also a subspace radio to get information about happenings in the galaxy. Mr. Spock will update the star chart if your ask for it while docked and your own radio is dead.

This command simply allows the specified number of stardates to go by. This is useful if you have suffered damages and wish to wait until repairs are made before you go back into battle.

It is not generally advisable to rest while you are under attack by Klingons or Romulans.

[Originally, this command was called “HELP”, but these days that might be misconstrued as an attempt to browse built-in documentation! In some later versions it was CALL.]

When you get into serious trouble, you may call a starbase for help. Starbases have a device called a “long-range transporter beam” which they can use to teleport you to base. This works by dematerializing your starship at its current position and re-materializing it adjacent to the nearest starbase. Teleportation is instantaneous, and starbase supplies the required energy—all you have to do is let them know (via subspace radio) that you need to be rescued.

This command should be employed only when absolutely necessary. In the first place, calling for help is an admission on your part that you got yourself into something you cannot get yourself out of, and you are heavily penalized for this in the final scoring. Secondly, the long-range transporter beam is not reliable—starbase can always manage to dematerialize your starship, but (depending on distance) may or may not be able to re-materialize you again. The long-range transporter beam has no absolute maximum range; if you are in the same quadrant as a starbase, you have a good chance (about 90%) of re-materializing successfully. your chances drop to roughly 50-50 at just over 3 quadrants.

You may abandon the Enterprise if necessary. If there is still a starbase in the galaxy, you will be sent there and put in charge of a weaker ship, the Faerie Queene.

The Faerie Queene cannot be abandoned.

You may self-destruct, thus killing yourself and ending the game. If there are nearby Klingons, you may take a few of them with you (the more energy you have left, the bigger the bang). It is possible to win this way, if you kill off your last adversaries with the blast.

In order to self-destruct you must remember the password you typed in at the beginning of the game.

Immediately cancel the current game; no conclusion is reached. You will be given an opportunity to start a new game or to leave the Star Trek program.

Utilizing the short-range sensors, science officer Spock gives you a readout on any planet in your quadrant. Planets come in three classes: M, N, and O. Only class M planets have earth-like conditions. Spock informs you if the planet has any dilithium crystals. Sensor scans are free.

To land on a planet you must first be in standard orbit. You achieve this in a manner similar to docking at starbase. Moving to one of the eight sector positions immediately adjacent to the planet, you give the orbit command which puts your ship into standard orbit about the planet. Since this is a maneuver, a small amount of time is used; negligible energy is required. If enemies are present, they will attack.

The transporter is a device which can convert any physical object into energy, beam the energy through space, and reconstruct the physical object at some destination. Transporting is one way to land on a planet. Since the transporter has a limited range, you must be in standard orbit to beam down to a planet. Shields must be down while transporting.

The transport command is used to beam a landing party onto a planet to mine “dilithium crystals”. Each time the command is given the landing party (which you lead) moves from the ship to the planet, or vice-versa.

You are advised against needless transporting, since like all devices, the transporter will sometimes malfunction.

The transporter consumes negligible time and energy. Its use does not constitute a “turn”.

An alternate way to travel to and from planets. Because of limited range, you must be in standard orbit to use the shuttle craft, named "Galileo". Shields must be down.

Unlike transporting, use of the shuttle craft does constitute a “turn” since time is consumed. The time naturally depends on orbit altitude, and is equal to 3.0e-5 times altitude. Shuttling uses no ship energy.

You should use the same travel device going from the planet to the ship as you use to go from the ship to the planet. However it is possible to transport to the planet and have the Galileo crew come and pick your landing party up, or to take the Galileo to the planet and then transport back, leaving the shuttle craft on the planet.

Once you and your mining party are on the surface of a planet which has dilithium crystals, this command will dig them for you.

Mining requires time and constitutes a “turn”. No energy is used. Class M planets require 0.1 to 0.3 stardates to mine. Class N planets take twice as long, and class O planets take three times as long.

Dilithium crystals contain enormous energy in a form that is readily released in the ship's power system. It is an excellent idea to mine them whenever possible, for use in emergencies. You keep the crystals until the game is over or you abandon ship when not at a starbase.

This is a very powerful command which should be used with caution. Once you have dilithium crystals aboard ship, this command will instruct engineering officer Scott and Mr. Spock to place a raw dilithium crystal into the power channel of the ship's matter-antimatter converter. When it works, this command will greatly boost the ship's energy.

Because the crystals are raw and impure, instabilities can occur in the power channel. Usually Scotty can control these. When he cannot, the results are disastrous. Scotty will use those crystals that appear to be most stable first.

Since using raw dilithium crystals for this purpose entails considerable risk, Starfleet Regulations allow its use only during "condition yellow". No time or energy is used.

Mr. Spock presents you a list of the available information on planets in the galaxy which are potential dilithium sources. Since planets do not show up on long-range scans, the only way to obtain this information is with the “SENSORS” command.

The purpose of the FREEZE command is to allow a player to save the current state of the game, so that it can be finished later. A plaque may not be generated from a frozen game. A file with the specified <file name> and type '.TRK' is created (if necessary) in the current directory, and all pertinent information about the game is written to that file. The game may be continued as usual or be terminated at the user's option.

To restart a game created by the “FREEZE” command, the user need only type “FROZEN” in response to the initial question about the type of game desired, followed by the <file name>.

NOTE: A “tournament” game is like a frozen game, with the following differences. (1) Tournament games always start from the beginning, while a frozen game can start at any point. (2) Tournament games require only that the player remember the name or number of the tournament, while the information about a frozen game must be kept on a file. Tournament games can be frozen, but then they behave like regular frozen games.

A point worth noting is that 'FREEZE' does not save the seed for the random number generator, so that identical actions after restarting the same frozen game can lead to different results. However, identical actions after starting a given tournament game always lead to the same results.

If you are using the screen-oriented interface, this command is suppressed; instead, a full status report will always be present on the screen.

This command allows you to get any single piece of information from the <STATUS> command. <ITEM> specifies which information as follows:

This command should be used only in those desperate cases where you have absolutely no alternative. The death ray uses energy to rearrange matter. Unfortunately, its working principles are not yet thoroughly understood, and the results are highly unpredictable.

The only good thing that can result is the destruction of all enemies in your current quadrant. This will happen about 70% of the time. Only enemies are destroyed; starbases, stars, and planets are unaffected.

Constituting the remaining 30% are results varying from bad to fatal.

The death ray requires no energy or time, but if you survive, enemies will hit you.

The Faerie Queene has no death ray.

If the death ray is damaged in its use, it must be totally replaced. This can only be done at starbase. Because it is a very complex device, it takes 9.99 stardates at base to replace the death ray. The death ray cannot be repaired in flight.

The Enterprise carries a limited number of Long Range Probes. These fly to the end of the galaxy and report back a count of the number of important things found in each quadrant through which it went. The probe flies at warp 10, and therefore uses time during its flight. Results are reported immediately via subspace radio and are recorded in the star chart.

The probe can also be armed with a NOVAMAX warhead. When launched with the warhead armed, the probe flies the same except as soon as it reaches the target location, it detonates the warhead in the heart of a star, causing a supernova and destroying everything in the quadrant. It then flies no further. There must be a star in the target quadrant for the NOVAMAX to function.

The probe can fly around objects in a galaxy, but is destroyed if it enters a quadrant containing a supernova, or if it leaves the galaxy.

The target location is specified in the same manner as the MOVE command, however for automatic movement, if only one pair of coordinates are specified they are assumed to be the quadrant and not the sector in the current quadrant!

The Faerie Queene has no probes.

This command provides a quick way to exit from the game when you observe a Klingon battle cruiser approaching your terminal. Its effect is to freeze the game on the file 'EMSAVE.TRK' in your current directory, erase the screen, and exit.

Of course, you do lose the chance to get a plaque when you use this maneuver.

This command reads the appropriate section from the SST.DOC file, providing the file is in the current directory.

Switch from tty to curses interface. Mainly useful for debugging, when continuing a replayed game.

Set or clear feature flags. With no argument, list feature flags. The verbs SET and CLEAR are available to set or clear a list of feature flags following on the line. Mainly useful for development and improving test coverage.

The original Star Trek seems to have been written by Mike Mayfield at the beginning of the 1970s. His first version was in BASIC for a Sigma 7 in 1971; in 1972 he rewrote it in Hewlett Packard BASIC. The source is included in the SST2K repository. In January 1975 it became part of the DECUS library under the name SPACWR.

While some people claim to have recollections of playing Trek games in the late 1960s, the earlier ones seem actually to have been variants of SPACEWAR, the earlier space-combat game on the PDP-1. Mayfield wrote in 2000 that he invented the Trek-style galactic grid, and the evidence seems to back that up. Some of the confusion probably stems from the fact that Mayfield's original and several early descendants were distributed under the name SPACWR.

Many different versions radiated from Mayfield's original; most of the ones in BASIC are descended from a SPACWR version that David Ahl published in 101 BASIC Computer Games, July 1973. This was a port of Mayfield's version obtained from the HP Contributed Programs library.

Our SST2K is descended from a Taurus BASIC program by Grady Hicks dated 5 April 1973. This does not appear to have been derived from Ahl's SPACWR. The header says "GENERAL IDEA STOLEN FROM PENN. U.", and the game has several features not present in SPACEWR: notably, the Death Ray, ramming, and the Klingon summons to surrender. And, of course, it predates Ahl's book. The source is included in the SST2K repository.

Dave Matuszek, Paul Reynolds et. al. at UT Austin played the Hicks version on a CDC6600, but disliked the long load time and extreme slowness of the BASIC program. (David Matuszek notes that the Hicks version he played had a habit of throwing long quotes from Marcus Aurelius at the users, a feature he found intolerable on a TTY at 110 baud. It must, therefore, have been rather longer than the one we have.)

The Austin crew proceeded to write their own Trek game, loosely based on the Hicks version, in CDC6600 FORTRAN. Most of the code was written in 1973-1974. At that time, the game was just called "Star Trek"; the "Super" was added by later developers. In the rest of this history we'll call it the "UT FORTRAN" version.

Dave Matuszek reports that the UT FORTRAN codebase he worked on in 1973-1974 was like Mayfield's original and most later versions in BASIC, in that it used used polar coordinates (a clockface angle and a distance) for manual navigation.

Tom Almy writes: "I've received further information that the black holes, Tholian web, Super Commander, and Emeritus mode were added by Marc Newman."

At the time the UT FORTRAN source was last translated to C it emitted the message "Latest update-21 Sept 78". Thus, it actually predated (and may have influenced) the best-known BASIC version, the "Super Star Trek" published by David Ahl in his November 1978 sequel BASIC Computer Games.

This 1978 "Super Star Trek" had been reworked by Robert Leedom and friends from (according to Leedom) Mayfield's HP port. There is internal evidence to suggest that at least some features of Leedom's SST may have derived from the UT FORTRAN version. In particular, Dave Matuszek recalls implementing command words to replace the original numeric command codes during 1973-1974, a feature Leedom's SST also had but the 1973 and 1975 SPACWRs did not.

One signature trait of the UT FORTRAN game and its descendants is that the sectors are 10x10 (rather than the 8x8 in Mike Mayfield's 1972 original and its BASIC descendants). The UT FORTRAN version also preserves the original numbered quadrants rather than the astronomically-named quadrants introduced in Ahl's SST and its descendants.

Eric Allman's BSD Trek game is one of these, also descended from the UT FORTRAN version via translation to C. However, the mainline version (now SST2K) has had a lot more stuff folded into it over the years — deep space probes, dilithium mining, the Tholian Web, and so forth.

Back in (about) 1977 I got a copy of the Super Star Trek game for the CDC 6600 mainframe computer. Someone had converted it to PDP-11 Fortran but couldn't get it to run because of its size. I modified the program to use overlays and managed to shoehorn it in on the 56k byte machine.

I liked the game so much I put some time into fixing bugs, mainly what could be called continuity errors and loopholes in the game's logic. We even played a couple tournaments.

In 1979, I lost access to that PDP-11. I did save the source code listing. In 1995, missing that old friend, I started converting the program into portable ANSI C. It's been slow, tedious work that took over a year to accomplish.

In early 1997, I got the bright idea to look for references to “Super Star Trek” on the World Wide Web. There weren't many hits, but there was one that came up with 1979 Fortran sources! This version had a few additional features that mine didn't have, however mine had some feature it didn't have. So I merged its features that I liked. I also took a peek at the DECUS version (a port, less sources, to the PDP-10), and some other variations.

Modifications I made:

Compared to original version, I've changed the “help” command to “call” and the “terminate” command to “quit” to better match user expectations. The DECUS version apparently made those changes as well as changing “freeze” to “save”. However I like “freeze”.

I added EMEXIT from the 1979 version.

That later version also mentions srscan and lrscan working when docked (using the starbase's scanners), so I made some changes here to do this (and indicating that fact to the player), and then realized the base would have a subspace radio as well — doing a Chart when docked updates the star chart, and all radio reports will be heard. The Dock command will also give a report if a base is under attack.

It also had some added logic to spread the initial positioning of bases. That made sense to add because most people abort games with bad base placement.

The experimental deathray originally had only a 5% chance of success, but could be used repeatedly. I guess after a couple years of use, it was less “experimental” because the 1979 version had a 70% success rate. However it was prone to breaking after use. I upgraded the deathray, but kept the original set of failure modes (great humor!).

I put in the Tholian Web code from the 1979 version.

I added code so that Romulans and regular Klingons could move in advanced games. I re-enabled the code which allows enemy ships to ram the Enterprise; it had never worked right. The 1979 version seems to have it all fixed up, but I'm still not overly happy with the algorithm.

The DECUS version had a Deep Space Probe. Looked like a good idea so I implemented it based on its description.

I imported CAPTURE from BSD Trek.

I started from an older Tom Almy version and added features I had seen in other mainframe variants of the game, I wrote a screen-oriented interface for it based on the curses library.

My changes got merged into SST2K in 2005.

I played the FORTRAN version of this game in the late 1970s on a DEC minicomputer. In the late 1980s Dave Matuszek and I became friends; I was vaguely aware that he had had something to do with the original Star Trek game. In October 2004, sitting in Dave's living room, we got to talking about the game and I realized it would make a great exhibit for the Retrocomputing Museum.

A few quick web searches later we found Tom Almy's page. We downloaded his code and Dave verified that that it was a direct descendent of UT Super Star Trek — even though it had been translated to C, he was able to recognize names and techniques from the FORTRAN version he co-wrote.

This game became an open-source project; see the project site.

After I launched the Berlios project, Stas Sergeev contacted me. We worked together to merge in his changes.

Modifications I've made:

Here are some good pages on the history of Star Trek games:

These are the original acknowledgments by Dave Matuszek and Paul Reynolds:

The authors would like to thank Professor Michael Duggan for his encouragement and administrative assistance with the development of the Star Trek game, without which it might never have been completed.

Much credit is due to Patrick McGehearty and Rich Cohen, who assisted with the original design of the game and contributed greatly to its conceptual development.

Thanks are also due to Carl Strange, Hardy Tichenor and Steven Bruell for their assistance with certain coding problems.

This game was inspired by and rather loosely based on an earlier game, programmed in the BASIC language, by Jim Korp and Grady Hicks. It is the authors' understanding that the BASIC game was in turn derived from a still earlier version in use at Penn State University.

These are the original references by Dave Matuszek and Paul Reynolds: