< The local multiplayer saga, ep 2The local multiplayer saga, ep 4 >
The local multiplayer saga, ep 3
Aug 16th 2022, by Arisotura
From the previous post:

However, there is still data loss in the client->host direction, which I need to investigate further.

So I've been doing exactly that. I'm not done yet, because the DS wifi is a rabbit hole, so many little details everywhere and especially in the local-multiplayer specific features.

If you have messed with wifi in melonDS before, you might have seen this message appear in the console:

wifi: !! unusual TXSLOT_CMD bits set C000

What is this about? The value for TXSLOT_CMD has two known parts. Bits 0-11 are the address of the CMD frame, and bit 15 tells whether the CMD slot is enabled. The rest is undocumented as of now.

In this situation, the game is setting bit 14, which prevents the hardware from automatically filling in the CMD frame's sequence number. This feature comes in handy if the host needs to retransmit a CMD frame for whatever reasons (for example, if some clients failed to respond). All in all, nothing too difficult to deal with.

Except implementing it in melonDS worsened the problem of client->host data loss in Pictochat. So I just ignored that feature, which made the transfers work nearly perfectly (albeit with some apparent lag). But you know our standards: that's not correct emulation, and also more likely to lead to other problems.

So I investigated the data flow. There are a few things of note in the Pictochat data flow:

* The host sends a CMD frame every 4 milliseconds. Each frame can be addressed to a maximum of 3 clients. Thus, the host needs 5 frames to poll every possible client. This is probably done to avoid monopolizing the wifi channel too much.

* The client, when receiving a CMD frame not addressed to it, will interact with the unknown hardware registers 0x244 and 0x228. Register 0x244, in this case, seems to be used to inhibit the transfer of a reply frame, which I'm not sure why they do it when no reply would be sent anyway. I don't know what register 0x228 does, I haven't observed any effects in my tests. Over all, this part doesn't seem very important.

* Most of the CMD frames the host sends are long frames, to which the clients respond with long replies. These are used to exchange messages being sent in the chat, for example. However, every once in a while, the host sends a short CMD frame, which clients normally respond with a short reply (heh). Except sometimes the client responds with a long reply instead. This seems to be the cause of the client->host comm hiccups.

While experimenting with MP replies, I (quite accidentally) found out that the hardware will refuse to send a reply frame that is too long: in this case, it behaves as if no reply frame was configured at all, and sends a default empty reply. How does it know if a given reply frame is too long? The CMD frame specifies the time window for replies, simply. It's then trivial to calculate the amount of time needed for a reply frame, based on the preamble settings, the transfer rate and the frame size.

This makes sense, and it's also a crucial detail in the situation above. When the host sends a short CMD frame, the reply time window is also short, so it definitely shouldn't be receiving a long reply.

I made a quick attempt at implementing this in melonDS, which gave imperfect but promising results. I need to implement it properly, which should hopefully solve our data loss issues.

If this does the job, what does that leave us with? There are a bunch of other fun details I found out (here), which are less important but still worth implementing. There are also some issues to iron out in the sync mechanism, and in the end I need to come up with faster IPC so this can run at acceptable speeds.

Stay tuned!
4 comments have been posted.
< The local multiplayer saga, ep 2The local multiplayer saga, ep 4 >
KyoteKy says:
Aug 16th 2022
These update posts are very nice! they are formatted in a way that is easily readable, and are fairly in-depth without being too confusing. I can't wait for the next one!

Also I'm glad someone is actively working on DS wireless emulation, I really want to help too, but I still need to learn how emulating the rest of the system works first lol. Kinda hard to find documentation on it online.
keisui says:
Aug 16th 2022
very interestingšŸ˜®
ari32 says:
Aug 17th 2022
This is the modern Da Vinci Code
mrjfilippo says:
Aug 18th 2022
Thanks for taking the time to explain some of the process!
Post a comment
Name:
DO NOT TOUCH