Home | Downloads | Screenshots | Forums | Source code | RSS | Donate

Register | Log in

< Quick newsNews of the great refactoring >

Wifi fixes: channels and power Apr 10th 2024, by Arisotura

Long time no update. Sorry about that. I'm getting better, though. Anyway, I recently felt like getting back into melonDS dev. I figured that trying to fix some wifi bugs could help me build up momentum and motivation I'll need to finish the big refactor. The point of the big refactor is to lay groundwork for turning netplay from a clunky proof of concept into an actual finished product. But netplay or LAN won't be very useful if the underlying wifi implementation is malfunctioning... The first bug I looked at was that weird bug in Meteos: when starting a download play game, if you're using a DSPhat firmware, you will instantly get a connection error, but everything will work fine if you're using a DSLite firmware. So I researched the bug, but the outcome was a bit disappointing. Long story short, it's a timing issue. The ARM9 starts wifi initialization and allows it about 44 milliseconds before deciding it has failed. The wifi initialization doesn't actually take this long, but on a DSPhat (or any console equipped with a type 2 RF module) the RF initialization includes an extra delay of 40 milliseconds. Changing the ARM9 cache timings fixes the bug. Cache emulation is something we're looking at for the next release, as it may fix quite a bunch of these timing issues -- there have been preliminary tests and it's looking promising. But in the meantime, that particular bug goes beyond my scope. No biggie, we have a plethora of other problematic games. In particular, I had gen4 Pokémon games in mind. In these games, players can meet into the Union room where they can decide to chat, battle, etc... but the Union room was said to be malfunctioning in melonDS if more than two players were in it. I first ran into some 'easy' bugs. For example, melonDS would not generate different MAC addresses for extra instances when using an external firmware. I also had to obtain different savefiles -- the game will get confused if multiple players using the same save file try to connect. Past that, I figured that the issue might be caused by the lack of wifi channel support in melonDS. You probably know about wifi channels: the 802.11 standard specifies a set of 14 channels, which correspond to specific frequencies. The tricky part is that on the DS, you don't have an explicit, clear register to tell it to "tune in to channel 6". Tuning to a channel is done by changing a bunch of RF and BB registers with values that are stored in the console firmware. Some of these values seem consistent across units, some of them are different. The way they are structured also depends on the RF type used in the console. So the way melonDS dealt with this was to... just ignore channels entirely. We're just receiving everything at all times. Which I figured might cause problems... I decided to base myself on RF registers to detect the current channel, as it seemed to be the most reliable way. I was thinking of how to implement it all. I eventually thought, we already read the firmware to determine which RF type to emulate, might as well pull the required register indices and values for each channel from there. Then, whenever the corresponding RF registers are modified, we check them against the values from the firmware to determine which channel we are tuning in to. Next it's a simple matter of adding the current channel number to the frames that we send out. When receiving frames, we check their channel number against our current channel, and discard them if they're on the wrong channel. Simple. In the end, I don't think the lack of channel support was the problem, but implementing them gave me useful insight. To make sure I wasn't breaking anything basic, I tested the WFC config utility in Mario Kart, and started an AP scan. It did not find melonAP. Oops. The AP scan basically cycles through all 14 channels, sending a bunch of probe requests, listening for responses, then moving to the next channel, and so on. When I looked at my logs, I saw that it was only actually sending frames on channel 1, and melonAP is set to channel 6, so you guess how that goes. Upon closer inspection, it was failing to send frames on channels 2 and up because it was stuck in power-down mode. When changing the channel, there is a sequence to power down the transceiver, change the channel, then power it back up. In this case, melonDS wasn't recognizing the instruction to turn the power back on. The power system of the wifi hardware is kind of complex and there is a bunch of different registers affecting it, and the support in melonDS was incomplete. The issues other games had when trying to connect more than 2 players came from the same problem. Transceiver staying powered down for too long, causing starvation -- when trying to listen to beacons, the game would just see nothing for extended periods of time, then be receiving a ton of frames at once, which doesn't bode well. In some cases this would happen while other instances were already engaging in a MP data exchange, and the game would be completely overwhelmed from receiving an absolute ton of MP frames at once. You guess how that goes. The wifi power system is a bit complex, I've done a bunch of research but there's a lot to be said and there are still some unknowns. But I have a better view of how it all works and how the various registers interact. I am still reworking the implementation in melonDS. It's unfinished, but the results so far are promising. Mario & Sonic at the Olympic Games, one of the problematic games. Now connecting 4 players, smooth as butter. I may write another post about the details of the wifi power system when I'm done with the implementation. Stay tuned!

12 comments have been posted.

< Quick newsNews of the great refactoring >

Post a comment
Name:

DO NOT TOUCH