Hello everyone!

Here's a little something that has been asked a few times but never
made it to the codebase until now(thanks d6 for the patch) -- handling
the 0x7f portion of the System/halt port as exit code.

http://wiki.xxiivv.com/site/varvara.html#system

Exit codes communicate whether a program has completed successfully or
not, it's useful for things like assemblers where you might not want
to continue the execution of a build script if the assembly has
failed.

https://shapeshed.com/unix-exit-codes/

I've been working on a game called Oquonie, which is larger than 64kb,
and where the assets are spread over 8 pages of memory. The game will
be shipped wrapped inside its own uxnemu, but after chatting on IRC
about the idea and seeing others interested in having access to this
sort of power, I've made a rough draft public so anyone can try it
out.

oquonie: https://youtu.be/cfkrGSMsT-E

It's not quite file seeking, but it might do what you need if you just
need extra memory.

initial draft: http://wiki.xxiivv.com/site/varvara.html#system

The magic number that uxn32 and potato is looking for is: a0 ** ** 80 06 37
http://wiki.xxiivv.com/site/metadata.html

Well done :) Looking forward to see what you build once in there.

Cheers Dave :)
Good catch, merged.

On 1/11/23, Dave VanEe <dave.vanee@gmail.com> wrote:
> Without casting the pointer the +1 pointer offset yields the incorrect
> high byte of the symbol address. There may be another way to fix it,
> but this is what worked for me.
>
> -Dave
>
> --- a/src/uxnasm.c
> +++ b/src/uxnasm.c
> @@ -451,7 +451,7 @@ writesym(char *filename)
>     fp = fopen(scat(scpy(filename, symdst, slen(filename) + 1), ".sym"),

I've ran some tests and screen/width and screen/height do return the
right numbers.
I've updated the screen.tal example to draw the screen size. They are
correct in DuskOS.

https://git.sr.ht/~rabbits/uxn/tree/main/item/projects/examples/devices/screen.tal

I'm going to investigate further to see what breaks in Left.

I'll run some experiments and let you know what I find. :)

Here's what it looks like on qemu for Arch.

https://assets.merveilles.town/media_attachments/files/109/662/418/058/444/247/original/771c021aba2c97af.jpg

The menu is not drawn across the screen, I'll run some tests, but it
might be that the screen/width and screen/height don't give out the
right values on DEI2.

Oh Nature, I answered before seeing your comment, but maybe I can add
something relevant.

First off, Uxn is the first time I ever try to design a general
purpose VM or anything of the sort so one lesson that I've realized is
that having only literals as immediate mode for a stack machine makes
for very slow operations.

I think one of the first lesson in Koopman's book is that you want to
"bake" as many static arithmetic operations as possible, for example,
instead of pushing a literal only to pop it immediately to jump is a
waste of time(Which I only realized recently) for anyone reading this
and interested in that sort of thing, the better way of doing that is
to follow the NOVIX NC4016 design somewhat, where you can have

I'm glad you put it to the test, it's unfortunate that it is too slow,
Left as far as text-editors are concerned is kind of on the heavy side
too, using proportional fonts instead of fixed width adds a
considerable slowdowns. For me, Left via Dusk is very tiny, the screen
is just a little part of the qemu window at the top left of the
screen.

When you say grid editor, do you mean a block editor?
http://turboforth.net/tutorials/blocks.html

Having designed uxn to target much faster platforms, I now wonder what
a vm designed to target systems like a pentium 75MHz might look like,
VMs altogether might be best ignored and focus on compiling code that
compiles natively for the device.

Hi all!

Sorry for the delay, I've been pretty swamped with non-computery
things lately, but I'm getting to the end of it soon so at least I'll
be able to work on this soon.

I've seen fseek requested over and over again, and while I'm
personally not too keen on reading large files, it's becoming clear
that we'll need this in one form or an other.

Modifying the append port and renaming it to something that needs a
magic number is not the worst idea, and if your application absolutely
needs it, then implement it and make some apps with it.