26 replies to this topic

[godslabrat]

I can't be the only guy who really likes ROB, but is bummed that only two games make use of him. Has anyone given serious thought to starting a project like this?

[Lendorien]

godslabrat, on Tue Feb 15, 2011 9:01 PM, said:

I can't be the only guy who really likes ROB, but is bummed that only two games make use of him. Has anyone given serious thought to starting a project like this?

You know, I think this would be a great idea, but it's not like Rob can do that much. Still, with the types of homebrewers out there, who knows what could be come up with.

[raskar42]

i would be interested in this i used to have rob years ago and thought it was cool - the problem now would be finding a functional rob at a reasonable price.

[godslabrat]

I guess another good question would be, has anyone documented the flashes needed to trigger ROB's movements?

[Lendorien]

godslabrat, on Tue Feb 15, 2011 11:18 PM, said:

I guess another good question would be, has anyone documented the flashes needed to trigger ROB's movements?

I assume that Rob works like a light gun does. All you'd have to do is play a game with it and record the game, then play it back on slow mo when it's flashing to get the timings down. But I suppose that's a lot of reverse engineering.

Edited by Lendorien, Wed Feb 16, 2011 12:43 AM.

[Tursi]

ROB reads PWM encoded data during the flash - it's a sequence. The details I don't have though, but in high school I spent a bit of time documenting it. A little different from the light gun, but yeah, if you record it and slow it down you could work out the patterns for each control. (If it hasn't been documented online already.)

[godslabrat]

Tursi, on Wed Feb 16, 2011 1:02 AM, said:

ROB reads PWM encoded data during the flash - it's a sequence. The details I don't have though, but in high school I spent a bit of time documenting it. A little different from the light gun, but yeah, if you record it and slow it down you could work out the patterns for each control. (If it hasn't been documented online already.)

I'd wonder if reverse-engineering the original ROM wouldn't be a more direct method.

[Tursi]

godslabrat, on Thu Feb 17, 2011 8:56 PM, said:

I'd wonder if reverse-engineering the original ROM wouldn't be a more direct method.

Seems to me that would take a lot longer - reverse engineering assembly code is not usually a fast process. Everything's hard-coded, there are only 6 movements, IIRC, and it'll be a binary PWM pattern - should be pretty easy to just write it down. I don't have a ROB or either ROB game anymore myself, though. To be honest I always thought it was too slow to be much fun - interesting gimmick though.

I wonder if there are any good quality video of the flashes online? Would be able to tell pretty quickly how easy it REALLY is to read the flashes. Had no luck on YouTube.

[Itchy Koala]

It would be nice to see games made for ROB, right now all he does is hold my phone while its charging :/

Edited by Itchy Koala, Mon Feb 21, 2011 8:48 PM.

[Tursi]

Watching YouTube it looked like left/right/open/close were pretty absolute commands, but that up and down varied (there are two steps in Gyromite but more than two for StackUp). So those two at least probably include some kind of distance or step command.

I don't have StackUp, but I took a look at Gyromite's signals via emulation, and these are the patterns I get. 0 is a black screen, 1 is a green screen (although any bright color will probably work, the color indexes used in Gyromite are $0F for black and $2A for green).

I believe it is setting the color every vertical blank (ie 60fps), which would be simplest. It may be 30fps (every other blank) just to accomodate TV frames.

I don't have a ROB and I don't know if anyone reading this thread can test code, so I didn't try to write any, but this is what I get from a quick look.

First, the screen should be blank during the flash cycle - either clear the screen or set the blanking bit (if the NES has that!) Use black for 0s and bright green for 1s, and change every vertical blank.

There seems to be a 5 frame sync signal: 00010 - The number of leading zeros is probably unimportant, and it's only important that there be at least three blank pulses before the 1, this is probably equivalent to a start bit. I would expect you could write a routine that generically shifts out 8 bits and so use 00000010 safely.

Next is 8 bits of control data. I don't know if the up and down contain data or are otherwise different in Stack Up, these are what Gyromite uses (or do I remember wrong and Gyromite has 5 or 6 stop points for up and down too??):

UP: 10111011
DOWN: 11111011
LEFT: 10111010
RIGHT:11101010
CLOSE:10111110
OPEN: 11101110

Finally, always end with a single frame of black (0).

If anyone wants to try this out, I'd love to hear if it works. If anyone can run custom software against the ROB (maybe with a flash cart or test with an emulator?), I could try to whip something up real quick.

[PAC MAN FEVER]

that would be so cool rob never gets enough screen time.

[Tursi]

Nobody seems able or interested in testing custom code, though, hehe.

[godslabrat]

Tursi, on Thu Mar 3, 2011 8:48 PM, said:

Nobody seems able or interested in testing custom code, though, hehe.

It's been a while since I started this thread, but I actually have an idea for a decent R.O.B. game. I guess the question now is, can I find time to learn how to program it?

[PAC MAN FEVER]

I'd love to see a new rob game I'll be watching this thread.

Edited by PAC MAN FEVER, Thu Apr 7, 2011 5:56 PM.

[Pong]

godslabrat, on Tue Apr 5, 2011 11:18 AM, said:

Tursi, on Thu Mar 3, 2011 8:48 PM, said:

Nobody seems able or interested in testing custom code, though, hehe.

It's been a while since I started this thread, but I actually have an idea for a decent R.O.B. game. I guess the question now is, can I find time to learn how to program it?

The only idea that I have is to disassemble Gyromite or Stack-Up and learning from that.

And I'm aware that it's a bad idea, but it's the only one we got.

[RayXambeR]

I'd love to see another title for this so crazy robot!

[Tursi]

Can anyone load and run test code on a real NES to try it against ROB? If so, I can make and post sample code, then once it's proven to work, anyone can run with it.

[sack-c0s]

Tursi, on Mon Apr 11, 2011 2:55 PM, said:

Can anyone load and run test code on a real NES to try it against ROB? If so, I can make and post sample code, then once it's proven to work, anyone can run with it.

would you even need to? Given that it responds to screen pulses at a given frequency surely that means it's compatible with pretty much anything that can produce them?

Edited by sack-c0s, Tue Apr 12, 2011 3:54 AM.

[Lendorien]

The screen would have to be a CRT because of how the tech works in the rob. It's pretty much the same tech as a light gun. Won't work on LCDs.

[yuppicide]

I got it for Christmas when it first came out. I played a lot of Gyromite, but I don't think I'd be interested in homebrews and I'll tell you why. I played
Gyromite without the robot.. just used my hands. I really just wanted to see all the levels. Has anyone mapped them all out? How many are there?

[x87bliss]

I was doing some testing with the following game genie codes I made for gyromite:

1) AAKZPTZA (allows you to decide what command gets sent to R.O.B. at direct screen) [not sure if this affects other parts of the game]
2) xAKZLTAy (determines the command that is sent) - note in this function the "command" number is just an index, not a bit pattern

Replace xy of code 2 with one of the following:
[Game Genie letters (xy) = Hex Value = Effect]
AA = 00 = do nothing - nothing happens at all, the screen doesn't even blank, no sound is played
PA = 01 = open
ZA = 02 = close
LA = 03 = test (this sends the pattern that turns on the red light on his head, but he does nothing else)
GA = 04 = nothing - this just blanks the screen. R.O.B. doesn't even respond at all
IA = 05 = up (two notches)
TA = 06 = down (two notches)
YA = 07 = left
AE = 08 = right

Any other values out of this range cause garbage on the screen.

I was hoping to find more information from this test, but it hasn't really revealed anything new, except that there may actually be a pattern strictly for the "test" function to turn R.O.B.'s light on. I think I may actually need to play with the Stack-Up ROM to find anything about moving up or down one notch only. I was hoping the code for these were in Gyromite even though they're not used, as if part of a R.O.B. code library.

Anyway, I am able to run custom code on an actual NES. I have a front loader and a programmable cartridge. My only requirements are that it's a valid ROM file that uses one of the mappers that this cartridge supports. I also have a functioning US R.O.B.; right now I only have the Gyromite parts, but the Stack-Up parts are in the mail.

Edit:
I just want to add an answer to Tursi's question about the number of stop points in Gyromite. R.O.B. himself has 6 points that he can stop on going up and down. However Each Up/Down command in gyromite makes R.O.B. move two of these. But it is possible in Gyromite to reach each individual spot, it's just a PITA.

Look at the following command pattern, assuming the neck positions are numbered 1(top-most) to 6(bottom-most)...

At position 1, Go Down 2
Now at 3, Go Down 2 again
Now at 5, Go Down 2 again
Tries to reach 7, but actually is forced to stop at 6.

Same thing going up:
At position 6, Go Up 2
Now at 4, Go Up 2 again
Now at 2, Go Up 2 again
Tries to reach 0, but actually is forced to stop at 1.

Edited by x87bliss, Wed Apr 13, 2011 9:26 PM.

[Tursi]

sack-c0s, on Tue Apr 12, 2011 3:54 AM, said:

Tursi, on Mon Apr 11, 2011 2:55 PM, said:

Can anyone load and run test code on a real NES to try it against ROB? If so, I can make and post sample code, then once it's proven to work, anyone can run with it.

would you even need to? Given that it responds to screen pulses at a given frequency surely that means it's compatible with pretty much anything that can produce them?

Would you even need to test it? It would be helpful!!

Yes, other things can probably produce appropriate flashes, but this thread is about NES homebrew. No matter what you want to use, until we prove I have the right pulse patterns by testing it against a ROB, everything else is rather silly.

An LCD actually may work with ROB... it's not exactly the same as the light gun. There's no feedback from ROB back to the NES, so it's okay if the flashes are slightly delayed with respect to the game, as long as every individual flash is present, and filtering/upscaling doesn't try to combine frames.

[x87bliss]

Edit: Updated information on V-Blanking

I'm doing some more reversing, but I'm not 100% familiar with the NES hardware.

First off, my R.O.B. does not work with my LCD TV. But I can see that the flashing signal gets messed up by the de-interlacing.

Secondly, Gyromite is programmed to wait to start at a certain point before it flashes each screen. First it waits for V-Blank to clear the Sprite 0 Hit bit of the PPUSTATUS, then it waits for the Sprite 0 Hit to occur again. If you step it on an emulator, you'll see the flashes wind up occurring about 1/5 of the way down the screen. However, this offsetting is completely unimportant. I reprogrammed the loop to make the frames occur exactly at V-Blank and R.O.B. still functioned perfectly.

Long story short, each flash should occur at each V-Blank. What I do not know is if the V-Blank occurs at 60 or 30 (29.97) times per second.

Here is the actual code for the wait loop between frames:
$80C1:AD 02 20 LDA $2002 = #$40
$80C4:29 40 AND #$40
$80C6:D0 F9 BNE $80C1
$80C8:AD 02 20 LDA $2002 = #$40
$80CB:29 40 AND #$40
$80CD:F0 F9 BEQ $80C8

Finally, I found the part of the Gyromite ROM where the flash sequences are coded:

Every command is 13 flashes long. Tursi is correct that all the commands (at least the ones in Gyromite) start with the 5 flash sequence: 00010.

The loop to execute the command has 14 cycles. The first cycle does absolutely nothing except wait for the right time for the first flash to occur (see the above loop). Then the next 13 cycles go through the sequence for the desired command. Note though, as previously said, the first five flashes always seem to be the same - maybe this sequence is used for timing R.O.B.'s sensor if he isn't hard-coded to the NTSC framerate.

The command sequences that Tursi listed in a previous post all seem to be correct. There is also another one for the "test" function in Gyromite that only serves to activate his light:
(00010) 11101011

I still don't know what the sequences are for the other two commands (moving up and down only one notch), or if there exists any other unknown commands. But I am at a point where I can reprogram Gyromite's sequences to test any sequence (it would just be time consuming to try all 255 possibilities).

Edit (Update):
I was experimenting with the timing a bit, so that it waited for every two frames instead of one to update the screen. (Essentially running the game at half speed). The idea was to see if R.O.B. would be able to adapt to the different timing, and thus have games able to be programmed for LCD TVs. Unfortunately, R.O.B. wouldn't respond to these now double length sequences on either LCD or CRT. So it appears that the timing is hard coded into R.O.B.

Final Edit/Update For this Post:
The color of the flashes don't matter. I changed the green (2A) to white (20), and also tried a bright red (26), all of the variants worked perfectly with R.O.B.

Edited by x87bliss, Thu Apr 14, 2011 7:11 PM.

[x87bliss]

I wrote a quick test program to play with R.O.B. It was my first ever NES program, and it was horrible. However, it let me experiment with sending him every possible command pattern.

From this experiment I learned that the timing seems to be very difficult to get right. I tried polling the PPUSTATUS for the v-blank bit toggling, and I also tried using the V-Blank NMI, but each way I did it, R.O.B. would only respond some times to the commands.

Gyromite flashes the screen by changing all the palette colors to the same (either black or green).

I found the following list of commands, and I'm pretty sure it's every command he will accept. They are written as 8 bit hex values, if you expand them to 8 bit binary, the most significant bit gets flashed first (0 for black, 1 for green).

Also note that you always need to flash 00010 (5 flashes) immediately before the 8 flash command.

AB - Calibrate (causes R.O.B. to open arms, go all the way right and all the way up, and then return to center - as when you first turn him on)
AE - Down 1 Notch
BA - Left 1 Notch
BB - Up 2 Notches
BE - Close
EA - Right 1 Notch
EB - Test (this just causes the red LED on his head to turn on if it was previously off)
EE - Open
FA - Up 1 Notch
FB - Down 2 Notches

If you look at these commands, you may realize that only the hex digits A, B, E and F are used. If you break these into their binary equivalents 1010, 1011, 1110 and 1111 respectively, you should see that there is never a sequence that contains two adjacent 0s (black screens) except in the 5 flash start sequence. More specifically only the even numbered bits [if numbered from 0(lsb)..7(msb)] can be a 0, which further enforces the no adjacent 0 "rule." Consequently, every 8 flash command starts with a 1 (green flash). Maybe this observation could lead to more efficient code, or a better understanding of R.O.B.s capabilities/limitations for more compatible code.

[Tursi]

Nice investigation!