Hmm.Ī couple hardware tests later, this theory is confirmed: if the transceiver is turned off while transmitting or receiving a frame, it will first finish that operation before actually turning off. However, the game had a loop waiting on some status registers after writing to W_POWERFORCE, which implied that the shutdown operation might not always be instant. But, that's the thing, we thought that operation was instant.
#Super mario 64 ds rom non.7z.com code#
The code uses register W_POWERFORCE to turn off the wifi transceiver. The game code may regularly decide to stop and restart the wifi hardware to reset some of its state, and I found out that sometimes that would happen while a frame was being received, which caused a bunch of problems in melonDS. In this case, it was related to the power-down registers. Turns out Nintendo's wifi code does quite a few weird things during a multiplayer connection, and we need to deal with these to keep a stable connection. Remember the issue I mentioned in the last post? I fixed that since then. Guess what I found out?ĥ comments (last by J.J.) | Post a comment What if, when receiving a beacon frame with the right BSSID, the DS automatically sets its USCOUNT register to the beacon's timestamp?īut you'd think that sounds far-fetched? I thought so too. Yesterday, as I went to bed, I had an idea. So I couldn't really see what that was supposed to achieve. Here, the value written to USCOMPARE was based off the beacon's timestamp, which was basically the host's USCOUNT register, which was obviously different than the client's. I had observed that it blocks BEACON_COUNT from triggering IRQ14 until USCOUNT matches USCOMPARE, effectively ensuring that the next IRQ14 will be triggered by USCOMPARE.īut that still didn't quite make sense. All fine and dandy.īack then, I had done hardware tests to figure out what bit0 in USCOMPARE does, given it's a special write-only bit. The former triggers IRQ14 every time the BEACON_COUNT timer reaches zero, the latter triggers it when USCOUNT matches USCOMPARE. In the DS wifi module, there are two ways of triggering IRQ14: BEACON_COUNT and USCOMPARE. Basically, when they're connected to a host and receiving beacons from it, games do that weird little dance where they take the beacon's timestamp value, add some offset to it, and write that to USCOMPARE, with bit0 set.Ī bit of background. I thought about bit0 in USCOMPARE, again. But I also didn't really have an idea what could be causing it or where to begin looking. In the previous post I said the slowdown problems in multiplayer games were fixed, but actually, they weren't.
![super mario 64 ds rom non.7z.com super mario 64 ds rom non.7z.com](https://i.ytimg.com/vi/bGIZ6VUQC4g/maxresdefault.jpg)
![super mario 64 ds rom non.7z.com super mario 64 ds rom non.7z.com](https://www.gamulator.com/img/roms/super-mario-64-ds-cover.jpg)
If you're running into trouble: Howto/FAQ (WIP) Wifi: local multiplayer, online connectivity.
![super mario 64 ds rom non.7z.com super mario 64 ds rom non.7z.com](https://www.romulation.org/media/img/screenshots/NDS/22/s756a52397f8da7609111941b345125dd.jpg)
Various display position/sizing/rotation modes.Nearly complete core (CPU, video, audio.While it is still a work in progress, it has a pretty solid set of features: MelonDS aims at providing fast and accurate Nintendo DS emulation.