I was wondering if there is any alternative firmware for the Teletype out there or if anyone here has ever attemted/succeded in creating one. To be a bit more clear: I’m not talking about additional OPs and MODs, but about a completely different (or massively altered) system running on the TT hardware.
A module like TT with it’s CV I/O, a nice display and keyboard support would be suited perfectly for tons of interesting, useful and crazy ideas. Right off the bat I could think of (and would possibly be interested in trying to implement) a port of @neauoire’s awesome Orca sequencer and other little esoteric sequencing languages.
I’ve already been looking through the firmware’s source code and the very helpful information in this thread. However, I’m still not sure about how tightly the more hardware related part of the code is coupled to the original purpose of the module and how hard it would be to implement functionalities that are (very) different from the original firmware.
So, I’d be happy to hear about your ideas or experiences!
P.S.: Of course I don’t see any reason for “removing” the original firmware from the module in favor of a different one. So that alternative firmware should best be running on a second TT module right next to the original
Thanks! This looks like a perfect basis for some first experiments!
I think so too, and the already existing C port could be a good starting point. However, being quite new to the embedded development game, I’ll probably begin with something a bit more simple.
Im currently working out the concept for a little pattern-based sequencing language, that could be suited as a first project. But I guess I’ll build a simple CLI prototype (probably in Go) first to figure out the ergonomics before starting the real thing…
while libavr32 does abstract the hardware layer, some of the function calls are still pretty hardware specific (like taking a hardware pin number as a parameter, for instance), and you still have to implement quite a bit of low level plumbing. i’ve been working on creating a higher level abstraction that takes care of that, and the main goal is pretty much to make developing new alt firmwares easier.
some of the features:
providing the ability to configure voices and use functions to create notes which will then be automatically translated into a proper hardware calls - like updating CV outputs, or sending appropriate i2c commands to just friends / telex / er-301
easier interfacing with grid/arc
easier way to set up timed events
taking care of parsing HID events and translating them into more meaningful events like keyboard press etc (other HID devices will also be supported - shnth already is, and hoping to add PS3 controller support at some point)
this should give you an idea of what you can do with it:
another benefit of using it - it also abstracts away the hardware differences between different modules, so you could write a firmware once and be able to build and run it on any of the monome modules. it already supports while whale, earthsea, meadowphysics and ansible. for teletype i have it working as well (just need to commit it to the repo, will try to do it this weekend), i just need to add screen functions.
i was also planning to add support for some common things, like preset management and USB stick support - still hoping to do this, just not enough time.
one request, if i may - for the potential teletype ORCΛ port could it have its own name, or some variation? there is already orca the alt firmware for white whale (and potentially other monome modules down the road, including teletype), it’s easy to distinguish between that and ORCΛ the livecoding tool since they run on different platforms, but it’ll be really confusing to have 2 different alt firmwares with the same name.
There’s an implementation of a shadow buffered display driver in telescope. It’s not well-documented, but it comports to the specification set out in the display’s documentation, which is required reading if you want to play with the graphics acceleration engine.
Many of the implemented API calls related to drawing modes have been written and tested to some extent, but do not feature in the implementation of telescope. I had fun playing around with the scrolling modes and the box drawing and it all worked.
The diff-based update engine in use in telescope is well-appropriate to a scope, with few pixels changing each update. Depending on your needs, you may wish to use other re-map modes for better performance in complex scenes.
There are some builds of it starting about here:
As you can see in that thread, the diff engine in the final build was 4x faster than the full-column write in the initial builds, but only for the scope. It will be slower for a full-screen redraw, which is capped at 141 Hz, IIRC.
Thanks for all the valuable input, hints and code examples! Looks like there is still a lot to learn and discover before I can actually get started with something as complex as an Orca port. But I’m already digging into the code and documentation and I’ll keep you posted as soon as there’s some progress!
Sure, I’d be absolutely fine with that. There should be enough other marine mammals out there that have not lended their name to a Monome firmware yet
Just one more (maybe a a bit naive) question: Is there any possibility to do serious damage to the TT module by uploading an altered firmware? I’ve heard several stories about people accidentaly “bricking” devices, so it would be good to know what the worst case scenario could be. So far my experience with embedded development is limited to some experiments with relatively cheap MCUs and development boards, and breaking a valuable module would be considerable worse than a fried Arduino…
I really don’t think so. Nothing you can’t fix by just flashing back to the release firmware. I’ve accidentally flashed Teletype firmware onto Ansible and vice-versa a number of times, and have run bad code that behaved weird or soft-locked a lot of times, always fine after a reset/reflash. Generally I think scary things you can do are pretty well protected on modern microcontrollers precisely because stuff like accidentally overrunning a buffer is super common. Also, most hardware accesses you would want to do are abstracted away inside libavr32, so you generally don’t need to directly do any register twiddling anyway.
Latest addition to my alternative firmware wishlist: A Super Mario port where the TT is outputting gates/CV for the background music and triggers for sound effects. Not going to build that one anytime soon though…
Now that I’m thinking about it, I guess there’s actually quite a bit a of low- and mid-level commonalities between TT and for example Orca, like text parsing and rendering, grid-like structures and CV processing. The turtle operator also definitely has some similarities with the way things move in Orca.
This text based sequencer I’m currently prototyping is actually even closer to the way TT works and would probably just require some changes to the data structures that hold the current state and the way the scripts get parsed/processed. It’s in some whays a bit similar to spacetime and Dunes, which I both just discovered today (and which once again made me think about getting a Norns sometime).
Just wanted to post and say I would support the development of a full on tracker interface. That was my main draw to the teletype initially. It would be much easier to resist the NerdSeq draw that way!