@tty also arguably you need 30 bytes for this (to print a trailing newline and add a #010f DEO to get the VM to exit cleanly)

@tty last post i promise:

if we allow unclean exit i can do it in 24 with:

|0100
LIT2 0a 'd LIT2 'l 'r LIT2 'o 'w
LIT2 20 'o LIT2 'l 'l LIT2 'e 'H
@loop #18 DEO ,loop JMP

@d6 haha, I love this!

Dropping the newline requirement (mine didn't have this) yours is actually 23

@d6 btw if we're ok with unclean exit now, mine /wo the BRK opcode is now also 23 😈

@d6 do you know the reason for this?

@tty I think the idea is that most ROMs don’t use most of the zero page so you save around 100 bytes per ROM to omit it

@d6 That makes sense, but it seems feasible for uxnasm to detect when you ARE trying to store data there, no?

@tty @d6 but then, how is the emulator to know if something starts at 0x0000 or 0x0100

@tty @d6 young uxn had the zero-page part of the rom, then we later moved to having an address at the start of the rom that indicated where the first vector was, then the concept of devices became clearer and we standardized all roms to start at 0x0100 since there wasn't that many roms that needed prefills anyways.

It has been like that since.

@neauoire @d6 Your question doesn't make sense to me. :o What do you mean by "if something starts at 0x0000 or 0x0100"?

Possibly clarifying: in calc.tal, there's a device living at #00, but then it also declares data at #0000. Are these different addresses?

@tty i think what @neauoire means is that the rom consists of a bunch of bytes and the emulator needs to know where the ROM bytes go into memory. currently the emulator just loads the ROM starting at 0x100, so the first byte in the ROM goes at 0x100, the second at 0x101 and so on. so if you wanted to optionally include a zero pad you'd need some kind of header or metadata to let the emulator know what the bytes mean.

@tty *zero page (not zero pad) but hopefully you get what i mean @neauoire

@d6 @neauoire Ok, that makes sense. What happens when you DO write data to the zero page, like calc.tal, which stores variables there, but does so by only storing labels to those addresses at compile-time?

@tty @d6 in calc, there is no data written to the zero-page

https://git.sr.ht/~rabbits/uxn/tree/main/item/projects/software/calc.tal#L10

It's assigning labels to addresses, so you have some values for .input, .stack, etc.

The devices are the same thing, it's not really doing anything special for devices, it's just assigning numbers between 0-256 to some label.

@neauoire @d6 Oh stars, I'm confused. ;input/value is at address 0x0000 - - isn't that on the zero page? If not, then what IS the zero page if it isn't the data in the first 256 bytes of the address space?

@tty @d6 Oh XD haha, okay I've confused everything. I thought you meant that calc was storing some sort of data on boot, which it isn't but it has a lot of zero-page addresses for the runtime.

So yes, zero-page is 0x000-0x0100. Nothing special happens when you write to the zero-page.

Most applications will store things that change a lot, or that you need quick access to.

@tty @d6 For example, in most applications, I keep a filepath in the zeropage, it's usually set as "untitled.txt on the init vector.

I also keep window/interface sizes that are responsive, so on init, once I know what the size of the window is, I cache a lot of values to make drawing the UI faster.

@neauoire @d6 Right. This all makes sense.

What I'm not clear on is why one can't write

|0000 "hello 20 "world 00

In the case you're describing with calc, data gets stored on the zero page at runtime, so why can't one do so at compile-time?

@tty @d6 Alright.

So let's say we did allow to write initial values in the zero-page. For example, in the calc, you could prefill the stack with values if you liked.

We'd instead load the rom at 0x0000 in memory, instead of 0x0100. For hello world, you could store the string in the zero-page, and the program would still start at 0x0100, the rom would be about 120-ish bytes long.

@neauoire Is the problem that uxnemu assumes that byte 0 in the rom is address 0x0100?

@tty It's a convention that came from iteration, but it's not a technical issue.

We have 3 options, that I know of, where you either

a) load the rom at 0x0000, making the smallest program at least 100 bytes long.
b) load the rom at 0x0100
c) add a sort of header to roms that indicates the various possible mappings of where a rom starts/ends, etc.. Like on the famicom.

@neauoire Got it. I was interpreting it as a technical limitation, which was confusing me. Thanks for explaining :)

@tty np :) We went through all 3 options over time, in the end I chose the option that had the least side-effects.