A long while ago, I made an interpreter for a custom Turtle language in Hybrid BASIC for the 84+CSE. I have long wanted to port this to the CE using C. In fact, that was the impetus to turtle library diving the Spirographic Generative Art program.

Well, I started working on it. As with the previous version, parameters are evaluated using the operation system's eval, so all math and variables are supported.

You can find the readme in the github repo with more info on commands:
https://github.com/merthsoft/tugace/blob/main/readme.md

Still a work in progress. No release availble yet.

Here are some screenshots to show off what it's capable of so far.

A spiral:


Code: https://github.com/merthsoft/tugace/blob/main/programs/SPIRAL.txt

A more advanced spiral, using the OS variables:

With different inputs:


Code: https://github.com/merthsoft/tugace/blob/main/programs/SPIRAL2.txt


A tree, showing off the ability to push and pop the turtle state onto a stack at will:


Code: https://github.com/merthsoft/tugace/blob/main/programs/TREE.txt

I'm current working on GOSUB and RET for TREEFREC to work:
https://github.com/merthsoft/tugace/blob/main/programs/TREEFRAC.txt

So cool! The graphical demonstrations are very nice.

I think it was a great idea to use the calculators ability to eval and such, lots of flexibility!

Yeah, makes it a lot easier for me, too, because then I don't need to worry about variables and such. And all commands can take lists, where it will use the first X elements where X is the number of params. So FORWARD L1 is the same as FORWARD L1(1 and GOTO L1 is the same as GOTO {L1(1),L1(2). Additionally, complexes are accepted, but the imaginary value is dropped. So you can do wild imaginary stuff if you want.

GOTO and LABEL actually work the same way. LABEL A doesn't create a label called A. It creates assigns the label number that A evaluates to. So if A is 13.2, LABEL A creates LABEL 13 at that spot. Labels only support real and complex values right now, not lists, so a small limitation. But I suspect I'll combine some of that code to make it easier and then that won't be the case.

I'm curious how people feel about this part of the spec:
https://github.com/merthsoft/tugace/blob/main/readme.md#additional-shorthands

Then programs could be written more tersely. E.g. SPIRAL would look like:

Code:


Which is equivalent to:

Code:


No matter what I'm keeping the colon for label definitions just because it makes them stand out and therefore more readable. The programmer could of course pick which shorthands they prefer to use. It would see a small performance increase.

Some additional design thoughts I had:

- I want to support using colon as a line delimiter. This is easy enough in the code. I just need to then
choose a different shorthand for LABEL. Perhaps pi.
- Right now, the interpreter is a big switch statement on non-contigurous values which are the commands hashed. This performs ok because it can be optimized to a binary search. Shorthands are turned into their equivalent hash.
- This will be changed to be a switch on contiguous values to make use of potentially a jump table. To that end, shorthands will be converted to their opcodes, as well as hashes, and then the switch will drive that.
- Given that change, I have planned a pre-processor pass which will pre-cache labels (where static) and tokenize the commands to their opcode value, thus the translation doeasn't need to happen on the fly and performance will improve.
- Tokenized commands will include pre-computed versions where operands have already been evaluated. This is appropriate if it's a constant value rather than a variable

Stack thoughts:
- There will be a system stack for GOSUB, RET, and any other commands that need a stack
- This is STACK -1 in terms of stack commands, you can access it as a programmer and do nasty things so beware
- The idea is to have a stack per turtle. You choose which stack is active, though, so it's up to you if you follow convention.
- It's one contiguous block of memory, one stack after the other. Right now you can't bleed over to other stacks, but It hink I will change that. So it's more like stack pages than separate stacks.

Header/launcher
- Soon it will check for program name in Ans and run that program. This will allow the Tuga programs to launch TUGA itself from the header.
- If it's launched without a valid program name in Ans, it'll have a little shell to select program, and only list them if they have the header "TUGA:"
- The first comment in the program (the second line after the header) is a description of the program. Up to you what you put.
- After the standard header will be an optional second comment which serves as the flags comment. This is how you will tun on the pre-processor and possibly various debugging flags and such

I finished GOSUB and RET, and added FADEIN and FADEOUT. Also, when done, you can press enter to restart from the top.


Code:


You can see here that I've changed the shorthand for label to comma, and goto to period. I may revert to a colon for label as I debate with myself whether to support colon-delimited lines.

I made some further progress today. I have fixed some bugs in the palette handling and fading in and out, as well as improved performance in the drawing code. No screenshots to share, but here's a screenshot of the planned remaining commands:

(POP [var] was removed, actually, because of ambiguity.)

On top of those remaining commands, the following is planned:
1) Start program from Ans when invoked
2) Small shell to browse TUGA programs
3) Shorthand commands
4) Pre-processor (Tokenize commands, pre-compute labels where able, some other things)
5) Invoking other TUGA programs from within a program
6) Tilemap support

Today I mostly did some under the hood stuff. However, I did add a new command, INIT, which returns the currently selected turtle to the initial conditions. I also implemented some OS BASIC token shorthands. Here's the familiar pretty spiral:

And this is the code for is:


You can see I'm using Lbl and Goto and If from the OS commands. Additionally, "LEFT" here is an OS token that's being interpreted as the "LEFT" command. Another one I added earlier is that "POPVEC" can use the single "PV" token. Good for when types on the computer.

I do still plan on supporting a more complete shorthand as well. The idea being the most used things are all on the main keyboard. So the above program could also be written like this:


I also did some work on the readme. It's got a lot of sections now:

Today I worked on letting PUSH accept a list, and POP accept a variable, as well as the RECT command. It will draw an empty rectangle if the pen is down, otherwise it will draw a filled rectangle. I did this in order to more easily implement this fractal:



Code:


The is recursively drawing a squares.

An animated PNG of it drawing:


As a fun milestone, I recently passed 1,000 significant lines of C code for this project, which is about the same amount of code in Block Dude CE.

I'm trying to think of how to grant access to the turtle's internal values for reading. You can right now do a PUSHVEC and then POP W\POP P\POP C\POP A\POP Y\POP X to have Width, Pen, Color, Angle, Y and X. Seven commands just to get the Turtle's X value into X seems excessive. So I'm thinking either something like:

Code:

First five get values directly. Other two let yo get the turtle into Ans (first one) or the vars that are passed in (second one) in-order and anything left out is just ignored, so GETVEC {D,E,Z,C would have the turtle's location in D,E, angle in Z, and color in C.

Additionally, a SETVEC that takes in a list and can set the turtle vector based on that list. This gives the progammer more direct control over the values in a direct way. SETVEC {X,Y then becomes an easy way to teleport without having to deal with the pen. I will need to decide if that wraps based on the t->wrap parameter.

I started to work on key input. Here's a picture:

Here's the code to do that:


Those familiar with BASIC should recognize those keycodes. Right now, KEYDOWN returns 1 in ans if the key is down. Originally, I had planned on making it work like If, but I think having it in Ans is better. GETKEY will also put the key in ans, or in the var passed in.

Here's the same program using GETKEY:




If you only need one key detection, this is a way to get a little more performance.

I am also thinking that KEYDOWN should be able to take and return a list. So KEYDOWN {21,24,25,26,35 will return {0,1,1,0,0 if up and left are pressed.

The rectangle fractal looks great! Nice work!

Thanks tr1p! Plenty more pretty stuff coming eventually. For today, I realized I don't need to choose between KEYDOWN working on Ans or like If. I added IFKEYDOWN and IFKEYUP. So now the KEYSCAN test code looks like this:

Worked on a lot of under the hood stuff today. Moved the interpreter core to its own file to make it more manageable. Also made it so the command hash gets converted to an opcode, and then I switch on that opcode. Once I pre-process, the hash will only happen once per line.
I also added the rainbow palette, and used it in this fractal:

https://github.com/merthsoft/tugace/blob/main/programs/BUSH.txt
Also, you can have multiple turtles going at once. Here's a Koch snowflake being drawn showing three at once:

https://github.com/merthsoft/tugace/blob/main/programs/SNOW.txt
I also had used the FILL command to fill the snowflake, but this eventually breaks:


I'm not sure why. Something with gfx_FloodFill I suppose.

Also, here's something I think is fun: I've been using the memory visualizers in CEmu to help me debug issues. Here's my debug view:

And then an additional level of debugging is available where it outputs a LOT of as it runs:

Finally got around to running the program that's in ANS:

The string in Ans will be restored to Ans after TUGA exits, so you can run it multiple times without resetting Ans, even though TUGA messes with Ans.

I also added support for the DCS header, so programs can include a nice icon that shows nicely in shells:

This just puts the DCS header first, so it's a four-line header:

Code:

Maybe I can convince shell makers to be more accepting with header format, and it could be:

Code:

or even:

Code:


If there's a way to get consistently the name of the program who called you, I could use that as well as ans. But when I asked calc84maniac he wasn't sure there was such a thing.

Still waiting for this to run DOOM.

Joking aside I love the visual that this produces.

Thanks!

Working on palette shifting and text output today. Text output is bugged. Palette shifting looks nice:

I'm not sure why some parts don't update even when the palette does. Not sure if that happens on hardware. I'd expect the text color to shift too, and all the bush bits.

It's pretty:

And works better than a bunch of flood fills:


That's very simply done:

Code:


Edit: Got text workin'

This is looking great!

Would you mind creating an issue on the toolchain where gfx_FloodFill fails?

Oh yeah! Absolutely! I've created this issue with a minimal reproduction of the error.

Working more on text and eval today. The EVAL command basically already worked, but I wanted to test some capabilities. It can't handle the sto arrow, but it can do quite a bit. This code:

Code:

Gives this response:

If you start your TEXT command with a double quote, it skips evaluation and just prints the string. If you don't, it evals what's passed in, so you can do complex stuff with it. That means the EVAL/TEXT line actually could've even been
TEXT toString(inString("SHAUN","A
But I wanted to text EVAL as a function. It basically does nothing, as all params are evaled anyway.

Right now, the TEXT command doesn't move the turtle with the text cursor. I'm thinking maybe it should, and you can use PUSHVEC/POPVEC to get back to where you were. The text cursor in the gfx library is really quite handy, and I think I'd like to preserve the ability to chain things.

I did some additional under the hood stuff today. If an error occurs, it pauses and lets you know. Eventually I'd like for it to tell you what the error is rather than telling you to check the console--since you can't do that on-calc . I need to find a way to open the BASIC editor at a specific line so I can take the user to the error.

Anyway, unrelated, here's a cool demo. Palette shifting the square spiral form the first post is pretty:


And with a grayscale palette:

Sprite update double post:


Code:

EDIT: If anyone's interested, here's an alpha release with some sample programs:
https://merthsoft.com/tuga/Tuga.zip
There are lots of things it doesn't check which could cause issues, and syntax errors and such are reported through the debug console, so probably run it through an emu for now. That said, I've been playing with it on-calc and haven't run into any major issues yet. Just know, it's possible unstable!

Worked on named labels today. You can now specify labels such as "LABEL SHAUN" and you can "GOTO SHAUN" and it'll work as expected. Numbered labels still work the same, and you can still do an evaluative goto with "+var", e.g. "GOTO +A".


Code:


For evaluative goto, it would work like this:

Code:


(I stripped out the preliminary stuff, see the repo for the full thing.)

Today I worked on getting the shell launch. This way people can browse specifically for TUGA programs. There will be icons eventually, and I've decided to abandon preserving the DCS header as it just makes things too complicated. Anyway:


Any program that starts with "TUGA" will show up. It's recommended that you at the very least include ":Return" after TUGA, so it doesn't function as a TI-BASIC program. Additionally, it still supports self-launching, so you can still do:

Code:


Or any amount of BASIC code on the first line that you want, really.

There are also two additional headers supported for the sake of the shell:
Iconless:

Code:


With icon:

Code:


Icon will be a 16x16 xLIBC palette sprite.

For sub-programs, just leave out "TUGA", and make the first line just "Return" (so it doesn't work as a BASIC program).

EDIT: After discussion with roccolox, I've decided on usign the same icon sprite format as the DCS header, so it'll be BASIC palette colors.

Additionally, I am probably going to change the prefix from `TUGA` to `0TUGA`, as calc84 pointed out `TUGA` can cause overflow, depending on the values in the variables.

Further, I'm pasting this from calc84 for future reference for me: