woah i totally forgot about the 2ds!
also @csboling is sneakily working on some that could be quite special
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.
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!
Thabks for this info, I couldn’t figure out what to do the other day
will try again soon
Uxn on the Teletype hardware, and a Teletype app for Uxn 
Progress!
What’s working:
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.To be done:
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.
nice !! i was just wondering about file system access for the emulator but this is even better
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.
You can find tutorial examples here.
#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 )
#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:
https://www.brolinembedded.se/projects/keyboard/
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)
@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. 

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 
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?
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
The difference here is that the operator you’ll want to use to make notes is the = character instead of :.
With the DS version, is there any way to load different roms?
Not that I know of, it would be nice to be able to browse the various roms, I agree.
thanks!! Will give that a go and finally start learning Orca 
the way i got around that is creating a folder for each different application and putting in each one a copy of uxnds and a boot.rom (which is that particular application renamed). not ideal but it works! some roms work better than others on NDS though