That’s pretty much the best way to figure out uxntal! You’ve recreated all standard program structures in it, with this, you’ll be invincible!
Normally, for while loops, I use LDAk, like:
;word
@while
LDAk #18 DEO
INC2 LDAk ,while JCN
POP2
BRK
@word "vermillion $1
So if I understand this, this is like, a foreach loop? it loads the value and then increments the address, and then loads the next byte? and then the $1 is a null byte at the end, which counts as a false for the JCN boolean?
Exactly 
Here’s a little something I’ve been toying around
I have a question.
The memory space of 10000h bytes, from 0000 to FFFF.
Is it an absolute requirement?
If implementing uxn on a device which itself has 10000h or less RAM available then this is not possible.
However most programs probably don’t need all memory.
Is there some convention used of how data is allocated in compiled programs? So that it would be safe to implement an uxn with less memory, skip some memory region, and expect at least some programs to work?
(I’m not actually considering implementing such a thing now. Just wondering.)
The convention is to use the most memory that you can, but like you said, most roms won’t be impacted by this at all. The convention is to use a page for the devices, but everything else is somewhat flexible.
For the arduino port, what I did is to use shallower stacks, so instead of a whole page, I use 80 bytes per stack, and only 1800 bytes of memory. It allows me to run most little roms.
I read about the fantastic live rom assembly/loading here:
So I created a .drifblim with src and dest path and run „uxnemu drifblim.rom“ but no success so far 
How does it exactly work? Thanks in advance!
Heyo, just dipping my toes into uxn with the lovely tutorial from compudanzas.net and having some trouble with the raw character rune. uxnasm returns “Unknown token: 'h” on the following bit of code.
( hello.tal )
|0100 LIT 'h #18 DEO
LIT 'e #18 DEO
LIT 'l #18 DEO
LIT 'l #18 DEO
LIT 'o #18 DEO
#0a #18 DEO ( newline )
If I change the single quote to double quotes it assembles just fine in uxnasm.
( hello.tal )
|0100 LIT "h #18 DEO
etc, etc.
Neither versions assemble in drifblim for me. the single quote version returns the same “Unknown token” error and the double quote version just returns an error with the name of the input file.
I’m trying to do this on Windows, so that is probably the root of the problem but any suggestions would be appreciated.
That’s a bit tricky, your drifblim file needs to look like this:
I haven’t written an interface to the project mode, it only writes this file directly in the zero-page. If this is all too cryptic, you should use the normal interface:
uxncli drifblim.rom input.tal output.rom
Ah! Yes, the ' and " were exactly the same behaviour, so I’ve removed the ' since it was creating confusion. Whenever you see single quotes in docs, you should use double-quotes, sorry about that.
Ah, I’ve got it. I also needed to rename drifblim.rom to launcher.rom and run it with uxnemu launcher.rom. Now whenever I want to refresh the screen I have to press F4 and the source gets assembled again. Great! I really love this development flow 
Thanks!
just updated the online tutorial to reflect this — i wasn’t aware the change had happened for sure!
thank you and sorry @A_Cormorant! i hope you enjoy what comes next 
Is there any convention around clearing the screen every frame?
I noticed that none of the uxntal I’ve seen does a full redraw every frame (except in special cases). Instead, for moving sprites people do the pattern “clear sprite, update, draw new sprite.” Is it un-uxn to redraw everything every frame?
Is it un-uxn to redraw everything every frame?
It’s totally fine to do it, there’s a few apps that do fullscreen clearing, like Turye, but not through the screen vector. Just don’t do it pixel-per-pixel, depending on your program, you can do 16 tiles vertically at once, and wipe horizontal sections of the screen. That should be fast enough for the DS and GBA to handle.
Left does a 8 tiles high fast wipe that you could inspire yourself from. Start by saving the screen size to wipe, at the beginning of your program, so you don’t recalculate each frame:
.Screen/height DEI2 #06 SFT2 NIP INC ;draw-textarea/height STA
.Screen/width DEI2 #03 SFT2 NIP ;draw-textarea/width STA
Then you’re good to clear each frame
( fast clear )
#71 .Screen/auto DEO
#0000 .Screen/y DEO2
[ LIT &height $1 ] #00
&h
#0000 .Screen/x DEO2
[ LIT &width $1 ] #00
&w
#00 .Screen/sprite DEO
INC GTHk ,&w JCN
POP2
.Screen/y DEI2k #0040 ADD2 ROT DEO2
INC GTHk ,&h JCN
POP2
Thank you very much!
Hi all! I hope you’re well.
I recently gave a little talk at Handmade Seattle that goes over much of the design process for this project. I tried to explain most of the choices, and experiments, that went into creating Uxn. I’d like to have a link to it on here for anyone else stumbling on this thread.
Here’s a tree in a few bytes of uxntal
|00 @System &vector $2 &pad $6 &r $2 &g $2 &b $2
|20 @Screen &vector $2 &width $2 &height $2 &auto $1 &pad $1 &x $2 &y $2 &addr $2 &pixel $1 &sprite $1
|0100
#23ef .System/r DEO2
#3b7f .System/g DEO2
#665f .System/b DEO2
,draw-tree JSR
BRK
@draw-tree ( -- )
#0060 .Screen/y DEO2
( star )
#0103
DUP2 ,draw-line JSR
#0203 ,draw-line JSR
,draw-line JSR
( tree )
#8000
&tree
DUP #02 SFT #3f AND DUP ADD STH
DUP #0f AND STHr ADD #01 ,draw-line JSR
INC GTHk ,&tree JCN
POP2
( bark )
#1000
&bark
#0802 ,draw-line JSR
INC GTHk ,&bark JCN
POP2
( ground )
#ff03
@draw-line ( width color -- )
,&c STR
#00 SWP
DUP2 .Screen/width DEI2 #01 SFT2 SWP2 SUB2 ,&o STR2
DUP2 ADD2 INC2 #0000
&l
DUP2 [ LIT2 &o $2 ] ADD2 .Screen/x DEO2
[ LIT &c $1 ] .Screen/pixel DEO
INC2 GTH2k ,&l JCN
POP2 POP2
.Screen/y DEI2k INC2 ROT DEO2
JMP2r
Enjoy, and keep warm
Hi all, maybe a bit of a tangent, but this seems like the best place to ask. I have rediscovered my 6502 fandom and have soldered together the OS816 kit by Vienna-based c0pperdragon. The kit is a minimal design with a 65816 processor (a 16 bit variant of the 6502, used in SuperNES and Apple IIgs), some flash and RAM memory, a serial port, a machine monitor programm and really nothing more.
I am now contemplating how to get a screen and keyboard for the board. At some point, I will just attach a little TFT screen and PS/2 keyboard to it.
At first however, I want to stick with the serial line as the only interface to the 65816 board. On the host end, I would like to have somthing like a Varvara computer as a kind of thick client, being controlled through the serial interface. It would allow to interact with all the devices normally controlled from UXN from the 65816 CPU. This very same mode of control could be used by other microcontrollers, e.g. an Arduino, using Varvara in a similar way as Open Sound Control.
Has something like this been attempled?
Best regards,
– Olav
Hi everyone, I wanted to know, in particular from @garvalf , if the effort porting uxn to the Atari ST was still ongoing ?
I started my own implementation of uxn in Pascal, and got a very early version of an emulator running on Atari ST using Pure Pascal. So far, only the console device is implemented, but it’s enough to run the test suite and the canonical Fizzbuzz example
Hi All. I’ve recently discovered Orca and am trying to figure out if I can run this using Uxn on an old portable 32bit windows 7 machine. I can load the included roms in the Uxn32 Essentials Pack, but when try to run the Orca rom (from: ~rabbits/orca-toy - Livecoding language, written in Tal - sourcehut git) I get (what I think is) a debugging window called ‘Beetbug’.
Please can anyone give me some pointers on what I might need to do?
Maybe try posting the issue in Uxn32’s GH. I haven’t used it myself but from the readme it should work on your system? Also you might get some help in Uxn’s IRC (ircs://irc.esper.net:6697/#uxn).
Thanks, I’ll give that a go.
@neauoire Ive been wondering, why choose a stack machine for Uxn, rather than a register machine? Not to disparage one or the other, but I mean like, what led you to that decision? Was it just easier to implement, or was it to be more like Forth?