Any interest in NES ROB homebrews?

[Pioneer4x4]

2 hours ago, zfields said:

@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.

OK, Gotcha.  Using it for something other.  Maybe even on-pause-off-on-pause-off...  like "hey, look at me" indicator.
Also how is 010101010101010101010101 different than 10101010101010101010101010 different from 01.....01   and 10...01?  No matter what your sending LED is off before you start any sequence and ends off after any sequence, right, so it is like sending 0 continuously until a 1 comes along.

[zfields]

19 minutes ago, Pioneer4x4 said:

Also how is 010101010101010101010101 different than 10101010101010101010101010

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.

Edited January 26, 2021 by zfields
typo

[zfields]

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

[Pioneer4x4]

45 minutes ago, zfields said:

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.

ANother thing is, since it was designed for use in front of a TV set running a video game, there would be some level of brightness hitting it all the time, then the sudden drop for that specific time, then a sequence would be easier (more reliable) to detect then just the sequence itself.  Someone needs to dump the rom (it can't all be discrete stuff, can it?) on the R.O.B.
I have 2, maybe I'll open one some day.

Edited January 26, 2021 by Pioneer4x4

[Tursi]

On 1/26/2021 at 5:54 AM, Pioneer4x4 said:

That's what I thought, and said on Saturday.  Just curious, why does anyone even want to turn it off?  

Well, I wish you'd done the reverse engineering, too, cause I had better things to do

 

[zfields]

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

Edited March 10, 2021 by zfields
Replace static image with GIF

[Pioneer4x4]

1 hour ago, zfields said:

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!

...Thanks again!
Zak

That is WAY cool, thanks for both doing it, and posting this.  I just told it what to do a few times.  Performed perfectly.

[Tursi]

2 hours ago, zfields said:

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.

Very cute!

 

[dtw_2000]

@zfields I recently repaired my r.o.b. and was able to get him to move around using your nesrob library.  Kudos and thank you for your work!  I had the itch to play gyromite off an emulator with a nes usb controller for rob, and I was quickly reminded that r.o.b. only works on a CRT monitor, which led me to this forum and your code.  I had a couple of thoughts on how to get rob going via emulation, and thought I'd throw them out there and see what you or others thought as feasible and possibly inspire towards something.  I've seen the Bluetooth glasses that have been offered, which is very cool, but not exactly controlling r.o.b. through the game.

 

Option 1.  How feasible would it be to add a camera module to an arduino, process the feed, and trigger you led commands if the black/green binary sequence was seen/processed?  This would be a true middle man solution to allow r.o.b. to see his commands.  I'm not sure if an arduino even has that kind of muscle.  Maybe it would require a raspberry pi.  Off the cuff, I'm thinking that some clever analysis of a few pixels at the correct framrate, with a threshold tolerance for black and threshold for green would allow for a decent interpretation which could trigger zfields ir library commands, but the devil is certainly in the details.

 

Option 2.  (Please forgive my semi-technical translation) I found where someone made patches to lightgun roms, allowing the lightgun to work with a modern display: http://neslcdmod.com/ with the caveat that the OG zapper needs some sort of bypass for the filter module that restricts reception to CRT frequencies.  3rd party zappers work without modification (again, apologies if this is a bad interpretation of how that works).  It seems like a similar patching process could be applied to gyromite/stackup, but it may also require some sort of filter mod to r.ob..  I know, modding rob is akin to blasphemy, but it'd be pretty sweet.

 

Option 3.  Similar to option 1, would be an extension to an emulator that would allow triggering commands based on the video output.  This is probably the most complicated option and least universal.

 

I might be able to pull off Option 1 if I were able to chew my way through some sort of arudino camera library, but it's probably a bit over my head.

Edited September 30, 2021 by dtw_2000

[zfields]

@dtw_2000 Which emulator are you trying to use?

[dtw_2000]

4 hours ago, zfields said:

@dtw_2000 Which emulator are you trying to use?

I usually use nestopia or fce ultra on pc.  If I'm playing nes off of a pi, I use whatever nes emulator core is bundled in retropie/retroarch.  To be clear, i have a modern LCD monitor (pc) and LCD TV screen (pi).  I'm guessing you can probably adjust the output/speed of the emulator slightly to achieve the same effect I referenced in "Option 2" without needing to modify/patch the rom, but I think it's probably the case  that r.o.b. would need the same treatment as the OG zapper.  I don't know what I'm doing, but I was thrilled to stumble across your code and get r.o.b. responding to commands.

 

That last option/idea I mentioned was more of a general "I wonder if ...".  I know there are tons of different NES emulators.  I was speculating that some are probably a bit more flexible with adding extensions, and that it was probably possible to analyze the video output.

[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

Edited October 1, 2021 by zfields

[AlbertCX]

Hey everyone,

I know it's been a while, but in case anyone is interested, we actually made a new batch of the Bluetooth R.O.B. control Goggles. Again, there are not too many, but we still have some available here:

 https://www.tindie.com/products/cxelectronics/bluetooth-control-goggles-for-rob/