Robopanda Hacks and mods

282 posts / 0 new
Last post
Anonymous
Anonymous's picture
Robopanda Hacks and mods

Has any one found any robopanda hacks?

i've thought of changing the LEDs in its eyes.

How about installing an IR sensor in one of the eyes??

I've just thought about these, i'm too afraid of breaking my little panda.

Nocturnal
Nocturnal's picture
There is already an IR sensor

There is already an IR sensor in the eye, if you look close at his... left (I think) eye when he is off, you should be able to see it.

Nocturnal
Nocturnal's picture
Why would they?

Why would they?

Nocturnal
Nocturnal's picture
I think they said IR Vision,

I think they said IR Vision, which is different.

Rudolph
Rudolph's picture
An IR receiver isn't IR

An IR receiver isn't IR vision. Vision requires an emitter and a receiver (at least one of each) to "bounce" the signal off an object and get that signal back. The quicker the IR signal sent by the emitter is received back, the closer the object in question is in proximity. A little bit of math can tell the robot a semi accurate distance measurement, if the software has been set up to do that.

Perhaps Panda's receiver is in preperation for the impending programmable remote?

milw
milw's picture
That's my guess too. has

That's my guess too. has anyone tried shooting panda with any of the remotes?

Nocturnal
Nocturnal's picture
Oh, it also has a IR emitter

Oh, it also has a IR emitter in the other eye.

Rudolph
Rudolph's picture
Perhaps they're in place for

Perhaps they're in place for a future firmware upgrade to give your Panda the ability to Tivo Animal Planet.

I can't bring myself to spend the money on the Panda to find out the answers to these wonderments. Maybe if my kid showed any interest in it at all I would... 

sevik
sevik's picture
If someone interested in

If someone interested in RoboPanda reverse engineering/hacking - check out http://sevik.org/robopanda

There is work in progress, but some results already achieved :))

milw
milw's picture
Wow, that's very impressive

Wow, that's very impressive Sevik! Do you have any videos of him saying something new? And would you consider posting a picture of your dev board and emulator cartridge in this thread? It will take a long time for me to read and truly understand all that you've figured out, but definitely a very nice job!

Nocturnal
Nocturnal's picture
Sevik is not quite that far

Sevik is not quite that far along yet. Exactly how the audio is formated is still in question.

sevik
sevik's picture
This is not such an easy task

This is not such an easy task :)

But we are moving :)

Hope to get attention of some more than 3 capable persons to this task... :)

About audio - I hope that some of codecs (only 2 seen in stock cartridges ) can be uncompressed PCM :))

milw
milw's picture
sevik said:

sevik said:
...Hope to get attention of some more than 3 capable persons to this task... :) ...

Are you working on this with other people, and are you asking for more people to help? It sounds like Nocturnal is already working with you perhaps?

sevik
sevik's picture
For now only me and Nocturnal

For now only me and Nocturnal really involved in this task.

And I'll be glad to see some more :))

More technical discussion takes place at Unofficial Robosapien Hacks and Mods Forum

Peter Redmer
Peter Redmer's picture
Thanks for sharing your

Thanks for sharing your project, Sevik. We'd love to hear more updates on how the project is going, and don't be afraid to discuss it here too :) There are lots of people here who would really enjoy seeing it.

Keep us posted and have fun. Pete

milw
milw's picture
Are you looking for any

Are you looking for any skills in particular that you and Nocturnal don't already have covered? I have a Robopanda to hand, and would love to hear him sing Stairway to Heaven instead of 'lets have an adventure'!

sevik
sevik's picture
:)) You can try to guess

:)) You can try to guess audioencoding methods :))

For now we need to decode many bytecodes and guess and check effects of many 29XX commands.

For decoding bytecodes small tracer like first nocturnal's version is really enought (there are need to trace first 30-40 accesses) and small spi flash based cardemu needed (minimal valid cartridge image can be put in 100-200 bytes).

I have big tracer and cartridge emulator, so any tasks with big amount of needed tracing/large cartridge contents can be accomplished.

There are always need in better tools :)) I have decoder and emu, but no real assembler.

milw
milw's picture
So from this bit of your web

So from this bit of your web documentation:
Audio data chunk format:

* int32 - length
* int8 - codec (07 or 09)
* int8 - something (always 128)
* 32 or 48 byte chunks of data
* int16 - something (always FFFF)
* int16 - checksum?

Looking in Nocturnal's cartridge image for patterns of x07 0F nn(32 or 48x) FF FF,
should hit a whole series of audio chunks, correct?

Nocturnal
Nocturnal's picture
Or you can go here and here,

Or you can go here and here, I wrote a program to dump the records out a while back.

Its been a while, but I'm pretty certain I dropped the record structure (except the details recorded in the name, which is probably recordnum-type-checksum), and just kept the data.

milw
milw's picture
Ah, thanks Nocturnal. Do you

Ah, thanks Nocturnal. Do you know if those are the equivalent of the cartridge_dump *.aud files from Sevik's emu_log archive? Also I gather the data is little-endian, correct?

Nocturnal
Nocturnal's picture
They are not quite the same,

They are not quite the same, the *.aud files include the record structure as well as the data, mine are just the data. We also seem to be disagreeing on the total number of items.

sevik
sevik's picture
there are list of pointers to

there are list of pointers to start of audio data chunks at start of cartridge (starting at 0005 offset, 3 byte for pointer up to @PEND string, So there are no need for guessing for number of items and its location. And yes, *.aud files - it's exactly this audio chunks.

play bytecode reads start of chunk from this table (see emu logs)

there are at least 2 codecs supported, and when by mistake I putted another value player worked too, but used yet another (not 32 or 48) frame size.

I plan to find all accepted codecs values but this task is lower in list - after decoding of most used bytecodes, assembler in cartridge builder and stack support in emu :))

sevik
sevik's picture
*.aud files has all record

*.aud files has all record structure, except for 4 bytes with length.

at least codec value is integral part of data, and can't be dropped :))

Looking at traces I found that player always (for 7 codec at least, I have not waited to end of song) reads 356 bytes more than really present in audio data...

may be It's player fifo prefetch. It matches initial read size of 254+140 bytes - 32 byte frame - 6 bytes of header(length + codec + 0x128). I think tailer really not supposed to be read by player.

Need to check this values for 9 codec.

sevik
sevik's picture
about different number of

about different number of chunks in our decompilations:

I dumped chunks based on index in begining of cartridge - and some chunks listed there more than 1 time (9 and 10 for example).

The same situation with mover scripts exists - there are many aliases for some scripts.

Nocturnal
Nocturnal's picture
Codec value is meta data

Codec value is meta data about the data, and it is preserved in my file naming scheme. So yes, it can be dropped from the data.

The way I read out the records was in sequence, using the record length to find the start of the next record, and continuing until I reached a record with a length of zero.

So assuming you dumped out the records using the index to find the start of a record, and then the record size for the amount of data, did you check for duplicate addresses?

Nocturnal
Nocturnal's picture
Damn it! I hate it when

Damn it! I hate it when someone replies while I am replying, but I guess its my fault for taking so damn long to write a reply.

sevik
sevik's picture
:))

:))

I dont like encoding metadata in filenames too :))

 

sevik
sevik's picture
Updated emulator with stack

Updated emulator with stack operations, first 139ms of training trace simulated successfully, including spi_reads with computed (not looked up in logs) addresses :))

Cycles with 0EXX commands successfully emulated too.

    7.359 00E8EC [SPI]   2: A1 01
    7.519 00E796 [CPU] 0063CB: call 00A1 // stack: [73CC]
    7.519 00E796 [SPI]   4: 95 C0 02 00
    7.903 002142 [CPU] 0000A1: extend // stack: [0000,73CC]
    7.903 002144 [CPU] 0000A2: pop @0A // @A = 0000, stack: [73CC]
    7.903 002146 [CPU] 0000A3: set $0, #00 // $0 = 00
    7.903 002148 [CPU] 0000A4: push $0 // stack: [0000,73CC]
    7.903 00214A [CPU] 0000A5: cmp #24 // 0000 == 24?, stack: [73CC]
    7.903 00214C [CPU] 0000A6: rjump_f0 0000B2
    7.903 00214E [CPU] 0000A7: rjump 0000AB
    7.903 002142 [SPI]  14: 02 29 0A 24 00 A8 00 2D 24 0E 0B F0 03 E0
    8.276 002156 [CPU] 0000AB: push @0A // stack: [0000,73CC]
    8.276 002158 [CPU] 0000AC: push $0 // stack: [0000,0000,73CC]
    8.276 00215A [CPU] 0000AD: pop2 @0A // @A,@B = 0000,0000, stack: [73CC]
    8.276 00215C [CPU] 0000AE: push #0000 // stack: [0000,73CC]
    8.276 00215E [CPU] 0000AF: push $0 // stack: [0000,0000,73CC]
    8.276 002160 [CPU] 0000B0: pop2 @2E // @2E,@2F = 0000,0000, stack: [73CC]
    8.276 002162 [CPU] 0000B1: rjump 0000A8
    8.276 002156 [SPI]  14: 0A 20 00 2D 0A 25 00 00 00 2D 2E 25 F7 E7
    8.484 002150 [CPU] 0000A8: inc $0 // $0 = 0001, stack: [0000,73CC]
    8.484 002152 [CPU] 0000A9: drop // stack: [73CC]
    8.484 002154 [CPU] 0000AA: rjump 0000A4
    8.484 002150 [SPI]   6: C0 2E 7E 29 FA E7
    8.752 002148 [CPU] 0000A4: push $0 // stack: [0001,73CC]
    8.752 00214A [CPU] 0000A5: cmp #24 // 0001 == 24?, stack: [73CC]
    8.752 00214C [CPU] 0000A6: rjump_f0 0000B2
    8.752 00214E [CPU] 0000A7: rjump 0000AB
    8.752 002148 [SPI]   8: 00 2D 24 0E 0B F0 03 E0
    9.133 002156 [CPU] 0000AB: push @0A // stack: [0000,73CC]
    9.133 002158 [CPU] 0000AC: push $0 // stack: [0001,0000,73CC]

....

   39.572 00215E [CPU] 0000AF: push $0 // stack: [0023,0000,73CC]
   39.572 002160 [CPU] 0000B0: pop2 @2E // @2E,@2F = 0023,0000, stack: [73CC]
   39.572 002162 [CPU] 0000B1: rjump 0000A8
   39.572 002156 [SPI]  14: 0A 20 00 2D 0A 25 00 00 00 2D 2E 25 F7 E7
   39.782 002150 [CPU] 0000A8: inc $0 // $0 = 0024, stack: [0023,73CC]
   39.782 002152 [CPU] 0000A9: drop // stack: [73CC]
   39.782 002154 [CPU] 0000AA: rjump 0000A4
   39.782 002150 [SPI]   6: C0 2E 7E 29 FA E7
   39.988 002148 [CPU] 0000A4: push $0 // stack: [0024,73CC]
   39.988 00214A [CPU] 0000A5: cmp #24 // 0024 == 24?, stack: [73CC]
   39.988 00214C [CPU] 0000A6: rjump_f0 0000B2
   39.988 002148 [SPI]   6: 00 2D 24 0E 0B F0
   40.110 002164 [SPI]   2: 78 29
   40.110 002164 [CPU] 0000B2: return // stack: []
   40.301 00E79A [CPU] 0063CD: call 05E7 // stack: [73CE]
   40.301 00E798 [SPI]   6: 02 00 DB C5 02 00
   40.481 002BCE [CPU] 0005E7: call 055E // stack: [15E8,73CE]
   40.481 002BCE [SPI]   4: 52 C5 02 00
   40.779 002ABC [CPU] 00055E: set $0, #00 // $0 = 00
   40.779 002ABE [CPU] 00055F: push $0 // stack: [0000,15E8,73CE]
   40.779 002AC0 [CPU] 000560: cmp #14 // 0000 == 14?, stack: [15E8,73CE]
milw
milw's picture
Nocturnal, do you have a high

Nocturnal, do you have a high res image of the panda cpu showing all the pin names? The corner I can see in your article has a good match to the pins of the SunPlus GPCE (here's one datasheet link). My apologies if you've already figured that out, my eyes get tired of reading orange on black!
ps also can you see the xtal frequencey?

Nocturnal
Nocturnal's picture
Close, thats actually almost

Close, thats actually almost identical to the one I think it probably is, your just missing the ICE port and a little bit of memory.

Its actually a pity that the resolution of the photos in the FCC filings is so low, otherwise we would be able to read the markings on the chip. Unfortunately as they are, its a little to blurry.

The gallery limits image to 900px, so its no surprise you can't read the labeling. I have a photo of the top and bottom. If you want better quality and more detail I'll have to pull out the scanner.

I also have made available copies of the datasheets for the probable cpu, probably SPI ROM, bus extenders, possible SND01A chip, and the eeprom here. The unlabeled epoxy chip is probably an audio amplifier, but I haven't confirmed that.

Oh, I almost forgot, I can't quite read the labeling on the crystal (I'll need to pull out a magnifying glass), but it looks like a standard 32.768khz watch crystal.

BTW, have you ever heard of SACM_S200?

sevik
sevik's picture
I have found somewhere on

I have found somewhere on chinese sites set of audio utilities for sunplus.

I have encoded sample files, but they does not looks similar (none of it has 32/48 byte frames).

I'll post sample files and utilites at evening when I will be at home.

Found it again here: http://211.64.32.2/dzxywlx/shiyanshi/index0/pic/faming/

Nocturnal
Nocturnal's picture
*Nods* I found that as well.

*Nods* I found that as well. The difference would be that SACM_S480 is a much higher quality codec.

sevik
sevik's picture
for 07 codec 32 bytes readed

for 07 codec 32 bytes readed for every 12.5 ms - it's 20kbit/s...

32/0.0125*8=20480

09 codec - 48 bytes at 20 ms - 24kbit/s

48/0.016*8=24000

So it looks like a2000 codec, but byte patterns is very different...

milw
milw's picture
heh, after reading GPCE data

heh, after reading GPCE data sheets last night, I'd settled on the GPCE061AV11 as well.

milw
milw's picture
Nocturnal said:

Nocturnal said:
...Oh, I almost forgot, I can't quite read the labeling on the crystal (I'll need to pull out a magnifying glass), but it looks like a standard 32.768khz watch crystal.
BTW, have you ever heard of SACM_S200?

 That'd make sense since the crystal pads are marked 'X32', which fits for a watchdog timer. Some of the datasheets make it look like the 'SACM' are voice synthesis algorithms rather than codecs. Sevik, which of the links on that page are you referring to for the utilities? Thx also for the links to images etc!

Nocturnal
Nocturnal's picture
Look near the bottom of the

Look near the bottom of the page, on the left hand side, in the box labeled " Voice TOOLS"

sevik
sevik's picture
I have tried different values

I have tried different values as codecs.

Sound for 4,5,6,7 codecs looks similar and noise-like with increasing frequency.

Sound for 8 fnl 9 codec is very different and sounds as random beeps.

Looking at rates and frame sizes 4-7 codecs can be 2bit adpcm or something like wit 5,6,7 and 8 kHz sample rate.

And according to sound 8 and 9 codecs is something like mp3/lpc/celp/etc framed, bit-packed codec.

But similar looking 00 00 .. 88 sequences for very different codecs support idea of scrabling audiodata.

8000 254+34X reset          no sound
8001 254+34X reset          no sound
8002 254+34X reset          no sound
8003 254+34X reset          no sound

8004 254+128 20/16ms = 10k  sound
8005 254+132 24/16ms = 12k  sound
8006 254+136 28/16ms = 14k  sound
8007 254+140 32/16ms = 16k  sound

8008 254+148 40/16ms = 20k  another sound
8009 254+156 48/16ms = 24k  yet another sound

800A 254+34X reset          no sound
800B 254+34X reset          no sound

Update:
Some more experimenting with more regular data saws no principal difference between different codecs...

Seems difference was dependent on frame size of test audio and its relation to tested codecs frame size (was used encoded using sunplus tools 20k sample file)

All 0 datafile roduces silence in 7 and 8 codecs (others not tested), so scrambling idea not confirmed...

milw
milw's picture
A question re stringing

A question re stringing together the audio chunks, are they read sequentially, or is there any thing that indicates the sequence of chunks? Also, did you guys look at the 'SPCE061' section on that page? That seems to be a closer match than the GPCE061 imho. Not that knowing the exact mcu would help much, as I have painfully learned!

sevik
sevik's picture
There are CPU bytecode for

There are CPU bytecode for starting of chunk number X play

Code used for testing of player:

0020: 0004   push      #0004  // push 0004 to stack                                                                                       
0021: 291A   volume           // pop volume from stack                                                                                    
0022: 0002   push      #0002  // push 0002 to stack                                                                                      
0023: 2928   play             // pop audio index from stack and start play
       L0_1:                  // xrefs: 0026                                                                                               
0024: 0000   push      #0000  // push 0000 to stack                                                                                        
0025: 297E   drop             // pop and drop value from stack                                                                             
0026: E7FE   rjump     L0_1   // jump to 0024                                    

push #2 at 0022 - it's an index of audio chunk in table at start of cartridge

index is 1 based starting at 0005, 3 bytes for chunk address

sevik
sevik's picture
I tried to shift data 1 byte

I tried to shift data 1 byte right with xoring by magic string before and after - this produces Darth Vader like sound :))

playing codec 7 audio data with codec 6 - produces r2d2 like sound :))

Seems there are star wars inside :))

http://sevik.org/robopanda/test_codecs.wav

Sounds:
original sound
shifted 1 byte sound
original sound
codec 06
original sound
codec 08
original sound
codec 09

Code:

0020: 0004      push   #0004    // push 0004 to stack                                                                                        
0021: 291A      volume          // pop volume from stack                                                                                     
0022: 0001      push   #0001    // push 0001 to stack                                                                                        
0023: 2928      play            // pop audio index from stack and start play                                                                 
0024: 2923      wait_play       // wait for and of play                                                                                      
0025: 0002      push      #0002 // push 0002 to stack                                                                                        
0026: 2928      play            // pop audio index from stack and start play                                                                 
0027: 2923      wait_play       // wait for and of play                                                                                      
0028: 0001      push      #0001 // push 0001 to stack                                                                                        
0029: 2928      play            // pop audio index from stack and start play                                                                 
002A: 2923      wait_play       // wait for and of play                                                                                      
002B: 0003      push      #0003 // push 0003 to stack                                                                                        
002C: 2928      play            // pop audio index from stack and start play                                                                 
002D: 2923      wait_play       // wait for and of play                                                                                      
002E: 0001      push      #0001 // push 0001 to stack                                                                                        
002F: 2928      play            // pop audio index from stack and start play                                                                 
0030: 2923      wait_play       // wait for and of play                                                                                      
0031: 0004      push      #0004 // push 0004 to stack                                                                                        
0032: 2928      play            // pop audio index from stack and start play                                                                 
0033: 2923      wait_play       // wait for and of play                                                                                      
0034: 0001      push      #0001 // push 0001 to stack                                                                                        
0035: 2928      play            // pop audio index from stack and start play                                                                 
0036: 2923      wait_play       // wait for and of play                                                                                      
0037: 0005      push      #0005 // push 0005 to stack                                                                                        
0038: 2928      play            // pop audio index from stack and start play                                                                 
0039: 2923      wait_play       // wait for and of play                                                                                      
          L0_1:                 // xrefs: 003C                                                                                               
003A: 0000      push      #0000 // push 0000 to stack                                                                                        
003B: 297E      drop            // pop and drop value from stack                                                                             
003C: E7FE      rjump     L0_1  // jump to 003A                                        

milw
milw's picture
hm interesting... so is

hm interesting... so is 'touch my arm to see what i've learned' a single audio chunk, and is it normally the first chunk in the index? or have you just stored it there for convenience in your testing? I'm still not clear on whether multiple chunks are played in sequential order when panda says something, or is each chunk a complete saying/recording?

sevik
sevik's picture
it's first in original black

it's first in original black cartridge

for testing I compiled test cartridge with 5 different variants of this chunk:
original index 1
shifted index 2
with 06 80 instead of 07 80 in header index 3
08 80 - index 4
09 80 - index 5

and code from previous message as cpu code.

http://sevik.org/robopanda/test_codecs.bin

sevik
sevik's picture
chunks which I checked - is

chunks which I checked - is complete phrases.

milw
milw's picture
ok, so a whole sentence is in

ok, so a whole sentence is in one chunk then, at least most of the time. Would it be possible for you to capture the speaker output as a wav file, so we have a 'before' and 'after' to compare? (I know it won't be perfect because your capture would only be an approximation of what was fed to the dac).

sevik
sevik's picture
I have not dissected my panda

I have not dissected my panda yet :)) You can write this cartridge image to any spi rom and check for yourself :))

For before and after - I think it will be very different.

For real audiodata analyze there are need for many small test for each bit position in frame to identify bit fields boundaries and it's meaning.

I think there are one general principle for all codecs implemented in robopanda and some of codecs implemented by "Voice Tools". They must have comparable number of coefficients, but with different resolution and some coefficients omitted in lower bitrates.

If you check voice tools output for 20k codec - there are 96 bytes frame with similar structure - low "1" count at start in random positions, and many 10..0 sequences at end.

sevik
sevik's picture
I think magic string is

I think magic string is tightly related to bifields boundaries :))

sevik
sevik's picture
Attached to DAC1 output...

Attached to DAC1 output...

Using scope - there are not seen remains of discretization rate or PWM of some sort.

Will check further using linear input of audiocard.

sevik
sevik's picture
Wav files posted to http:/

Pages