Some of these are already scattered around my other pages and
sometimes part of other things, gathering all of it together so I
don't keep having to hunt the stuff down. Most of these programs
are descended from '70's-era minicomputer and mainframe programs,
converted as needed to run them on modern PC's or available
simulators and sometimes highly modified to make them work the way
I want. Some are not modified and presented as I found them.
Five systems/languages are represented here...
As far as I can tell, the material here was derived from public
domain material, obtained from public sources and presumed free to
distribute, or in the case of the antique operating systems, has
been graciously released by the owner for non-commercial use. Star
Trek is a registered trademark of CBS Studios Inc. which have
nothing to do with any of this. This material is intended only for
personal non-commercial use.
Most of the programs from the HP Contributed Users Library ran on
larger Time Share BASIC systems such as HP2000C or ACCESS. It's
possible to simulate the full system but it's tricky - two
instances of the SimH hp2100 simulator have to be running and
synchronized with each other, and if the system loses power while
running it usually becomes damaged. The HP2000E was a cut-down
version that ran on a single CPU, and it was simple enough to rig
up a simulation environment for it on a relatively compact 7900
disk image with a utility system on the other side for booting it
and fixing it when it didn't get put to sleep.. which only takes
one forgetful window close. Although TSB-E only provided a bit
over 4KW of memory, its BASIC was similar enough to the full
version that interesting programs like STTR1 could be run without
too much trouble, just had to break into chunks. The TTYTREK
version of Trek was small enough to fit into memory in one chunk
and required minimal mods to run.
STTR1 was written by Mike Mayfield in 1973 for the HP2000C Time
Share BASIC system, based on an earlier version written for a
Sigma 7 mainframe that apparently was never saved to an actual
file. The story with a note from the author can be read in this Games
of Fame article.
Here's my modified TSB-E version of STTR1...
The main visual mod was I compacted the display and added
divisions to the borders to make it easier to play.
Here is the TSB-E source code for this program: STTR1 STTR1A STTR1B STTR1C
Took a bit to figure out, but this appears to be the original STTR1 code I used to make the TSB-E
version, the "Extracted from" comment isn't part of the actual
code but was very helpful for tracking it down as I had lost my
original source (I did the TSB-E conversion in 2006). Here's what
a similar version of STTR1 looks like
running on a simulated ACCESS system...
This is an interesting Trek variation written by "Joe Altmaier sometime in the late 70s", adapted to run under TSB-E...
The concept is similar to other early Treks, the navigation
directions and quadrant/sector system is the same as STTR1, but it
uses letter inputs which are easier to remember than numbers and
some things are very different like the enemy base and attacks
taking place elsewhere. The look has been changed a bit, replaced
empty space with periods to help navigate. Here's the source for
TSB-E version of TTYTRK and brief
instructions I made for it in TTYTRI.
Here's what looks to be the close to the original
TTYTREK program, and least that's what I started with.
Simulated TSB=E system
Here's a simulated TSB-E system
containing these and several other programs (last modified
This is the initial "HELLO" and a CAT listing of the current
To run the simulation you will need a copy of the SimH HP2100 Simulator.
Also works with my old
hp2100 binaries from 2008. For Linux, besides hp2100 the
scripts are written to use the xterm terminal program. Edit the
boot script to use something else. The Windows boot batch will
likely need adapting, I couldn't get plain telnet to work but
PuTTY worked mostly fine.. bit of noise at the startup so first
thing entered is always wrong, but fine after that. Disconnection
is a bit noisy about a network error.. it gripes Are You Sure when
closing then gripes when the simulator just closes it. In Linux
the telnet client just exits with no fuss.
Here's the operator console and the instructions it prints for
starting up and shutting down...
TSB-E is a fairly fragile system, at least when running in a
simulator (the real minicomputer originally used ferrite core and
could ride through power outages). Accidentally closing the
simulator console window or even the telnet window can and usually
does break the system. Each time it is properly shut down the
system writes itself to a simulated magtape file which can be used
to restore the system if it breaks, if you get the dreaded system
not slept halt, just enter do fix.sim to restore the disk from the
last backup tape. Assuming it's good. Or just restore the disk
image from the zip.
The stock TSB-E system uses the "_" character for "rub out", so
entering CQT__AT is the same as CAT - it was designed for a
teletype machine. These days our TTY devices can actually back up
the cursor. With disk utilities and knowing where to look it's
easy to change the "_" to an ascii-8 backspace for more normal
operation. Most modern terminals emit ascii-127 for backspace,
enter control-H or control-Backspace to get ascii-8 (some
terminals have a swap function for that). On Windows BS used to be
ascii-8, not sure what it is now. Control-H doesn't erase the
character being backed over, and can't stop at the input prompt,
but it's better that CQT__AT. Here's a HP-IPL/OS-based TSB-E utility I made for patching for
that and restoring stock behavior. Can also flip the sleep flag,
usually permitting unslept systems to boot again, at least long
enough to copy off unsaved work. Does other stuff.
In 2002 I started getting into HP1000-series
minicomputers and with the help of Bob Shannon (along with a
bit of insistence and bribery) we made a simple (almost but not
really) Forth-like operating system called HP-IPL/OS. I did
most of my work using the SimH hp2100 simulator program but Bob
was into real hardware and sent me a real HP21MX E-series with
128KW ram to test with, in particular custom disk interfaces -
real period HP disk drives were very expensive and difficult to
maintain (not to mention being huge) so Bob designed an interface
that permitted hooking up a plain IDE drive, common at the time.
Bob made some words that could write and read chunks of memory to
and from disk sectors, and I used those words to make "XDOS". In
retrospect a really bad file system but it was simple and reliable
and worked for what we were doing. Files were limited to 32KW max
because it was designed primarily to save and load 31K binary
copies of ABS files and that was the size of the main memory bank
(the top 1KW is reserved). When it loads a binary it loads it into
alternate memory then runs a tiny program that lives at 77000
octal that simply swaps main and alternate memory and runs from
location 2. When done running the program, execute 77000 to return
to HP-IPL/OS. Thus the system could run existing software like
HPBASIC and MSUBASIC, and after exiting a program it was copied
back to alternate memory so if it contained a BASIC program
listing, the whole thing could be saved as a disk file or punched
to a PC file, just had to figure out the continue or run entry
point for BASIC and patch locations 2/3 to avoid erasing the
listing on startup. While XDOS for HP-IPL/OS requires a 21MX
system with at least 64KW memory, the binaries themselves run
standalone on any 32KW HP21xx system.
I started converting TSB code to papertape BASIC around
2007-2008, mostly at first using MSUBASIC because I found the
source for that first (MSUBASIC is compatible with papertape
HPBASIC). But as with TSB-E, best I could do for backspace was
find and change the "_" rubout character to control-H. The
game-changer came in 2010 when I got hold of the source code for
real "20392" HPBASIC and used the information to make "overlay"
patches that added cool stuff like a proper ascii-127 backspace,
peek, poke, byte I/O and my favorite feature, the ability to punch
itself with an embedded BASIC program to make standalone ABS
"apps". I didn't modify the core HPBASIC source at all, just made
trivial mods to the prepare program to make it spit out a 28KW
version then loaded stuff past that (including the old OCTOPUS
utility) with a few hooks into the HPBASIC code to intercept
characters for backspace etc. The modified version of HPBASIC with
source code and a bunch of games is in the hpbapps.zip file.
TREKPT - a STTR1 conversion for Papertape BASIC
The first thing I converted to papertape BASIC was STTR1 in
2007-2008, started with the TSB-E version since I liked the way it
worked and that code had already been somewhat simplified. This
turned out to be a major undertaking, as this was before I found
decent docs and source code. I mistakenly thought that papertape
BASIC only supported single letter variables (it can use
letter+number variables like TSB, I was just having other
issues..) so in an attempt to make it work I changed all the
variables to single letters or arrays. Somehow I managed to mess
up the coordinate system, after the conversion it use X,Y
coordinates instead of the usual Y,X but otherwise worked fine.
Here's TREKPT for papertape BASIC...
TTYTREK for Papertape BASIC
Here's a papertape version of
This conversion went much smoother, by this time I had better
This is a conversion of L.E.
Cochran's version of Star Trek...
This program was originally written for the Altair computer and
published in Computer
Notes 1976 02 01. For this papertape BASIC conversion I
started with the QBasic version of the program (file date 2000)
presented below and did the usual mods to make it run under
papertape basic - one statement per line, no strings, array
indexes start at 1 not 0, added number print subroutines, etc.
Since memory isn't as much of an issue the instructions are built
in. I was a bit surprised that papertape basic supports
comparisons in math expressions but the sign is flipped compared
to MS BASICs like QBasic and Altair BASIC - expressions like
(A>2) evaluate to 1 if true rather than -1 so that had to be
fixed. After the conversion it only barely resembled the original
code (plus there was a conversion bug in my originally posted
version.. happens) so made a few changes to the original logic.
The original subtracted one stardate for every move, no matter how
small or large.. changed the formula so that moves less than warp
1 cost only that much time (rounded to 0.125 increments.. no
cheating by doing 0.1 instead), and moves more than warp 2 add an
extra 0.1 year for each extra warp distance traveled. A bit more
balanced now. Dropped years remaining from the short scan display,
added that and other information to a new status report command,
and modified some of the text displays. This is fun code to hack
Here's a zip containing binary ABS
versions of TREKPT, PTSTRK and TTYTREK that work with the
HP2100 simulator notes
The "new" hp2100 simulator from the SimH HP Simulator
page works a bit differently than old versions of hp2100. I've
only just began to use the latest version (version 3.11-2 Release
30), the biggest change I've noticed so far compared to old
versions (I don't know how long it's been this way) is the command
'load file.abs' no longer works as a general purpose load
mechanism, it is now strictly restricted to the boot loader area
in the top 64 words of memory. This was always kind of a cheat,
the command was as if someone hand-decoded an absolute binary
system format papertape and keyed in the decoded words via front
panel switches one word at a time. While theoretically possible
(but fairly sure that it never happened for anything lengthy) and
certainly convenient for the modern hp2100 simulator operator,
this load behavior is not realistic and is nothing like how real
HP21xx and HP1000-series minicomputers operate. The correct way to
load a long ABS file is to do it how it's done on the real
hardware.. replace the simulator command 'load filename.abs' with
'attach ptr filename.abs' followed by 'boot ptr', that should work
the same with all versions of hp2100. This method is also more
compatible as, although rare, it's possible that software might
depend on values left by the stock papertape loader or expect that
PTR remains attached to the input binary to load additional data.
Other other visible changes I've noticed (that affect my existing
scripts or how I use the simulator)... Commands like 'set throttle
50%' have to be entered as 'set throttle 50%%' if used from the
simulator prompt, scripts don't seem to be affected but different
simulator versions interpret it differently so changing the
scripts to use commands like 'set throttle 3000K' instead. If
there is an unrecognized command (such as the 'set [device]
translate' command I added to my old modified hp2100
simulators for simple HP terminal emulation) the simulator
pauses rather than just skipping the command. Pressing control-E
to halt the simulator now drops to the scp> prompt where you
can enter one command then the simulator automatically continues.
Have to now press control-E twice to get to the sim> prompt.
The CLK device is now called TBG but it still accepts CLK. The d
tty ttime and d tty ktime commands no longer work... this affects
the 7906 Disk Sim but that's the least of its trouble - binary
loads don't work any more with the new simulator version .. for
now to keep that simulation running I included the old working
Linux/Windows binaries, not a clue what the trouble might be.
The following simulator commands can load these and other ABS
binaries scattered around my pages, and should work with all
versions of hp2100...
;next two commands only matter if using extra memory
set cpu 21MX
set cpu 256K
;next command determines the speed
set throttle 3000K
;the dev sets are optional if just using TTY text output
;otherwise must match the binary that is being run
;MSU BASIC expects clk to be device 10. TTY defaults to 11
set clk dev=10
set tty dev=11
set ptr dev=12
set ptp dev=13
;this is needed for terminal codes or lowercase
set tty1 7B
;change the next command for what's being loaded
attach ptr filename.abs
;starting address, usually 2
To just load say TREKPT.abs and not use the punch capability, it
set throttle 3000K
attach -e ptr TREKPT.abs
Here is my current general purpose ABS load-and-run script for
Linux, included in the zip linked above...
----------- begin file hp2100_runabs -------------------
# This script assists in running abs files in the SimH hp2100 simulator,
# associate *.abs files to this script or run as a file manager script.
# Creates a temporary file in the /tmp/ directory containing the setup.
# As written uses xterm for the terminal, edit for other terminals.
# Note - filename must not contain spaces
# 2/26/21 updated to work with both old and new hp2100 simulators
cd $(dirname "$1")
> $tempfile echo "set cpu 21MX"
>> $tempfile echo "set cpu 256K"
>> $tempfile echo "set throttle 3000K"
>> $tempfile echo "set clk dev=10"
>> $tempfile echo "set tty dev=11"
>> $tempfile echo "set ptr dev=12"
>> $tempfile echo "set ptp dev=13"
>> $tempfile echo "set tty1 7B"
>> $tempfile echo "attach -e ptr" $(basename "$1")
>> $tempfile echo "boot ptr"
>> $tempfile echo "run 2"
xterm -geometry 80x25 -bg black -fg green -fn 10x20 -e hp2100 $tempfile
----------- end file hp2100_runabs ---------------------
I've updated the HP2100treks.zip and TSBEsim.zip packages here but there are other hp2100 simulator related things around my pages that will need adjustments to work with the new hp2100 simulator. So far I've been able to find settings that work with the old, new and the v4 branch of the hp2100 simulator.
I went through a few 8-bit computers early on.. ZX81, Tandy Color
Computer, Commodore 64, then in the late '80's got into the Atari
8-bit computers. The Atari 800 was a really nice machine, built
like a tank, but it only had 48K ram. The XL and XE series were
flimsier but nicer to program. One of the programs I played with a
lot was a version of Super Star Trek that I typed in from David
Ahl's 1978 book BASIC MICROCOMPUTER GAMES. Like most 8-bit
computers back then, the Atari had a fairly limited 40-column text
display so had to get creative. My TREK.BAS program kept the SRS
display on screen at all times and auto-updated it (unless it was
damaged), new commands would "suck up" the text from the previous
command. Or at least was supposed to.. sometimes the display would
get messed up and required a SRS command to fix it.
My old Atari XE130 system was still working when I got a PC in
the early '90's and I was able to dump my floppy disks to disk
images, I forgot how I did that but probably involved some sort of
serial transfer, I had a box for my Atari that contained extra
memory, a real time clock and a serial port. Just glad I was able
to save a lot of my old Atari stuff.
Last year (2020) I dragged out my old Atari version of Super Star
Trek and fixed up some of the screen update bugs, and added
difficulty levels that increased the initial Klingon strength and
the chances of the Klingons attacking when entering a quadrant (in
the stock game the Klingons never fired first). Recently fixed a
couple more screen update bugs.
Here's TREKMOD running in the Atari800 emulator...
Here's the TREKMOD source
listing, it's not the actual source code as besides Atari
BASIC programs being stored in tokenized form, PC's do not
understand the Atari
character set. To create the source display files, the BASIC
programs were LISTed to PC disk files (the Atari800 simulator can
access PC files using the H: device) then a QBasic program I made was used to
convert the listing to Unicode and HTML that somewhat resembles
how the code looks on an Atari. My converter does not handle every
possible character and does not use many of the "potential Unicode
equivalents" listed on the wikipedia page, instead
This version of Star Trek seems to be inspired by the mythical
CDC6600 FORTRAN mainframe version or the "INTELLECT MDS" version
that was inspired by it, this variation of the Star Trek game uses
a 10x10 sector grid and directions are entered by clock direction,
due east is direction 3, north is 12 etc. I don't know who wrote
this version or remember where I got it from, but certainly from a
BBS because back then there was no public internet.
Here is a converted listing of the ENTERPRI.BAS program and
This is Ed Spoon's take on a Star Trek game...
It's not at all like other text versions of the game, if you
can't dillydally in this one or you will be taken out. As the documentation explains it
is not meant to be like "the monotonus Enter coordinates/star
chart Star Trek clones of the past". Here is the converted STARTREK_BAS listing. This
is just like I found it in my Atari disk dumps, I do not know if
it has been altered but likely not. The Internet Archive has the original
disk version of Ed Spoon's STARTREK.
Here is a zip file containing a disk image containing these Atari Trek games along with source
listing and Linux scripts for booting it in the Atari800 emulator.
The following programs require the actual QBASIC.EXE program to
run as listed, they will not run in QB64 or FreeBasic without
mods, although the mods should be fairly minor. In particular,
QB64 and FreeBasic do not support DEF FNX(Y)= type of function
definitions (it shouldn't be that hard to convert). The real
QBasic is used because it is closer to the original BASICs and
many of the original programs require only minimal modification.
The original QBASIC.EXE is widely available and works under
DosEmu/FreeDos or DosBox. QBasic.net
has downloads and instructions. Microsoft even has QBasic
for Windows 10 in their app store but I don't know how close
it is to the original.
This is a QBasic conversion of Super Star Trek from David Ahl's BASIC MICROCOMPUTER GAMES...
I started with listings from the Vintage Basic
Games website, little was done to it beyond separating the
commands and incorporating the instructions into the program, it
still requires uppercase input. A typo was corrected in line 440
(B9=2 is supposed to be B9=0) that causes the number of bases to
be off by 2. There is a similar typo in line 1150 (the 120 is
supposed to be 100) but that one is in favor of the player and
remains in this version.
This is a QBasic version of Ron Williams' *** SUPER STAR TREK ***...
This version of the game is based on the CDC 6600 mainframe
version, despite the name it is very different and more
complicated than the version of the game published by David Ahl.
This and similar descendants (including trek from the bsdgames
package) use clock-face directions - 12 is due north, 6 is south,
1.5 is north-east etc. There are other versions of this floating
around but most have been converted to run on other versions of
BASIC. The other day I was rummaging around and found a cryptic
program named STREK.BAS that
when run produced a zip file containing ST.BAS, which turned out
to be an older but damaged INTELLEC MDS VERSION of Trek. I think I
found most of the major bugs but I won't swear to it.
Popular file name! This is a QBasic
version of L.E. Cockran's Trek, originally from 1976...
Here's the instruction file. I
don't know where I got it, the files are dated November 2000, as
far as I can tell I haven't made any changes to it. This is
simplified version of Mike Mayfield's concept with only 6
commands, no need for separate shields or having to remember to
raise them. Those must be short years. The program was originally
written for an Altair computer, this appears to be the original
BASIC source code. The QBasic code is very similar as both
are Microsoft versions of BASIC.
Here is a zip file containing the above QBasic Treks.
Something extra.. here's a QBasic
conversion of UT-Trek that I just started working on...
So far I've done just enough to it to make it run, needs a lot of
BBC BASIC for SDL
is Richard Russell's cross-platform implementation of BBC BASIC
and is available for Windows, Linux, Mac and even Android. It can
run many old BBC BASIC programs unchanged or with minimal
modification and it doesn't take much to convert other BASIC
programs to work with it, yet it is also a modern BASIC that runs
on modern computers and can be used to create rather impressive
graphical software. BBC BASIC for SDL programs can be compiled to
Windows executables using the BBC BASIC
for Windows compiler, the resulting binaries are compact and
have no dependencies and work under Linux too using wine (is not
an) emulator. The compiler also works fine in Linux with wine.
SST2.bbc is a fairly straight
conversion of David Ahl's Super Star Trek...
It uses a grid to represent the quadrant which I find makes it
easier to navigate and aim torpedoes without computer assistance,
the stock look can be restored by changing a couple variables near
the beginning of the program. Not a whole lot was needed to get
SST to work in BBC BASIC, the original mostly already works but
the formatting is off because BBC BASIC doesn't add extra spaces
(I like that! I always disliked the extra spaces added by
Microsoft BASICs) and help lists can't be brought up because in
BBC BASIC out of range ON GOTO is not allowed. So fixed up that
stuff. When reading the docs I learned that BBC BASIC uses the
stack to control loops and there was five places (that I
noticed..) where it jumps out of a FOR/NEXT loop without going
through NEXT - while the code seemed to work fine the docs
specifically warn to not do that and it can leak memory and result
in subtle to severe bugs, so converted that code to use counters
and conditional jumps. Added a subroutine to be able to enter
commands in lower-case, played with the display and made a couple
changes to the computer to move the record to option 6 so enter
would bring up the list, added current location marks to the
record and modified the calculator so it would also print unit
Once I was playing it and was seriously low on energy and while
status said I had three bases but having been through the galaxy
found only one... then got to looking at the init code and that's
when I found the B9=2 typo in the Vintage Basic source listing.
Later also found and fixed a similar typo on line 1150.
Now to have fun with it...
The SST3 version adds color, game
save and restore, harder difficulty levels, and preferences that
it saves to a file. I had been playing with SST2 on my Android
phone, and on a tiny screen sometimes it was hard to tell what was
what and often I missed critical information like running out of
energy or shields. Adding COLOUR commands helped a lot.. bad
things are red or magenta, caution things are yellow, things like
damaged systems being fixed are green etc. If the color is too
much you can turn it off in the preference dialog. The game save
feature lets me save a game in progress by entering SAE (save and
exit) then continue later, if a save file is present it prompts to
restore the previous game. It's not intended as a cheat mechanism,
you can work around it but normally when the game ends by winning,
losing or quitting, the save file is removed. The harder
difficulty levels increase the initial Klingon strength, and make
it so that sometimes the Klingons shoot first when entering a
quadrant. This is similar to the mod I made for the Atari version.
It is still experimental, higher levels make it very difficult to
survive long so to make up for that you get more energy when
recharging, use level 0 (or just press enter when prompted) for
the stock game.
Running the program under Android is a bit different due to
platform differences... on my phone anyway, the only way to
trigger Esc to interrupt the program was to hit the "back" button
twice, and then the on-screen keyboard went away and it is very
tricky (but possible) to get it back. To get around that I added
another command STO for stop that stopped the program and
displayed the BBC BASIC > prompt without making the keyboard go
away, perfect for hacking the code on the go. The Android version
of BBC BASIC uses a shell called "touchide" for browsing and
running BBC BASIC programs, most of the examples return to the
shell by trapping errors including Esc, so pressing back once or
twice (depending on if the keyboard was showing) made it exit back
to touchide, at other times I prefered to just quit. I was using a
separate versions for different behaviors but keeping them in sync
was a hassle so added a SET command that brought up a preferences
dialog. It ain't pretty, just a sequence of prompts where just
enter keeps the stock setting. The SET dialog lets you choose
Monochrome or Color (if monochrome then prompts for foreground and
background color codes), choose between 5 different SRS displays -
stock, grid, dots and two styles of top/bottom border divisions -
lets you choose how it exits - quit, end or touchide (which only
shows if running under Android) - and what to do if an error
occurs (or Esc pressed) - end for a > prompt with an error
report or whatever is chosen for exit. Then it prompts to save the
preferences. If no then if a preference file exists it prompts to
delete it. Despite the sequential nature it's easy to use, enter
always defaults to do nothing.
Here are some screenshots of the Windows exe version running
Here's a zip file with the SST3 package,
it contains the source in text and .bbc form, the Windows
executable and a doc file.
It probably isn't "done" (code like this never really is done,
just periodically frozen in moments of time) but one of the things
I'd like to do now is explore BBC BASIC's more graphical features
and other modes (perhaps something that also works with the stock
BBC Micro), maybe use some of the concepts from these old Trek
games to make an entirely different game. Doesn't have to be Trek
but having played this and similar games for a large portion of my
life I'm kind of partial to the basic idea - a grid of areas to
visit, within each grid there is stuff to do, and most
importantly, it waits for you to decide.
This page was created Feb 26, 2021, last mod Mar 11, 2021.
Terry Newton (firstname.lastname@example.org)