Uxn - Virtual Computer

This looks like a lot of fun. I assume a touchscreen on a Pi would replace the mouse?

Ohh wow I might have to try this, looking up that screen now and it looks really interesting.

1 Like

A gargantuan shoutout to @neauoire for making this a reality, my 2ds hasn’t had this much use in years, if ever.
Uxn-Nds emulation on a 2ds is successful!!! A try at building on Pi pico is next, perhaps?


woah i totally forgot about the 2ds!

also @csboling is sneakily working on some that could be quite special


Uxn on the Teletype! That would be sweet, very fuckin sweet.

In other Uxn news

Uxncle is a small C-like programming language for the Uxn virtual machine.

Uxn on the Esp32

Uxn instances can now communicate with each other, like:

uxnemu orca.rom | uxnemu piano.rom

That would make me buy a second teletype!

1 Like

Thabks for this info, I couldn’t figure out what to do the other day :smiley: will try again soon

1 Like

Uxn on the Teletype hardware, and a Teletype app for Uxn :grin:



Here’s a build. Just enough to play with if anyone is interested in developing for this platform.
teluxn.hex (166.4 KB - 2021/06/27 - bebeac1)

What’s working:

  • keyboard
  • screen
  • gate inputs and outputs (via a device mapped at 0xc0 - example program). A GPIO device seems like perhaps a need other pieces of hardware would have as well, it might be good to standardize on an interface for this so roms can support it.
  • you can load .rom files from an attached USB disk. Insert a disk, pick a rom using the PARAM knob, and load it with the button next to the USB port. I was pleased to discover that this works just fine if you put the roms on an SD card and use a USB card reader. Currently limited to the first 8 .rom files, expected to be at the root of the drive.

To be done:

  • the screen is tiny (specifically 128 x 64 pixels with 4 bit monochrome depth), and roms may need to be modified to support a low-resolution mode in order to work properly. For example, Orca calculates the workspace dimensions based on the screen size, but as you can see this currently results in a single row of 9 cells, a unique programming challenge.
  • there should be a way to save a loaded rom to flash so you can just load directly into that rom at power-on.
  • midi device for the midi features Teletype supports.
  • file device which lets roms access the USB drive. Making this work is complicated by the fact that you can’t have a USB disk and keyboard connected at the same time. Probably this could work by giving you a prompt and waiting for you to insert the USB drive, then save/load.
  • ii control device? This would be specific to this hardware, so maybe better to do something like map certain midi controls to i2c messages.
  • analog I/O for the CV outputs as well as IN and PARAM. There is probably enough address space for these to also live in the “gpio” device.
  • grid / arc? can these be made alternative “controller” device layouts or so?

This is incredible!

I have updated orca.rom to use the full available size of the screen instead of having this extra padding on small screens.


We have just modified the Uxn Console device to handle the full power of I/O(stdio/stdout) and Orca currently has 3 operators, it could possibly have input operators if that makes sense for the Teletype.


  • = synth(channel octave note): Plays a note through Uxn’s APU.
  • : midi(channel octave note): Sends 6 bytes one after the other 3 for the midi note on, 3 for the midi note off.
  • ; byte(octave note): Send a single byte(0-255).

Which other operator do you think could be useful for this? Any special request?


Aha, this perhaps could map onto the gate I/O, depending on how roms are expecting to use it. Teletype has eight gate inputs, when any of these receives an edge, we want to set the appropriate bits of the “gate input” register and call a vector. There are four gate outputs, I currently have these mapped to 4 bits of a register and update the I/O when that register is written to. I think this would all fit into the console address space, but this data is not text in general, so it might not be compatible with how a given rom wants to use the console.

There are also four analog outputs, and two analog inputs. On Teletype each of these has a 14 bit resolution, where 0 is 0V and 16383 is 10V. I was thinking these would be four 16-bit registers to give the rom full control over output voltages. When you want to use Teletype as a sequencer, however, you generally want to output the specific DAC values that correspond to note numbers – for Orca specifically I would guess this is the main use case?

I confess I am a very inexperienced Orca user, I would love to hear if some folks using both Orca and a modular system have given some thought to what their ideal ops would be.


I don’t think there’s enough space on that little screen to juggle 4 shorts at once. We’d need a way to differentiate which port we’re using, and which note value we want to send to which jack. In orca, normally, note values are octave note, that forms a byte midi pitch value. We could add an extra port to target a specific device?

device octave value there would be a max of 36 “devices” that we can send to, we’d have to devise a mapping that makes sense, like 0-4 gate out, 5-8 note out, etc… Would that work for you? I could modify the midi operator to stop sending the 6 bytes and convert it to that scheme.

1 Like

nice !! i was just wondering about file system access for the emulator but this is even better

1 Like

The emulator has a tiny File device that can read and write, I’ve implemented it in a few projects, including orca(here). It just save/load a length of bytes in and out of memory. :slight_smile: You can find tutorial examples here.

To Load

#1000 .File/length DEO2 ( how many bytes )
;filename .File/name DEO2 ( address of the path to the file )
#1234 .File/load DEO2 ( where should it be written in memory )

To Save

#1000 .File/length DEO2 ( how many bytes )
;filename .File/name DEO2 ( address of the path to for file )
#5678 .File/save DEO2 ( where should it be written in memory )

I think this makes a lot of sense and would leave room to grow – the host could map different “devices” to panel outputs, or i2c note messages, or a parallel port, or websocket, or Gameboy link cable… At the memory map level I am tempted to maybe think of this as an expanded notion of the “console” device to a “bus” device, which adds an additional device identifier register (either 1 or 2 bytes) that allows the emulator to interpret “writing to the console” in one or more ways depending on the device.

In keeping with Unix reserved file descriptors, device 1 could mean “stdout” and 2 could mean “stderr”. The host could set this device ID register before calling the .Console/vector and restore it afterwards, and the program could write it to select different buses to write to. Each device implemented by the host could then have some freedom to select what it means to write a byte / short / buffer. To use binary data this way you would need to know a length when working with buffers, this could be done with an additional length register or by using length-prefixed strings.


Incidentally, the GBA can potentially accept keyboard input through the linkport:


I also believe this can be a much more straightforward process given that with a PS/2 adapter, LSDJ accepts keyboard input, albeit less conventionally:

Though I doubt this unconventional usage reflects any specific constraint of the system or port. (certainly utilizes a hell of a lot of keys)


More smol victories…
I finally stepped outside of my Python comfort zone and jumped into the world of C…. it took a few days (and tutorials, and a ton of errors) but I’m pretty proud of where it has brought me.
New doors are opening.
Infinite thanks to @neauoire for all the help along the way.
If anyone out there needs some assistance in getting things up and running, I’m slightly less under-qualified in this realm than I was a few days ago, and always happy to help… just holler.


(Just three days? Yo, pass a brother those tutorials)

(Unless I should just go right to assembly in the opinions of the… assembled)

(Biased tho it may be)

1 Like

@Ghost_Cat That’s awesome! I’m glad you’ve got it all figured out. You’re ready to make your first little assembly program in uxn now. :fist:



Got orca running on the DS version but I still have absolutely no idea how to even begin using that so I will have to try and compile some of the other roms and try those :slight_smile:

With the DS version, is there any way to load different roms? I tryed all imaginable buttons/combos but couldn’t find any menu or anything. Does it only load the one titled ‘boot.rom’ or am I missing something?