~rabbits/uxn

Nonstandard varvara features of uxn38 (should some be made standard?)

Details
Message ID
<1695425349.bystand@zzo38computer.org>
DKIM signature
missing
Download raw message
Here is a list of nonstandard varvara features of uxn38, and in my opinion
might would be useful to be made standardized; these are my proposals. (Read
uxn38 documentation (and, if anything is unclear from the documentation, also
the source code) for more details about how these are working; this message
is only a simple explanation of them.)

If it is on here then a proper discussion can be made about such things, I
think; and whoever is responsible for the official specifications can also
make the considerations of these things (if they wish to do so) after a
suitable discussion has been made. Please make a comment, including if you
have any questions, objections, suggestions for changes, etc.

(Currently, uxn38 requires the -x switch to enable any of the features listed
below. If any of them are made standard (in the past some nonstandard features
have later been implemented as standard), then the -x switch will no longer be
required for that feature to be usable.)

Ports:

16 = Input flags; the low byte is set if the input vector should be called
when the input is EOF. (The other bits are not meaningful.)

36* = Detune register; divide by 65536 and add 1.0 and multiply that by the
frequency number by the MIDI note number specified (for example, #8000 would
mean a just fifth above the note specified by the MIDI note number). (This
allows for music that is not 12-TET, and even non-equal-temperament music.)

46* = Detune register.

56* = Detune register.

66* = Detune register.

a7 = In addition to its usual effect, writing anything to this port (even if
it is the same value already written) closes the file if it is currently open.

ac* = I think it used to be standard but was later removed, that reading from
ports #ac and #ad can read a single byte each. Some of my programs still use
this feature, although I can change it if necessary. (Because this was part
of the official implementation before, the -x switch is not required to use
this, at this time.)

b7 = Like #a7 but for the second file.

Expansion commands:

02 = Tell the number of available pages of expanded memory. (Some emulators
will automatically allocate memory. I am not sure what to do in such a case;
perhaps report #ffff and then fatal error if the memory allocation fails. If
this is the case, then programs should ensure not to allocate memory in the
middle of writing a file or something important like that.)

03 = Used for specifying nonstandard devices and commands by UUID. This way
will avoid a namespace collision. (Some implementations may still load some
nonstandard devices without this command.) (Using a UUID will avoid the
namespace interference, in case other people make up their own.)

a0 = Seek the first file to the specified absolute 32-bit offset. Not valid
for append mode. If the file is not already open, it is opened for reading
and writing together if this is possible.

a1 = Seek to the specified relative 32-bit offset.

a2 = Seek to the specified relative 32-bit offset from the end of the file.

a3 = Tell the current 32-bit offset of the opened file.

b0 = Like #a0 but second file.

b1 = Like #a1 but second file.

b2 = Like #a2 but second file.

b3 = Like #a3 but second file.

Note that I have made the high nybble of the expansion command number to be
the high nybble of the device number, so that they can be grouped by devices
and so that nonstandard devices can define their own expansion commands without
namespace interference.

I have deliberately tried to make it simple, to avoid complicating it too
much. I included the things which I think are most likely to be useful (or
important enough to include) and not too complicated or too difficult. (I
think these are probably the mostly desirable features anyways, although I
am not really sure because I do not have real data; I just know that some
of these have been mentioned by other people too. I have used some of these
in some programs already, although some of them are incomplete.)

Note that I am not proposing that any UUID-based extensions should ever be
standard, although reserving expansion command 03 for implementation-specific
extensions (like devices #d0 to #ff also are, as far as I know) might be worth
doing, in order to avoid interference with different incompatible versions.

-- 
Don't laugh at the moon when it is day time in France.
Reply to thread Export thread (mbox)