Multiplayer CMD/REPLY packets don't behave like on hardware #2282
Comments
|
I've just released version 1.8.0 of BlocksDS (https://github.com/blocksds/sdk/releases/tag/v1.8.0, thanks to @Arisotura for the melonDS forum WiFi notes!), which includes the new version of DSWifi and the examples. This means that now it's easier for other people to build them. This example is the cleaned-up version of what I posted in the first post, which doesn't work correctly (CMD/REPLY packets fail, data packets work): https://github.com/blocksds/sdk/tree/6a664546baa2bdfc18b213d31e2f528201f8ec97/examples/dswifi/multiplayer_packets However, funnily enough, this other example that uses CMD/REPLY packets works! https://github.com/blocksds/sdk/tree/6a664546baa2bdfc18b213d31e2f528201f8ec97/examples/dswifi/local_multiplayer |
|
would be interesting to see how the frames themselves are built -- maybe something is wrong in there. |
|
I don't think this is the reason, though, I spent quite a bit of time debugging why my frames didn't work so I compared my frames with the frames of an official game using Wireshark and the addresses and other information were the same (my issue was using the non-CF frame types, if you're curious). My guess is something to do with the timings of the counter and the status values in the TX header in the MAC RAM. |
|
oh, yeah, the frame types
that would explain it
…On Fri, Mar 7, 2025 at 2:20 AM Antonio Niño Díaz ***@***.***> wrote:
CMD:
https://github.com/blocksds/dswifi/blob/ea5b2540ae40539397c8a2794ddd2c53a754096a/source/arm9/rx_tx_queue.c#L101-L170
REPLY:
https://github.com/blocksds/dswifi/blob/ea5b2540ae40539397c8a2794ddd2c53a754096a/source/arm9/rx_tx_queue.c#L172-L240
I don't think this is the reason, though, I spent quite a bit of time
debugging why my frames didn't work so I compared my frames with the frames
of an official game using Wireshark and the addresses and other information
were the same (my issue was using the non-CF frame types, if you're
curious).
—
Reply to this email directly, view it on GitHub
<#2282 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKAI6YPRCZ5MNH7DOKYOJT2TDX6PAVCNFSM6AAAAABXZOBXDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBVGI4TQMZTGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
[image: AntonioND]*AntonioND* left a comment (melonDS-emu/melonDS#2282)
<#2282 (comment)>
CMD:
https://github.com/blocksds/dswifi/blob/ea5b2540ae40539397c8a2794ddd2c53a754096a/source/arm9/rx_tx_queue.c#L101-L170
REPLY:
https://github.com/blocksds/dswifi/blob/ea5b2540ae40539397c8a2794ddd2c53a754096a/source/arm9/rx_tx_queue.c#L172-L240
I don't think this is the reason, though, I spent quite a bit of time
debugging why my frames didn't work so I compared my frames with the frames
of an official game using Wireshark and the addresses and other information
were the same (my issue was using the non-CF frame types, if you're
curious).
—
Reply to this email directly, view it on GitHub
<#2282 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKAI6YPRCZ5MNH7DOKYOJT2TDX6PAVCNFSM6AAAAABXZOBXDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBVGI4TQMZTGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Oh, sorry, I didn't mean that this specific issue was due to the frame types, I mean that I checked the frame headers for a long time until I realized that my types were wrong, so the addresses and other details should be okay. The bug I've reported here happens even with the current version of my DSWifi library, which works well on hardware. Also, I don't think the frame headers are wrong because of the other example I've mentioned here #2282 (comment), which works fine using the same library. |
I've been working on the fork of DSWifi of BlocksDS adding local multiplayer support, and I've noticed that melonDS doesn't treat them the same way as hardware. I have created a test ROM that you can use to test the issues I mention.
mptest.zip
With this ROM, press X on one DS to enter host mode, and Y to enter client mode on the other one. Press A on the client to connect to the host. You can send raw data packets from the host with up/down, and from the client with X. Those ones are received correctly.
However, you can send CMD packets with L from the host, and they are received 4 times on the client. You can prepare REPLY packets with Y on the client, but they are never received on the host. This all works correctly on hardware (DSi and DS lite), where one CMD packet is received and the REPLY is sent to the host correctly.
Some more useful information:
To send CMD packets, W_TX_RETRYLIMIT is set to 0x0707 here https://github.com/blocksds/dswifi/blob/464e1bf1064a5c2a8fab13eff484e59f560734c2/source/arm7/tx_queue.c#L402-L408 and the transfer starts here https://github.com/blocksds/dswifi/blob/464e1bf1064a5c2a8fab13eff484e59f560734c2/source/arm7/tx_queue.c#L249-L304. I have never seen the value of W_TX_RETRYLIMIT change after starting a CMD transfer, though. Also, the process has proven to be quite delicate, so I use a slightly different formula than the one in GBATEK to set W_CMD_COUNT, which works much better for me: https://github.com/blocksds/dswifi/blob/464e1bf1064a5c2a8fab13eff484e59f560734c2/source/arm7/tx_queue.c#L281-L295 I live in a block of flats so the DS needs a lot more time to start the CMD/REPLY transfer, and sometimes it needs so much time to start it runs out of time and it fails (status 5 in the hardware TX header).
REPLY packets are prepared to be sent here: https://github.com/blocksds/dswifi/blob/464e1bf1064a5c2a8fab13eff484e59f560734c2/source/arm7/tx_queue.c#L322-L353
I also have setup a manual retry counter in the interrupt handler of "CMD packet done": https://github.com/blocksds/dswifi/blob/464e1bf1064a5c2a8fab13eff484e59f560734c2/source/arm7/interrupts.c#L73-L77 and https://github.com/blocksds/dswifi/blob/464e1bf1064a5c2a8fab13eff484e59f560734c2/source/arm7/tx_queue.c#L306-L320 where I manually decrement W_TX_RETRYLIMIT until it reaches 0.
The text was updated successfully, but these errors were encountered: