Porting the original text star trek game to Arduino?

Back when I was a wee tot and computers were typewriters with reams of paper..

There was a text based Start Trek game. It was funky and fun. I'd like to port it to Arduino. or more precisly, I'd like to port it to my handheld that is run by an Arduino.

I think found the codebase for it in this time period : The Classic Super Star Trek Game

I'm not all that zippy porting things, so I was wondering if anyone would like to have a go at that bit?

I can do the UI graphics and packaging with a touch screen.

No, this is not for money. This is just for fun if someone wants to help.

Thanks!

-jim lee

What is the Arduino?

wildbill:
What is the Arduino?

Huh? Looks around. Its everywhere?

OH!

Teensy 3.2

-jim lee

I hacked it until it compiled, much of which was commenting stuff out where it was trying to use the file system or the clock. There was some problem with some of the extern references too - just persuading old C stuff to actually compile. It's still using stdio though which I wouldn't have expected to get past gcc for AVR.

It's not at the point where it would actually work, but it compiled to ~110k of code for an Uno (the machine I was using doesn't have any Teensy stuff loaded). So I expect it can be done.

I do worry because the screen I have can only do 40 chars across. (Just did the calculation) Is there a setting for screen width? I don't think 40 char was too uncommon back in the day.

The display I use has an SD drive. If the disk stuff is important we could use that.

-jim lee

To my surprise, just doing a make on the standard ansi C source built it on a Pi without errors and it didn’t crash when I ran it. Running a few commands (commands, srscan) shows that it was probably designed for 80 chars wide.

I made a version that I was able to load to a Teensy. Rudimentary commands work in the serial monitor. I had to make quite a few changes to the code though, mostly minor stuff just to get rid of warnings but I may have broken something. There are some remaining compiler warnings about possible use of uninitialized variables too so it may well have bugs of its own - the code is nasty or perhaps I should say, antique.

Some of the screens I've seen in basic testing are wider than 40 characters, so as you suspected, if you want to get this running on your device, the display piece is going to need some work.

I only have 240 pixels.. I'll just give it a go, see what I see. Maybe I can come up with something? I guess I could mix graphics, but that kinda' goes againced the whole text game thing.

And yes, I remember that code from the late 60s. Its OLD! I used to play it on a teletype hooked to an HP 2000. Man! I wasted a LOT of paper playing that.

How should we integrate the two parts? I'm thinking I could just pretend I'm the serial monitor. we could share a string buffer. I fill it with user command. You fill it with the reply?

-jim lee

Actually, I don't know. I made it compile and then I had to make changes for the Teensy and the linker. Almost everything I did was cosmetic - casts and such. One of the errors I had vanished while I was still working it.

So. I don't know the code yet. Haven't really looked at it except where the compiler was unhappy. It needs some attention: good names for the functions would be a start but then there's variables called kk. Madness.

That said, the thing is driven by serial right now. If your front end provides the same interface, it could work. I'm just uncomfortable because it feels like we're about to embark on some big bang testing.

Here’s the code. Perhaps take a look at commands and srscan and see how you would display those. Maybe then we can see what a generic method would be.

It’s painful code, but there’s so much of it, I’m very reluctant to change it more than cosmetically for fear of breaking it.

ai.cpp (16.2 KB)

battle.cpp (36 KB)

events.cpp (20.6 KB)

finish.cpp (14.1 KB)

moving.cpp (24.9 KB)

osx.cpp (680 Bytes)

planets.cpp (13.5 KB)

reports.cpp (14.5 KB)

setupx.cpp (16.1 KB)

sst.h (11.7 KB)

sst.ino (300 Bytes)

sstx.cpp (16.7 KB)

typedefs.h (241 Bytes)

vars.cpp (471 Bytes)

Ok, grabbed the files. Shall I set up a github spot for them? Might make this easier.

As for the 40 - 80 char width thing. I think I'll rewrite my stuff to allow horizontal scrolling. That may take a bit, but it would be really nice to have in the long run.

I see where you setup getch(). What is it using for output?

Also is this just basically a command processor? Or does it have something like loop() where it can initiate changes? So far, it looks to me like its just responding to commands.

The class this os going to "live in", or at least my current plan, Has setup(), loop(), idle(), closing(). 'ill add in a getch() and whatever you need for output.

-jim lee

Here you go : starTrekArduino on github

Hope this makes things easier..

-jim lee

Ok, I got it running on one of my Teensys. What kick! Thanks millions for getting it this far.

I found another website on this game : http://www.catb.org... super-star-trek It has playing instructions. etc.

Thanks for getting it runnable!

-jim lee

jimLee:
I see where you setup getch(). What is it using for output?

Also is this just basically a command processor? Or does it have something like loop() where it can initiate changes? So far, it looks to me like its just responding to commands.

The class this os going to "live in", or at least my current plan, Has setup(), loop(), idle(), closing(). 'ill add in a getch() and whatever you need for output.

Output is a mess. There are several different ways: It looks like the intent was to use some routines called prout, proutn and prouts. But some of the code uses printf instead. I started changing that to Serial.printf because the linker was complaining that it couldn't find _write and I had assumed that printf was the reason. Halfway through that process, I did something unknown that fixed that issue so I left some of the plain printfs in there. There's also a PutChar function that's only called twice and only for '\n'. Obviously there's some scope for cleanup.

As far as I can see, it just responds to commands. The main function I renamed runsst. It has an infinite loop that mostly calls makemoves which is the command processor. All the rest of the game logic resides in the functions that are called to execute commands.

Got it to compile for my handheld but..

"`FLASH' overflowed by 9352 bytes"

I'm going to have to do some trimming of my stuff in there.

-jim lee

Ok I got it starting to run on my hand held. at least the text mostly coming to the screen. Getting a message back is a bit.. tricky..

Spent no end of time trying to figure out where or what chew() was.

-jim lee

jimLee:
Spent no end of time trying to figure out where or what chew() was.

It's riddled with poor names. Luckily, many of them have comments where they are defined. That's how I know that justin means just came in to this quadrant. Really!!?? That's also why I have a terminal window open so I can use grep!

I suspect that this was written for a machine where int is 16 bytes. So there are some savings to be made with variable types if RAM gets short. There are a number of flag variables that these days would be bool too.

Got it running on my hand held!

Now I have to go through and format stuff to be veiwable on my little screen.

I've never been ab le to grasp the ? command stuff.

What would this be as a standard if statement?

starch[quadx][quady] = damage[DRADIO]>0.0 ? d.galaxy[quadx][quady]+1000:1;

Thanks!

-jim lee

Never mind, I found it.

-jim lee

Really bad quality but, my son shot a quick video of me playing it on my little Arduino handheld.

U-Tube link.

Thanks again for the help wildbill!!

-jim lee