Teletype 3.+ feature requests and discussion



what should they be named, maybe I1 and I2?

we could follow the existing pattern and use a single letter but maybe we should keep single letters for some future global vars and ops.

since some features are already being implemented i’m going to post beta versions in the OP as things get added. posted a beta that includes the fix for vortex keyboards and new DEVICE.FLIP, DEL.X and DEL.Y ops.


E and F are still clear, aren’t they?


we should think of some clear distinction between global and local variables. I right now is the only local var. if we make E and F local, what happens when we add more global vars?


I guess I tend to agree about reserving single letters for additional globals and new ops. The only downside to I1 and I2 of course is that you’re likely using them to try to maximize characters available for the assignment or execution following a conditional.

IF ** I1 I2: [stuff]

is 13 characters including the space trailing the colon as opposed to 11 with a single letter.

But I can’t think of anything better, and that’s kind of what I what I was initially thinking too. I guess you’d still have the option of tapping a global here if you’re really strapped.


I, J, K are often grouped together – it seems safe to use those for locals. It seems unlikely to me that we would need more than A-H for globals, but I admit bias in the way I use Teletype personally :slight_smile:


I, J, K were my intuition as well, but I can see the argument of future proofing for more global and other variables ops that might want to use J and K.


I J K makes total sense to me also.

Long init scripts also make lots of sense. :grinning::heart_eyes::star_struck::stuck_out_tongue_winking_eye:


I J K was exactly what I was going to say!


I J ust don’t K now. J ust K idding.:slight_smile: I can see the justification for using a single letter too. We’d gain two locals that could be used in every single script without fear of trouncing on something important, even if the script is called as an interrupt from another script. So in some sense they would carry as much weight as a global in my eyes.


I spent this whole time thinking there were only as many variables as there were because there was some reason the system didn’t have capacity for more. That’s embarrassing. I guess I’d better join that firmware thread.


here’s the branch for J and K variables. I won’t be able to flash and test it until later, but community help with testing would be appreciated. I tried to be very thorough, however there are a lot of places that needed to be updated for the additional variables, so I may have missed something.


More variables.

(That would be my main feature request)

So I am happy that this is being discussed.

As per some earlier conversations about this in other threads: why not double characters e.g. AA, BB, etc. for variables, or character/number combinations A1, A2, B1, B2, etc. ?
I understand we would be losing a precious character per line of code, but I would happily make that trade for having more variables to work with.


Using # as a special character indicating a variable name could be cool; you’d define your own variable names, which could make code much more readable, and would forever solve the “not enough variables” problem, as you could have any number. To be fair I don’t know enough about parsing and how Teletype does it to know if that would be possible.


Do you have a hex file? Or would testing require installing the tool chain at this point?


oh yes how silly of me.

teletype.hex (567.4 KB)

not sure if I did this right, but here’s the zip too. (1.2 MB)


So, is this for J/K as local variables only?


yes 20 characters of J & K


So DEL.X and DEL.R are not in this build?

Also this just occurred to me; what if these ops used I as an increment counter? For something like:

DEL.R 4 500: TR.TOG I

Just throwing it out there since you’re active in this part of the code.


sorry should’ve clarified. DEL.X/R are part of this build. it’s just the beta plus J & K.

about your second point. do you mean I gets incremented on every subsequent command, so it would toggle 1/2/3/4?


Yeah, that’s the idea. I don’t have a specific use case in mind yet, but since it’s effectively looping through adding to the delay stack, could be useful to have a counter there. Might be pretty handy for referencing pattern values, for example.

I have never looked at the source code so no idea whether that would be simple or not.