Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Harden serial comm interface #1847

Merged
merged 26 commits into from
Feb 16, 2025

Conversation

Tails86
Copy link
Contributor

@Tails86 Tails86 commented Feb 14, 2025

This PR is fully compatible with DreamPort v0.999 and is compatible with older versions of DreamPort in host-1p mode.

  1. I found an issue with the DreamConn controller not being deleted when unplugged and traced it to the shared_ptr held within maple_devs.cpp, so I created tearDownDreamConnDevices()
    • I was having trouble putting the right delete calls in there and eventually just switched MapleDevices to use smart_ptr
  2. Renamed DreamcastControllerUsbPico to DreamPort
  3. A single serial object is used for DreamPort devices. This still means that only 1 device is supported at a time, but now there is support for the host-4p mode which can communicate with 4 controllers at once.

@kosekmi helped me to test these changes. He reports they work on all OS, but we have a few minor bugs to work out in the future.

  • MacOS and Linux: When disconnecting DreamPort during a game, the reconnect ends in "Operation timed out". Can only be solved by restarting Flycast
  • Changing the bus number of a DreamPort device during gameplay does not change over the communication (because nothing is being done to communicate that with maple_devs.cpp)

There are also a few things I'd like to clean up with future PRs:

  • I think it makes sense for the current "DreamConn" to be a virtual base class and do away with TYPE_DREAMCONN and TYPE_DREAMPORT macros
  • I have some issues wrapping my head around DreamConnVmu and DreamConnPurupuru - the way it's swapping out what was already there. Seems like something should be injected into maple_cfg to allow the controller to dictate what gets created, but I don't feel confident with this code yet to say with much conviction.
  • The _unique_id of the SDLGamepad can be adjusted to serial and known letter of a DreamPort device to overcome the weird randomness of Windows
  • I want to continue working toward supporting multiple separate DreamPort devices

Thank you for allowing us to contribute to this project. It has been a great experience, and I love this emulator now 😄

@flyinghead flyinghead merged commit 4e74619 into flyinghead:dev Feb 16, 2025
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants