Lee Stewart, on Mon May 20, 2013 2:32 PM, said:

That can be fixed with the following, assuming you don't have rigid control of the input value:

	  MOV @MYVAR,R0
	  ANDI R0,>000F
	  JEQ SKIP
	  SRA R1,0
SKIP

Adamantyr

RasmusM, on Mon May 20, 2013 1:27 PM, said:

Use SRC (Shift Right Circular) instead to avoid the check. This does have the effect of rotating the bits on the right over to the left, though. If that's not desirable you'll have to use the JEQ to bypass. (At least it's only two bytes to do it...)

Adamantyr

Probably the ONE thing that would have made the TI more viable was to add CPU RAM to the console in the 4A revision. Had they done that (Even just 8k into the lower RAM section), history may have turned out differently. Add a memory mapper so you could do paged amounts of RAM and the sky would have been the limit.

Mind you, it's hard to remember at times that the TI-99/4 architecture was designed in the late 70's. The Commodore 64 benefited from coming years later, when RAM had gone down in price considerably and you could afford to stick 64k in machines.

The TI-99/8's design (paged memory, refined CPU, 128k base) shows they KNEW what they needed to do; the TI-99/4 and 4a were just their throwaways. They just took too long and the market crashed before they could get it out. Pity.

Adamantyr

Text adventures can be implemented in a variety of ways in BASIC and Extended BASIC.

One technique I read in an old Rainbow magazine (The TRS-80 Color Computer's magazine) was to store your noun/verb sets into very long strings. Then you use the POS function to immediately find out if the noun/verb exists in the vocabulary. If you're going with 4-character limits on noun/verb preciseness, you can just divide the returned position by 4 to indicate a verb/noun match.

I would definitely use strings over numeric variables in a text adventure, especially if you are using the 32k memory expansion. A single character takes only 1 byte, while a numeric variable takes 8 bytes. The amount of extra code to process strings over numerics won't unbalance the code size at all, and while it may run a LITTLE slower, text adventures aren't supposed to be that fast anyway...

Adamantyr

TI BASIC slow? Yes. But it's a LOT easier to learn than any other BASIC language out there.

The "BASIC for Beginners" book is actually a very well written manual on learning to program for people who had never used a computer before. Which was basically the entire market at the time. In that, I think TI erred on the positive side. While BASIC was clunky and slow compared to the raw implementations on other machines, it was easy to learn and it boxed away some of the more complicated and confusing parts of how computers worked.

The biggest problem that TI had was you really had no easy upgrade path. Extended BASIC cost $100 back in the early 80's (Around $300 today, the cost of a non-discounted copy of MS Office or Visual Studio) and didn't immediately offer more memory, just more features and slightly faster operation. (In fact, you LOST memory with Extended BASIC on the bare bones console...) To get the 32k expansion required an enormous commitment of money that most users didn't have, since you had to get the Peripheral Expansion Box as well. And assembly language? Well, either the Mini-Memory (eclectic, hard to use, very user un-friendly) or the Editor/Assembler (expensive, full system needed) were required, and you had almost NO materials on programming in the relatively unknown TMS9900 language. Compare this to other 8-bit systems where all your RAM was in the console and TI is definitely looking like the wrong choice for a consumer who wants to expand their programming potential.

If I had to rate a particular set of BASICS for power AND ease of use, I'd say that Tandy BASIC (TRS Model I-III, TRS-80 CoCo) and Apple's BASIC were the best. They still had good syntax and structure, but they also had machine language access with POKE and PEEK allowing you to accomplish some real cool stuff.

Adamantyr