Ideas for generic handling of hardware devices

[Tails86]

@RikkiGibson and @flyinghead

I've been thinking through how to generically handle Dreamcast hardware devices like this going forward. I was thinking that if a hardware device was detected & attached to a specific port, an entry like DreamConn could show up in the drop downs under Dreamcast Devices which could be automatically selected. Otherwise, a Network Expansion Device could be selectable for slots 1 and 2. Then more generic DreamLinkController and DreamLinkPeripheral classes could be created to just follow what the hardware demands rather than having DreamLinkVmu and DreamLinkPuruPuru. This would depend on #2163 which should allow for command execution without delaying flycast emulation. There are a few gotchas in this which would need to be carefully thought through, but I wanted to start with thinking about what a good UX looks like.

[Tails86]

Here is a mock-up of what I'm thinking:

[RikkiGibson]

I'm also thinking about how to make the Flycast<->DP comms setup work on android in the future. Think for dual screen devices like the AYN Thor especially. So, I'll think through options a bit and report back.

[flyinghead]

I just realized I completely broke the DreamPotato integration on master :( I started seeing crash reports occurring in DreamConn from macOS machines and thought something was really wrong! I didn't know DreamConn was being used for something else.
Anyway, the way it's currently done is quite weird and insanely complicated.

The good news is I have DreamPotato running on my linux desktop so I can test what I'm doing. Like Rikki said, I'd like to introduce a new interface designed to communicate with external maple devices, with send and send/receive methods and other stuff (like use physical VM memory). This interface would be used by maple devices in hw/maple (mainly vmu and purupuru) and would not depend on SDL. And DreamLink would inherit from it as well. But this is still back of the envelope design at this point.

A few comments regarding my experience with DreamPotato:

• It's only listening on IPv6 loopback, not IPv4 so I couldn't connect at first. I had to change IPAddress.IPv6Loopback to 0 in MapleMessageBroker.cs:559.
• I spent some time figuring out why DreamPotato wasn't cooperating although it was connected and responsive. Until I found the Dock to Dreamcast option... I think that, either this option shouldn't exist, and it should dock as soon as a connection is open. Or it should refuse the connection if the option is not set. Otherwise it's really confusing.

[RikkiGibson]

Thanks for taking a look at it. Do you think that the crash reports you saw mentioning DreamConn on Mac reflected a real bug related to including DreamConn.cpp on non-Windows?

I have at least been able to use the Mac flycast and DreamPotato builds together successfully. (The Mac version of DreamPotato is only published in the CI builds right now.)

Anyway, the way it's currently done is quite weird and insanely complicated.

Yes, I think we can definitely do better.

It's only listening on IPv6 loopback, not IPv4 so I couldn't connect at first. I had to change IPAddress.IPv6Loopback to 0 in MapleMessageBroker.cs:559.

This is due to a wonky behavior on Windows. Listening on the IPv6 loopback address, causes the connection to get established much faster, compared to listening on the IPv4 address. https://daniel.haxx.se/blog/2024/08/14/slow-tcp-connect-on-windows/

If this is creating problems on Linux, then, maybe the DreamPotato server could listen on both the IPv4 and IPv6 addresses, and accept the first client to connect to either one of them.

it should dock as soon as a connection is open.

This sounds good. Generally at the point the connection is established you probably want to actually use the VMU with the Dreamcast.

The point of the existing dock/eject command is: user should be able to load a game onto the VMU, from the Dreamcast side, then eject the VMU without disrupting anything, beyond notifying the Dreamcast game in that moment that the VMU is no longer connected, and without reverting to using a "Flycast-managed VMU" in that slot. I felt that keeping the TCP connection open, but sending a refresh message, then reporting a different set of devices (VMU or nothing in each slot 1 and 2), was a reasonable way of accomplishing this. We can certainly revisit the details of this as part of introducing the new interface we are talking about.

Essentially the dock/eject command is supposed to mean the same thing as inserting or removing the VMU from the controller, if you were playing on a real Dreamcast. While the "Dreamcast connected over TCP" bit is more like.. is the controller connected to the console.

[flyinghead]

I believe the crash I saw was due to the call to maple_ReconnectDevices in DreamConnImp::disconnect

For the IPv4 / IPv6 issue, you should probably use IPv6Loopback only on Windows. Note that I don't know why I wouldn't connect to the IPv6 address since my machine has ipv6 working. A linux quirk perhaps...

[RikkiGibson]

I believe the crash I saw was due to the call to maple_ReconnectDevices in DreamConnImp::disconnect

Dang. IIRC, I included a workaround specific to the physical controller case for that, but, it must also be occurring for non-controller cases, simply from the DreamLinks being deleted when the emulator is shutting down.

I wonder if I am not seeing this crash when I am debugging on Windows, because I have some exception breakpoints turned off in VS. IIRC, there were a lot of segfaults when debugging while a game was running, which from poking around a bit, looked like was intentional.

I can try to send a PR, when I get a little time, to more properly address the crashing issue. i.e. simply do not call maple_ReconnectDevices, when we are in the process of shutting down, as well as restoring the removed functionality.

[flyinghead]

@Tails86, how are used the connect()/disconnect() methods in DreamPicoPortImp? Why would you want to disconnect() other than when the device is physically unplugged? Any other use case of connect/disconnect?
In the DreamConn case, it's possible that the controller is detected by SDL but the network connection fails but this is an error case that shouldn't happen. And it doesn't require the connect/disconnect methods to be public.
DreamPotato will have a lifecycle of its own and either it exists and it's connected, or it doesn't exist.

[Tails86]

I only implemented that to conform with the interface. As you guessed, there is no real need to disconnect/reconnect.

The only edge case I can think of is if the libusb device was already claimed by another application (another instance of flycast or the settings application). As a side note, that can be resolved if a polling mechanism was added to keep trying to connect if initial connect fails. I can take a look into that later.

[flyinghead]

Having an internal poll or retry mechanism could be useful for DreamConn and DreamPotato too. But I don't feel this needs to be exposed. Only the isConnected() is a nice to have to notify the user of the state of the link.
Thanks

[RikkiGibson]

The exposed connect()/disconnect() methods are used in the "Connect/Disconnect DreamLink" UI command. I think this command is useful. I think if user is troubleshooting why something is not connecting, they are restarting one or both programs, adjusting settings, retrying, etc., it is reasonable for them to have a clear/direct way of manually starting/stopping the connection.

Also, in the Load State case, we have a behavior where the physical memory is automatically disconnected, to try and restore a memory card state consistent with the original point of the save state. (I think this is actually buggy today, the state of the remote physical memory isn't fully preserved when we originally save the state. But that is a separate issue.) In my opinion, the user should also be able to "restart" the connection from UI in this case, so that they may resume using physical memory, with minimal jumping through hoops. This happens to be conveniently solved by allowing manually reconnecting from the UI, though, certainly a solution which doesn't involve disconnecting would be possible.

Separately, I definitely want the next version of the maple over TCP protocol we use, to have a heartbeat (poll) message, with a response, so that Flycast does not need to do select() tricks to detect a disconnect, and can better handle an ungraceful disconnect by timing out, etc. This may also be a good opportunity to remove the "reset message" concept, which I think is a bit kludgey/error-prone, with instead polling for whether the expansion devices have changed, which seems more similar to the real hardware anyway.

[flyinghead]

The usual way to deal with controller issues is to unplug the controller, restart flycast or both. I think it still applies for DreamConn and DreamPicoPort. In the case of DreamPotato, there's really nothing that can/should happen. Tracking load states to disable VMU writes should not be handled by disconnecting DP.
I have implemented Tails86's UI and in the worst case, you can switch back to regular VMU and back to DP to reconnect cleanly.

One thing that's bothering me is the "ascii dump" format used in the maple over TCP protocol. I'm sure Chris has his reasons to have done it this way for DreamConn but I think just sending the binary maple data over the wire would make more sense. That would probably help with getting socket status and errors. We can design our own custom maple messages if needed, but having unsolicited messages being sent from connected devices is a major change to the maple protocol if I'm not mistaken. We could have a ping request/response that flycast would send regularly to check the connection status.

[RikkiGibson]

In the case of DreamPotato, there's really nothing that can/should happen.

I wasn't sure what you meant by this. I will say, I am concerned about scenarios like:

• DP is launched after the flycast game is started.
• DP is simply closed and reopened.

For the controller cases, it looks like flycast handles an event when the controller is physically attached to the system, and it can just make a new specialized controller object for the DPP/DConn cases, which set things back up at the right moment.

Basically, the "recovery" case for controllers, asks user to insert/remove something from the USB port, turn Bluetooth off/on, etc. DP handles that case today by having the user pause and click a button in the main UI, which is only present when the general setting to use this connectivity is enabled.

It's quite possible that all interesting cases can be handled gracefully, without exposing specific disconnect()/reconnect() methods on the base DreamLink. I'm definitely open to that.

Separately, I agree that we shouldn't need to fully reconnect the DreamLink in order to switch back to physical memory. That is just the only way I think we have to do it at the moment.

For context, I need to reattach physical memory somewhat frequently when I use flycast normally. I load a state, but I would still like to use the external memory card that I was using already. I know that some games have disruptive behavior when a memory card is suddenly removed and inserted, which is really unfortunate, because I wish this step could be very streamlined.

One thing that's bothering me is the "ascii dump" format used in the maple over TCP protocol.

Definitely agree with everything you are saying here.

It sounds like custom maple messages, will let us define whatever we need, in terms of new message type codes, new payloads with whatever data we find necessary, etc. For example, I imagine that just a generic error message type, which lets us pack in a message as a string, that the receiver can just log, may be useful to define up-front.

[flyinghead]

I pushed the current state of my work to the dreamlink branch.
I introduce a new MapleLink interface, which is used by maple_device's to communicate with linked devices. It also maintains a registry of linked devices indexed by bus/port. DreamPotato implements this interface and its lifecycle is controlled by static methods called at start up and and when the user changes the Dreamcast devices configuration.
The base maple_sega_vmu and maple_sega_purupuru now look up the linked device for their location and sends the current maple message to it. So there's no need to use specialized devices to do this anymore in the common case (no VMU storage).
When the "Use Physical VMU Storage" is enabled however, we use a MapleLinkVmu in place of the regular one (previously known as DreamLinkVmu).
DreamLink extends the MapleLink interface and shares the same registry. I moved everything gamepad-related to new DreamPicoPortGamepad and DreamConnGamepad classes, so that DreamPicoPort and DreamConn concentrate on the link aspect. And everything specific to DreamPicoPort was removed from DreamLink.

I was able to test DreamPotato and DreamConn but unfortunately I can't test DreamPicoPort, so it's likely that the latter is seriously broken. Hopefully @Tails86 can help me put it back on track.

[Tails86]

Ah ok. I was assuming that entry should be saved, but connection of that is a manual process, so I can see why that shouldn't be saved.

[Tails86]

I just noticed that the write thread was removed for writing to VMU. That was there to prevent the game from stuttering during saves and to ensure timing between writes were appropriate or else write may fail without the game detecting. I'll need to add Seaman to my tests for this because its initial save process is the most difficult over 64 kB of data. That is currently consistently failing for me.

[flyinghead]

I thought I removed it from DreamPotato only, but not DreamPicoPort.
I didn't really understand why you'd need a write thread for DreamPotato since you need to return a response to the game after a write. And there's no exotic hardware involved in this case 😄

[flyinghead]

The previous DreamLinkVmu implementation was relying on MDCF_GetLastError when writing to the VMU iirc. This can be added back to MapleLinkVmu if needed. We'd need some default implementation in BaseMapleLink or DreamPotato that would return the expected MDRS_DeviceReply. Then you can do fancy things in DreamPicoPort.

[Tails86]

I missed the fact that MDCF_GetLastError wasn't be handled as well. That would explain the oddities I was seeing today. The VMU storage uses that message to sorta "commit" a page of data on flash. I can't say I understand what exactly is going on, but the data doesn't persist without this.

I can submit a quick patch PR for this soon. I'm currently poking around with making a more generic device which generically links to hardware, so I don't think this patch needs to be super polished.

[flyinghead]

I've been thinking about saved states mixed with storage-enabled linked VMUs.

I think saving a state should be disabled when VMU storage is enabled. A save state is supposed to save the entire state of the machine, including the memory of all connected VMUs, which isn't possible when the memory is remote.

When loading a state however, I'm not sure of the best approach.
One way is to disable storage on the linked device and load the state data. The game won't notice any maple device change and will use a regular locally-saved vmu from then on. Unfortunately it's a bit more complex to implement but nothing major.
The alternative is to force a reconnect of the linked VMU, ignoring the loaded state data. The game will notice the VMU change and may display a message. But the linked VMU continues to be used and storage can stay enabled.

[Tails86]

Disconnection from physical memory is currently being done on state load here: https://github.com/flyinghead/flycast/blob/master/core/hw/maple/maple_devs.cpp#L2609

[Tails86]

But yeah, there is a bit of weirdness with this implementation since it can overwrite the memory stored on the file system with whatever was read from physical
Nevermind that comment - I was mistaken. It doesn't use local storage.

[Tails86]

God damn, I really need to fully parse things before I comment. Yes, that would overwrite VMU data on the local system since that flag would be forced to false: https://github.com/flyinghead/flycast/blob/master/core/hw/maple/maple_devs.cpp#L2191

[flyinghead]

Well, this code will be gone anyway.
What would be your preference: force reconnect of the currently linked VMU and keep storage enabled, or switch to a regular emulated VMU and disable physical VMU storage?

[Tails86]

Eventually, I would like to allow usage of the same physical storage only if the read memory region matches what is loaded (there are markers which keep track of what sections of data is synced with physical). This would at least allow for someone who is just trying to get past a hard point of a game, before a save point. Otherwise, swap to emulated storage.

If that sounds too complex for this round of development, just disable loading state while physical storage is used. That would force the user to go and uncheck that checkbox themselves.