I want to make a tech demo to show off how ROB the Robot works, but I can't find any resources on how to actually program him. I know how he works, he uses lights that come from the TV. But what colors trigger what reaction? I'd also like to make a Zapper demo. What bit is triggered when the Zapper gets a light signal? What bit is triggered when the trigger is pulled? (And I'm sorry for using the word "Trigger" a lot, It sounds cool.)
Zapper reference:
http://wiki.nesdev.com/w/index.php/ZapperThe wiki doesn't have an article on R.O.B. yet but there's some stuff on it in Noca$h's document:
http://problemkaputt.de/everynes.htm#robroboticoperatingbuddy
Man, programming for that thing was hard! No wonder it could only get two different games!
Less that it's hard, and more that it's very low bandwidth, has no store/playback ability, and thus isn't that useful...
Yeah it's easy to program for once you understand how it works. I had a game idea that would use ROB and the Robot Block parts, but yeah it's quite limited what you can do with it, and the Robot is very slow. The Robot Block parts comes with Stackup for NES which has became very rare in USA due to cannibalism (the cart has a Famicom adapter inside) but I thought the player should be able to reproduce the blocks using PET bottle caps or something (the Robot Gyro parts would be much harder to reproduce). The biggest problem though is that not many people would be able to play my game because they don't have a ROB or Famicom Robot in the first place, and that it would only work on CRT TVs.
I made a Robot Test demo if you search the forum a little. I was much more of a newbie back then though and still didn't understand lots of things, so the code is very messy and may have several misconceptions. I'm planning to rewrite it one day once I have cleared up a few details.
Information is transmitted to R.O.B. serially, one bit at a time, as a sequence of black (bit 0) and green (bit 1) frames displayed at the NTSC framerate of ~60 fps. All bit sequences begin with a 5-bit header: 00010. This is followed by an 8-bit command (transmit left-to-right, most significant bit to least significant bit):
$AE - down half-step
$FB - down full-step
$BA - left
$BB - up half-step
$FA - up full-step
$BE - close hands
$EA - right
$EB - test
$EE - open hands
It's really more of a 4-bit command with clock bits in the middle... 000101w1x1y1z
How you choose to pack that for playback is another question.
How do you tell ROB to prepare for the next bit? Would you make the screen blue? What I mean is that after you write a bit, how would you tell ROB to get ready to read the next bit?
The CPU inside R.O.B. already knows when the NES is redrawing the screen; it already has a 50/60Hz clock source from that.
(Inside R.O.B.'s eyes, there's basically something identical to another Zapper)
If you're ever played Gyromite or Stack-Up, and you notice how the screen background flickers between black and green? That's it. R.O.B. is just looking for a bright flash after at least three vertical syncs (60/50ms) of dimness.
While we're on the subject, is there any emulator with a "virtual R.O.B." feature?
I feel like a lot of the obscurity of this device could be countered with more readily available ways to simulate it.
rainwarrior wrote:
While we're on the subject, is there any emulator with a "virtual R.O.B." feature?
I feel like a lot of the obscurity of this device could be countered with more readily available ways to simulate it.
Do you mean an emulation of the chips inside of R.O.B?
Not really, no. I mean, if you want to dump its programming and emulate its CPU you could use that, but that's a low level detail, and I don't think that really matters to the end user. We're not reprogramming the R.O.B. so whether your emulation does all that stuff at the low level is a bit invisible to the user anyway. All the responses you get from R.O.B. are very coarse. I'm talking about high level emulation of it.
I mean a representation of what it does, its current physical state and how it interacts with you and the game. Maybe done with icons or pictures, or even a 3D model would be really interesting. The screen flashes, and you watch the "virtual" ROB turn or move or press a button on controller 2 or spin up a top, etc.
rainwarrior wrote:
Not really, no. I mean, if you want to dump its programming and emulate its CPU you could use that, but that's a low level detail, and I don't think that really matters to the end user. We're not reprogramming the R.O.B. so whether your emulation does all that stuff at the low level is a bit invisible to the user anyway. All the responses you get from R.O.B. are very coarse. I'm talking about high level emulation of it.
I mean a representation of what it does, its current physical state and how it interacts with you and the game. Maybe done with icons or pictures, or even a 3D model would be really interesting. The screen flashes, and you watch the "virtual" ROB turn or move or press a button on controller 2 or spin up a top, etc.
Nintaco simulates R.O.B.
zeroone wrote:
Ahh! That is really great! Thank you.
rainwarrior wrote:
zeroone wrote:
Ahh! That is really great! Thank you.
I just want to mention that I've discovered and fixed a few glitches with the R.O.B. simulation. And, I'll eventually post a new build.
Also, I made Stack Up interactive. It will automatically advance the level when you complete each sequence.
Oh for real? That's just great! Too bad this machine doesn't have Java so I can't try it at the moment.
Does it simulate the blocks, gyros and spinner as well? Does it support all commands (neither game are using the reset command, but the test carts are)?
Making Stackup interactive is also nice, that game is too easy to cheat in on real hardware.
rainwarrior wrote:
if you want to dump its programming and emulate its CPU you could use that, but that's a low level detail, and I don't think that really matters to the end user.
This might be interesting on it's own though, and maybe even for reproducing ROB. Would be cool with a ROB that's compatible with non-CRT TVs.
Would running the composite video signal through some sort of amplifier into a green LED make a signal that ROB can pick up?
It worked for the Zapper.
I guess it would. It probably doesn't even have to be a green LED. It's just that the two games are always using the green $2A for flashing the commands to ROB for some reason. ROB worked on my PAL TV which can't do NTSC colour and therefore became black & white.
Pokun wrote:
Does it simulate the blocks, gyros and spinner as well? Does it support all commands (neither game are using the reset command, but the test carts are)?
It simulates the blocks, gyros and spinner. However, the gyros are always spinning; they never run down and do not require using the spinner, though it is available.
Where might I find these test cart ROMs? Nintaco currently doesn't support the reset command either.
I see, that makes the game a lot easier, and still a lot better than nothing. I think I once measured my gyros how long they would spin from a full charge in the spinner, but I forgot how long it was. But it was quite long anyway, like 3 or 5 minutes or so, they are of really good quality.
My own test program should support all the 10 known commands. The ROM is in the zip in the attachment of the first post. Warning again for bad source code. Alternately this
Family BASIC program also supports all commands (my test ROM is actually using the same machine code).
Otherwise
this test cart may support all commands I think, if you can find the ROM for it.
Pokun wrote:
My own test program should support all the 10 known commands. The ROM is in the zip in the attachment of the first post. Warning again for bad source code. Alternately this
Family BASIC program also supports all commands (my test ROM is actually using the same machine code).
Otherwise
this test cart may support all commands I think, if you can find the ROM for it.
Thanks for the links. I'll test them out soon.
What does the Reset command do? Does it restore R.O.B. to some default rotation and elevation? I'm guessing center and top?
Yes it restores him to the default position no matter what position he is in when the command is sent. It's the same thing that happens when you power him on, so you can achieve the same result by power cycling him.
I don't remember exactly what the default position is but I think maybe centre and top as you say. I remember that his arms are too high for him to fit in his own styrofoam box in the default position, so you have to manually move down his arms in a game before putting him back in his box again.
Pokun wrote:
Otherwise
this test cart may support all commands I think, if you can find the ROM for it.
GoodNES 3.23b contains NTF2 System Cart.7z <NTF2 System Cart (U) [!].nes>
However, when I run it, all I get is:
How does it even analyze the AC Adapter status? And, why does it think it's broken.
There is a section about the
NES Test Station in Wikipedia's NES page. I guess this cartridge is designed for use in that hardware.
The NTF2 System Cart is specifically for the Test Station; it relies on hardware that is not normally present in an NES.
user:game-tech.us has a video series on youtube about the Test Station:
https://www.youtube.com/watch?v=-OaaJLkBBak
I see, it passes in some emulators but not on my Everdrive.
In the second video, game-tech.us reads off the parts on the Test Station mainboard. After the ones that are part of the NES mainboard, he additionally noted a "74hc"third again", hc04, hc139, hc139, hc273, hc358 again, hc08, hc32, hc04, hc32, hc541, hcu04, cd4011, hc10, 4066, lm339, 74hc32"
so ... whatever it's doing, it's not terribly complicated, but it's completely undocumented.
It seems not unlikely that what happens when you try to run it on an ordinary NES depends on the RAM (both cart and system) power-up state.
In FCEUX 2.2.3, I can get "NTF2 System Cart (U).nes" to start up on its menu if I freeze address $1000 to value 7:
1. Go to the Tools menu and choose Cheats.
2. Put in Addr 1000 and Val 7 and click Add.
3. Go to the NES menu and choose Reset.
The ROB TEST only tests 7 commands (LED TEST, UP, DOWN, CLOSE, OPEN, LEFT, RIGHT).
Oops I remembered incorrectly then! Sorry!
It seems it doesn't even have the double up and down commands (Robot Block have the single up and down commands and Robot Gyro uses the double up and down commands if I remember correctly, but none of them allows testing both).
I guess UglyJoe's Family BASIC program and my test program based on that are the only available programs that can test all known commands, including the reset command. I remember my test program wasn't always reliable though, the Robot randomly does nothing. But the Family BASIC program works every time so it's probably some bug in my menu program.
Also the LED test is a bit different in my program (and the Family BASIC program). I only flash the command once so the LED lights up. Robot Block/Gyro is doing something else with it.
Hm. Since the encoding has a 4-bit field, I assume that people have long since already tried sending all 16 different codes and only these documented 10 do anything?
I guess so, but I'm wondering, it might be worth testing again before adding ROB to the wiki. UglyJoe seems to just have taken the commands from
this Atari Age thread which has these 10. That thread also had some misconceptions I think.
In Block/Gyro there's a test mode that keeps making the screen blink green until you press SELECT. While this is going on ROB's LED will, if ROB is looking at the TV, blink somewhat slowly. This is for the user to adjust ROB's head until it's looking at the TV (LED starts blinking). But in our test program the TEST command will only make the LED light up, and there seems to be no way to turn it off (it might turn off automatically after a while, I don't remember). Therefore there might be another command that is used to turn the LED off or something. It's possible it's just sending the TEST command over and over though, but from my observations the TEST command is not a LED toggle.
I have a Famicom Robot but no CRT TV nearby at the moment, so I can unfortunately not do any tests.
Do you have an LED? We can try
tepples's suggestion pretty easily.
Yes I have some LEDs and other parts laying around. I could try it if someone told me what to do.
Well, as far as "super quick" options, I just tried plugging an "ultrabright" red LED into my NTSC NES deck video output, verified that I could see it flicker at 60Hz, and then verified that the Zapper could pick that up.
Should be an OK place to start. Might need a current amplifier to allow the NES to drive both a TV input and the LED at the same time.
Current amplifier huh, I don't know electronics enough to know how to design a circuit for that.
I guess I could try working Robot Block's Direct mode in the blind for the sake of testing first though.
In what manner would the LED connect to the video output? I have some LEDs in various colors with built-in resistors designed for 5 V circuits. Could I just connect one of these directly to the RCA-plug's ground- and video-lines?
Yeah, I just connected
VideoCenter --- |>| --- VideoShield and got something that worked.
That will probably only would work with "old" LEDs (red, orange, amber, yellow, yellow-green); "new" LEDs (rich green, cyan, blue, violet, purple, white) probably have too high of a required voltage.
I also tried
VideoCenter --- |>| --- TV input center and separate
Shield --- Shield and got something that ... technically worked but was very marginally visible. Just barely enough for me to see the output of tepples's Zapper test program.
The other final quick configuration you could try (which I've not tested) would be:
Code:
VideoCenter ---+--- TV input center
|
+-|>|-+
|
VideoShield ---------+--- TV input shield
but there's a chance that the TV's input impedence will be too small for the voltage to be high enough for any current to flow through the LED. This is the first one that even could drive both the LED and TV at the same time usefully, though.
The "current buffer" I was describing would be shaped like this:
Code:
VideoCenter ---+--- TV input center
|
~10k
| c---|<|---Vext
+--b|< npn
e
VideoShield ---------+--- TV input shield
Vext could be 3V from some batteries, 5V from somewhere inside the NES, or anything below your BJT's Vcemax