It's a good idea, most of the apps I've written support a system similar to this, so they are compatible with potato, it not only include the name and version, but also exposes all application controls, so a menu manager can hook into the app and route input.
I'd love to see more applications building around these sort of UX precepts.
For a while, I was considering a secondary file to a rom, like a "disc sleeve" which contained all that meta stuff.
I think what I would do is instead of a header, is expect the first bytes to be LIT2 $2 #f0 DEO2, and use the second and third byte to locate the address of the meta data.
@neauoire @tty ok so it sounds like if you read {a0, X, Y, f0, 37} then you can interpret that as representing a uxn rom with metadata located at XY address (so XY-256 bytes into the file).
(this could be at the end as kira suggests, or anywhere else in the rom.)
@tty I've kept 0e and 0f explicitly for this sort of shenanigans 😀 It'll be safe for Varvara-compatible roms. So this would be our 5 bytes "header", with 3 unique bytes, it's probably quite unlikely to clash with something else. a0 is a , I wonder if it's common for files to start with that.
@neauoire @tty ok i'm going to try to write up a new proposal based on this idea.
do you all have opinions on what sort of metadata fields we should support? i had a bunch (author, version, description, icon, etc). am i missing any? are these too many?
Devine Lu Linvega
in reply to ⛧ esoterik ⛧ • • •Content warning: uxn metadata proposal
I'd love to see more applications building around these sort of UX precepts.
For a while, I was considering a secondary file to a rom, like a "disc sleeve" which contained all that meta stuff.
Devine Lu Linvega
in reply to Devine Lu Linvega • • •Content warning: uxn metadata proposal
Nasu would begin like
|0100 ( -> ) ;about #f0 DEO2
https://git.sr.ht/~rabbits/nasu/tree/main/item/src/nasu.tal#L1387
~rabbits/nasu: src/nasu.tal - sourcehut git
git.sr.ht⛧ esoterik ⛧
in reply to Devine Lu Linvega • • •Content warning: uxn metadata proposal
Devine Lu Linvega
in reply to ⛧ esoterik ⛧ • • •Content warning: uxn metadata proposal
And I would like for it to trigger a vector binding event, so the emulator can handle this if they want.
⛧ esoterik ⛧
in reply to Devine Lu Linvega • • •Content warning: uxn metadata proposal
(this could be at the end as kira suggests, or anywhere else in the rom.)
⛧ esoterik ⛧
in reply to ⛧ esoterik ⛧ • • •Content warning: uxn metadata proposal
it's not quite as obvious as "uxn" but it's still 3 fixed byte values, hopefully minimizing the chances of other formats "looking like" a rom.
Devine Lu Linvega
in reply to ⛧ esoterik ⛧ • • •Content warning: uxn metadata proposal
⛧ esoterik ⛧
in reply to Devine Lu Linvega • • •Content warning: uxn metadata proposal
do you all have opinions on what sort of metadata fields we should support? i had a bunch (author, version, description, icon, etc). am i missing any? are these too many?
Devine Lu Linvega
in reply to Devine Lu Linvega • • •Content warning: uxn metadata proposal
this way you can cycle through all of it with a single simple non-popping string-printing routine, like: https://git.sr.ht/~rabbits/nasu/tree/main/item/src/nasu.tal#L1056
~rabbits/nasu: src/nasu.tal - sourcehut git
git.sr.htDevine Lu Linvega
in reply to Devine Lu Linvega • • •Content warning: uxn metadata proposal
the 5 fields you picked are nice: name, version, author, desc, icon.
;metadata ;print-string JSR2k JSR2k JSR2k JSR2 ;print-icon JSR2
voila 👏
Andy Alderwick
in reply to Devine Lu Linvega • • •* the JSR2 has “string*” on the top, while
* the JSR2k's have “string* routine*” on the top.
Devine Lu Linvega
in reply to Andy Alderwick • • •