I'm looking to make Snap!TI (name subject to change, feel free to make suggestions), a drag and drop programming environment for TI 83/4+ family calculators. I want to take Snap!, a javascript block-based programming environment itself inspired by Scratch, and mod it.

I will start with plain old TI-Basic, and then add other libraries.

One planned feature that I think would be very useful would be variables with names. The “compiler” script will rename them A-Z,theta, finance variables, etc; and then use a list (or an appvar?), possibly in order of appearance, and possibly in a way that would be most efficient (eg; variable that gets called least will be the one stored as a list item).

Another possible feature, for implementation via libraries, would be automatic compilation of spritesheets. Snap's sprites would have to be changed to grayscale, and locked to less than the size of the screen.

One major boon to this project would be integration with jsTIfied, as that would allow you to test all or part of your code on the fly, as all or part of the "compiled" program was passed to the emulated calculator and executed.

Thoughts, comments, suggestions, etc; are welcome.

Back Burner:
Flowchart display mode (suggested by Luxen)

I think a block-based programming language would be pretty cool!

technically, it is possible to start with TI-Basic as a base language (Check out my Ignition project!), but you tend to be SOOOOO limited with what you can do that it is very aggravating. even if you did include DCS Libraries, you would be limited, in both speed and power.

however, don't let me get you down! having a block-based language sounds pretty cool. please let us know when you have something to show us of your efforts!

Well, I'm farmiliar with TI-Basic, and figured that that and Hybrid Basic would be a good place to start. Is there some universally better language which would be a better default method of export for a block-based programming environment?

I think at least initially a performance trade-off due to the ease of programming this way would be acceptable until all waters have been tested. The only way to truely know what the best approach would be is to experiment! .

Assembly is always the best language to use on the calculator when you end up doing major projects, and Axe could also work, though I have no experience with it myself.

as to what Tr1p1ea is saying (because I didn't understand him right off the bat), create a concept in TI-Basic/Hybrid, and then start expanding upon it. that sounds like an acceptable approach to tackling any project.

I completely disagree with you there. Assembly is only the best language when your major concerns are speed and program size. TI-BASIC or Hybrid BASIC can easily be the best when your primary concerns are things like code readability or simplicity. I think an abstraction into a simpler language than TI-BASIC should absolutely "compile" down to TI-BASIC so that programmers of the high-level language could inspect the TI-BASIC code to see what their block-based coding created.

I started working on the blocks for Snap!TI. I set up 6 categories: Control, Sensing, HomeScreen, GraphScreen, Operators, and Variables. I'm open to critique on that, as I myself have forseen some potential overlap problems. (eg; is 'pause and display string' a control block or a homescreen block?)

Here's a screenshot of the control blocks I have made so far...



What do you think?

Also, I'm also open to block suggestions. For example, should I just mirror the TI-Basic commands, or include some multi-command blocks? If so, which?

Pause serves a purpose for both I/O and Control, but I feel that it is meant for control, where the I/O function is dispensible. apply the same logic to the rest of the commands; what feels like a certain piece of code's "main" purpose?

As for block suggestions, I cant think of too much at the moment, besides a handful of graphical commands. at the moment.

Also, I was wondering how you catch errors in this language? what happens when something tries to render off-screen, or if it runs into an infinite redundancy?

Thank you, that seems like a good system.


What kind of graphical commands?

Oh, that reminds me, It would be nice if I could universalize the coordinate system. Was that what you were thinking of? What would be a good way to do this without confusing everybody?

Would it make sense to...

1. automatically set the graphscreen coordinates to something if any non-function graphical blocks are used
2. convert pxl ot pt arguments (which is better? - not both!) so they become the same. This would replace any purely numerical arguments, or use the formula in simplest form for any evaluations

Hmm, thanks for bringing that up! I had thought about this a little bit, but not very much. I don't have anything set up at the moment, but that's definitely important!

I suppose I'll have to implement some sort of compile-time error checking. It may be possible to implement on-the-fly checking as well for static things like pxl-On(, but for window-variable-dependent things, it may be impossible to do it that way.

Here's a screenshot of Snap!TI in its current state:

(Disclaimer: Some visible UI elements are leftover from the parent project, and will be removed before official release.)



You'll notice I've thrown together a mini program for testing purposes.

I've set up the basic control blocks, as well as one of the homescreen blocks, but only visually.

The next step is to get this to export to .8xp properly, and then I'll be able to continue adding more blocks, making the rest of the project until 1.0 relatively simple (if time-consuming).

Currently, It seems that the best course of action would be to convert the blocks into a text file in javascript, and pass that to a tokenizer and wrapper for .8xp files, although I'm not quite sure how to do that. Do these things exist in a reuseable format? What does sourcecoder use?

And as always, questions, comments, etc; are welcome about anything relating to this project.

Okay, I feel really stupid right now...

When I was talking about the program language this should be for, I was under the foolish impression this was an engine on the calc, and completely missed that tidbit that this "compiles down to".

I agree with Kerm 100% now.

anyways, back to the present. I love the look of the code blocks so far. while it really isnt neccesary, will you also have a "view in flowchart" mode? that would be kinda nifty, too, another way of veiwing the blocks.

Can you explain what you mean by "flowchart" here, luxen?

Maybe flowchart in a Simulink-style format; where the graphics show dataflow between blocks?

Look up "Program flowchart examples" on google, and you will see what I mean.

That seems like an interesting idea, but It'll be back burner for a long time, and then I might look at the graphical code of the program I'm remixing and try it.

Javascript question:

I need to convert each block to the appropriate TI code. What would be the best way?

I could add a variable in each block object that would be the TI-code text, but some of the TI commands can be used in different ways, and would need a more complicated script.

I could add a function to each block that returns the appropriate TI code based on the block's inputs, but that might be somewhat redundant, and I don't know how the end of C blocks is reported in the list of used blocks yet.

Also, in which object would be the best to process the script, in terms of swapping out the block code for TI code and optimizing? A normal array? If so, how would I get from that array to filish object for export or passing to the emulator?

It sounds like you'll want to come up with some kind of template system that will (1) map between the variables in the Snap::TI program and TI-BASIC, and (2) generate TI-BASIC code for each block, substituting in the variables.

That's true.

Why do you believe that would be redundant? Where else would that information be?

It sounds like you want to map each block to a set of lines of code, then combine the lines of code from each block into a long array of lines (and subsequently to a single string of TI-BASIC code). But I think these questions are a lot more about Javascript than TI-BASIC, to be honest.