It’s beautiful :3

I'm confused by the first paragraph in the linked page. It says that the location of the the rom metadata is at the address that's at offset 0001 in memory. However, looking at https://git.sr.ht/~rabbits/noodle/tree/main/item/src/noodle.tal, that doesn't seem to be the case.

yup, I guess I'll rephrase this

i think the point that doc is making is that the very first byte in the rom is a LIT2 instruction, and the next two bytes are the address. @neauoire

Question: since this is a from-scratch OS essentially, why did you go for C-Strings rather than Pascal-Strings for the manifest?

What d6 means is that the first 5 bytes of a rom is always going to be:
a0 XX YY f0 37

The metadata address is located at location XXYY

minor correction, it's the first six bytes due to the LIT before f0:

a0 XX YY 80 f0 37

but yes, this means a nice consistent header for supported ROM files, without anything special needed in emulators!

@alderwick right, thank you. Can't read right this morning ^^;

@alderwick I'm adding a capture to uxn11 that renames the emulator window with the rom name and version. This will allow all sorts of fun things 😁

@alderwick it also shows how to add extra fields (like UXN version) via a write to a metadata device port, again in a standard 6 byte chunk @neauoire @tty

Oh! I was going to ask if the manifest could end with a double 00, so it's trivial to make extensions for it. The examples already do that, but if that's the intention then it'll be great to add some body text to clarify it.

Oh no, games/apps contained entirely within the titlebar!

@tbsp donsol micropayments

The metadata is part of the rom.

https://git.sr.ht/~rabbits/nasu/tree/main/item/src/nasu.tal#L1389

The #f0 is only so the emulator can also become aware of that metadata. For example, to rename the window, to draw an icon, etc..

;meta is a normal uxntal label that holds an absolute position to that location in memory.

https://git.sr.ht/~rabbits/nasu/tree/main/item/src/nasu.tal#L30

it's a convention that requires that the first 5 bytes of a rom is always going to be:
a0 XX YY 80 f0 37

The metadata address is located at location XXYY

If a rom doesn't begin with a0 XX YY 80 f0 37, then it doesn't have any metadata.

So the ROM author will have at the top of their .tal file:

|0100
;my-metadata #f0 DEO2
@on-reset
;0123 .System/r DEO2
[…]

and the assembler does the rest.

It doesn't place it at the front of the rom, it just write an address to that location. The metadata can be anywhere in the rom.

Ah! I think I understand what you're asking.

So, this whole thing doesn't require any change to the assembler. It uses just an old boring ;label reference.

That label can be named anything, the ;meta #f0 DEO2, is kind of like setting a vector, but we're not worrying about that right now, #f0 is a non-specified device in Varvara.

The assembler sees ;meta, and write the position of the @meta label, which could be any other name too.

https://git.sr.ht/~rabbits/drifblim/tree/main/item/src/drifblim.tal#L446

This line in the program does that: https://git.sr.ht/~rabbits/nasu/tree/main/item/src/nasu.tal#L30

When you assemble a rom, all the ;labels are resolved to actual addresses, they're constants. And they can be seen in the assembled rom as real addresses.

In this image, I'm looking at the assembled nasu rom, and the address of ;meta, solved to the address of the @meta label in the program. So an external program can look for the second and third byte of that program, and go to that specific address in the rom, and can expect to find the meta data.

https://git.sr.ht/~rabbits/potato/tree/main/item/src/potato.tal#L408

yup!

nop, this is absolutely not required, and doesn't require any change to emulators. It's only if someone feel inclined do add some meta data, it will be ignored as writing to an unknown device.

Oh, what potato will do is that if the 4th to 6th bytes are not #f0 DEO2, then it will say "no metadata"

yes! very much interested :>

Would you be interested in a wiki patch that tries to make this clearer? It's possible I'm an outlier, but I've written a fair amount of uxn and that was NOT obvious to me hehe

would it be alright to make a PR instead?
https://github.com/XXIIVV/oscean/blob/main/src/htm/manifest.htm

cheers 😀

it's perfect. Thanks Kira 💜

if you look at the tobmp method [1] you can see the code that converts ICN data to a single BMP image @neauoire

[1] http://plastic-idolatry.com/erik/nxu/uxnmeta

you have to read the ICN format carefully (ICN is defined in terms of tiles which are each 8x8) @neauoire

yeah this is confusing. it's 8 tiles x 8 tiles (and each tile is defined as 8 pixels by 8 pixels) @neauoire

Oh hey, realizing that the doc says 8x8 icon, but is that actually true? Noodle provides a much larger graphic:

https://git.sr.ht/~rabbits/noodle/tree/main/item/src/assets.tal#L67

yup, erik is right, I'll add an extra note to say that the unit is tiles.