Not working with certain games

[ExtremelyLazyCat]

Hey: I've been using your 13th commit(https://github.com/rcombs/n64-tasbot/commit/08fb7ccfa48b049992606d8a848e3947ac45eda0), because I don't really know how to work your earliest commit(I heard you were using a Teensy, I am using an Arduino Nano). I am trying to verify a Majora's Mask TAS, but when I power on the N64, the Serial Monitor spams "Controller identified", and the game states a "No controller detected" error. And I mean like "Controller identified" x ∞. So, if anyone knows a solution, let me know.

[ghost]

Also having this issue, but on the latest commit.

[ghost]

With some googling, it seems like Majora's Mask is a special case, in which the device needs to respond to commands that other games do not need?

Source: http://www.afermiano.com/index.php/n64-controller-protocol In the "Zelda Majora's Mask behavior" section.

and: http://svn.navi.cx/misc/trunk/wasabi/devices/cube64/notes/n64-observations

According to reference #3 on the second source, some games will not work if the game fails to communicate with the controller pak. As is it currently implemented, the Arduino will respond to 0x00 (which falls to 0xFF in the current code) with 0x050001 , which indicates either a memory pak or a rumble pak? I'll modify the project to respond with a 0x050002 and see if this fixes the issue, as this is supposed to indicate no controller pak.

[ghost]

Changing the response did nothing. I did, however, find something of interest when testing. When running the program with MM, the serial output on the title screen constantly displays the name of the selected file, rather than just displaying the inputs per frame.

I noted this behavior in Ocarina of Time, as well, and the TAS did not work, but OOT reported that the controller was present. One thing different in OOT, however, was the fact that serial reported that the initial frames of the TAS were the only thing being outputted on a constant loop (roughly the first three). I am unsure if this behavior is also present in MM (I'll test later today).

This makes me think that the issue could partially be something to do with the TAS not playing out completely. I'm not fluent in C++, but I'll continue to test and see if a fix can be found.

[ghost]

Just ran more tests, and I think I've identified the problem. For some reason, the Arduino is constantly resetting itself when communicating with either OOT or MM (IE setup() running repeatedly for some reason, which is not supposed to occur).

This explains a lot of things:

1. @ExtremelyLazyCat 's issue of "Controller Identified" being repeated constantly, since the Arduino is rerunning all of the initial setup.

2. Why MM can't identify the controller, but OOT can, since MM needs the communication with the controller to verify its there (though previously mentioned problems with the specifics may still persist after fixing this issue).

3. Why the first frame or two are repeated, and therefore a replay of OOT can't finish despite the fact that OOT recognizes the controller.

I tested the same replay on other games, and their inputs registered, as well as a SM64 tas on MM, and it had the same issue, so its not an issue of a specific replay.

I literally have no idea why this would occur.

[ZekePolarisBSH]

Got any gameboy tas files for Pokemon?

[ExtremelyLazyMeg]

https://tasvideos.org/UserFiles/Game/16

[ZekePolarisBSH]

Omg N00b moment, I forgot about tasvideos dot org!!! Thanks

[ZekePolarisBSH]

Are these used on any emulator or just BizHawk?

[ZekePolarisBSH]

Files downloaded does not show up in list. Did I downloaded the right ones?

[ExtremelyLazyMeg]

Coming back to this issue 6 years later(I was about 10 when I first submitted this), I've discovered that the reason behind certain games not recognizing the controller is a combination of both games like Majora's Mask and OOT using different methods for ensuring controller connectivity, and the Arduino program not handling this different protocol correctly. More specifically, I've observed that MM and OOT constantly request status updates from the controller and try to constantly send write requests to the controller pak. SM64 only sends 0xFF(reset) once at startup, then just requests input updates(0x01). The LOZ games, along with the input requests, request controller status updates(0x00, which falls through in the code switch to 0xFF) every frame along with the write requests(0x03). The constant status and write requests cause the code to freak out and output Controller identified and Got a write, what? every frame, which at the 9600 baud rate throws off the timing of the read/write of the Arduino to the N64, leading to the "No Controller" complaint from the console. This can be fixed by commenting out the Controller identified, Got a write, what?, and the Got a read, what? outputs to the Serial Monitor. It took me six years to figure this out. Wow.