Jump to content

x87bliss

Members
  • Content Count

    3
  • Joined

  • Last visited

Community Reputation

0 Neutral

About x87bliss

  • Rank
    Combat Commando
  1. 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.
  2. 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.
  3. 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.
×
×
  • Create New...