Elvis Cartridge has been hacked (updated: Article is on the way)

361 posts / 0 new
Last post
RetroPlayer's picture
Elvis Cartridge has been hacked (updated: Article is on the way)

The Wowwee Alive Elvis utilizes a cartridge which contains all of his songs and monologues. Opening the cartridge, we found that it contained a single IC. We looked up the datasheet for this IC and determined that it was a 32MB 3.3v NAND flash. Using the datasheet and a multimeter, we were able to determine the pinout of the cartridge connector.

Knowing that xD and Smartmedia flash cards, typically used in cameras and MP3 players use a straight-through NAND flash interface, we compared the pinouts of the cards with the pinouts of the cartridge. We found that all needed signals were present to connect the cartridge directly to a USB xD/Smartmedia reader and dump the cartridge contents.

What we found was a very pleasant surprise! The cartridge is formatted as a standard FAT16 volume viewable by Windows, Linux, Mac, etc..

There are 123 files on the cartridge which takes up about 26.5MB of the 32MB cartridge. The cartridge is not write protected and there is approximately 5MB free.

First, we looked at the audio clips. The 8 Song titles, 8 Songs, 8 Karaoke versions of the songs, and 37 monologues are all regular MP3s with the file extension, *.dat. The audio clips are endcoded with these settings: 44.1kHZ, 128kb/s Joint Stereo.

For every audio clip, there is an animation script associated with it. Its filename is the same as the audio clip, but with a *.txt extension. It is not a text file and cannot be opened or edited with a text editor. Instead one must edit the files with a hex editor (or a custom program) once the format is decoded.

There is also one MSDOS *.exe file on the cartridge. Running it calculates the checksums of all files on the cartridge and the total checksum. It looks like it is used in production to ensure that none of files are corrupted before shipping.

What this means, so far, is that it should be possible to customize Elvis' behavior in his three modes of operation: Songs, Monologues, and Karaoke; including making him an entirely different character. Combined with GWJax's articles on customizing the Elvis skin, this makes for a great entry-level animatronics platform for halloween displays, etc...

What we cannot do, so far, using this method:

  • Connect Elvis to a PC to control him in real-time
  • Modify any of his voice and animations when in autonomous mode
  • Create any level of interactivity using his IR sensors
  • Add more sensors, motors, etc...

This limits the usefulness of this hack, but techniques are being discussed to utilitze this method to its fullest, however, it should be good enough for simple displays. Further research is being done to accomplish the rest of the above list.

Things left to do:

1. Modify Elvis to accept custom cartridges --DONE!

  • Option A: Modify USB smartmedia reader with cartridge slot
  • Option B: Create custom cartridge with xD adapter                    ---DONE!
  • Option C: Install xD or Smartmedia socket in the Elvis bust

2. Decode the animation scripts and write a program to create custom scripts --- 1/2 DONE (still need a decent program to make animations)

3. Dump flash on Elvis mainboard, determine its contents and develop a method for reflashing it in-circuit                           ---- DONE!

4. Possibly replace the CPU on the Elvis main board to accomplish full interactivity, addition of hardware, and real-time computer control

4. Determine practical methods of applying this knowledge to completely modify the behavior of the Elvis bust into a programmable and interactive animatronics platform.

RetroPlayer's picture

Here is a list of the files on the cartridge:

FOLDER M:\ ------- 0 123 26,529,375 26,529,375 (approximately 26.5MB) FAT16 format
FILE CoSong01.dat ********DAT files are audio
FILE CoSong02.dat ******** Audio is MP3 format
FILE CoSong03.dat ******** 44Khz 128Kbps Stereo
FILE CoSong04.dat ******** CoSong##.dat are full songs
FILE CoSong05.dat
FILE CoSong06.dat
FILE CoSong07.dat
FILE CoSong08.dat
FILE Mono01.dat ******** Monologues
FILE Mono02.dat
FILE Mono03.dat
FILE Mono04.dat
FILE Mono05.dat
FILE Mono06.dat
FILE Mono07.dat
FILE Mono08.dat
FILE Mono09.dat
FILE Mono10.dat
FILE Mono11.dat
FILE Mono12.dat
FILE Mono13.dat
FILE Mono14.dat
FILE Mono15.dat
FILE Mono16.dat
FILE Mono17.dat
FILE Mono18.dat
FILE Mono19.dat
FILE Mono20.dat
FILE Mono21.dat
FILE Mono22.dat
FILE Mono23.dat
FILE Mono24.dat
FILE Mono25.dat
FILE Mono26.dat
FILE Mono27.dat
FILE Mono28.dat
FILE Mono29.dat
FILE Mono30.dat
FILE Mono31.dat
FILE Mono32.dat
FILE Mono33.dat
FILE Mono34.dat
FILE Mono35.dat
FILE Mono36.dat
FILE Mono37.dat
FILE Song01.dat ***** Songs without Elvis vocals
FILE Song02.dat ***** For Sing-Through mode (karaoke)
FILE Song03.dat
FILE Song04.dat
FILE Song05.dat
FILE Song06.dat
FILE Song07.dat
FILE Song08.dat
FILE SongNa01.dat ****** Song names in Elvis voice
FILE SongNa02.dat
FILE SongNa03.dat
FILE SongNa04.dat
FILE SongNa05.dat
FILE SongNa06.dat
FILE SongNa07.dat
FILE SongNa08.dat
FILE ELVIS.EXE ****MS-DOS console app. Calculates the checksum of all files
FILE CoSong01.txt ****Animation scripts, named after the audio clip
FILE CoSong02.txt ****it corresponds with.
FILE CoSong03.txt
FILE CoSong04.txt
FILE CoSong05.txt
FILE CoSong06.txt
FILE CoSong07.txt
FILE CoSong08.txt
FILE Mono01.txt
FILE Mono02.txt
FILE Mono03.txt
FILE Mono04.txt
FILE Mono05.txt
FILE Mono06.txt
FILE Mono07.txt
FILE Mono08.txt
FILE Mono09.txt
FILE Mono10.txt
FILE Mono11.txt
FILE Mono12.txt
FILE Mono13.txt
FILE Mono14.txt
FILE Mono15.txt
FILE Mono16.txt
FILE Mono17.txt
FILE Mono18.txt
FILE Mono19.txt
FILE Mono20.txt
FILE Mono21.txt
FILE Mono22.txt
FILE Mono23.txt
FILE Mono24.txt
FILE Mono25.txt
FILE Mono26.txt
FILE Mono27.txt
FILE Mono28.txt
FILE Mono29.txt
FILE Mono30.txt
FILE Mono31.txt
FILE Mono32.txt
FILE Mono33.txt
FILE Mono34.txt
FILE Mono35.txt
FILE Mono36.txt
FILE Mono37.txt
FILE Song01.txt
FILE Song02.txt
FILE Song03.txt
FILE Song04.txt
FILE Song05.txt
FILE Song06.txt
FILE Song07.txt
FILE Song08.txt
FILE SongNa01.txt
FILE SongNa02.txt
FILE SongNa03.txt
FILE SongNa04.txt
FILE SongNa05.txt
FILE SongNa06.txt
FILE SongNa07.txt
FILE SongNa08.txt
TOTAL M:\ ------- 0 123 26,529,375 26,529,375

123 files ~26.5MB, ~5MB free space, 32768 KB total (32MB)

Based on a raw image dump of the entire 32768 Kbytes of memory, this volume is FAT only and there are no hidden partitions or unallocated space.

RetroPlayer's picture

I will be laying out a cartridge with an xD socket on it next. I'd like to see how big of a card it can actually handle.

I'll also look into the animation scripts a little more.

I don't see any switches in the elvis.exe, it was compiled with Borland Turbo-C and does not look encrypted, compressed, or "packed." I believe it is just a test application used in production to ensure that none of the files are corrupted. It doesn't print, doesn't create any files, etc.. just displays all the files, their individual checksums, and the total checksum for the disk.

Finally, I will see if I can figure out what exact format the audio clips are stored in. As I said, I can play them with VLC, but it complains that it doesn't recognize the format (but plays anyway.)

More tomorrow.

RetroPlayer's picture

Audio clips are 44KHZ, 128kb/s stereo. They are definitely a headerless MP3 file. Every program I have plays it just fine as an MP3.

I will have to look at what is in a MP3 header that needs to get removed (if it even needs to get removed at all) for custom audio clips.

RetroPlayer's picture

Hmm, I just found some of the dat files with headers.

This is from the SongNa04.dat file:

00000000 4944 3303 0000 0000 0176 5052 4956 0000 ID3......vPRIV..
00000010 000E 0000 5065 616B 5661 6C75 6500 B054 ....PeakValue..T
00000020 0000 5052 4956 0000 0011 0000 4176 6572 ..PRIV......Aver
00000030 6167 654C 6576 656C 00E2 0C00 0000 0000 ageLevel........
00000040 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000A0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000B0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000C0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000D0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000E0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000F0 0000 0000 0000 0000 0000 0000 0000 0000 ................

Does this mean anything to anyone?

sevik's picture

Have you decoded action scripts format?

Can you put some of script files somewhere?

Or just post hexdumps of some...

sevik's picture

About headers - seems like just plain MP3 ID3 tags:

00000000 49 44 33 03 00 00 00 00 05 76 54 45 4e 43 00 00 |ID3......vTENC..|
00000010 00 12 00 00 00 53 70 69 64 65 52 20 43 6f 6c 6c |.....SpideR Coll|
00000020 65 63 74 69 6f 6e 54 49 54 32 00 00 00 1c 00 00 |ectionTIT2......|
00000030 00 44 69 72 74 79 20 44 65 65 64 73 20 44 6f 6e |.Dirty Deeds Don|
00000040 65 20 44 69 72 74 20 43 68 65 61 70 54 52 43 4b |e Dirt CheapTRCK|
00000050 00 00 00 02 00 00 00 31 54 59 45 52 00 00 00 05 |.......1TYER....|
00000060 00 00 00 32 30 30 34 54 43 4f 50 00 00 00 04 00 |...2004TCOP.....|
00000070 00 00 53 61 52 54 50 55 42 00 00 00 08 00 00 00 |..SaRTPUB.......|
00000080 4b 69 63 6b 61 73 73 54 43 4f 4e 00 00 00 0a 00 |KickassTCON.....|
00000090 00 00 48 61 72 64 20 52 6f 63 6b 54 41 4c 42 00 |..Hard RockTALB.|
000000a0 00 00 14 00 00 00 54 68 65 20 42 6f 6e 20 53 63 |......The Bon Sc|
000000b0 6f 74 74 20 59 65 61 72 73 54 50 45 32 00 00 00 |ott YearsTPE2...|
000000c0 06 00 00 00 41 43 2f 44 43 54 50 45 31 00 00 00 |....AC/DCTPE1...|
000000d0 06 00 00 00 41 43 2d 44 43 57 58 58 58 00 00 00 |....AC-DCWXXX...|
000000e0 13 00 00 00 00 53 70 69 64 65 52 20 43 6f 6c 6c |.....SpideR Coll|
000000f0 65 63 74 69 6f 6e 43 4f 4d 4d 00 00 00 16 00 00 |ectionCOMM......|
00000100 00 65 6e 67 00 53 70 69 64 65 52 20 43 6f 6c 6c |.eng.SpideR Coll|

sevik's picture

real mp3 files - not enclosed in RIFF/WAV container does not have visible header, they are just sequence of MP3 frames

See http://en.wikipedia.org/wiki/MP3 section "File Structure"

RetroPlayer's picture

DOH!! What a moron. VLC isn't complaining about the MP3 file, it is trying to load the associated .txt as a lyric file, and complaining about that.

So... they are simply MP3s. Some have headers some do not. Doesn't seem to matter.

Also, I am making some progress already on the animation script. I'll show the hex for it before explaining what I see.

This is from SongNa08.txt, one of the small animations:

00000000 0000 6100 5100 3100 ..a.Q.1.
00000008 0000 6200 5100 3200 ..b.Q.2.
00000010 0000 6300 5100 3400 ..c.Q.4.
00000018 0000 6400 5100 3400 ..d.Q.4.
00000020 0000 6500 5100 3300 ..e.Q.3.
00000028 0000 6600 6100 3300 ..f.a.3.
00000030 0000 6700 5100 3000 ..g.Q.0.
00000038 0000 6800 5000 3300 ..h.P.3.
00000040 0000 6900 5A00 3800 ..i.Z.8.
00000048 0000 6A00 5100 3800 ..j.Q.8.
00000050 0000 6B00 5100 3800 ..k.Q.8.
00000058 0000 6C00 5100 3800 ..l.Q.8.
00000060 0100 6100 6100 3100 ..a.a.1.
00000068 0100 6200 5100 3200 ..b.Q.2.
00000070 0100 6300 6100 3400 ..c.a.4.
00000078 0100 6400 6100 3400 ..d.a.4.
00000080 0100 6500 5100 3300 ..e.Q.3.
00000088 0100 6600 4100 3300 ..f.A.3.
00000090 0100 6700 5100 3000 ..g.Q.0.
00000098 0100 6800 4100 3300 ..h.A.3.
000000A0 0100 6900 4700 3800 ..i.G.8.
000000A8 0100 6A00 4700 3800 ..j.G.8.
000000B0 0100 6B00 5100 3800 ..k.Q.8.
000000B8 0100 6C00 5100 3800 ..l.Q.8.
000000C0 0200 6100 5100 3100 ..a.Q.1.
000000C8 0200 6200 5100 3200 ..b.Q.2.
000000D0 0200 6300 5100 3400 ..c.Q.4.
000000D8 0200 6400 5100 3400 ..d.Q.4.
000000E0 0200 6500 5100 3300 ..e.Q.3.
000000E8 0200 6600 6100 3300 ..f.a.3.
000000F0 0200 6700 5100 3000 ..g.Q.0.
000000F8 0200 6800 6100 3300 ..h.a.3.
00000100 0200 6900 4100 3000 ..i.A.0.
00000108 0200 6A00 5100 3800 ..j.Q.8.
00000110 0200 6B00 5100 3800 ..k.Q.8.
00000118 0200 6C00 5100 3800 ..l.Q.8.
00000120 FFFF ..

As you can see, the first two bytes go 0000, 0100, 0200, etc... in extremely long files this just keeps climbing and climbing.

For each of these, there are always 12 entries. No matter how long the animation is.

The second group of two bytes, always starts at 6100 and also increments through the frame, and ends with 6C00 and then starts over. This one actually increments in each row for each of the 12 records.

The third set of 2 bytes varies pretty wildly in longer songs. This is probably actual animation information. I have never seen anything but 00 in the second byte.

The fourth set of two bytes, also varies, but doesn't seem to change as wildly. Also, I have never seen anything other than 00 in the second byte of this group.

So, the first 16 bit word looks like a frame header, the 6100-6C00 looks like a record (motor group, maybe?) and the last 32 bits look like animation information.

I'll be interested to hear your thoughts on this. How many motors are there total in the Elvis again?

RetroPlayer's picture

The fourth set of bytes in several full song animations that I looked at never go lower than 3000 and never higher than 3800. So, 9 total variations. There are 9 motors in the Elvis if I remember correctly. I will need to dig out my elvis and actually count the motors unless someone else knows off the top of their head.

The third set, I am still working on. It does seem to stay within a range. After looking at a few file, I don't see it going below 4100 and never above 6100. So, 32 different vaules.

sevik's picture

I don't have elvis myself :)) I have Robopanda and it's cartridge format is not so straightforward unfortunately...

About your analyze - it seems very likely and if elvis really has 12 motors, than 3 and 4 group can be target position and moving speed for each motor.

You can try to match length of animations with length of song - to see if it's a fixed rate action stream.

RetroPlayer's picture

Song08.dat is 57 seconds in duration
The details of the associated Song08.txt file:

I forgot to mention that all .txt files end with FFFF

First the hard data in case I get some math or conversions wrong below:
File size is 27178 bytes (including end of file "FFFF")
The last offset (hex)of the data is 6A27

The highest "frame" is 1D01

There are 3,396 "records"/12 = 283 "frames"
3396 records/57seconds = 59 records per second (hmm... 60, actually?)
283 frames/57 seconds = 4 frames per second

File length is 27176 bytes (not counting the always present "end of file" FFFF)

I just noticed something about this particular file. Starting at 1901, it only contains 5 rows, and the typical 6100-6C00 is no longer being followed.

Here's the dump of the last several rows beginning at 1901:

00006960 1901 6300 5200 3400 ..c.R.4.
00006968 1901 6400 5200 3400 ..d.R.4.
00006970 1901 6600 6100 3400 ..f.a.4.
00006978 1901 6900 4100 3400 ..i.A.4.
00006980 1901 6B00 4100 3400 ..k.A.4.
00006988 1A01 6300 5200 3400 ..c.R.4.
00006990 1A01 6400 5200 3400 ..d.R.4.
00006998 1A01 6600 6100 3400 ..f.a.4.
000069A0 1A01 6900 4100 3400 ..i.A.4.
000069A8 1A01 6B00 4100 3400 ..k.A.4.
000069B0 1B01 6300 5200 3400 ..c.R.4.
000069B8 1B01 6400 5200 3400 ..d.R.4.
000069C0 1B01 6600 6100 3400 ..f.a.4.
000069C8 1B01 6900 4100 3400 ..i.A.4.
000069D0 1B01 6B00 4100 3400 ..k.A.4.
000069D8 1C01 6300 5200 3400 ..c.R.4.
000069E0 1C01 6400 5200 3400 ..d.R.4.
000069E8 1C01 6600 6100 3400 ..f.a.4.
000069F0 1C01 6900 4100 3400 ..i.A.4.
000069F8 1C01 6B00 4100 3400 ..k.A.4.
00006A00 1D01 6300 5200 3400 ..c.R.4.
00006A08 1D01 6400 5200 3400 ..d.R.4.
00006A10 1D01 6600 6100 3400 ..f.a.4.
00006A18 1D01 6900 4100 3400 ..i.A.4.
00006A20 1D01 6B00 4100 3400 ..k.A.4.

Perhaps this part being different might be the key that unlocks this!

sevik's picture

heh :))

This supports idea of 2 group as motor number. so only needed in this frame moves are encoded.

Data is clearly in different endiannes - so 0 in 2,3,4 groups is not a LSB, but MSB.

0x11D = 285
285/57 = 5.000000

So most likely 1 group is frame number with 5 frames per second...

sevik's picture

last frames with constant values in 3 and 4 groups possible give some time for motors to settle on target positions...

RetroPlayer's picture

OK, started listening to all the files.

Song01.dat to song08.dat have no Elvis lyrics in them, just instruments and backup vocals. Karaoke mode?

CoSong01.dat to CoSong08.dat are the full songs. Not "conversations" like I thought.

SongNa01.dat to SongNa08.dat are the names of the songs in Elvis' voice

There are 37 monologues named Mono01.dat to Mono37.dat

I will have to see how the animations between the Song and CoSong files differ. I wouldn't imagine that he would be lipsynching in karaoke mode (I didn't even know there was a karaoke mode... goes to show how little I played with it before taking it apart!)

Notably absent are any clips of his "reactions." I don't remember all of his reactions, but it seems that he at least said something if you held his head while he tried to move.

Also, there is no "master script" that tells what audio clips are on the cart and when to play them. This means that right now, modifying him is limited to the monologue, Karaoke, and song modes. I imagine that he will play any number of them, however, if they planned to make other carts in the future.

Looks like for this to be really useful, I still need to dump the main flash on the motherboard and see if I can find a serial port. Another day... I would like to get the animation scripts decoded first. I would post the files somewhere, but I am pretty sure that wowwee would not be cool with this. Especially the MP3s.

sevik's picture

For decoding action script values just split it by motor, and i think you will see much cleaner picture...

Try to match values from script with real motions of elvis (using stopwatch, video or some other method).

RetroPlayer's picture

Just compared the CoSong01.dat to the Song01.dat. The files are almost identical. The field that changes in every frame is the fourth field (the one that goes from 30 to 38) In fact, that's what it changes. Every ninth "record" it is 0x30 in CoSong and 0x38 in Song. Almost makes me think this has to do with the mouth.

There are some other differences in group 3, but they don't change as often. It appears to happen only in the 8th record of each frame. So far, I don't see a pattern to this other than it always being in the 8th record, though. And it doesn't change in every frame.

Oh, and CoSong01.dat is the first file I have seen that doesn't have the FFFF at the very end, so I checked a couple of others. Some have it and some don't.

Hmm... as much as I want to keep playing, I have to stop for now. I'll muddle it over in my head and maybe have it figured out by tomorrow.

RetroPlayer's picture

Sevik, My Elvis all taken apart right now, so I can't watch him function. I will try to count all the motors, though. It does seem like I counted them when I first took him apart and there was 9. I never wrote it down though. I'll have to dig him out. I need to figure out how to rip the flash off the main board anyway.

Good day...

sevik's picture

Good night actually :)) it's 23:00 localtime :))

milw's picture

You should try giving GWJax or Robosapien-4mem8 a PM, they both have elvises and I know GW has taken his apart and remodelled the face... good work RetroPayer!

Nocturnal's picture

GWJax's articles say 10 motors. The 3rd group does look like a target position. I seem to recall GWJax said all the motors have pot sensors, so it makes sense (either an 8 bit adc or rounding to 8bit to eliminate jitter).

That last segment you posted with only 0x63, 0x64, 0x66, 0x69 and 0x6B suggests to me that if a motor is not being moved, you don't need a line for it, though obviously you can have one (why the 6 prefix? 0x00 - 0x0C would work just as well).

That just leaves me with the question, did GWJax miss two motors, or is there something else in evlis that can have its state set that would be handy for animation?

Once again, I wish I had an Elvis.

GWJax's picture

RetroPlayer said: The fourth set of bytes in several full song animations that I looked at never go lower than 3000 and never higher than 3800. So, 9 total variations. There are 9 motors in the Elvis if I remember correctly. I will need to dig out my elvis and actually count the motors unless someone else knows off the top of their head. The third set, I am still working on. It does seem to stay within a range. After looking at a few file, I don't see it going below 4100 and never above 6100. So, 32 different vaules.

there are 10 motors in the Elvis 8 in the head and 2 in the shoulders. very good work! what I would do is record or change one byte at a time and see if you notice what motor or sensor is changing, this will be titious but it will tell you what is what. but make a backup of the firt as I know you will do.

GWJax's picture

Nocturnal said: GWJax's articles say 10 motors. The 3rd group does look like a target position. I seem to recall GWJax said all the motors have pot sensors, so it makes sense (either an 8 bit adc or rounding to 8bit to eliminate jitter). That last segment you posted with only 0x63, 0x64, 0x66, 0x69 and 0x6B suggests to me that if a motor is not being moved, you don't need a line for it, though obviously you can have one (why the 6 prefix? 0x00 - 0x0C would work just as well). That just leaves me with the question, did GWJax miss two motors, or is there something else in evlis that can have its state set that would be handy for animation? Once again, I wish I had an Elvis.

the only thing I can think of is the 2 rx,tx sensors in the jacket but these are disabled when singing or taking in the montaloge. but at ramdom talking theses sensor are active so it dependes on what it is tryingto do, sing, talk or look around

RetroPlayer's picture

Some further thoughts:

Sevik is most likely correct; the bytes are swapped. So 0100 would actually be 0001.

Here is what I think would be needed to implement an animation script:

1. Frame number for synchronization
2. Motor number
3. Position
4. Speed

MP3s are actually a series of frames. Perhaps the time is not where to look, but the frame count.

The script is probably read line by line, since the number of records in a frame varies and there is nothing to tell the parser how many records are in the frame. Unless it just counts them... maybe; sounds like extra uneeded work, though. If the script is read line by line, this would make my 60 records per second calculation above make sense. 60 frames per second is pretty standard in animatronics and lines up nicely with media time marks.

I will parse a second set of MP3/script files to see if it correlates with 60 (or 5) as the one above did. By the way, 60frames/12 motors = 5, so there would always be time to implement all motors in a script without truncation. Also, if it is being read line by line, it seems possible that the same motor could be moved more than once in the same frame to increase the smoothness of a movement.

Some hard numbers:

There are 10 motors:
Head Rotate
Head nod
Head Tilt
Eyes L/R
Eyes U/D
Left Eybrow
Right Eyebrow
Left lip
Right lip

However, wouldn't it make sense to group the Left and Right lips together for movements where he is not sneering? Since otherwise, you would need two frames to move both sides and that would mean that they were not in sync. Also, the same with the eyebrows. So, perhaps this accounts for the extra two motor groups we (think we) see.

So, given this, here is my theory (I am going to swap the bytes)

0100 6100 4100 3000 becomes 0001 0061 0041 0030

0001 - FFFE = frame, timemark, whatever
0061 to 006C defines a motor or motor group
0041 to 0061 defines a position. 32 possible positions
0030 to 0038 defines a speed, 9 possible speeds

Now why 0061 instead of just 0001? I am not sure. The binary representation of this number may mean something.

I am really beginning to think this might be based on an ARM or SAM7 processor. Being able to decode FAT, handle sensor inputs, I2C communications to ADCs, motor control outputs, IR reception, etc... all at once needs quite a bit of CPU power. If this is an ARM or SAM7, then there is definitely a couple of serial ports as well as JTAG, etc.. There may even be an OS on this like uClinux. If so, and we unlock the console port, we are in for a VERY customizeable animatronics platform. Keep in mind that the SAM7 (with uClinux) is being used in quite a few medium-priced multimedia toys right now.

I need to get my Elvis back together and then I will start playing with some modifications to the animation scripts to see if I can figure out what is going on. Then, it should be a simple (lol) matter of creating a program to build an animation script and sync it to the audio. What would be really great is if someone knew how to write lip syncing routines that would read the audio and automatically generate the jaw and lip movements. But, hack it and they will come! Lots of talented people out there, you just gotta do some of the work and stimulate the creative potential.

RetroPlayer's picture

Some details on how I did this (so others can do it):

I purchased two Dazzle xD/Smartmedia readers off eBay. I picked a smart media reader because it would be easier to solder to.

I removed the combo socket, jumpered the voltage selection switch to 3.3v and then carefully soldered 18 wires between the smartmedia socket pads and the cartridge. I didn't use wire-wrap wire and wish I would have. It was pretty difficult to solder the 24 gauge ribbon cable on to the cartridge.

Looking back, I think I would have preferred to have just removed the cartridge connector from the Elvis main board and just rigged that up. I might still do that. Then, I could just replace the cartridge with a built in xD socket. It is highly doubtful that wowwee will produce any more cartridges for this, so what's the point of keeping the cart port (and with a rigged up cart socket, I can just copy the cart to an xD card anyway if I wanted.)

Alright, I am off to dig out my Elvis and see what else I can figure out.

Oh, and a tool that will come in handy with the NAND flash reader: http://www.majorgeeks.com/SelfImage_d5588.html

Allows you to make a byte for byte image an entire physical drive (meaning it does not have to be formatted or even have a partition -- also called blind copy) and it can also burn the image back. Oh, and it's free. Took me a while to find a free disk image program that could do this.

GWJax's picture

now knowing this I'll change my Elvinator board and see what I can come up with to adding the port to the PC and using the main board as the pass through hub. Thanks for all your hard wook! Now I see an eisier way to connect it to the PC rather than building a new MCU board, but I'll still have that in the back of my head for a backup incase this does not work the way I want it to work.

Nocturnal's picture

Sorry to rain on your parade GWJax, but I don't see how this will allow you to have PC control. Create a custom cartridge, yes, PC control, no.

What RetroPlayer is talking about is using an xD/SmartMedia card reader, to read the existing cartridge, as well as replacing the existing cartridge slot on the Elvis with an xD slot, and using an xD card instead of the cartridge.

Unless what your planning on doing is ditching the cartridge entirely, and attempting to emulate the cartridge in realtime (somewhat akin to what sevik has done with the RoboPanda), or I am missing something.

GWJax's picture

No N. you hit the nail on the head, I was thinking on ditching the catridge all togeather and emulate the cart. on the pc side if I can get that to work. then all my data can be stored on the HD and continue to grow in size as time goes by. I have to make a board and joystick to record head movements and tie the data into the routines. Just by knowing that the chip is a FAT format and sounds are mp3's is a huge advantage now. and when retro finds the correct routine or data structure I can start there. Once again Thanks again retro for doing this work for us!!!

Nocturnal's picture


Hmmm... that might just be possible. You might be able to use the printer port on a PC to emulate a xD device. Its just a question of speed.

RetroPlayer's picture

It certainly should be possible. I am not 100% sure why someone would need to do that, though. If you just write a cart, you can plug it in.

At least right now, the custom animations and audio clips are only going to be tied to the preset 'modes.'

Hmmm, unless you start a mode and just continuously stream a never ending animation to keep him going on a certain "monologue" or whatever. Then you would at least have the appearance of complete control. Is that the idea? If so, that's pretty smart!

I am pretty certain that I have the right format for the action scripts, but I still need to identify the motor groups, and what the range of positions and speeds do.

Still working on it, but I have a "for money" project coming up again soon, so things might get a little slow again.

GWJax's picture

Speed is a good thing. but say in theory could one build a buffer to keep the data stream going fast enough like a spooler for printers. This way the pc could send commands ahead of time before the elvis starts its routine. that should correct any speed issues, It just would not be truly in real time but a small lag for any reponse from him. Only a thought have not worked out any details yet.