You are not logged in.
Pages: 1
I have an Arduino Esplora. And that thing packs almost all I/O features of the NDS:
an analog joystick (can be used to emulate the D-pad)...
... with a button under it (Start)
4 big physical buttons (ABXY)
a microphone
a squeaky can speaker
a light sensor
an RGB LED
an analog slider
a 3-axis accelerometer
an optional LCD screen
running an Atmel ATmega32U4 microcontroller at 16MHz
connected to the computer over USB
So I wonder if there is any way to create a plugin or an adapter software, and the corresponding firmware for the microcontroller so DeSmuME can use it as an input device?
Offline
In principle, sure. Good luck.
I doubt you could move enough data through that thing to control an LCD. Consider: 256x192x2x2x60 = 11.7MB/sec.
So just to use it as an input device, I recommend you begin by interfacing with a program running on your PC. Only if you have success with that should you bother breaking into desmume.
Offline
In principle, sure. Good luck.
I doubt you could move enough data through that thing to control an LCD. Consider: 256x192x2x2x60 = 11.7MB/sec.
So just to use it as an input device, I recommend you begin by interfacing with a program running on your PC. Only if you have success with that should you bother breaking into desmume.
As an input device I have already able to implement some basic functionalities using the keyboard emulation feature of the microcontroller, translating operations on the Esplora into default keyboard bindings. However to make things like microphone or accelerometer work some kind of direct interface between DeSmuME and the firmware is needed.
Offline
To use it as an input device, I recommend you begin by interfacing with a program running on your PC. Only if you have success with that should you bother breaking into desmume.
Offline
To use it as an input device, I recommend you begin by interfacing with a program running on your PC. Only if you have success with that should you bother breaking into desmume.
I have long established communication between that device and the PC (remembered me mentioning that I have already leveraged its USB HID keyboard simulation to perform basic interfacig between it and DeSmuME?)
I have long been able to use Esplora to control my own apps.
Here is my suggested method of allowing other programs to control DeSmuME, using pipes. I am disregarding the perks of Windows here.
Command-line flag: --gamepad=<file|stdin|[bind-address]:port|console> --touchscreen=<file|stdin|[bind-address]:port|console>
The first flag controls the source where DeSmuME takes keypad input from, and the second determines the touchscreen input:
console means taking the input from the user's keyboard or mouse (default behavior as of now);
file means taking control inputs from a normal file (for macro replaying,) character device (if the device can emit the corresponding instruction string right after being opened without any ioctl;) UNIX domain socket or pipe (usually from another program;)
stdin uses the standard input as the input file, with the same rule as when a file name is given (so desmume --gamepad /dev/ttyUSB0 and desmume --gamepad stdin < /dev/ttyUSB0 are synonymous, and it is possible to say myusbdriver /dev/ttyUSB0 | desmume --gamepad stdin);
[bind-address]:port means open a listening socket on this bind address (default to localhost) and port and listen to commands from there
By documenting the protocol used by this interface anyone can plug their own controller into DeSmuME without having to touch the codebase of DeSmuME any more. They just need to implement interface between their own method of input and this protocol, or in some cases, implement this protocol in hardware directly (e.g. a Wi-Fi connected controller can implement this protocol and speak to DeSmuME over network directly, if DeSmuME is launched with the option of taking gamepad input from network)
Last edited by xcvista (2016-07-26 20:41:01)
Offline
insufficient for microphone and accelerometers. If all you want is buttons and gamepads, that's more doable. You could do it right now by using luasockets in desmume's LUA, which is able to feed pad and touch input into the core. LUA was put there so that exotic things like this could be done without having to touch the codebase of desmume any more.
To be more sophisticated, I suggest you investigate adding this functionality to retroarch (which can run the desmume core) so that it can be done ONCE for every platform, instead of wedged ungracefully into desmume. I don't think anyone but you will be interested in adding such rarely-used functionality to desmume all by its lonesome.
Offline
insufficient for microphone and accelerometers. If all you want is buttons and gamepads, that's more doable. You could do it right now by using luasockets in desmume's LUA, which is able to feed pad and touch input into the core. LUA was put there so that exotic things like this could be done without having to touch the codebase of desmume any more.
To be more sophisticated, I suggest you investigate adding this functionality to retroarch (which can run the desmume core) so that it can be done ONCE for every platform, instead of wedged ungracefully into desmume. I don't think anyone but you will be interested in adding such rarely-used functionality to desmume all by its lonesome.
Then can the built-in Lua environment handle device files (for direct tty access) or call C libraries (for libusb calls if direct HID is used) or use sockets (so a third party program can feed control into it) then?
Offline
it can do all those things (at least it can use sockets) and if it can't you can make it load a dll/so module which does it. I understand this is a cumbersome way of achieving what you want, but at the present, thats the best way for something else to take control of the emulator main loop, short of making an all new frontend
Offline
Pages: 1