Tho Oregon Trail for TI-99/4

[TheTIGuy]

Hello, so a while back i decided to try to convert the 1971/78 version of The Oregon Trail (OREGON) to TI-BASIC (see here, scroll down on 1st page), and i thought it would be good to post my project, and have the text files available, because i can't use my TI and such stuff as often as when i started.

MY GOALS:

have a finished (or at least use-able) version by year's end

have compatibility with the regular ti-99/4, but special features and hints for the 4a.

have both text file and audio file versions

have a completely finished version by today on 2018

have a physical tape copy of the program (witch means a audio cable soon any-who)

I will also let people modify the finished versions, and will post updated versions so others can add to them.

P.S if you do add something, please post the version you made here.

[JamesD]

The original BASIC code isn't very good, and the MECC version is a bit different.

[TheTIGuy]

The original BASIC code isn't very good, and the MECC version is a bit different.

 

I know, but my code is worse (=) and it is the MECC version, it was created for the MECC, in '71 , when they first started, existing as a public timeshare-computer system for education.

[TheTIGuy]

Sorry, i forgot the actual code. =Poregon- NOTDONE.txt

[+arcadeshopper]

[x24b]

I like this. I wish I had the time to help! I will be watching though.

 

Watching intently from the sidelines, thinking; "More popcorn!"

 

[majestyx]

I just have to ask - will this fit into a non-expanded TI? I see the file you posted is almost 20KB and even if every bit of the 16KB was available, I don't see how this would work on a stock TI. I'm asking because this really does interest me, but also want to be realistic in the hopes of it actually working.

[JamesD]

I know, but my code is worse (=) and it is the MECC version, it was created for the MECC, in '71 , when they first started, existing as a public timeshare-computer system for education.

By MECC version, I'm talking about the Apple II version everyone is familiar with.

[TheTIGuy]

By MECC version, I'm talking about the Apple II version everyone is familiar with.

 

Oh. Sorry.

I just have to ask - will this fit into a non-expanded TI? I see the file you posted is almost 20KB and even if every bit of the 16KB was available, I don't see how this would work on a stock TI. I'm asking because this really does interest me, but also want to be realistic in the hopes of it actually working.

That's what was talking about, removing clutter (like the last 5 or so lines) and adapting to TI-BASIC. I've seen longer code before so...

That is also why i posted the doc, so other people can improve it.

EDIT: speaking of this, newer, smaller version with in-code shooting-timing footnotes separate. NotesOnShootingSub-Routine.txtoregon-Updated but still not done.txt

EDIT II: well, the code is brakes on my TI often, so i may have to rewrite from scratch!... or just change a TON of code...

Edited August 1, 2017 by TheTIGuy

[+adamantyr]

You should remove all LET keywords, they are redundant. Also the finished game I would remove all REM statements. Doing that may squeeze it down enough to fit.

 

I haven't had a chance to look more closely at the code, but I do see your text statements are pretty long... formatted for a 40 character screen? The TI only has 28, so you may need to slim down and tighten text.

 

Personally, I'd write the game in Extended BASIC with memory expansion so I could use sprites for the shooting subroutine, but that's just me.

[JamesD]

The logic could be simplified as well. I'm not sure if it would be smaller though.
Some of the strings could be put in DATA statements, then read into arrays and just PRINT STRING(I) instead of using ON GOTO with separate prints.
I have a work in progress version I converted to C somewhere.
Not sure what state it's in though.
The nice thing about C is you just define the arrays, so you don't need to read in the arrays, just use them.

Edited August 1, 2017 by JamesD

[majestyx]

I know, but my code is worse (=) and it is the MECC version, it was created for the MECC, in '71 , when they first started, existing as a public timeshare-computer system for education.

 

Actually, it looks like you're using the David H. Ahl 1978 version. It matches up against what's available as a .doc file here: https://deserthat.wordpress.com/2010/11/07/oregon-trail-ver-3-basic-3-1-1978/

 

Are you actually working with this on either a real TI or in an emulator? Because glancing at some of the code, there are things that just aren't going to work like:

 

770 IF $9=5 THEN 790

and

790 $9=0

 

($9 should be D9)

 

You can delete line 150 since the variable list is not present, although it is in the link above.

 

Also, not sure what lines 810 and 820 are doing, although that's in the .doc file as well (would need to figure out what that's doing in CDC and adapt it to ANSI/TI BASIC).

 

810 X1*-1

820 K8*S4*F1*F2*M*M9*D3=0

Definitely needs a lot of work, since its current form is in 3.1 BASIC for a CDC Cyber.

EDIT: I looked at the original listing in Creative Computing, May/June 1978 issue (available on archive.org) and in the above lines, the * should be an = which means it is setting all of those variables in 820 to zero. That syntax will not work in TI BASIC.

Edited August 1, 2017 by majestyx

[barry.peterson]

I just have to ask - will this fit into a non-expanded TI? I see the file you posted is almost 20KB and even if every bit of the 16KB was available, I don't see how this would work on a stock TI. I'm asking because this really does interest me, but also want to be realistic in the hopes of it actually working.

 

A ~20KB text file will result in a much shorter Program file

[TheTIGuy]

 

A ~20KB text file will result in a much shorter Program file

 

Yes. I KNOW THAT, but other people don't seem to.

 

 

Actually, it looks like you're using the David H. Ahl 1978 version. It matches up against what's available as a .doc file here: https://deserthat.wordpress.com/2010/11/07/oregon-trail-ver-3-basic-3-1-1978/

 

Are you actually working with this on either a real TI or in an emulator? Because glancing at some of the code, there are things that just aren't going to work like:

 

770 IF $9=5 THEN 790

and

790 $9=0

 

($9 should be D9)

 

You can delete line 150 since the variable list is not present, although it is in the link above.

 

Also, not sure what lines 810 and 820 are doing, although that's in the .doc file as well (would need to figure out what that's doing in CDC and adapt it to ANSI/TI BASIC).

 

810 X1*-1

820 K8*S4*F1*F2*M*M9*D3=0

Definitely needs a lot of work, since its current form is in 3.1 BASIC for a CDC Cyber.

EDIT: I looked at the original listing in Creative Computing, May/June 1978 issue (available on archive.org) and in the above lines, the * should be an = which means it is setting all of those variables in 820 to zero. That syntax will not work in TI BASIC.

 

 

Yes, i know it need a lot of work, that is why my time-frame is more than 4 months. Also, see post 1.

You should remove all LET keywords, they are redundant. Also the finished game I would remove all REM statements. Doing that may squeeze it down enough to fit.

 

I haven't had a chance to look more closely at the code, but I do see your text statements are pretty long... formatted for a 40 character screen? The TI only has 28, so you may need to slim down and tighten text.

 

Personally, I'd write the game in Extended BASIC with memory expansion so I could use sprites for the shooting subroutine, but that's just me.

I don't own XB, i only have parsec, muchman and hunt the wumpus. Also, a command can take 2.3 lines, so I'm fine with that, Also, as pointed out above, "A 20KB text file will result in a smaller program file than 20KB".

[TheTIGuy]

You know, i might just give up. People are criticising me instead of trying to help, and i frankly don't have the time for this anymore. IT IS STILL UNFINISHED, HOWEVER IF YOU WISH TO FINISH IT BE MY GUEST.IF YOU DO FINISH IT AND GET IT WORKING, PLEASE POST HERE.TRAIL-FINAL PROTOTYPE.txt

...

I may occasionally post a small update here, or even a few, and i will try to get a finished version out by august 2018.But no promises, and i mayn't ever finish it.

Edited August 2, 2017 by TheTIGuy

[majestyx]

Sorry, TheTIGuy - it wasn't my intention. I stated that I was quite interested in this project. In fact, I'm really surprised this was never made for the TI either commercially or by a hobbyist.

 

I thought I was helping by pointing out some things that would be causing errors as well as a concern for items that might be eating up memory unnecessarily. And since the source listing was for a completely different system, not much of which had been changed, I thought it would make sense to explain what it was from in order to figure out any differences between it and TI BASIC, especially for anyone else wanting to offer help. The listing that is available on the site I linked to above still has a number of typos, likely from bad OCR conversion, which is where funky errors like that $9=0 come from, and is why I referred to the original Creative Computing issue that has a printout of the program in order to use as another and/or better reference.

 

I do have to take exception with a statement made above. There really isn't much size difference in a TXT file LISTing of a BASIC program and the actual saved program file. A case in point would be the STRANGER program that is included in Classic99. The saved program file is 12,160 bytes, while the text file listing of the program is 13,744 bytes (using LIST "CLIP" in Classic99 to paste to Notepad), an 11.5% reduction. However, 818 of the 1584 bytes is nothing more than a CRLF (carriage return-line feed) at the end of the 409 lines of code, leaving an overhead (for lack of a better term) of 766 bytes which is only a 5.6% reduction. So no, it really isn't a much smaller file than the TXT file LISTing... but every bit (byte?) helps.

 

Of course, removing REMs, LETs and anything not needed to run the program will help in a final version of the program, which I see you've done some of already. My concern as to whether it would fit and run on a stock TI is now greatly reduced.

[TheTIGuy]

Sorry, TheTIGuy - it wasn't my intention. I stated that I was quite interested in this project. In fact, I'm really surprised this was never made for the TI either commercially or by a hobbyist.

 

I thought I was helping by pointing out some things that would be causing errors as well as a concern for items that might be eating up memory unnecessarily. And since the source listing was for a completely different system, not much of which had been changed, I thought it would make sense to explain what it was from in order to figure out any differences between it and TI BASIC, especially for anyone else wanting to offer help. The listing that is available on the site I linked to above still has a number of typos, likely from bad OCR conversion, which is where funky errors like that $9=0 come from, and is why I referred to the original Creative Computing issue that has a printout of the program in order to use as another and/or better reference.

 

I do have to take exception with a statement made above. There really isn't much size difference in a TXT file LISTing of a BASIC program and the actual saved program file. A case in point would be the STRANGER program that is included in Classic99. The saved program file is 12,160 bytes, while the text file listing of the program is 13,744 bytes (using LIST "CLIP" in Classic99 to paste to Notepad), an 11.5% reduction. However, 818 of the 1584 bytes is nothing more than a CRLF (carriage return-line feed) at the end of the 409 lines of code, leaving an overhead (for lack of a better term) of 766 bytes which is only a 5.6% reduction. So no, it really isn't a much smaller file than the TXT file LISTing... but every bit (byte?) helps.

 

Of course, removing REMs, LETs and anything not needed to run the program will help in a final version of the program, which I see you've done some of already. My concern as to whether it would fit and run on a stock TI is now greatly reduced.

I'm sorry, I've just had a bad week, and the code is looking rather difficult, and i spent all last night trying to fix the code.

And I'm also rather surprised it never got a commercial release, but at the time the game wasn't too popular.

And yes, you have been a great help, majestyx. =)

...

edit: slightly shorter code update TRAIL PROTOTYPE MK VII.txt

Also, i may just start from scratch, seeing as how bad the code is, it will probably break too much.

 

Edited August 2, 2017 by TheTIGuy

[sometimes99er]

 

Some of the strings could be put in DATA statements, then read into arrays and just PRINT STRING(I) instead of using ON GOTO with separate prints.

 

That may take up more memory. Especially when running as both the data and the array will be in memory.

The nice thing about C is you just define the arrays, so you don't need to read in the arrays, just use them.

 

I think many programming languages can do that. Allocate and assign an array in one statement - within reason.

Even TI Basic can allocate and assign in one statement. Well, one element at a time and only for the first 11 elements (0-10).

100 a$(0)="Hello"
110 a$(10)="World"
120 print a$(0),a$(10)
 

Edited August 2, 2017 by sometimes99er

[majestyx]

I'm sorry, I've just had a bad week,

 

 

No problem, it happens to us all.

 

Just a quick question - is the initial goal to just get it up and running and then add some more flare to it after it's running if there's memory left to do so? I'm actually going thru this myself and once I get something decent, I can post what I have. I forgot how annoying the 28 character lines are on the TI, which makes formatting text that much more of a pain! And like you, I'd like to get this running in TI BASIC as opposed to Extended BASIC since that's all I had back in the day. Plus I haven't seriously programmed on a TI in over 30 years, not counting some simple programs to get me familiarized with TI BASIC once again.

 

Oregon Trail was never really a game I cared for, but as a project, it's got me excited, plus it has bizarrely gotten more exposure in pop culture in recent years, at least when it comes to memes (YOU HAVE DIED OF DYSENTERY). Had you not pointed out that this was never made for the TI, I'd have never known, so thanks for noticing. I'm still waiting for someone to find a version on a PD compilation somewhere, but until then, I'll keep working on it myself.

[JamesD]

I lived in Utah for a while, and some of my friends have posted Mormon spoofs on Oregon Trail.
"You failed to gain a 2nd wife" comes to mind.

Hmmmm... that should probably say "Oh my heck! You failed to gain a 2nd wife!"

[+FarmerPotato]

I have to tell you, Oregon Trail is one thing I wish for, because when I bring the TI-99.4A to computer shows, invariably some kid sees my Oregon Trail disks and screams "Can I load these! My dad will be so excited!" and I have to tell the kid it's for Apple 2 or PC or Mac. So we load it on one of those... or all of them! one operator is even wearing a T-shirt proclaiming "You have died of dysentery." So, I will be very happy to have an Oregon Trail on the TI-99/4A.

[majestyx]

Well, you guys weren't kidding that the BASIC code for this isn't very good. This is pretty much a perfect example of "spaghetti code." Trying to figure out how certain variables are being used and why operations are being done on them is like unraveling Charlie Brown's kite string when it gets devoured by his nemesis The Kite-Eating Tree.

 

On a more positive note, I'm about halfway through converting this myself but am back to being concerned about it all fitting into an unexpanded TI. I had to get creative with the timing on the typing of the gunshots, but was able to come up with something that I believe is in the same spirit of the original. And my version will be the bare bones approach used in the May 1978 Creative Computing article, at least initially. If there's any room for enhancements, I'll add them after I get it working. Will provide updates as I progress.

[JamesD]

FWIW, Using string arrays for a lot of the text got rid of a lot of crap. It gets a lot easier to read after you do that.
The undocumented math formulas might be explained in the article.

I think there were two issues with the C version I was working on. It requires floating point, and there is no standard way to implement a timer for the shooting code.


*edit*
Lines 1280 - 1680 can be replaced with this if you use arrays for strings.
It saves around 35 lines of code:

1280 IF D3 > 18 GOTO 1690

1290 PRINT MONTH$(D3)

1300 GOTO 1720

Edited August 3, 2017 by JamesD

[majestyx]

The undocumented math formulas might be explained in the article.

 

 

It's more like "supporting information" which has to be compared against the sections of the program listing, not really explicitly explaining the formulas being used in the relevant lines. Better than nothing but could have been a lot better.

[majestyx]

Well, as I had originally feared, I got the dreaded * MEMORY FULL error when attempting to type in another line of code. I still need to input about 80 or so more lines of code so trying to cut down what's already entered is going to be extremely tough without removing something that's likely essential or that would be missed. Looks like I should start over using EB or even RXB, but I have very limited experience with EB and none with RXB. It's something I'm up for, although due to this setback it looks like it will take longer than I had expected.