I don't think you can emulate it on a tiny piece of hardware; the smallest full Uxn/Varvara implementation I've seen so far is the GameBoy Advance, which has 384KiB of RAM. On the other hand, you've previously been able to emulate some pretty astonishing things on pretty astonishing hardware.
There are a lot of minor things in Uxn and Varvara that make them hard to emulate efficiently. Extensive use of self-modifying code, memory-mapped I/O, and using a stack instruction set, for example.
I'm interested to hear how you'd redesign Uxn/Varvara to be easy to emulate on some tiny piece of hardware; of everyone in the world, you're probably the best person to answer that question. Little-endian, check. What else?
There's no requirement that stacks grow upwards in Varvara.
If your stacks grew downwards then you could use LE instructions to operate on 16-bit values on the stack. You'd still need to support loading from BE memory into the LE stack but that might not be too bad (two 8-bit operations instead of one 16-bit operation).
The device ports are also specified as BE so in theory you'd need to split those reads/writes up too. However, in almost all cases those are done directly from the stack values so I bet most ROMs would work fine with LE devices and LE stacks. LE devices would only cause issues when someone used 8-bit reads/writes from part of a 16-bit port.
Awesome, thanks for the link! I didn't remember that aspect of the 4004 project.
This would be a pretty amazing project. I wonder if you could get existing Uxn/Varvara applications like the Left text editor or Orca to run fast enough to be usable. Presumably for Orca you'd want to hook up external sound hardware rather than trying to bitbang the sound on the 8008, and I guess the same is even more true of a framebuffer.
If you were bitbanging RAM access at 7kbps it might be hard to get it to run instructions fast enough to be usable, though.
Uxn uses big endian primarily because it is meant to be easily assembled from (or disassembled into) a thin programming language called Tal. I think Tal is meant to be the highest-level language available in this platform, so it should be as convenient as possible without being too fat---`#1234` in Tal would ideally be assembled to two bytes `12 34` therefore.
Little endian is generally a lot more amenable to emulation, since math of almost all kinds of done LSB-to-MSB