VMU/Maple support for DreamConn+ controller

[chrisvcpp]

Hi there!
My name is Chris Daioglou, and I'm the creator of the DreamConn+ wireless controller, and the later VM2 for the Dreamcast
It's a while now that I was thinking of suggesting fellow developers for an addition to the Flycast emulator.

As you may know, the DreamConn+ is the only wireless controller, that supports actual VMU & Rumble Pak, giving the same experience as the original wired controller. It's a while now, that I've added support for using the controller with Windows PC, making it compatible with Steam, games and emulators.

The only feature that lacks from any current emulation system, is the transmitting of Maple data regarding the VMU, or Rumble Pak.
So, I was thinking that we could collaborate, in order for Flycast (Windows version at least) to transmit/communicate with an intermediate channel (i.e. local IP port) that the DreamConn+ could use to gather data and use with the actual VMU plugged into the controller.
This should give the ultimate experience with using the emulator along with the DreamConn+, giving an experience as close to the original console as possible.

[flyinghead]

Hi Chris,
Sorry for not getting back to you earlier (!!)
How do you see an integration of DreamConn+ with Flycast so that maple data can be exchanged? I see that it can be used with a PC, and I guess the controller part works with flycast through SDL.
If using a local IP socket for maple data, would that work with more than one controller? Do you have an idea for the data format/protocol?

[chrisvcpp]

Hi, Thank you for getting back to me! I actually already did dome progress with it. Please check a video preview here: https://x.com/CDaioglou/status/1852811345684533310 I used the later 2.4 version from the Git and made a custom built - only for Windows x64 since the DreamConnS controller is compatible only with Windows. At the moment I used something similar to named pipeline(instead of IP socket), and using only the LCD Maple messages for all Slot[1] ports : A1, B1, C1, D1 Didn't commit the changes to the project, as I know that Flycast aims into being cross-platform.. But, it would be great if you'd be willing to officially add support for the DreamConnS controller. I can imagine that using local IP sockets (one for each port, so 4 in total) would be awesome! The data format/protocol would be the Maple commands as they're! No need to make any special formatting. Just forwarding the Maple commands through the corresponding IP port would be more than enough to me. This way, we can add support for even more functionalities than just LCD data.For example, I could use all of the Maple commands for actually using all of the VMU features : LCD, save/load, buzzer, clock/date, etc. Let me know if this's something feasible and that you'd like to do.. Many thanks,- Chris Στις Τετάρτη 11 Δεκεμβρίου 2024 στις 02:24:39 μ.μ. EET, ο χρήστης flyinghead ***@***.***> έγραψε: Hi Chris, Sorry for not getting back to you earlier (!!) How do you see an integration of DreamConn+ with Flycast so that maple data can be exchanged? I see that it can be used with a PC, and I guess the controller part works with flycast through SDL. If using a local IP socket for maple data, would that work with more than one controller? Do you have an idea for the data format/protocol? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[flyinghead]

Yeah, I saw your video when you posted it on Twitter. Impressive work!
Is there any way you could share your flycast changes? I could integrate them upstream. I don't have a device to test with so I need at least some working prototype code to boot me up.

[chrisvcpp]

Sure thing! I only added a few lines of code to the maple_devs.cpp -> function u32 dma(u32 cmd) override -> section case MFID_2_LCD : ============================================== case MFID_2_LCD:{     DEBUG_LOG(MAPLE, "VMU %s LCD write", logical_port);     r32();     rptr(lcd_data,192);     if (!strcmp(logical_port, "A1") || !strcmp(logical_port, "B1") || !strcmp(logical_port, "C1") || !strcmp(logical_port, "D1"))     {         char sfile[30]; sprintf(sfile, "data\\vmu_lcd_%s.dat", logical_port);         FILE* f = std::fopen(sfile, "wb");         if (f != NULL)         {             std::fwrite(lcd_data, 1, 192, f); std::fflush(f); std::fclose(f);         }     }    .     .     . ============================================== As you can see, I'm just writing the 192 bytes of the LCD-related data to a corresponding A1/B1/C1/D1 file - the rest of work is done by the DreamConn utility app.. In our case, working with IP ports will be much easier (and a better solution) : you will just have to forward the Maple messages related to VMU(A1/B1/C1/D1) to the IP port.Then I will handle everything through my application.. Στις Τετάρτη 11 Δεκεμβρίου 2024 στις 03:30:16 μ.μ. EET, ο χρήστης flyinghead ***@***.***> έγραψε: Yeah, I saw your video when you posted it on Twitter. Impressive work! Is there any way you could share your flycast changes? I could integrate them upstream. I don't have a device to test with so I need at least some working prototype code to boot me up. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[flyinghead]

Would it make sense for the DreamConn utility app to be the "network server", to which flycast would connect to?
I suppose your utility must be running as long as you use a DreamConn+ controller. Whereas flycast may be opened and closed several times depending on which game the user is playing.

So the DreamConn utility could open a listening socket (or one socket per controller) on known ports. Flycast would then try to connect to this port at start up, and establish the connection. Then raw maple data would be sent to it.

A few more thoughts:
It would help if flycast could detect that a given controller is a DreamConn+. That way flycast will only connect to the DreamConn utility when a DreamConn+ is detected, and correctly identify which maple port it's connected to. I guess a vendor/product ID is enough, or the controller name as reported by SDL.

As a first step, I can forward maple messages related to LCD screen update and beeper. These messages don't really need any answer from the controller or vmu. However, if we want to use other functions such as storage, flycast will have to wait for a maple response before proceeding.

Flycast will also need to know the controller configuration: which device is connected (vmu, rumble pack, none) on which port. I guess this can be done with the maple protocol on the network port.

[chrisvcpp]

Hi, Yes, I could make the utility app to be the server. Whenever a controller is connected, I can open a specific TCP port (which corresponds to A1/B1/C1/D1). Regarding your thoughts: 1. At the moment, when a DreamConn controller is connected, the utility app presents a virtual XBox360 controller (XInput) to Windows (up to 4 of them).This virtual controller can also report specific vendor/product ID, so yes, this is quite feasible and easy to do! 2. You're quite right about this! Maple messages that do not require specific responses (other than "ACK") like LCD & BUZZER will be easier to begin with.For other more complex Maple commands (like saving/loading), we can do it later on - I can think of a few "tricks" that can make it easier and also keep Flycast as close to its original/current state as possible. 3. For the controller configuration, this can easily be done by Flycast sending a "Get Condition" (command 9) to the TCP port.The utility will respond with the controller's state indicating which slots are occupied (Slot1 occupied means VMU is present, Slot2 occupied means Rumble is present). Στις Πέμπτη 12 Δεκεμβρίου 2024 στις 06:02:29 μ.μ. EET, ο χρήστης flyinghead ***@***.***> έγραψε: Would it make sense for the DreamConn utility app to be the "network server", to which flycast would connect to? I suppose your utility must be running as long as you use a DreamConn+ controller. Whereas flycast may be opened and closed several times depending on which game the user is playing. So the DreamConn utility could open a listening socket (or one socket per controller) on known ports. Flycast would then try to connect to this port at start up, and establish the connection. Then raw maple data would be sent to it. A few more thoughts: It would help if flycast could detect that a given controller is a DreamConn+. That way flycast will only connect to the DreamConn utility when a DreamConn+ is detected, and correctly identify which maple port it's connected to. I guess a vendor/product ID is enough, or the controller name as reported by SDL. As a first step, I can forward maple messages related to LCD screen update and beeper. These messages don't really need any answer from the controller or vmu. However, if we want to use other functions such as storage, flycast will have to wait for a maple response before proceeding. Flycast will also need to know the controller configuration: which device is connected (vmu, rumble pack, none) on which port. I guess this can be done with the maple protocol on the network port. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[flyinghead]

I committed a first prototype for DreamConn+ support (dev branch)
Right now, each dreamconn must be enabled in emu.cfg:

[input]
DreamConn0 = yes
DreamConn1 = yes
DreamConn2 = yes
DreamConn3 = yes

At start up, flycast will connect to locahost:37393 for port 0, localhost:37394 for port 1 and so on.
it will send a MDCF_GetCondition/MFID_0_Input maple message: 09 20 00 01 00 00 00 01 and wait for a reply, which is mostly ignored except to determine which expansion devices are connected to the controller.

When a game starts, flycast will forward maple messages for the VMU LCD and rumble pack to the DreamConn utility through the network socket. MDCF_BlockWrite/MFID_2_LCD for the VMU LCD and MDCF_BlockWrite and MDCF_SetCondition for the rumble pack. It doesn't expect a response in this case and won't even try to read from the socket (at least for now).

[chrisvcpp]

Great! Will start modifying the Utility app and let you know how it goes.. Also, (in case it's of any use to you) I've already modified the Utility to register each virtual XBox360 controller with :Vendor ID: 0x4457Product ID : 0x4443 Στις Δευτέρα 16 Δεκεμβρίου 2024 στις 07:15:39 μ.μ. EET, ο χρήστης flyinghead ***@***.***> έγραψε: I committed a first prototype for DreamConn+ support (dev branch) Right now, each dreamconn must be enabled in emu.cfg: [input] DreamConn0 = yes DreamConn1 = yes DreamConn2 = yes DreamConn3 = yes At start up, flycast will connect to locahost:37393 for port 0, localhost:37394 for port 1 and so on. it will send a MDCF_GetCondition/MFID_0_Input maple message: 09 20 00 01 00 00 00 01 and wait for a reply, which is mostly ignored except to determine which expansion devices are connected to the controller. When a game starts, flycast will forward maple messages for the VMU LCD and rumble pack to the DreamConn utility through the network socket. MDCF_BlockWrite/MFID_2_LCD for the VMU LCD and MDCF_BlockWrite and MDCF_SetCondition for the rumble pack. It doesn't expect a response in this case and won't even try to read from the socket (at least for now). — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[chrisvcpp]

I've made the modifications to the Utility and now ready to test :

1. Do you have a build somewhere that I can download, or do I have to build it myself?
2. One minor change I would suggest is this : instead of transmitting the Maple messages in raw bytes, it would be better if you could transmit each message as a string with line feed at the end (\r\n). This will make it easier for me to distinguish between messages and buffer them in a FIFO pipeline. The bytes can be represented in HEX with a space separator.

[flyinghead]

You can download the lastest dev build here: https://flyinghead.github.io/flycast-builds/#dev

So you basically want the message as an ASCII dump like in this C string "09 20 00 01 00 00 00 01\r\n". I assume you will use the same format for responses.

[chrisvcpp]

That's right, the messages can be in the format : "09 20 00 01 00 00 00 01\r\n"
For response, I can use any format that suits you - either the same string format, or raw bytes..
Once you have the updated build, please let me know so I can download it and start testing..