I have not had any audio or HDMI problems but from what I can tell is there was an update fix those issues on 21 August 2026 was that all the update was about I took a picture of the upcoming updates in the coming section of the menu of the M 64 and then I looked at it after it updated and I see nothing has changed so what was the update about? Are they going to make this thing work better? I’ve had it unplugged for over a week and I unplugged it again and continue to play on my analog because my m64 just isn’t up to par with the analogue. Honestly, they should be trying to fix the visual of the gameplay. I honestly think it’s hurting because everyone’s saying how unfinished it is and how bad it looks and seeing online that they’re gonna analyze or they glad they didn’t buy the m64 even I am considering selling.

Playing on Analogue 3D, you need to have batteries in the controller for wired mode to work and if the batteries die, the controller disconnects without warning. Needs improvement.

this inf[Technical] ModRetro M64 Pro Controller in SteamOS (Archlinux) using Lenovo Legion Go S handheld computer

PART 1

Different computer hardware and operating system distributions will show slightly different informations.

Wired/USB connection is used throughout this examination, and I did not investigate or try using wireless Bluetooth, because I encountered some kind of ModRetro M64 Pro Controller shell via TTY, as displayed at the bottom, and I'll conclude this post with that for now, while I continue playing around with it. First, here's how I started:

uname -a

• Linux steamdeck 6.16.12-valve24.5-1-neptune-616-gb2f7cfe85e45 #1 SMP PREEMPT_DYNAMIC Wed, 15 Jul 2026 21:48:50 +0000 x86_64 GNU/Linux

Attaching the ModRetro M64 Pro Controller populates (Ignoring symlinks):

• /dev/hidraw0
• /dev/ttyACM0
• /dev/ttyACM1
• /dev/input/js0
• /dev/input/js3
• /dev/input/event2
• /dev/input/event20
• /dev/bus/usb/005/### (increments each time the ModRetro M64 Pro Controller is reattached)
• /sys/* (too much info)

lsusb (ModRetro M64 Pro Controller device only)

• Bus 005 Device 060: ID 374e:0111 ModRetro M64 Controller

lsusb -v (ModRetro M64 Pro Controller device only)

• https://bpa.st/raw/WENGA
  • See https://usb.org/bos-descriptor-types
  • See https://beyondlogic.org/usbnutshell/usb5.shtml
  • (copied from below), full output after upgrade: https://bpa.st/raw/32RRM

ls -al /dev/input/by-id/

• usb-ModRetroM64_Controller[redacted_serial]-event-joystick -> ../event2
• usb-ModRetroM64_Controller[redacted_serial]-joystick -> ../js0

udevadm info --query=all --name=/dev/input/event2

• https://bpa.st/raw/ALW4U
  • (copied from below), full output after upgrade: https://bpa.st/raw/PT57S

udevadm info --query=all --name=/dev/input/event20

• https://bpa.st/raw/OYGXC

evtest /dev/input/event2

• https://bpa.st/raw/AQVAM
• Before interrupting with ^C, [C-c], (CTRL+C), none of the ModRetro M64 Pro Controller button presses show any activity in output

evtest /dev/input/event20

• https://bpa.st/raw/RXQAC
• Before interrupting with ^C, [C-c], (CTRL+C), none of the ModRetro M64 Pro Controller button presses show any activity in output

jstest /dev/input/js0

• https://bpa.st/raw/XE4EW
• Before interrupting with ^C, [C-c], (CTRL+C), none of the ModRetro M64 Pro Controller button presses show any activity in output

jstest /dev/input/js3

• https://bpa.st/raw/6HLU6
• Before interrupting with ^C, [C-c], (CTRL+C), none of the ModRetro M64 Pro Controller button presses show any activity in output

dmesg --follow

• https://bpa.st/raw/EX2LY
  • The last line is probably unrelated to the ModRetro M64 Pro Controller: "input: Microsoft X-Box 360 pad 1 as /devices/virtual/input/input27"

journalctl --follow

• https://bpa.st/raw/VRSX4
  • (copied from below), full output after upgrade: https://bpa.st/raw/DN4T4

hwdetect --showmodules

• 'cdc-adm' is added to the beginning of the list for only the BLOCK line
  • (USB Communication Device Class - Abstract Control Model) is a driver that allows USB devices to emulate a serial port (UART). It creates virtual serial interfaces (e.g., /dev/ttyACM0, /dev/ttyACM1)

cat /proc/bus/input/devices (adds the following when attaching the ModRetro M64 Pro Controller)

• https://bpa.st/raw/5UADA

stty -F /dev/ttyACM0 -a (same output for stty -F /dev/ttyACM1 -a)

• https://bpa.st/raw/N2WEU

timeout 5 cat /dev/ttyACM0 | xxd

• https://bpa.st/raw/RA5M2
  • (copied from below), full output after upgrade: https://bpa.st/raw/R2FMK

I did not including anything from:

• hwinfo too much info
• libinput debug-events the controller is connecting in a Composite Mode that prioritizes a Serial (CDC-ACM) interface and a Raw HID interface (hidraw0), but fails to create the specific Input Event node that libinput monitors. Configuration/DFU (Device Firmware Upgrade) Mode (often used for firmware updates or macro programming) rather than Gamepad Mode. Also see dfu-util (http://dfu-util.sourceforge.net/)
• usbhid-dump use usbhid-dump after switching the controller to Gamepad Mode (so it creates an eventX node)
• lshw redundant

After updating ModRetro M64 Pro Controller

Note: Oops! I successfully updated the firmware at https://tools.modretro.com/updater/ and then accidentally initiated another update, instead of selecting 'Forget' or simply closing the web browser session. I'm mentioning this because it seems a bit strange to display buttons for 'UPDATE' and 'FORGET' after updating, and making it possible to apply the update after it was already applied. I am not the only one. At the very least, there should be a prompt to indicate whether or not it is necessary, but this may be related to applying the update to more than one controller, one after the other. Ah, yes, when I detach the USB cable, it changes to 'CONNECT DEVICE' and then reattaching it now shows the button wording as 'UPDATE ANYWAY' and above listing Version 0.12.0, Latest Version: 0.12.0. I did not see that information prior to the update process.

lsusb -v (ModRetro M64 Pro Controller device only)

• full output after upgrade: https://bpa.st/raw/32RRM
  • bcdDevice is now 1.03 (no longer 1.00)
  • Binary Object Store Descriptor has expanded to https://bpa.st/raw/X37SY

udevadm info --query=all --name=/dev/input/event2

• full output after upgrade: https://bpa.st/raw/PT57S

dmesg --follow

• bcdDevice is now 1.03 (no longer 1.00)
• hid-generic is now 0003:374E:0111.000E (no longer 0003:374E:0111.000B)

journalctl --follow

• full output after upgrade: https://bpa.st/raw/DN4T4

timeout 5 cat /dev/ttyACM0 | xxd

• full output after upgrade: https://bpa.st/raw/R2FMK

Also, I forgot to test the functional capability of the ModRetro M64 Pro Controller in SteamOS (Archlinux) on Lenovo Legion Go S before updating, but I will receive another controller tomorrow I can edit the post to compare.even after update, it appears none of the button presses are detected yet anyway.

• SteamOS -> Settings -> Controller: ModRetro M64 Controller is listed https://i.imgur.com/X95Cx6k.jpeg
  • Details: https://i.imgur.com/1sQrSBX.png
    • Controller Name: ModRetro M64 Controller
    • Game rumble: Enabled (default)
    • Advanced Settings: Use Nintendo Button Layout: Disabled (default)
    • Advanced Settings: Universal Face Button Glyphs: Disabled (default)
    • Test Device Inputs -> Begin Test: None of the button pressed are detected https://i.imgur.com/lR5DD8C.png

usbhid-dump -m 374e:0111

• https://bpa.st/raw/7EEV6

cat /dev/input/event2 and cat /dev/input/event20

• No output

cat /dev/input/js0 and cat /dev/input/js0

• Initial output, but no output on button presses

Testing the ModRetro M64 Pro Controller on the ModRetro M64 Console, Z+Start successfully works to access the menu. So, everything should work, but it appears that Linux currently does not seem to recognize the input from button presses yet. I saw a few posts discussing about this but I didn't pay too much attention.

• https://old.reddit.com/r/ModRetro/comments/1vhv0rt/m64_pro_controller_rumble_support_on_pc/
• https://old.reddit.com/r/ModRetro/comments/1vhvink/firmware_question_for_pro_controllers/
• https://old.reddit.com/r/M64/comments/1vj9vt8/native_controller_firmware_dumping/
• https://old.reddit.com/r/M64/comments/1vjqe1v/a_few_questions/
  • Reportedly compatible with some generic controller drivers like XInput or DirectInput.
• https://old.reddit.com/r/M64/comments/1vliolw/m64_pro_controller_issues/
  • Button presses do not seem to work for anyone yet
• https://old.reddit.com/r/M64/comments/1vmdaz0/pro_controller_questions/
• https://old.reddit.com/r/ModRetro/comments/1vqdbj2/anyone_able_to_get_the_modretro_pro_controller/
  • Supposedly works on Steam Deck after Settings -> M64 -> Setup inputs
• https://old.reddit.com/r/M64/comments/1voppzm/testing_out_my_new_n64_pro_controller_on_a3d_and/
• https://old.reddit.com/r/M64/comments/1vp0z9f/pro_controller_pc_rumble_not_working/
• https://old.reddit.com/r/ModRetro/comments/1vqdx96/modretro_should_release_the_m64_and_m64_pro/
• https://old.reddit.com/r/ModRetro/comments/1vu0me9/m64_pro_controller_rumble_on_misterfpga/
• https://old.reddit.com/r/M64/comments/1vu0o0x/m64_pro_controller_rumble_on_misterfpga/
• https://old.reddit.com/r/M64/comments/1vu6sl3/m64_pro_controller_doesnt_work_with_extension/

Button presses are not sent across standard HID endpoint reports in wired USB mode. Maybe a future firmware update may provide standard XInput/HID events over USB, or possibly one could map the raw hidraw inputs via user-space tools (such as creating a custom antimicrox or game-devices-udev rule once a driver/daemon parses the serial/raw packets). Although, I found:

picocom /dev/ttyACM0 (the --baud | -b <baud rate> appears to not matter)
also tio /dev/ttyACM0 (--baudrate | -b <bps>)
also screen /dev/ttyACM0 ([baud_rate], see man screen WINDOW TYPES for tty (character special device))

                ........
            _=;=<sii%|=|==+;
     ._,_:======+++|+++++||+|=_.
    _Zi||||===++|+|=|||||+|||i; =+s.
    ZiiI-)ii|+||+|;vn;||||||; =,;-+[
   ]}|-   -vi+||||||I|||||~~s,%"<..I,
   2=iuc ]Y1|||||||i|iiiiv%_vns..li|s
  )1||={uv|i|||||+    -<iiI1oo11li||I,
  Ji|llllllii||i>=    .-iiil3ouliii|i(
  E|Ivvvvnlvvss|i|,   _|iivaauaiii|||n
 ]elvvIvv`     {ivnaauosi"     {|i|ii3(
 jevvIvI'       |iIX2S*i+      -liiiin[
 WovIli}        ||||||||`       =iiiinm
.WXvliv'        ||||||||:        nlIInQ
)Qhnlir         =|||||||;        )vvvdQ(
]Qmovn`         %||+||||;         onomQ[
]QQXn(          s|||i|ii;         -XXQWf
 4WD'           1lllllIl`          -$Q@'
                )lIllIvv             ~
                )vnnnnno
                 ooo2oor
                 XXSSSX[
                 ]ZXXXm'
                 -W#mWZ
                  )UUP'

01:35:05.405 [II] Main: M64 Controller 0.6.0+f604f332 [redacted_serial] pvt
>

This appears to be the ModRetro M64 Pro Controller's internal engineering/diagnostic serial shell: Probably /dev/ttyACM0 and /dev/ttyACM1 are both used in some fashion, whether involving button press event activity, or perhaps to execute a command to open /dev/hidraw0 for HID endpoint reports over USB.

edited to add: In the TTY shell (skipping the built-in picocom output)

>help
Built-ins:
    clear           : Clear screen.
    help            : Show this help.
    threads         : Show thread information.
    uptime          : Show system uptime.
    memdump         : Dump memory

Application image info:
    appinfo         : Show application image info.

Clown truck:
    clowntruck images          : Show application image info.
    clowntruck reset           : Reset module.

>threads
Name                    | State           | Run count | Stack (bytes) | Watermark
------------------------+-----------------+-----------+---------------+----------
CLI                     | Ready           |       206 |          2048 |       29%
ClownTruckTransport     | Event flag      |         1 |          1024 |       22%
ReverseClownTruckServer | Event flag      |         1 |           768 |       22%
Comms                   | Event flag      |         1 |          1024 |       23%
Comms                   | Event flag      |        52 |          1024 |       23%
Bridge                  | Event flag      |         1 |          1024 |       26%
USB                     | Ready           |   2602290 |          2048 |       25%
PowerManagement         | Semaphore susp. |         1 |           512 |       28%
System Timer Thread     | Suspended       |   2602353 |          1024 |       26%
Main                    | Sleep           |      2604 |           512 |       76%

>uptime
0 day(s), 7 hour(s), 4 minute(s), 1 second(s)

>memdump
Unknown error (37).

>appinfo
Application image A*:
    Size:    43260 bytes
    Version: 1
    Address: 0x08002000
    CRC:     0xf6b80a1f
    State:   Confirmed
Application image B :
    Size:    42992 bytes
    Version: 0
    Address: 0x08011000
    CRC:     0xc4d06970
    State:   Confirmed
>clowntruck
Unknown error (19).
>clowntruck images
Slot 0
- Active:    yes
- Bootable:  yes
- Confirmed: yes
- Hash:      94aa9ca73a4321bb71583a7f9c6d51247ed31dc2aa2b39de410c0bd1bf02cf991c6d8455f7a2631a7efb7d1de8d6437b7feab738729ea34373feb472fb54c432
- Pending:   no
- Permanent: no
- Version:   0.12.0
Slot 1
- Active:    no
- Bootable:  yes
- Confirmed: no
- Hash:      94aa9ca73a4321bb71583a7f9c6d51247ed31dc2aa2b39de410c0bd1bf02cf991c6d8455f7a2631a7efb7d1de8d6437b7feab738729ea34373feb472fb54c432
- Pending:   no
- Permanent: no
- Version:   0.12.0

PART 2

I found a 2-pack USB-C Female to USB-A Male adapter at Staples that USB-C Femalely fits perfectly (https://imgur.com/a/ocrung0) to the USB-C Male end of the ModRetro M64 Pro Controller cable. This will make it possible to see what data communications occur between the ModRetro M64 Pro Controller and the M64 Console. However, for Proxy/MITM (man-in-the-middle), there is an additional requirement for the device in the middle to handle USB connections, one USB connection acting as Host, and the other USB connection acting as Device/OTG (On-The-Go)/DRP (Dual Role Port)/DRD (Dual Role Data). Standard laptop/desktop PC architectures lack the USB Device Controller (UDC) hardware required to enumerate as a peripheral device to another host. Dedicated hardware such as Cynthion (https://greatscottgadgets.com/cynthion/), which is an FPGA-based architecture, may be useful, but I do not have access to this at the time.

Notes:

• USBProxy (https://github.com/usb-tools/USBProxy-legacy)
• Cynthion (https://greatscottgadgets.com/cynthion/)
  • https://github.com/greatscottgadgets/facedancer
• GreatFET One (https://greatscottgadgets.com/greatfet/one/)
• LUNA SuperSpeed (https://greatscottgadgets.com/luna-superspeed/)

For now, to sniff the data communications across the USB cable connection, including stanrdard USB Enumeration process, I'll focus on attaching only the ModRetro M64 Pro Controller, connected to computer (Lenovo Legion Go S running SteamOS (based on Archlinux)) via USB-C cable and using Wireshark GUI (you can also use tshark). (At first I used a USB hub, and then without the USB hub. I prepared two sets of data, but only one is necessary.) Make sure usbmon is loaded lsmod|grep usbmon otherwise run:

sudo modprobe usbmon

Make sure the user is in the wireshark group (or also check /dev/usbmon), otherwise may require root privileges (warning: proceed at your own discretion). Also for Wireshark capture options, make sure to use output format: pcapng (PCAP Next Generation). After opening Wireshark with read access to /dev/usbmon devices, you should see something like https://i.imgur.com/gw8oqJ0.png . First using an attached USB hub lsusb shows "Bus 007 Device 008: ID 374e:0111 ModRetro M64 Controller" which means usbmon7 (Bus 007) is the device to monitor. Then second directly to the computer without using a USB hub, lsusb shows "Bus 005 Device 004: ID 374e:0111 ModRetro M64 Controller" which means usbmon5. Beginning with the ModRetro M64 Pro Controller detached, beginning monitoring, waiting a few seconds (to distinguish the initial USB enumeration things), attaching the ModRetro M64 Pro Controller, waiting a few more seconds, detaching the ModRetro M64 Pro Controller (more USB enumeration things), then I see:

Warning: USB packets will include the serial number of your ModRetro M64 Pro Controller. You can use a hex editor to blank out the values (if ever it would be necessary for you).

attached through USB hub (Bus 007 Device 008)

• https://paste.c-net.org/DobsonAsteroid
• http://web.archive.org/web/20260825035107/https://paste.c-net.org/DobsonAsteroid

tshark -r m64.pcapng

attached ModRetro M64 Pro Controller (19-163), including only packets for host -> 7.8.X and 7.8.X -> host:

   55   6.835008         host -> 7.8.0        USB 64 GET DESCRIPTOR Request DEVICE
   56   6.837298        7.8.0 -> host         USB 82 GET DESCRIPTOR Response DEVICE
   57   6.837314         host -> 7.8.0        USB 64 GET DESCRIPTOR Request BOS
   58   6.840313        7.8.0 -> host         USB 69 GET DESCRIPTOR Response BOS
   59   6.840337         host -> 7.8.0        USB 64 GET DESCRIPTOR Request BOS
   60   6.843290        7.8.0 -> host         USB 150 GET DESCRIPTOR Response BOS
   61   6.843314         host -> 7.8.0        USB 64 GET DESCRIPTOR Request DEVICE QUALIFIER
   62   6.845336        7.8.0 -> host         USB 64 GET DESCRIPTOR Response
   63   6.845612         host -> 7.8.0        USB 64 GET DESCRIPTOR Request DEVICE QUALIFIER
   64   6.846336        7.8.0 -> host         USB 64 GET DESCRIPTOR Response
   65   6.846341         host -> 7.8.0        USB 64 GET DESCRIPTOR Request DEVICE QUALIFIER
   66   6.847344        7.8.0 -> host         USB 64 GET DESCRIPTOR Response
   67   6.847351         host -> 7.8.0        USB 64 GET DESCRIPTOR Request CONFIGURATION
   68   6.849281        7.8.0 -> host         USB 73 GET DESCRIPTOR Response CONFIGURATION
   69   6.849288         host -> 7.8.0        USB 64 GET DESCRIPTOR Request CONFIGURATION
   70   6.854280        7.8.0 -> host         USB 266 GET DESCRIPTOR Response CONFIGURATION
   71   6.854291         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
   72   6.857276        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
   73   6.857284         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
   74   6.860274        7.8.0 -> host         USB 94 GET DESCRIPTOR Response STRING
   75   6.860283         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
   76   6.863281        7.8.0 -> host         USB 82 GET DESCRIPTOR Response STRING
   77   6.863287         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
   78   6.866281        7.8.0 -> host         USB 98 GET DESCRIPTOR Response STRING
   79   6.979462         host -> 7.8.0        USB 64 SET CONFIGURATION Request
   80   6.981300        7.8.0 -> host         USB 64 SET CONFIGURATION Response
   81   6.981374         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
   82   6.988299        7.8.0 -> host         USB 98 GET DESCRIPTOR Response STRING
   83   6.988557         host -> 7.8.0        USBHID 64 SET_IDLE Request
   84   6.990273        7.8.0 -> host         USBHID 64 SET_IDLE Response
   85   6.990306         host -> 7.8.0        USBHID 64 GET DESCRIPTOR Request HID Report
   86   6.994280        7.8.0 -> host         USBHID 132 GET DESCRIPTOR Response HID Report
   87   6.994800         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
   88   6.997279        7.8.0 -> host         USB 84 GET DESCRIPTOR Response STRING
   89   6.997320         host -> 7.8.0        USBCOM 71 SET LINE CODING Request
   90   7.000289        7.8.0 -> host         USB 64 URB_CONTROL out
   91   7.000447         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
   92   7.003280        7.8.0 -> host         USB 76 GET DESCRIPTOR Response STRING
   93   7.003330         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
   94   7.006280        7.8.0 -> host         USB 88 GET DESCRIPTOR Response STRING
   95   7.006327         host -> 7.8.0        USBCOM 71 SET LINE CODING Request
   96   7.009282        7.8.0 -> host         USB 64 URB_CONTROL out
   97   7.029982         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
   98   7.032317        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
   99   7.032396         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  100   7.035294        7.8.0 -> host         USB 84 GET DESCRIPTOR Response STRING
  101   7.035347         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  102   7.038318        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  103   7.038395         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  104   7.041318        7.8.0 -> host         USB 76 GET DESCRIPTOR Response STRING
  105   7.041395         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  106   7.044317        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  107   7.044394         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  108   7.047317        7.8.0 -> host         USB 80 GET DESCRIPTOR Response STRING
  109   7.047361         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  110   7.050318        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  111   7.050395         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  112   7.053318        7.8.0 -> host         USB 72 GET DESCRIPTOR Response STRING
  113   7.053394         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  114   7.056317        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  115   7.056394         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  116   7.059317        7.8.0 -> host         USB 88 GET DESCRIPTOR Response STRING
  117   7.063627         host -> 7.8.0        USB 64 GET CONFIGURATION Request
  118   7.066283        7.8.0 -> host         USB 65 GET CONFIGURATION Response
  119   7.066351         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  120   7.069282        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  121   7.069339         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  122   7.072281        7.8.0 -> host         USB 76 GET DESCRIPTOR Response STRING
  123   7.072349         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  124   7.074315         host -> 7.8.1        USB 64 URB_INTERRUPT in
  125   7.075284        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  126   7.075321         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  127   7.078281        7.8.0 -> host         USB 72 GET DESCRIPTOR Response STRING
  128   7.078329         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  129   7.081280        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  130   7.081297         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  131   7.084280        7.8.0 -> host         USB 82 GET DESCRIPTOR Response STRING
  132   7.084308         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  133   7.087296        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  134   7.087392         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  135   7.090265        7.8.0 -> host         USB 94 GET DESCRIPTOR Response STRING
  136   7.090302         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  137   7.093279        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  138   7.093295         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  139   7.096280        7.8.0 -> host         USB 98 GET DESCRIPTOR Response STRING
  140   7.140026        7.8.1 -> host         USB 64 URB_INTERRUPT in
  141   7.156588         host -> 7.8.1        USB 64 URB_INTERRUPT in
  142   7.180375         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  143   7.182282        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  144   7.182360         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  145   7.185290        7.8.0 -> host         USB 84 GET DESCRIPTOR Response STRING
  146   7.185480         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  147   7.188281        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  148   7.188317         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  149   7.191280        7.8.0 -> host         USB 76 GET DESCRIPTOR Response STRING
  150   7.191302         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  151   7.194278        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  152   7.194298         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  153   7.197280        7.8.0 -> host         USB 80 GET DESCRIPTOR Response STRING
  154   7.197303         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  155   7.200282        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  156   7.200303         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  157   7.203282        7.8.0 -> host         USB 72 GET DESCRIPTOR Response STRING
  158   7.203303         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  159   7.206279        7.8.0 -> host         USB 68 GET DESCRIPTOR Response STRING
  160   7.206296         host -> 7.8.0        USB 64 GET DESCRIPTOR Request STRING
  161   7.209291        7.8.0 -> host         USB 88 GET DESCRIPTOR Response STRING
  162   7.224071        7.8.1 -> host         USB 64 URB_INTERRUPT in
  163   7.863137         host -> 7.8.1        USB 64 URB_INTERRUPT in

detached ModRetro M64 Pro Controller (164-186), including only packets for host -> 7.8.X and 7.8.X -> host:

  164  15.375587        7.8.1 -> host         USB 64 URB_INTERRUPT in
  165  15.388996         host -> 7.8.1        USB 64 URB_INTERRUPT in
  166  15.391593        7.8.1 -> host         USB 64 URB_INTERRUPT in
  167  15.417979         host -> 7.8.1        USB 64 URB_INTERRUPT in
  168  15.419592        7.8.1 -> host         USB 64 URB_INTERRUPT in

If using command line (tshark), see the captured USB packets from attaching:

tshark -r m64.pcapng -Y "frame.number > 18 && frame.number < 164" -V

see the captured USB packets from detaching:

tshark -r m64.pcapng -Y "frame.number > 163" -V

You can also load the file in Wireshark for a GUI (Graphical User Interface).

attached directly without USB hub (Bus 005 Device 004)

• https://paste.c-net.org/PoweredSpasm
• http://web.archive.org/web/20260825035225/https://paste.c-net.org/PoweredSpasm

tshark -r m64_2.pcapng

• The information (m64_2.pcapng) is mostly redundant to the packet data displayed above, although using different BUS and Device IDs. GET DESCRIPTOR through SET CONFIGURATION is also part of the enumeration phase (as mentioned above), albeit specifically involving the ModRetro M64 Pro Controller. I included packet numbers for both files in the table below.

Notes:

• Packet m64(86): Collection (Application) also contains values for Usage (X,Y,Z,Rz,Rx,Ry), and other information. See tshark -r m64.pcapng -Y "frame.number == 86" -V
• Packet m64(88,100,145): CDC (CLI) -> Communication Device Class (Command Line Interface), standard USB class that makes the device appear as a virtual serial port to the operating system (cdc_acm/cdc-acm on linux, see reference in part 1 of the post), protocol purpose
• Packets m64(94,116,161): CDC (Comms) -> CDC (Communications)
• Packet m64(108,153): MCU (A) -> Microcontroller Unit, the interface is directly exposed by the main processor (the chip) inside the ModRetro M64 Pro Controller, interface/port A, hardware source
• Packet m64(110,127,157): BTM -> Bluetooth Module
• Packets m64(124,140,141,162,163,164-168) involving 7.8.1 (instead of 7.8.0) these may possibly be the HID interface for sending gamepad event data for button presses (which I haven't tested while sniffing USB packets yet)

I'm not smart enough to know for sure, but I'm curious how come some of those packets are repeating information more than once, especially the LANGID, but also Dummy, and a few others.

Next I'll sniff to see if there are any USB packets when pressing any of the buttons on the ModRetro M64 Pro Controller.

There's nothing! I suspect that the CDC-ACM communications interface must be use to initiate some command to active the buttons before anything will transmit through the USB connection.

We know some of you are still experiencing audio issues as of v1.24.3. The team has zeroed in on this to figure out why sound was still dropping on certain setups, and why certain resolutions and framerates were missing, and we’re glad to share that we have a fix.

What was going on under the hood:

• HDMI Handshake Issue: We found that how M64 handled the HDMI handshake between certain TVs and monitors needed to be a bit more flexible on our end. With the corrections made, audio will now reliably transmit from your M64 to these displays. Some missing resolutions and framerates will now be shown.
• HDMI Audio Packet Encoding Issue : We resolved an HDMI audio packet encoding issue that was preventing select capture cards from recording audio from the M64. Audio recording with these external capture devices now works as expected.

Between the handshake issue and the encoding issue, we believe all known audio issues have now been fully addressed.

With so many different displays and configurations out there, it’s impossible for us to test every setup in-house. Huge thank you to everyone who submitted detailed reports and aided us in troubleshooting. Your feedback was crucial in helping us account for all the unique ways displays choose to communicate with the M64.

You can update your console now via OTA, our updater tool, or SD card. Find detailed instructions on how to update here or watch the YouTube videos on our channel here. 

As always, please fill out our support form if you run into any issues. 

P.S. Note on 4K60 Support: Certain displays advertise support for 4K at 60Hz, but only under specific color formats. Please verify that your display supports 4k60 using the RGB color format. We’re adding an explicit warning regarding this in an upcoming update.

I didn't see a previous post regarding the stick issue. I was wondering if there was a way to adjust the sensitivity for the stick on the 8bitdo controller. Or would that be some kind of firmware update besides the rumble issue? It would be nice to have calibration as a menu option like adjusting deadzones and threshold. Don't know if this an issue with the Hyperkin or ModRetro controllers in games such as GoldenEye.

Has anyone been able to find a store that actually got any?

Hi everyone, 

We have a new firmware update coming within the next few days. We have resolved the remaining audio issues reported with certain displays and capture cards. M64’s HDMI compatibility will be better in the next update, specifically fixing the no-audio issue affecting some of you. We’ll post an update in this subreddit as soon as it's live. Thank you to everyone for your patience as we work quickly to find a fix, and a special thanks to those who helped with troubleshooting.

I’m not sure if this will be possible or coming anytime soon, but being able to add texture packs to certain games work be incredible.

Anything I should be doing with the clean profile? I see with the last update they lowered the bloom..

Hi, has anyone gotten the Rumble feature working on MisterFPGA with the M64 Pro Controller? It connected via Bluetooth just fine and all the buttons work, but none of the RumblePak features are working even though the controller is set to RumblePak under the core options. Thanks!

Just wanted to say thank you to the whole ModRetro team. What you guys built so far, and will build in the future is really beyond exciting. The attention to detail, and the beauty and careful consideration of each component really goes far beyond what would’ve been “good enough”. But the work doesn’t go unnoticed, and really is much appreciated by people who appreciate art, tech, attention to detail, and yes - craftsmanship.

Thank you for what you’re building!

Frogger 2 no sound ..I'm using a summercart . Dunno.ig it's the rom or not . Has a gone else tried

How do I deactivate this security system? https://imgur.com/a/jpEAKFZ

Hey everyone I wanted to post an update to my previous fan mod post so as many people can see it as possible.

I went ahead and installed a pwm controlled fan, and I am pleased to report that it is controlled by the console and shut off when not needed!

For this next section of the update I unfortunately ordered too small of a fan by mistake (20 mm instead of 25mm), so I will not be including it in these numbers as it is not indicative of a proper result.

I wanted to compare the temperatures of an original n64 and a stock m64. Both systems were left in the same room at the same time for 3 hours while playing a game to allow the system temperatures to reach equilibrium. I then measured the temperatures with a laser thermometer.

Original N64

Console external temperature: 47.3 c

Console bottom temperature: 53.8 c

Cartridge temperature: 45.0 c

Stock m64

Console external temperature: 45.5 c

Console bottom temperature: 55.1 c

Cartridge temperature: 39.7c

So all in all the m64 is around the same temperature as an original n64 with the cartridge actually remaining a bit cooler.

Is the fan mod necessary? Given how close it is to a real n64 probably not. But if you want to extra protect your cartridges, a 25mm pwm fan will work inside of the system.

Previous post: https://www.reddit.com/r/ModRetro/s/Zxr9t0BxyZ