d6
/
nxu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

updates

This commit is contained in:
~d6 2022-11-11 21:51:52 -05:00
parent c0b81129e2
commit c7515aab22
1 changed files with 7 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
proposal.txt
View File

@ -43,6 +43,11 @@ i propose adding four bytes to the start of every rom:
- the literal 3 bytes "uxn" - the literal 3 bytes "uxn"
- a fourth metadata mode byte - a fourth metadata mode byte
the bytes "uxn" correspond to the instructions STA2r ADD2r JSR2r, so
we aren't at risk of creating an ambiguity with valid uxn roms which
previously would have worked, since a rom starting with STA2r would
immediately crash.
this proposal just covers metadata modes 0 and mode 1, but in the this proposal just covers metadata modes 0 and mode 1, but in the
future we could have up to 254 other modes to use (though we might future we could have up to 254 other modes to use (though we might
choose to forbid those later to keep things simple). choose to forbid those later to keep things simple).
@ -122,7 +127,7 @@ external applications might have an easier time with other formats
of use by other uxn roms running inside varvara. of use by other uxn roms running inside varvara.
the maximal "uxn1" header size (assuming all strings are maximum the maximal "uxn1" header size (assuming all strings are maximum
length and using an icon format of x0a3) would be 5904 bytes. while length and using an icon format of 0xe3) would be 5904 bytes. while
this is substantial it is unlikely to push most rom sizes over 64k this is substantial it is unlikely to push most rom sizes over 64k
(the point at which working with them from within varvara becomes (the point at which working with them from within varvara becomes
annoying). since the maximum rom data size is 65280, authors are annoying). since the maximum rom data size is 65280, authors are
@ -153,7 +158,7 @@ doesn't feel better than just limiting ourselves to ASCII (but maybe
that's my own cultural bias speaking) and (d) sounds like total chaos. that's my own cultural bias speaking) and (d) sounds like total chaos.
so my take is that inside varvara only ASCII values are likely to be so my take is that inside varvara only ASCII values are likely to be
well-supported, but for display outside varvara UTF-8 feels like the well-supported, but for display outside varvara UTF-8 feels like the
best option (e.g. allowing author's to write their names correctly). best option (e.g. allowing authors to write their names correctly).
another weirder option would be to provide graphical tiles or font another weirder option would be to provide graphical tiles or font
data that authors could use to encode program text. embedding a data that authors could use to encode program text. embedding a