Let's say a large, complete TI-83+/TI-84+ calculator programming guide was being written. Let's say that it was aimed at the general public, many of whom might not have previous programming experience. Let's further assume that the audience is high school students and teachers, college students and professors, and perhaps some professionals like statisticians and engineers. My general question is to have you freewheel about what you would like to see in such a guide, or what you would have liked to see in such a guide when it was relevant to you. Are you a student, a teacher, a professional? Do you think TI-BASIC should be the sole focus, or that ASM should be discussed too? To appeal to teachers and students alike, would it be good to show off new concepts with both math programs and games? In fact, what would be good examples, in your opinion? What do existing BASIC (and ASM?) guides do well and badly.

Come on, throw me your opinions. No opinion is too long, too short, too critical, or too baseless.

I would like a basic section and an assembly section. Also describe like what each command would do and an example of when you would use it.

If you write a decent section on using the Finance app functions I'd probably get such a guide to my grandfather who currently has a TI but is mourning the loss of his HP, and what he considers to be its superior financial capabilities.

Would a sort of guide where topics are incrementally introduced make the most sense to you? For example, first introduce the general editor tools, then things like disp and input, then how to use variables and manipulate them, which lets you create simple math programs. Then maybe an intro to playing with graphs, then the graphscreen in general to annotate graphs, then some flow control with loops, then labels, usual warnings about memory leaks, then maybe some getkey/output stuff, etc? That sort of progression?

@Elfprince: TBH, I'd have to learn more about those functions myself, but that sounds like a good idea.

3 parts: Part 1 is about general usage for math-related purposes, as well as information on connecting to your computer. Part 2 is about using TI-Basic effectively, with the last bit of part 2 dedicated to integrating with DCS's Celtic III/xLib features. This leads into part 3, which is dedicated to assembly programming.

I think a part of the guide should be dedicated to using the calculator effectively, like graphing equations, editing lists, and then how to connect your calc to the computer. The second part could be an introduction to TI BASIC, and it could show both math programs such as a Sierpinksi's triangle program and games. The third part could show how to optimize TI BASIC and how to use the various libraries that DCS provides. The fourth section should be an introduction to assembly programming.

Hmm, I like the idea of having optimization and libraries be smaller than a full section. If this theoretical guide were a three-part dealie, I agree that section 1 should start with a section or two motivating learning to program in the first place; I had two specific examples in mind, a math program and a game, that might appeal to a nice slice of the projected audience I mentioned. Second part would be the meat of it, introducing a few concepts at a time, as you said. I think that optimization, libraries, then a bunch of sections on assembly, would be a good third part.

Yes I think that would be good.

Sonlen, regarding the list-editing, graph-using bits, etc, would you still recommend that even if this was a guide for programming specifically, rather than just a general hguide to using your calculator?

Often times, lists that I use in TI-Basic are edited via the list editor. Save data, level data, etc, is generally edited there. Perhaps only the parts of the OS useful to a programmer should be covered.

That's a good point; that could probably be a fairly handy part of the Part I: Getting Started sort of material, eh?

s/Sonlen/Souvik/? Yeah, I would still recommend it because knowing how to use your calculator makes learning TI Basic easier, especially list manipulation.

I think that topics should be introduced incrementally and built on each-other. I'd focus more on programming concepts than on specific commands, but introduce them as they become relevant. I strongly suggest having a collection of simple programs / games / demos be the vehicle, and they can get more and more complex. And there are more than just programming concepts and commands; also explain other aspects of the calculator.

For example, explain the screen coordinates and how to use the pxl commands to turn on/off/toggle pixels; then explain how to use variables to put them at variable locations; then explain how to loop and increment to have a moving pixel; then explain how to use conditionals to detect if it hits a wall (and stop simulating); then add in the idea of "direction" variables, and the conditions negate them; then add in the use of GetKey to have the arrow keys alter the direction/speed. .... Eventually, you can explain how to setup the graph window and use point-commands and the line command to create a bouncy-line screen-saver. Another demo/example would be just moving a character around on the homescreen, and getting it to push objects around (and using a list or matrix to represent what is where); and then possibly changing it into a more complex game where one thing chases you while you have to collect something, and then walls start closing in... a drawing program with savable/loadable pictures, a text-editor program ... anyway, the focus is using input and output and update-loops, representing things with variables and in other data structures, etc.

I'd explain all the basic commands, and then some of the more useful ones too; but then also list most of the other commands with what they do and their inputs, and maybe a small example of how they can be used. Focus on programming usefulness rather than completeness of commands just because they are there.

Have a section separate from other sections just on optimization techniques, with common unoptimized code. You can also explain more efficient techniques, such as combining conditionals into a single expression to save on IF's (speed and size improvement), as follows:

GetKey -> K
...
(K=26 and Y < 16) - (K=24 and Y -> Y
...
(K = 34) - (K = 25
Ans - 8(Ans> + 8not(Ans -> X

I like the idea of 3 main sections: why, the BASICs, and ASM. I also propose that you include things like how to work from the graph (My stepdad is having so many issues working with his 84+/SE he got and Trace/Calc functions). If any help would be needed on this hypothetical guide, I'm always here

Catherine, many thanks, I'll almost definitely hit you up for proofreading/opinions if I ever attempt this sort of thing. I agree that such a theoretical guide would be well-advised to talk about some not-technically-programming things like manipulating graphs before introducing programmatic graph manipulation.

Dan: That's an excellent idea, and probably a great way to go through the graph screen, for example. The only thing I might change there would be to discuss Pt-*() commands before Pxl-*() commands, since someone moderately familiar with a calculator would hopefully have graphed before and at least has a vague idea that different parts of the screen are different coordinates in Pt terms. I'm glad we all agree on the optimizations; I'd probably take some swathes of stuff from the 1337 Guide to TI-BASIC if JPez didn't object.

Great idea; it would be a great to have a detailed guild to programming with some examples.

The game could be an RPG that's text based at first, but gets expanded upon later to include sprites and other graphics. The math program could be a base converter.

I like that idea. Start with a basic Input/Disp system and then move to homescreen tilemapping (Output) and then do basic graph screen drawings (like Line and Pxl-On), then text sprites, and end with some DCS C3/xLib coding of the RPG. It'd also be nice to toss in some DCSB GUI Libs, for certain parts of it.

Yeah, I was thinking that the DCSB libraries could be used for the base converter. That could be used to explain the GUI stack concept and how to use the mouse.

Oooh, I like the idea of a base converter. I was also thinking of an orbit simulator, something of the ilk of http://www.ticalc.org/archives/files/fileinfo/394/39496.html, but for planets. I wrote it at some point, not sure where it went. I like the RPG idea for a game, the only problem is that I would want the code at the end of each section showing the program-in-progress expanded with the new concepts to be relatively short and not take up too much space.