zfields

@dtw_2000 Just brainstorming here, to save your R.O.B. from modification... Instead of using a camera, it seems like it may be easier to jump into the raw video stream (HDMI, etc.) and have a program watch for the commands as they come out of the game. Then you could use the same program to "forward" those commands to R.O.B. via an Arduino with an LED (or directly to his MCU). I have seen a Zapper project that watches the video output of the game, and combines that with Zapper input to make Duck Hunt work. Making R.O.B. work with Gyromite and Stack-up should be much more simple, because you don't need input from R.O.B - only output from the game. I tried to find a link to the project I'm referencing, but I was unable to come up with it. Best of Luck, Zak

@dtw_2000 Which emulator are you trying to use?

I want to offer many thanks to the research done by the folks on this thread, especially @Tursi, @Pioneer4x4, and @x87bliss. Thanks to your efforts, I was able to pull all this information into a fun little project, where anyone on the internet can drive the R.O.B. in my house! Check it out at: https://nesrob.live/ When you press the INFO (select) button on the controller, then you can see a breakdown of the project. Otherwise if you are interested in my research, then you can visit the open-source repository where I'm housing the control library and documentation. It should work with any Arduino on the market. https://github.com/zfields/nes-rob Thanks again! Zak

Learnings from testing the binary signal: `10` issued 10 times (or `1010101010101010101`) is the most reliable way to flash the LED. It can happen with less iterations, but the behavior is sporadic at best. If the LED starts OFF, it will flash for ~264ms, and turn OFF again. If the LED starts ON, it will turn OFF immediately. The LED always ends in the OFF position, regardless of the starting position. When the signal is issued constantly the light will blink at a regular interval, as seen in the Gyromite test screen video. Out of curiosity, I tested using the initialization sequence followed by a byte with the binary pattern (0xAA), and it does nothing (`00010 10101010`). Oscilloscope Captures: constant binary signal intermittent binary signal (`1010101010101010101`) TEST_LED (0xBE) + `1010101010101010101` issued continuously TEST_LED (0xBE) + `1010101010101010101` issued intermittently

This is a great question, and I was curious about it as soon as I saw the initialization sequence was `00010`. I would say there is NO difference when a single instruction is issued. However, leading zeros can provide a necessary buffer when the instructions are run back to back. Also, I want to create instructions to match the original inputs as accurately as possible.

1010101010101010... makes the LED blink and appears to leave it in the off position! Now to narrow it down and see if I can minimize the pattern to the smallest reproducible size required to make it work reliably.

@Pioneer4x4 I see your point in the context of the Nintendo, because the LED indicates that R.O.B. is able to successfully receive commands. Once he has been set in clear view of the television, then there is no reason for that to change. However, when R.O.B. is used as a stand alone robot, there seem to be near limitless uses of an LED. For example, it could be used to indicate errors or statuses of the program running on the microcontroller driving R.O.B. @Tursi Thank you! I will definitely check to see what that does. In case it matters, were you being specific when showing the first blink as GREEN (1), followed by BLACK (0), then repeating? I will be trying several different approaches, but I would like to be as close as possible to the original signal.

I tested the padded sequence proposed by @ta0, but it does NOT cause the LED to flash. Furthermore, it appears to be less reliable at enabling the LED than the standard 13-bit TEST sequence discussed in this thread (based on the number of attempts it takes for R.O.B. to recognize the signal). It should also be noted, I sent successive TEST signals (both padded and unpadded), at 1Hz, 2Hz, 4Hz, and immediate intervals. The LED did not toggle (i.e. the behavior did not change). This leaves an open question regarding which signal disables the LED on R.O.B.'s head; as seen on the Gyromite TEST page in this video.

I am using WHITE, but the color doesn't seem to matter, just so long as it is bright. If you have any Arduino compatible board, then you can use Arduino Library Manager to install the "NesRob" library, and you should be up and running in no time. I'm also looking for feedback, so any critiques or comments would be appreciated. Please let me know if you run into any problems getting it going. Ahh-hah, that's right! Now I remember reading that, but I realize I had forgotten to test it. The spacing is odd 5,6,7,5 (`00000 000101 1101011 11111`), but I appears to the standard 13-bit sequence prefixed with an additional `00000` and followed by `11111`. I will test the longer sequence and report back. In the meanwhile, if anyone already had an emulator setup and is willing to record the signals happening in the Gyromite test screen it would be much appreciated.

That is where I started. @Zendocon offered to do just that, and I was trying to take him up on it. FWIW, I don't have an emulator, ROM's or anything of the sort. I just have a R.O.B. (purchased from a flea market), and I have used this thread and the Adafruit guide to get my library up and running. I'm trying to reverse engineer him, keep all my notes, and share them with anyone who attempts to follow in my footsteps. I don't have any way to slow down the frames of the video to confirm this, so it was not as obvious to me. Are you just assuming it only sends one signal (0xEB), or did you actually slow down the video and confirm this?

That hasn't been my experience so far. Maybe I'm doing something wrong? Do I need to send TEST repeatedly at a fixed time interval to see the blinking behavior? I've attached an oscilloscope capture from R.O.B.s spinal cord. In the picture, I'm showing the samples collected from the S (signal) and L (LED) lines. You can see the test TEST signal on the S line, but the L line stays at ~2V and never turns off (drops to ground (0V)). The first pulse is the 1 in the preamble `00010`, and the next pulses represent the 1's in (`11101011`). If R.O.B. was turned off and I turn him on, his motors will run through the calibration sequence, and the L line will be off (0V). Then once I run TEST, the L line will turn on (2V). Furthermore, if I run any command (other than TEST), the LED will turn off while the motors are engaged, then turn back on immediately following (example below). LED turns off (L line drops to 0V) while motors operate during arms left command (`10111010`). In short, I have not experienced the TEST command toggling the LED; only turning it ON if it was previously OFF. > DISCLAIMER: I'm using an LED to send light directly into R.O.B.'s left eye, not an old CRT television and hacked ROM.

Did you watch the video I linked? R.O.B.'s light is flashing on and off during the TEST portion, and as far as I can tell he is not moving. I may be mistaken, but if not I would like to know the off command. It seems bizarre they would only have an instruction to turn the LED on but not off.

I am particularly interested in learning how to turn the LED off, as shown in the video (shared above) using the Gyromite test screen. I'm currently writing an open-source library to control R.O.B. using an Arduino, and I would like to incorporate the LED off command. The source is available on GitHub: https://github.com/zfields/nes-rob Also, it's already available in the Arduino Library Manager under the name NesRob.