#1

Hello all,

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 :wink:

7 Likes
A user's guide to the wonderful world of teletype ⌨
Orca
#2

all of the monome modules use the libavr32 library which abstracts all of the hardware calls.

it should be very straightforward to do a complete alt firmware. for example, @scanner_darkly has done various alt-firmwares for the white whale and ansible modules.

a good starting point might be a simple firmware to just get the i/o and screen interacting, and perhaps the HID keyboard if that’s you main input use case.

feel free to ask specific questions when you get started! i would suggest populating the UART header on the back which is useful for debugging via serial cable.

6 Likes
#3

I made an oscilloscope / visual generator with it once.

13 Likes
#4

sounds like a great idea! can’t wait to see what you make :slight_smile:

porting Orca to TT would be amazing.
i could also see a nerdseq style tracker working well.

3 Likes
#5

having not used a nerdseq, how heavily would this differ from the teletypes built in tracker mode?

#6

yeah, the TT patterns work quite well for tracker duties!
off the top of my head, some additions could include:

• longer patterns
• higher resolution
• song mode - sequence patterns
• added lanes for designating special behaviors - glide, legato
• read qwerty keyboard as a musical keyboard for easy note entry
• realtime input - 4 track recorder with overdub (including non quantized recording)

some of these things can be done with teletype as-is (it’s so flexible!!)… but sometimes a focused interface can open up different workflows.

4 Likes
#7

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…

#8

There is a C implementation of Orca which may come in useful. Looks like they’ve split the ‘core’ library out into something with very minimal C requirements.

And hello @sliderule, nice to see you around here again.

2 Likes
Multipass - a framework for developing firmwares for monome eurorack modules
#9

I’m interested, please let me know if you have any question!
I would love to see Orca on the Teletype.

8 Likes
#10

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.

take a look, the repo is here: https://github.com/scanner-darkly/multipass i need to add documentation, but hopefully should be pretty straight forward to start. polyearthsea firmware is using this already, so you could use it as an example of how to set it up, and i’ll be happy to help with any questions.

@sliderule - nice to see you again!

7 Likes
#11

Not usually a fan of alt firmwares, but Orca would be a great project and I’d love to see it. It will also be interesting to see how Orca on Norns + Crow plays out.

3 Likes
#12

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.

6 Likes
#13

VCRO? :upside_down_face: (and 20 chars)

1 Like
#14

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.

@sam, @scanner_darkly :wave:

6 Likes
#15

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 :grinning:

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…

#16

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.

3 Likes
#17

Thanks, that’s good to know!

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… :sweat_smile:

2 Likes
#18

I made a table tennis simulator within teletype. Can’t find the video of it though.

It used the turtle operator (@) to bounce the cursor around the tracker screen. It could have been extended to use the 4 triggers for P1(up, down) P2(up, down) to make an actual game out of it.

I once considered adding graphics operators to the teletype codebase to draw on a new screen using the graphics acceleration of the display.

What I’m saying is that you don’t have to modify the teletype codebase that far to make games.

Also, here are my demo videos of various stages of the oscilloscope development:

14 Likes
#19

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).

2 Likes
#20

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!

2 Likes