Inspired by this Lobsters thread, and some of the great comments within it, I would like to ask if anybody is doing some hobby programming this weekend?

  • mlg@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    ·
    1 day ago

    I’m messing with making a kernel softmac driver that can handle Nintendo specific 802.11 frames so that MelonDS can connect to a real DS or to another device using the native Nintendo wirelesss protocol.

    Lot’s of interesting reading and packet capture fun with Wireshark has given me an idea of where to start, but the tricky part is that the DS needs less than 20us of round trip latency for it to work, which is insanely low. Otherwise the connection is considered interrupted and gets dropped.

    afaik, the only part that “verifies” the latency are ACK frames which the DS expects a return for every frame transmitted, so it should in theory be possible to just make a small driver that generates ACK frames at kernel priority, and forwards the rest of the frame to MelonDS for actual game handling.

    I’m hoping it turns out that easy but the MelonDS forums have a long ass thread about how much of a PITA the DS wireless multiplayer timing synchronization requirements are.

    • xianjam@programming.dev
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 day ago

      Wow, this would be quite cool. When DS emulators were new, I wanted this to be a thing so bad.

      Unrelated (and not what I’m doing this weekend), but I’ve always been interested in reversed-engineering the DS / DSi firmware drivers that connects to WiFi to attempt to backport the 802.11b driver to WEP-only DS games.

    • Maddier1993@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      1 day ago

      Ooh, It does sound interesting. My wild conspiracy is that Nintendo has made hardware offloaded functions that run with sub-microsecond latencies so this 20 us looks more like blocking non-DS hardware from communicating with the DS.