Sub commands on the teletype

Continuing the discussion from Replacing the parser code on the teletype (and also from ʜ⊥ᴚoℲ (and other Teletype ideas))

I’ve started a new topic for this, even though it’s the continuation of the parser work in the linked thread…

For users:

I’ve managed to get multiple commands running on the teletype, this is done by separating additional commands with a semi-colon, e.g.

X 1 ; Y 2 ; Z 3
L 0 3 : PN I 0 1 ; PN I 1 2

In the loop example, the code after the : would be run 4 times.

Do the examples make sense? I’ve got to dash soon, but I can write up a more detailed explanation / tutorial if needed. My feeling is that this (along with the mathematical operators) would be considered an ‘advanced’ topic.

For devs:

As with all things in computer science:

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

While the first hasn’t been a bother I have struggled a bit with the last two. To that end I’ve tweaked the nomenclature a little and introduced the concept of a sub command:

(the old concept of a sub command has been renamed to post command)

As it stands the code hasn’t been pushed anywhere yet (or even run on hardware). The changes are actually quite small, but I need to walk away from it for a bit, and then come back and double check it and add comments, tests, etc.

Once all the I2C gremlins have been fixed I’d like to get a PR opened for this (and implicitly the parser work). It’s probably going to be the last big change I make for a while. Things are looking a bit busy for the next few months.


this all makes wonderful sense and i’m in favor of the update. thank you for your excellent contributions!


This is a great addition to the syntax! It expands the capabilities of the PREs without the use of SCRIPT, not to mention extending scripts beyond 6 expressions. (Now, if only there were nested PREs… :sweat_smile:)

I have a TT sitting here, but my case hasn’t arrived yet. If it doesn’t show up soon, I’m building a power supply for it so I can test and/or develop. I have cycles to burn over the next couple of months, so any time spent not synthesizing will likely be spent staring at code.

(Also, I got a chuckle out of your dev joke. :smile: )



need time to contemplate but this looks great

1 Like

This looks great. TT just gets better & better - thank you!


I LOVE this idea!

Totally useful.
Increasing code’s available space to functionality ratio.
Super elegant implementation that honors the simplicity of the TT code syntax.

is there an actual name for the TT code?
it’s not quite a “language” but…


[quote=“laborcamp, post:6, topic:5987”]
is there an actual name for the TT code?
[/quote]good question

I’ve thought about it but never actually asked…

It’s basically Forth, but backwards (hence my terrible ‘ʜ⊥ᴚoℲ’ pun).

i.e. on the teletype you’d write ADD 1 1, but in Forth you’d write 1 1 ADD.

It has similarities to Lisp too (as any backwards Forth would). There is a Hackaday article on Forth here too.


Good to know @sam.

but, so:

is htrof as the name for the TT script your idea?

is @tehn calling it anything?

1 Like

Sorry for the stupid question, but :
is there any goal other than gaining more code space (which is already awesome) ?

1 Like

Note that the PRE is valid on the whole thing (POST)… So as it is now, you have to sacrify a entire script with SCRIPT to do that.

After thinking about it… There is still the end of line constraint. Curly brackets around the statements would be awesome, as it would allow a new line. Then again, probably overkill for this mini language…

[quote=“sakul, post:11, topic:5987”]
There is still the end of line constraint
[/quote]I think it’s buried in the other thread but do you remember how many characters (or spaces) fit per lline?

didn’t think of this ever somehow.



it’s a thing.

should have a name, no?

(and monome is notoriously awesome with names of things)

Subcommands also open up the ability to ‘pass arguments’ to a ‘subroutine’ SCRIPT, e.g.:

L 1 4 : A MUL I 5 ; SCRIPT 2

Really this isn’t ‘new’ functionality, as you could just


inside script 2 to derive I because I always increments up by 1. It comes at the cost of an additional variable though, so the new functionality is cheaper. Also you save code space in script 2 and it’s arguably cleaner.

Actually tried the code on my Teletype today! Did my usual Turing Machine / Noisering / SoU script, but tweaked to take advantage of all the new features.

This is the I script, the first 3 lines set up a pentatonic scale in pattern 3. The 4th line empties patterns 0 and 1. And the final 2 lines set the first 8 entries of patterns 0 and 1 to random 0s and 1s.

And then this is the actually Turing Machine-esque script. (Though there is a minor typo, PN 4, should really be PN 3, but it still works!)

(one caveat, I increased the number of ops per line from 12 to 16, just for my local build)

Here is the commit for anyone that wants to see:

In particular see process_command:

(I’ve added some comments so hopefully it’s easy to follow along.)

It still needs more testing, in particular I need to check things like delays and stacks work properly. I’m stilling aiming to put a PR in once the I2C stuff is sorted out.



I’ve been playing around with the parser in the simulator. I have been running with

mod_separator = ':';

without any problems. All the tests run okay, including all permutations of existing tests using no spaces around the colon.

The semicolon might be able to be afforded the same treatment. Code density is a big concern in these little scripts!

Yeah, there is some discussion of it on the parser thread:

The tl;dr is that everyone wants to get rid of the spaces around : (and therefore ; too) but the font needs a bit of fiddling with, plus print_command will need updating too.

If you interested it would be a good little project to do, update the font, get print_command working (add some tests for it…). I can help you out if you need, though I think I’d rather get my code merged to master first.

Yeah go ahead and get your stuff merged to master. I don’t have a functioning TT yet (still waiting for case to arrive) so I don’t have a real test environment, I’m just exploring the code base.

I hadn’t considered print_command. I’m not sure there’s an easy solution there, it’s ambiguous. Either the lack of spaces will be enforced (which will reduce legibility for short lines) or lost (breaking/overflowing long lines), or we’ll have to carry around state information for which spaces are present somehow.

One solution not mentioned in the thread is 4 different tokens for the separator with identical behaviour / parsing. [':', ' :', ': ', ' : ']

It would probably be less ROM intensive than storing the text representation of the script, but on the other hand: eeeeeeeeeew. :tired_face:

I’ve had another play on hardware today. Everything still seems fine.

Early next week I’m going to merge master into my branch and open up a PR.

1 Like