Serial comm update

[Tails86]

• Did some refactoring to encapsulate the controller connection (was necessary to perform the following changes without making a mess)
• Added a thread for serial communication to DreamcastControllerUSB
• Ensure the read buffer is empty before writing
• Added read and write timeouts to the serial communications
• Fixed bug: asio::buffer() references the string given to it, and the string given to it was potentially going out of context before the asynchronous write operation completed
• Removed crc value from controller mapping
  • I'm getting a different crc on my machine. This may be because Windows is caching old values of some strings, but I don't think this check is really necessary anyway since matching the VID and PID is enough

I only did testing on Windows. @kosekmi do you mind checking on Linux and Mac?

[Tails86]

It turns out this worked when built locally, but this is problematic when built by the github runner. I'm not ready for this to be reviewed yet.

Never mind. This seems to be the same weirdness I've experienced in the past where the DreamConn doesn't seem to be created until after the configuration file is fully setup, and then flycast is restarted. I wasn't experiencing this on my local build because I wasn't deleting the config files before rerunning tests. I'll dig into why that is later.

Also, I think I'd like to argue for a separate thread to handle the serial context. There really isn't any guarantee that data will be sent on async_wrie until the context is run. With what's in there, that may not happen until the next write. Are there any restrictions this project makes toward spinning up another thread?

[flyinghead]

No problem adding a new thread to handle serial communication.

[Tails86]

Sorry, I had to force push because I somehow committed submodule updates, and it was getting too frustrating to try and roll them back. I reset to dev and reapplied the changes. Changes from #1818 are integrated. @kosekmi this is ready to be tested on Mac please

[kosekmi]

@Tails86 Verified on MacOS 15.2, Ubuntu 20.04, Windows 11 23h2

[Tails86]

@flyinghead this should be good to go then

[flyinghead]

Hey guys, somewhat unrelated but I'm looking for the actual maple bus speed, so I can set the maple DMA timer correctly in Flycast. Some games are very sensitive to this.
So I read that the theoretical max speed is 2 Mbps, but the actual speed is around 1 Mbps. Looking at the logic analyzer traces on your github, I find that it's more like 370 kpbs since it sends data in 64-bit "trains" with quite some wait in between. Also the console might be sending data faster than connected devices respond?
What's your experience on this?

[Tails86]

Hey guys, somewhat unrelated but I'm looking for the actual maple bus speed, so I can set the maple DMA timer correctly in Flycast. Some games are very sensitive to this. So I read that the theoretical max speed is 2 Mbps, but the actual speed is around 1 Mbps. Looking at the logic analyzer traces on your github, I find that it's more like 370 kpbs since it sends data in 64-bit "trains" with quite some wait in between. Also the console might be sending data faster than connected devices respond? What's your experience on this?

I came up with these maximum estimates based on the timing I was seeing.
https://dreamcast.wiki/Maple_bus

• The Dreamcast host transmits each phase at about 160 nanoseconds
  • This works out to be about 2 mbps raw data transfer speed
• Dreamcast controllers and other peripheral devices usually transmit a little slower at about 250 nanoseconds per phase and sometimes with about 110 to 130 microsecond delays between each 4-word chunk after the first frame word
  • This works out to between about 0.5 and 1.3 mbps raw data transfer speed

If I recall correctly, I generally noticed that communication happens at 60 Hz (I assume it would be 50 Hz for 50 Hz systems though). It always polls the controller at that frequency, and communication to the VMU would happen at that frequency too. I'll parse through some of the data I have saved in a few hours.

[Tails86]

But I guess with that data, you could roll with 0.5 mbps since I assume you're tied to the game's driver anyway for the frequency in which data is requested from the device. I had computed 1.3 mbps as an upper end because I didn't always see that 64-bit train delay for some things the controller was communicating. I think that gap was mainly caused by memory access delay.

[Tails86]

Oh, but I did create my client-side driver without that gap, and I didn't see any issues from the games I played on a real Dreamcast. What games are being touchy with that?

[flyinghead]

Apparently I was off by a factor of 2 since it's 128-bit trains (4 words), not 64. So that translates to a speed of 740 Kb/s, presumably from a VMU, which is in line with your findings.
Games that are sensitive to maple speed are:
Power Drift (Yu Suzuki Game Works Volume 1): This game wants a very high maple speed (2 Mb/s) but it's probably due to some other emulation issue.
Silent Scope: will fail to load the VMU at boot if maple speed is too high.
D+Vine: A and B button presses not detected in some cases with one controller if speed too high.

[Tails86]

Apparently I was off by a factor of 2 since it's 128-bit trains (4 words), not 64. So that translates to a speed of 740 Kb/s, presumably from a VMU, which is in line with your findings. Games that are sensitive to maple speed are: Power Drift (Yu Suzuki Game Works Volume 1): This game wants a very high maple speed (2 Mb/s) but it's probably due to some other emulation issue. Silent Scope: will fail to load the VMU at boot if maple speed is too high. D+Vine: A and B button presses not detected in some cases with one controller if speed too high.

Yep, you're right. I was also just thinking 16 bit words for some reason. I think I computed that lower ~0.5 mbps from 128 bits / ((250 ns * 3 phases * 128 bits) + 130 microseconds) = 566371 bits/sec. I'm going to have to try those games with my client-side driver now 😆 Thanks for that