Someone asked me if we could add a way to detect if a device is a
missing, the usecase is like, trying to load noodle, with uxncli,
should say "Device is missing", something like this.
We could do it in emu-space, like: when a read/write happens on a
missing device, it prints a warning saying that the device is missing.
We could do it in uxn-space, maybe: if after setting a vector, the
vector is still #0000, then that means the device is missing? It would
work for most devices that disambiguates uxnemu/uxncli, but datetime
has no vector(yet).
Let me know what you think, in the meantime, I'll add warnings to
uxncli when a DEI/DEO occurs on a missing device.
On Tue, Jun 14, 2022 at 08:49:02AM -0700, Devine Lu Linvega wrote:
> We could do it in uxn-space, maybe: if after setting a vector, the> vector is still #0000, then that means the device is missing? It would> work for most devices that disambiguates uxnemu/uxncli, but datetime> has no vector(yet).
I like the idea of doing it in emulator space -- it makes it more
likely that ROMs will be able to show a useful and specific message
when a capability they need is missing.
One problem with your proposal here is that you can't provide such a
message until you try to use the capability, meaning you need to
intersperse this "error handling" code all through your program. It
would be nicer to check what you need _before_ actually trying to use
it, and putting all that logic "up front" in the program.
If we can justify adding system ports a nicer interface might be:
|00 @System
&vector $2
&wst $1
&rst $1
&query $1 ( proposed )
&reply $1 ( proposed )
&pad $2
&r $2
&g $2
&b $2
&debug$1
&halt $1
The idea would be that using DEO on .System/query would ask emulator
supports a device or device port. Examples:
.Audio .System/query DEO
.Datetime/isdst .System/query DEO
.File/append .System/query DEO
.Mouse/scrollx .System/query DEO
In all cases the response would be read using DEI:
.System/reply DEI ( returns #01 or #00 )
If we wanted to be able to do other kinds of queries we could either
make the query port 2 bytes or else limit the interface to asking
about devices (#01 through #0f) rather than device + port pairs.
What do you think?
-- Erik
> The idea would be that using DEO on .System/query would ask emulator> supports a device or device port. Examples:> > .Audio .System/query DEO> .Datetime/isdst .System/query DEO> .File/append .System/query DEO> .Mouse/scrollx .System/query DEO> > In all cases the response would be read using DEI:> > .System/reply DEI ( returns #01 or #00 )> > If we wanted to be able to do other kinds of queries we could either> make the query port 2 bytes or else limit the interface to asking> about devices (#01 through #0f) rather than device + port pairs.>
How about a bitmask? That wouldn't require a coupled DEO/DEI
operation and the number of devices is limited (and ordered)
anyway.
felix
I've considered this but I couldn't find any example where the errors
didn't fire, for example, the moment you try to set a vector for mouse
or controller devices, the error fires.
The reset vector will invariably set some sort of vector or something
that will trigger the errors, there might be a way to skip the check
somehow that I haven't conceived of yet.
Found an exception.
The file device is a bit tricky I suppose, for example, noodle doesn't
assign a File/name until it tries to save, but the device does have a
vector, although it is unused.
Maybe applications should still test available devices on reset, I
could set a #0000 to File/vector on reset to make sure that it is
available.
If all else fails, a bit mask in a byte might work, but let's try to
see if we can do without first.
I've implemented a simple check using a device support bitmask at the
emulator level, it'll catch 90% of the incompatibility issues which
will likely be folks trying to run graphical roms with uxncli.
The report came from someone using uxn11 on BSD, but this should
probably be added to uxnsdl as well.
https://git.sr.ht/~rabbits/uxn11/commit/5d837313e56d19cd6ecfa2ad9746edca20afb5f6