Uxn ecosystem on Haiku

Uxn is a complete application ecosystem, intended for the development of small tools and games, in the form of a virtual machine programmable in a dedicated assembly language (uxntal) and having only 32 instructions, on the principle of a machine forth, of which it keeps the postfix syntax, the stack and the capacity to produce a solution from simple and basic components.

Uxn can be seen as a processor, and the rest of the peripherals (audio, screen, keyboard, mouse) are managed by an ideal machine named Varvara, the two systems cohabiting perfectly.

The software written for Uxn is portable and intended for computers with few resources, in the spirit of permacomputing. Indeed, only a C compiler is needed to run the CPU core (in console). For access to peripherals, there are developments and ports to various platforms, including SDL2, which allows it to run on many OS (Linux, Mac OS, Windows, Haiku …). Moreover there are specific versions, for example Game Boy Advance, Nintendo DS, Playdate, DOS, Raspberry Pi Pico, Libretro, Web…

Don’t expect to recreate 3D games with this system, because the specifications are quite frugal, with 64 kB of RAM in particular. It is a bit like some imaginary consoles (like TIC-80).

Uxn won’t use the native Haiku toolkit, but it can use the SDL interface so it runs flawlessly on Haiku. It’s a great “hobby” language even if it can go beyond this.

The main developer of Uxn is Devine Lu Linvega, from the couple Hundred Rabbits. Rekka Bellum illustrates the site and the tools developed for Uxn, and thus contributes greatly to the imagination around this ecosystem.

Among the available tools developed for Uxn, we can find :

  • ‘calc’, a graphical calculator and focused on the hexadecimal.
  • left’, a text editor (not utf-8 unfortunately, so it is not adapted to the French prose).
  • nasu’, a sprite editor.
  • noodle’, a pixel-art drawing tool.
  • donsol’, a card game in the form of roguelike.
  • orca’, an incredible midi sequencer, where the notes are entered in a grid in the form of ascii code.
  • turye’, a font editor (in pixel, it is not the equivalent of fontforge either).
  • ‘dexe’, a hexadecimal editor.
  • ‘piano’, a small synth to be used with orca for example.
  • ‘turquoise’, a graphic programming language close to the “turtle” of the logo.
  • ‘nebu’, a spreadsheet / .csv editor in 6,2 kb!

You have to keep in mind that the generated binaries are extremely compact, for example the orca sequencer is only 11 kb in the Unx version. Its console version (for terminal), written in classic C, takes a little more than 100 kB, while the version for Electron, which has almost the same functionalities, weighs more than 400 MB!

In conclusion, Uxn is an original tool, developed by enthusiasts and designed with the aim of breaking out of the modern development paradigms.

If you wish to compile Uxn on Haiku, you’ll have to add this in console, before launching ./build.sh, otherwise it won’t compile:

export CC=cc-x86

Builds fine without the “export” (just switched gcc compiler to gcc11 in 32bit with setarch x86)

EDIT available in the depot now :slight_smile:


many things changed in uxn recently. I wanted to compile the latest version, but now the build.sh script complains that it can’t find sdl2-config. I’ve also seen there is no longer the sdl development files (like SDL.h) on my system.

Did haiku remove the development files from the Haiku depots? I’m almost sure I’ve installed them from the graphical interface.

Anyway, I’ve managed to install SDL2 with this command:

pkgman install libsdl2_devel

and compiled latest unx version

It seems to be much slower now than with the uxnemu from last year… and there are also some visual artefacts

By default devel packages are not visible in HaikuDepot because simple users like me don’t care. You can toggle that in the menu.

1 Like

I missed this one. Thank you!

Created a local package for the commit 20230804 (3 days ago), packages fine still without only the checksum change in the recipe.
I can’t test the package as I don’t have any rom’s here to test it with, what where the issues you encountered?
If the current one from the depot is still fine we could just leave it like that.

The uxnemu currently on HaikuDepot, both 32 and 64 bits, doesn’t run some rom’s correctly: launcher.rom doesn’t show the text (menu), oquonie.rom doesn’t run at all.

1 Like

I could push a new(er) release, but want it to be better then before, maybe some can do a local build (shouldn’t be that hard) and check it out?

Did a quick 64bits build of uxn-1.0, uxnemu worked fine, even oquonie loaded and played ok.

OT: also did a build of the (debian) console sudoku…


I can’t really tell. I’ve made further tests, and uxn from april 2022 (or your version from may 2022) are running normally (for an old amiga.rom boing ball demo rom, it should reside in projects/examples/demos/amiga.tal), while latest version from this month is very slow (with newest amiga.rom). Maybe it’s something with my graphical card (nvidia GeForce GTX 660), I can’t test it on other hardware.

Here is a video:

1 Like

Good old days on AMIGA :wink:

1 Like

Let’s just keep what we got then :slight_smile:

1 Like

Try to recompile it with

export CC=cc-x86

Made a huge difference in speed on my x86.

1 Like

thanks a lot. I was just testing different things and this did the job! I got a notification of your answer while I was struggling between the binaries and different revisions of the source code!

Ironically, this command is in the last line of my first message, but since it compiled now without this command, I didn’t looked further…

if I run file on the binaries, on the correct speed version I get:
uxnemu: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

while on the wrong one:
uxnemu: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /system/runtime_loader, stripped

compiled with cc-x86 it is fine now, so I suppose it would be better to update the binaries now! :wink:

Can be done like this, but the more common way to switch to the modern gcc compiler on Haiku is by issuing the command “setarch x86”.

1 Like

yes, someone talked about this command earlier, I haven’t looked further about it, probably I should have, it would have saved me some time…
My system is not 64bit I suppose I’ve installed the x86 version, uname -a gives me

Haiku shredder 1 hrev56578+87 Aug 16 2023 06:04: BePC x86 Haiku

with setarch -l I see I have only 2 options: x86_gcc2 and x86. I suppose without setarch x86, I was using the older legacy gcc2? That would explain why it was slow maybe?

Yes, you are indeed on the 32 bit (x86) version of Haiku. By default you get gcc 2.95 (hope I’m correct here, not on Haiku right now), which is about 20 years old now. This compiler is used for the OS itself, to enable binary compatibility with old BeOS apps. By issuing the “setarch x86” command you switch your environment to the modern gcc compiler (version 13 at the moment I think). To compile applications this is the better option, except you are compiling very old code.

On 64bit Haiku (x86_64) only the modern compiler is available (no binary compatibility with BeOS anyway). Thus no setarch command is needed.


Updated to yesterday’s commit, build on both buildmasters now. :slight_smile:


thanks a lot for the informations. I knew about the fact haiku was still binary compatible with the old BeOs apps, which is quite interesting for legacy usage.

I didn’t understand the older gcc was still default for compilation. I understand better why some programs couldn’t compile. I managed to compile gforth after I’ve changed the arch!

And many thanks to @Begasus for the update!