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.
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.
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.
Why would they?
I think they said IR Vision, which is different.
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?
That's my guess too. has anyone tried shooting panda with any of the remotes?
Oh, it also has a IR emitter in the other eye.
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...
If someone interested in RoboPanda reverse engineering/hacking - check out http://sevik.org/robopanda
There is work in progress, but some results already achieved :))
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!
Sevik is not quite that far along yet. Exactly how the audio is formated is still in question.
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 :))
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?
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
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
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'!
:)) 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.
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?
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.
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?
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.
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 :))
*.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.
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.
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?
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.
:))
I dont like encoding metadata in filenames too :))
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.
Pages