R.O.B. Firmware

Discussion of development of software for any "obsolete" computer or video game system.
Pokun
Posts: 1448
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: R.O.B. Firmware

Post by Pokun » Sat Nov 30, 2019 2:14 pm

I see, in that case none of the leading zeroes should really matter if the background is dark, and the real format would be 14 vsyncs total. Maybe I'll experiment with a bright background some time.


So you mean one bit is really one flash light to dark? I guess the number of vsyncs there is between the flashes is important or else it wouldn't be able to tell the difference between UP FULL STEP (%0111011) and CLOSE (%0111110) which both uses two flashes but at slightly different timing. So in other words, %10 is really 0 and %11 is really 1 (or the other way around). That makes sense.

And the 25 Hz is in case of PAL, since the PAL version probably uses the same unmodified ROM for the games and is still fine with the slower timing.

lidnariq
Posts: 9403
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: R.O.B. Firmware

Post by lidnariq » Sat Nov 30, 2019 2:34 pm

Pokun wrote:
Sat Nov 30, 2019 2:14 pm
I see, in that case none of the leading zeroes should really matter if the background is dark, and the real format would be 14 vsyncs total. Maybe I'll experiment with a bright background some time.
Uh, I suspect that R.O.B. requires quiet time both before (the three preceeding vsyncs) and after (either Z or padding).

... Admittedly, I don't know why it would require quiet time after.
So you mean one bit is really one flash light to dark?
Yeah, that's how CRTs work. I fear this means R.O.B. won't work on a modern HDTV where the display is constantly emitting light.
in other words, %10 is really 0 and %11 is really 1 (or the other way around). That makes sense.
I think that also makes it really easy for them to handle NTSC and PAL in the same firmware in R.O.B. Get a flash of light, see if there's another flash of light within 1s/50=20ms-ish. (Regardless of whether there is, be ready to receive another "clock" bit after 33ms)

If we finish disassembling the code we might find out what kind of window R.O.B. is looking for.

Pokun
Posts: 1448
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: R.O.B. Firmware

Post by Pokun » Sun Dec 01, 2019 9:01 am

Uh, I suspect that R.O.B. requires quiet time both before (the three preceeding vsyncs) and after (either Z or padding).

... Admittedly, I don't know why it would require quiet time after.
Oh I didn't understand that the extra vsync is at the end.

Anyway, I imagine that ideally all necessary flashes should be there no matter what colour the background is. Even if it's black, if the phototransistor happens to be directed towards a bright part of the screen the command might fail, so the whole screen should probably always be flashed to guarantee that all data is sent.

I'm looking forward to a disassembly that uncovers ROB's remaining secrets, with exactly how many flashes and with what timing he expects.

nocash
Posts: 1211
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: R.O.B. Firmware

Post by nocash » Sun Dec 01, 2019 9:43 am

One detail that wasn't cleared mentioned here yet: One of the ROB webpages says that the light sensor uses same components as the zapper lightgun, and the zapper is known to ignore "constant" light, it will pass-on the light signal only if it receives 15kHz scanline pulses. So, a 60Hz light pulse would need to be divided into smaller 15kHz pulses.

Lightgun optics are usually including a photo sensor, a barrel, and a lens. That's making the sensor to see only small section of the screen, with maybe a dozen scanline pulses. Anything outside of that window is not visible to the light sensor (in so far it doesn't matter what color is output during vblank because the sensor won't see it).
On the other hand, when using a LED to emulate flashes, one should flash the LED only during the visible period (ie. only a dozen 15kHz scanlines, then switch to dark until next 60Hz frame).

For ROB, there was also that sunglasses add-on. That might also affect the size (?) of the visible window, or the visible color range.
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

lidnariq
Posts: 9403
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: R.O.B. Firmware

Post by lidnariq » Sun Dec 01, 2019 11:41 am

Pokun wrote:
Sun Dec 01, 2019 9:01 am
Anyway, I imagine that ideally all necessary flashes should be there no matter what colour the background is. Even if it's black, if the phototransistor happens to be directed towards a bright part of the screen the command might fail, so the whole screen should probably always be flashed to guarantee that all data is sent.
Don't the two existing commercial games only flash the background color, though?
nocash wrote:
Sun Dec 01, 2019 9:43 am
One detail that wasn't cleared mentioned here yet: One of the ROB webpages says that the light sensor uses same components as the zapper lightgun, and the zapper is known to ignore "constant" light, it will pass-on the light signal only if it receives 15kHz scanline pulses. So, a 60Hz light pulse would need to be divided into smaller 15kHz pulses.
Previously, when I was experimenting with the Zapper, I discovered that a single sufficiently bright flash of light was sufficient to trigger the Zapper's photosensor. (I even explored the idea using this to transfer data to the NES, but decided the bandwidth was too low – around 6kbit/sec – to be worth releasing)

Maybe some day I'll get my hands on a spectrophotometer and quantify exactly what the Zapper is looking for. Doesn't seem like it'll be any time soon.
For ROB, there was also that sunglasses add-on. That might also affect the size (?) of the visible window, or the visible color range.
Reportedly, the sunglasses were there to help with bright rooms. Since the photodiode responds to all light, not just modulated light, and the photodiode's output saturates after a certain number of photons, one may need to reduce the total number of photons it sees.

There isn't enough room in R.O.B. for the exact same lens as the Zapper. I don't know if it's only using the photodiode's internal lens or if there's some other optics.

Pokun
Posts: 1448
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: R.O.B. Firmware

Post by Pokun » Sun Dec 01, 2019 1:29 pm

I got the Famicom version of ROB (just called Robot) CIB quite cheap, but the shades wasn't included. He works alright without them even with the light on though. I'd like to get them one day to complete my set. There's no mention of them in the manual as far as I can remember so it's possible they where not originally included, and only included in later sets after customers complaining (it seems to come with a unique insert paper as well).

BTW there is a picture on the phototransistor in the Adafruit guide. I see no barrel, but it might be in the eye of the head case. A working timing is also described.

lidnariq wrote:
Sun Dec 01, 2019 11:41 am
Pokun wrote:
Sun Dec 01, 2019 9:01 am
Anyway, I imagine that ideally all necessary flashes should be there no matter what colour the background is. Even if it's black, if the phototransistor happens to be directed towards a bright part of the screen the command might fail, so the whole screen should probably always be flashed to guarantee that all data is sent.
Don't the two existing commercial games only flash the background color, though?
Nope, they change all palette entries to either black or green (except in test mode) just like in my program. As I said before I haven't checked their code but I can see in Mesen that all palettes are overwritten.

In my old program, instead of changing the palettes, I used the normally unused palette entry $3F04 and enabled forced blanking, so not all palette entries had to be changed (because it was first designed by UglyJoe for Family BASIC, and he didn't want to have to save the original palette). This time I didn't want to use forced blanking though so I just flashed all palette entries like the games do.

nocash
Posts: 1211
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: R.O.B. Firmware

Post by nocash » Fri Dec 06, 2019 2:40 pm

I have disassembled most of the ROB rom (I'll release the disassembly later, but isn't fully finished yet). I haven't spotted any useful commands (except maybe one that seems to set an unused bit; which appears to be useless). But I've noticed some glitches and oddities, which I am unsure how they behave in practice...

The motors seem to be just motors? Not stepping motors? With a stepping motor one could do 100 steps, and would then know the exact position. With a normal motor one can just do something like running the motor for 100ms, and hope for the best. For example, if the batteries drop below 6V... then the moves would become shorter and shorter, right? Or does the thing somehow work reliable without hitting such problems?

The power-up init (and reset command) is working about as so:
-- rotate 4 steps right (and up) (and open arms), until/unless already being at rightmost position
-- rotate 2 steps left (and up) (and open arms), ie. rotate to center
-- move 1 step up, unless already being at topmost position
I assume that is intended to reach horizontal center and topmost position.

The main bug is that it doesn't seem to do enough "up" steps (eg. if it's powered-on in bottom-right position, then it would do only 0+2+1 steps upwards, that isn't enough to go from bottom to top). Can somebody test/confirm if power-on behaves like that?
As a workaround, software might send a few more "move up" commands to fix that problem, so it might be no problem in practice.

Another small issue is that 4 steps right are normally enough to move from leftmost to rightmost. But it might be a bit short if the position had drifted slightly beyond leftmost due to some mechanical inaccuracies. Well, unless it's hitting a mechanical barrier and can't exceed leftmost at all.

The commands are 13bit wide (carry+4bit+4bit+4bit) (starting with three dark frames, then one green frame). There seems to be no need to output a dark frame after that 13bits. Well, apart from the command execution time: You can't send a new command when the old one is still busy (so one must send several dummy frames (with don't care colors) while motors are running; and maybe one does also need at least one dummy frame when just sending the LED=On command).

---

Concerning CIC opcodes. Segher mentioned a NEG A instruction, and a PORT[L]=0 instruction. I suspect that' both don't really exist in that form, and that they are just same as in SM590 datasheet (apart from opcode 44h/54h and 48h/49h being swapped in newer chips).

So, PORT[L]=0 would be actually PORT[L]=RAM[HL]. The CIC roms for older & newer chips are actually using that instruction... and they do always set RAM[HL]=0 before using the instruction... it does look pretty much as if they are solely doing that because the instruction is doing PORT[L]=RAM[HL] rather than PORT[L]=0.

And NEG A might be as well the same as SKIP_if_CARRY from the SM590 datasheet. For ROB it's definetly like that. For CICs it's harder to say because the instruction is used only with the newer chips (that have 44h/54h swapped), and it's only used in one place (the weird function that seems to execute random dummy opcodes, including opcode 5Eh).
Going by the disassembly, nothing hints on NEG A to exist, so it might have been just a wrong guess (unless somebody had actually identified a NEG A circuit in the decapped chip logic).
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

lidnariq
Posts: 9403
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: R.O.B. Firmware

Post by lidnariq » Fri Dec 06, 2019 3:18 pm

nocash wrote:
Fri Dec 06, 2019 2:40 pm
The motors seem to be just motors? Not stepping motors? With a stepping motor one could do 100 steps, and would then know the exact position. With a normal motor one can just do something like running the motor for 100ms, and hope for the best.
Yes, they're just cheap brushed DC motors with plastic gears:

A bunch of screengrabs from a video:
e.g. elevation:
http://youtu.be/qMTDTNs9Tfw?t=769
http://youtu.be/qMTDTNs9Tfw?t=769
claw:
http://youtu.be/qMTDTNs9Tfw?t=780
http://youtu.be/qMTDTNs9Tfw?t=780
base:
http://youtu.be/qMTDTNs9Tfw?t=828
http://youtu.be/qMTDTNs9Tfw?t=828
There's metal plates on all three degrees of freedom, and some repair advice seems to be to glue them "back" together ... I think that might be a torque limiter? Gluing it up is probably actually a terrible idea, but if the R.O.B. is already nonfunctional I guess "destroying the gears at some random point in the future" is better than "it doesn't work at all right now".

Depends exactly on how tactical the glue application is, of course.

--

As to how reliable positioning is as the batteries discharge? I don't know. Pokun?

nocash
Posts: 1211
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: R.O.B. Firmware

Post by nocash » Sat Dec 07, 2019 10:47 am

Uh, that pictures are difficult to understand. But I think I got it:
Middle picture with red/blue wheels is for opening/closing the arms, and it does rotate the long axis (which goes to the 2nd arm).
Upper picture with black/cyan wheel is for up/down move, with some wheels sitting on same long axis as above (but not firmly attached to that axis).
Lower picture with white/yellow wheels is in base unit for left/right rotation.

Yeah, the metal plates seem to be for transferring force from a plastic wheel to another nearby wheel (or to the long axis for the arms). I guess that plates were intended to use some sticky fat instead of glue. With the glue on the up/down wheels, the gears are probably self-destroying with some loud krakrakrakrakrak sound when trying to move beyond topmost/bottommost position?

I think I might have misunderstood the function of the switches. I had originally thought that they get triggered at upper/right position (similar as pos0 switches in floppy drives). But that doesn't seem to comply with the software disassembly...
Now I am wondering if the switches get triggered at every step position, ie. for the five rotate left/right postitions, are there five edges/notches that trigger the switch at each position?
Or maybe only at the middle three positions (the software runs motors until with switch-trigger, or until timeout) (the timeout might be for mechanical errors... or for absent switch-triggering on leftmost/rightmost positions)?

Oh, and another note on needing darkness after end of command: After sensing light, the software waits for end-of-light (that is intended to find the position where to start looking for the next bit). So if the last bit was green, the software will wait endless if the light is kept on without darkness in following vblank (it won't need a full dark frame though, just vblank should be enough).
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

lidnariq
Posts: 9403
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: R.O.B. Firmware

Post by lidnariq » Sat Dec 07, 2019 2:06 pm

nocash wrote:
Sat Dec 07, 2019 10:47 am
With the glue on the up/down wheels, the gears are probably self-destroying with some loud krakrakrakrakrak sound when trying to move beyond topmost/bottommost position?
In the best case, the motor will stall. In the worst case ... yeah, the gears will run past each other and quickly strip themselves.
I think I might have misunderstood the function of the switches. I had originally thought that they get triggered at upper/right position (similar as pos0 switches in floppy drives). But that doesn't seem to comply with the software disassembly...
I made the same assumption...
Now I am wondering if the switches get triggered at every step position, ie. for the five rotate left/right postitions, are there five edges/notches that trigger the switch at each position?
Found another video with some evidence to support this.

First, we're told that the pair of blue wires connects to the base limit switch.

So here's where the limit switch sits in the base, under the battery compartment:
http://youtu.be/_KJK4bnokrU?t=33
http://youtu.be/_KJK4bnokrU?t=33
rob-base-limit-switch-in-situ.jpg (28.82 KiB) Viewed 4614 times
And here's a view of the molded plastic that holds it in place:
http://youtu.be/_KJK4bnokrU?t=32
http://youtu.be/_KJK4bnokrU?t=32
rob-base-empty-place-for-base-limit-switch.jpg (26.9 KiB) Viewed 4614 times
And here's the five detents in the base that the limit switch can enter:
http://youtu.be/_KJK4bnokrU?t=26
http://youtu.be/_KJK4bnokrU?t=26
rob-detents-for-base-limit-switch.jpg (10.16 KiB) Viewed 4614 times
Or maybe only at the middle three positions (the software runs motors until with switch-trigger, or until timeout) (the timeout might be for mechanical errors... or for absent switch-triggering on leftmost/rightmost positions)?
I think the six ridges on the back of ROB's "neck" are the vertical limit switch detents. Not clear how we get seven positions out of that, though.
http://youtu.be/_KJK4bnokrU?t=50
http://youtu.be/_KJK4bnokrU?t=50
rob-neck-with-detents.jpg (15.58 KiB) Viewed 4614 times
I think the vertical limit switch is nestled in between the two motors on the back, where you can vaguely see a green/blue wire:
http://youtu.be/_KJK4bnokrU?t=50
http://youtu.be/_KJK4bnokrU?t=50
rob-shoulders-limit-switch-and-motors.jpg (17.7 KiB) Viewed 4614 times

nocash
Posts: 1211
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: R.O.B. Firmware

Post by nocash » Sat Dec 07, 2019 8:26 pm

Okay, with the switch getting triggered (or released) by that notches it does make all more sense. And then it's also no problem to find the positions with normal motors instead of stepping motors. Six positions for up/down should be right (not seven).

I've finished my firmware disassembly: https://wiki.nesdev.com/w/index.php/R.O.B._Firmware
It's also linked on the https://wiki.nesdev.com/w/index.php/R._O._B. page (and I've renamed half & full steps to 1 & 2 steps, I think that makes more sense, especially with the notches representing one step). Ah, or is one of the official games using the notation "half step" somewhere?

For where they are using glue: It looks as if there is normally a corn-flake shaped spring between the metal plate and plastic wheel. Maybe glue could work when applying it only to one side of the corn-flake thing... although the terrible repair guides seem to suggest to put glue everywhere at best guess.

For the light sensor, the 9pin chip is called "IR3T07 JAPAN, SHARP 8637 B", that chip was somewhere also mentioned to be used for nintendo's arcade guns (in VS unisystem or PC10 or so). As far as I know, the NES zappers are using "IR3T07A" (with -A suffix). Unless very old zappers were using "IR3T07", too?

I am still not sure if/what kind of lens or barrel is used in ROB. In terms of light guns and light sensors "barrel" would just mean "a hole where the light can enter the case" (leaving apart internal reflections). And a lens might help to focus on the TV set, or a certain spot on the TV set, and maybe to receive "stronger" light pulses as than without focus lens. I don't know if a lens would be needed for any of those purposes in this case.
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty

Post Reply