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 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.
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?
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.
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.
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.
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.
