majestyx

Sure thing. One of them was this line: 410 GOSUB 2070::DISPLAY AT(19,1):"YOU KILLED THE ";M$(MT,1)::GOSUB 5000 I had to change it to this: 410 GOSUB 2070::DISPLAY AT(19,1):"YOU KILLED THE ";M$(MT,1);"!"::GOSUB 5000 ...because it would only display the first letter of what was in that array. Adding the exclamation point after it forced the entire contents of it. So for example, if M$(1,1) was "RAT " it would only display R on the screen. Another was using '&' when adding to a string variable. I had originally set the program up to construct a variable A$ for a later DISPLAY AT command. An example would be A$="YOU FOUND "&W$(11+INT(RND*5))&W$(16+INT(RND*5)) This completely crashed the compiled program when it encountered a line such as this. I changed lines 520 & 530 to just display the strings one after the other. One other issue I encountered was with ACCEPT AT incorporating a SIZE(-1). No matter what I entered, it wouldn't accept the input. I originally had the "play again?" routine like this: 6080 DISPLAY ERASE ALL AT(12,1):"WANT TO PLAY AGAIN? (Y/N) Y" 6090 ACCEPT AT(12,27)VALIDATE("YN")SIZE(-1):N$ 6100 IF N$="N" THEN 7998 6110 RESTORE 8102::GOTO 160 If I tried to enter an N it would not allow it. I changed it to: 6080 DISPLAY ERASE ALL AT(12,1):"WANT TO PLAY AGAIN? (Y/N)" 6090 ACCEPT AT(12,27)SIZE(1):N$ 6100 IF N$="N" THEN 7998 6105 IF N$<>"Y" THEN 6090 6110 RESTORE 8102::GOTO 160 I believe those were the 3 that caused me the most trouble. Your guide on how to work around the changes to XB were very helpful such as the IF-THEN limitation of only being able to use line numbers and floating point math when using RND. If it wasn't for your compiler, what I came up with would have been scrapped due to how slow it runs in interpreted XB.

So after completing my XB version of Oregon Trail, I decided to go a different direction entirely and, since I saw a thread from about four-and-a-half years ago regarding a Rogue-like game for the TI: http://atariage.com/forums/topic/157876-roguelike/ but never seeing a resulting game, I thought it would be a cool idea to run with. I also saw a similar game on Jim Gerrie's TRS-80 MC-10 website, specifically here: http://jimgerrie.blogspot.ca/2013/01/grail-of-gods-port.html which is itself a port of a DarkBasic 20-line challenge, so I thought this looked promising and doable. The only issue I could think of was how slow it would run on a stock TI. That concern proved well-founded. I programmed it in Extended BASIC as it's so much easier to use than standard TI BASIC. The game absolutely crawls in Normal speed in Tursi's Classic99 and is playable but still sluggish in CPU Overdrive. Thus I compiled it using Harry Wilhelm's XB compiler, which presented its own challenge in additional manipulating of the code to get it compliant with the compiler's known requirements, plus a couple of other things that don't seem to compile properly even though they are supposed to, or don't work the same as in interpreted XB. The common thread for the things that didn't work right involved strings. Regardless, I came up with workarounds and am pretty satisfied with the end result. So what I ended up with is a simple 8-level dungeon crawler using ASCII characters. I gave up on generating random mazes pretty early when it was taking 10 minutes in CPU Overdrive to get one level to 10% completion. So I "borrowed" the dungeon layouts from the "Doom" dungeon in Ultima III with very minor adjustments. The levels are 17x17 (15x15 explorable due to the border), each with static locations for gold, traps, potions, starting location, and exit, plus random placement of monsters, weapons and armor. For those playing it, I will note that there is really no difference in any of the weapons or armor that you find. A rusty dagger will increase your weapon meter exactly the same as a magic claymore, the same as cloth gloves will increase your armor score as much as plate armor. The original was like this, so I didn't deviate from that, at least for this initial version of the game. I just wanted to make certain I could get something like this to work and was happy to find that I was able to. Also, the only plot is to get to level 8 and claim the Grail of the Gods. Goals can be to see how much (or little) gold you can get, how high a rank you can achieve by wiping out all of the monsters, or how low a rank you can achieve yet still reach the Grail. Hope you enjoy playing it as much as I did programming it. The attached ZIP file contains the compiled version of the program (GRAIL-C), the XB source that the compiler used (GRAILEB), and a txt file of the program listing with some explanations at the beginning of it. Latest version available in this post: http://atariage.com/forums/topic/271679-grail-of-the-gods-a-rogue-like-game-in-compiled-xb/?p=3922022 GrailOfTheGods-TI-XB.zip

For the most detail, the upper left, to me, appears to have it. However, I prefer the lower left. It loses some of the detail but more often than not, looks to flow the most smoothly since there aren't as many alternating black pixels as in the top 2. The bottom right is the least pleasing to me.

I found a few more things I needed to fix in the XB version so I've attached the latest bug fix here. Just the Extended BASIC version this time. OREGONTEB.zip

Silly me! Looks like I didn't get the memo!

Thanks for noticing that. I'm guessing you mean the XB version? While it doesn't stop for me (it gives a warning but re-prompts to input the amount again), I really should have put in validity checking for blank. I've fixed that in both the initial purchase phase (which uses INPUTs) and in the fort routine (which uses ACCEPT ATs). I'll wait a little bit to see if anyone finds any other issues before posting an updated version. Unfortunately there's no room in the TI BASIC version to add this, but the program doesn't stop but gives the WARNING: INPUT ERROR IN line# so that will have to suffice.

Just noticed that I forgot to remove a debugging DISPLAY AT I used for timing the shooting routine in the version I uploaded. Fixed in attached download. EDIT: Didn't realize I could still edit my previous post. I could swear in the past there was a time limit of around an hour to do so. Anyway, either post has the corrected XB version. TIOregonTrail.zip

Very cool! I knew it was just a matter of time until someone would figure this out. BRAVO~!

Okay, so, after the fiasco of what happened to my original TI BASIC version of Oregon Trail I had posted here: http://atariage.com/forums/topic/268340-tho-oregon-trail-for-ti-994/?p=3822181 with... well, I don't know what to say about the multiple versions that did nothing that I could notice to improve or enhance it, as well as versions that won't work on a stock TI... but anyway... and after seeing what could be done by Jim Gerrie on the TRS-80 MC-10: http://atariage.com/forums/topic/268340-tho-oregon-trail-for-ti-994/?p=3822550 , I figured I'd redo this in Extended BASIC. Of course my OCD made me decide to tighten up the TI BASIC version as well by fixing a few things I messed up logically as well as implementing some more efficient code thanks to suggestions by other members of the TI community here at AA. While I personally feel it's nothing to really get excited about (it wasn't a game I ever really played back in the 1980s when I had an Apple //c - I was more interested in Ultima, Wizardry, Bard's Tale and text/graphic adventures), I believe it's a more polished product, at least in the XB version. This was my first program ever in XB and since I wrote a TI BASIC version of it, I figured I'd ease my way into XB by working with something for which I had some familiarity. So for this version, I made pretty decent use of the DISPLAY/ACCEPT AT commands, implemented a simple ox & wagon graphic similar to what Jim Gerrie did, changed screen color, put in two simple tunes - a "charge" fanfare and a "creepy" four note stinger - as well as putting the instructions back in, made slightly more descriptive events, and added a bit more character that was, and still is, missing from the TI BASIC version. I did a decent amount of testing, but I surely could have missed something, particularly when it comes to losing or messing up on the trail, as I mainly played to win. While I was disappointed with what another member here did with my initial version, I still have to thank him for getting me to program it in the first place, and then giving me motivation, albeit not purposely, to create a better version of it. Also, a big thanks to carlsson, chue, and Casey (the 3 Cs - how 'bout that?) for suggestions on improving and optimizing the code, to JamesD for suggesting a look at Jim Gerrie's MC-10 version (as well as other ports he's done for that computer) and Tursi for Classic99. As much as I'd have liked to have used Rich's RXB, I figure I should do baby steps until I'm used to the good ol' standard XB. Plus it's cool to see what I could have done back in the day, if only I had the tools then. All credit for OREGON TRAIL goes to Dan Rawitsch and Bill Heinemann who developed the very first version of this back in 1971 and MECC for commercializing it. The version I used for reference is the one published in the May/June 1978 issue of Creative Computing, pages 132-139, for the CDC Cyber 70/73-26 in BASIC 3.1: https://archive.org/details/creativecomputing-1978-05 with additional material sourced from David Ahl's Westward Ho 1847 http://www.atariarchives.org/bca/Chapter02_WestwardHo.php Note that I do not have any TI hardware so this was developed and tested on Classic99 only. The attached ZIP contains both the Extended BASIC version called OREGONTEB and the newly revised TI BASC version called OREGONTR which can be placed in whatever DSKx folder you'd like in Classic99. Latest XB version available in this post: http://atariage.com/forums/topic/271162-oregon-trail-for-extended-basic-and-updated-version-for-ti-basic/?p=3872773 TIOregonTrail.zip

It seems like there is a forgotten emulator when it comes to the TI-99 and it's Ed Swartz's v9t9 which i believe was the first PC-based TI emulator that wasn't a commercial product (PC99) back during the DOS days. Since it now runs in Java, it means that it SHOULD operate on any platform with enough power. Has anyone attempted using it on a Pi? Also, no idea how it would interface with the multi-emulator solutions that are being developed for the Pi but figured it was worth mentioning in case someone has a RPi3 with Java installed on it and can see how fast or slow it runs. Been meaning to get a RPi3 myself but life keeps getting in the way!

That page overstates that color capabilities by a factor of 16. And the picture with all the sidecars shows a TI-99/4. Plus most the comments show as being posted 11 years ago, even though the post itself is listed as having been posted in 2011. Certainly strange.

Yeah, it was a pretty ridiculous scenario, with the people from the show being pretty much bit players (the game's packaging makes it seem like you will have all kinds of ways to interact with them) and most of the actual adventuring being done in the jungle. It ends up being closer to Telarium's Amazon than what one would expect from a game based on the Dallas TV show. Here's a walkthrough for anyone interested:

I remember playing Dallas Quest on the Apple ][ back when in the mid to late 80s. It was a fun little game for the time and would be apropos in that a) Dallas was an iconic show from the 80s and b) it's based in Texas so what better platform than the TI? But based on this quote above: That is also why I "Betrayed" the TI. TI-BASIC sucks! ...I'm guessing he's no longer pursuing this endeavor. Plus it would indeed be a major undertaking, even for someone who is familiar with TI programming languages, without any source code for reference.

Yes, I thought that too. The first part of the article seemed to be the guy explaining the Rube Goldberg contraption he has for entering programs on his TI. I came away thinking that it would have been much easier to have simply typed it in!

Cool story. I really liked that magazine, which changed its name to Computer Fun due to the video game crash, then unceremoniously disappeared. I recall buying that same issue back in the day, although I didn't have Extended BASIC for my TI. Now that I'm learning it, I find it to be a shame that they didn't include this language with the console itself. It's really amazing how much more is possible with XB.

In Chapter 2 of Teach Yourself Extended BASIC (PHD 5019) where it explains what CALL LOAD does, it gives this warning: CARELESS USE OF "CALL LOAD" MAY CAUSE SYSTEM FAILURE. USE "CALL LOAD" ONLY AS INSTRUCTED IN THE DOCUMEN- TATION FOR ASSEMBLY LANGUAGE SUBPROGRAMS. Found that to be quite interesting. Not sure if they meant it would lock up/crash the computer or actually frying the hardware.

While I admire your desire to write programs using TI BASIC only, you really should familiarize yourself with, at the very least, Extended BASIC, as it offers so much more to work with. Otherwise, you'll be very limited to what you're going to be able to do - no sprites, no access to additional RAM, one command per line, terrible IF-THEN implementation... you'll spend more time trying to figure out how to program something that's so much more simple to do on other computers of the era. Once you've got that some experience with XB and if you are looking for a challenge, then go back to TI BASIC and see what your skills can come up with despite its limitations. TI BASIC and the Beginner's BASIC tutorial were an absolutely awesome introduction to programming (it's what got me started in late 1982) but if you want any hope of making something worth playing at any semblance of speed, you'll have to move on to Extended BASIC and/or the other languages available on this platform.

Question regarding additional RAM - can Extended BASIC take advantage of the SAMS Support in the configuration? I guess what I need to know is can Extended BASIC in C99 actually access more than the built in 16 KB? I couldn't find any setting for 32K RAM expansion so I am guessing that if SAMS is enabled, the RAM can be used. I'm not familiar with SAMS either which is why I am asking. And if so, how much of it can it use?

What does "Consumer"/"Finished" version mean? Other than a few extra print statements (lines 1-6 and lines 181 and 2111), it looks pretty much identical to the version I posted here: http://atariage.com/forums/topic/268340-tho-oregon-trail-for-ti-994/?p=3822181 Also, what is meant by mem mod? As far as I know, TI BASIC is unable to access any add-on RAM. That was the main reason I cut out what I did from the original version of the game. Of course, if it's being run in TI Extended BASIC with add-on RAM, then I'd guess it would work.

I was referring to UAE which is of course a dedicated Amiga emulator as opposed to MAME/MESS which is a one-emulator-fits-all solution. Also, MAME's mission is different from dedicated emulators/simulators in that it's attempting to emulate exactly the original hardware. I don't know what the benchmark is of the Amiga emulation within MAME. Still, as a user it seems weird that the Amiga with all its custom chips and the 4000, having been released 11 years after the TI-99/4A, can be emulated at such a high speed while the TI is stuck at 10%. And based on your response which mostly went over my head, I'm guessing that is the reason why this is.

I still find it kind of bizarre that an RPi 3 can emulate an Amiga 4000 running around 7X faster than that machine's physical hardware, yet the TI runs at less than 10% of the physical hardware. Since I don't program emulators, I'm sure this is a case of apples and oranges.

The picture was a loose CV (off-center, just the console), but the few word description had it as Brand New.

Here is a joystick testing program you can use to see if it's an issue with the joysticks (or possibly the port itself): http://atariage.com/forums/topic/145666-any-ti-99-4a-basic-programs-you-can-share/?p=1773311 The games would have to be programmed to use the keyboard in order for them to work with the keyboard. Try a game like Hunt the Wumpus or Parsec which definitely map directions to ESDX to see if the keyboard is working with games that should do so. Q is the usual default FIRE button.

I lean more towards the deprotection route. There were some protections back in the day which, even if you had an original, wouldn't work properly. The SPS takes their good old time in "approving" submissions, not to mention that, as far as I know, you still can't get those images once they have been approved unless you are the one who submitted them. It seems like a whole lot of effort and expense for very little reward. I do know that the UAE Amiga emulator is able to use IPFs if you can find them, but I'm not as familiar with the Apple ][ side of things. I've also come to find that the most heavily protected games usually weren't the best ones, making me wonder why back in the day they didn't spend more effort on making a good game instead of such annoying copy protection. One I can think of was Shadowkeep. I had an original of this back in the 80s and could never make a backup of it with any copy program that was available. The program ran ridiculously slow with non-stop disk access which was my main reason for wanting to make backups. I didn't bother to play it for very long before moving on to something else. I do appreciate the historical implications behind using the Kyroflux, but for practical purposes, I'm in the deprotection camp until the IPF format is both implemented in emulators and the images are made more widely available for use in an emulator.

Cool, that worked. Forgot about the PC Keyboard option.