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

361 posts / 0 new
Last post
GWJax
GWJax's picture

RetroPlayer said: It certainly should be possible. I am not 100% sure why someone would need to do that, though.

This would be used for talking with the elvinator and having him respond to you using the Alice bot program. this would be the only reason I would connect it to the PC.

RetroPlayer
RetroPlayer's picture

Here are the rough dimensions of the Cartridge. I needed them to lay out a new PCB (or find a suitable socket):

(These are rough, my micrometer is not exactly a highly precise instrument, but knowing which way to "give or take" on means I should be able to get away with it.)

PCB:
Inserted portion only: 23.75mm Wide x 10mm High
Board is .9mm thick

Contacts:
1mm (.039") centers (or pitch)
.8mm wide contacts
.35mm gaps between contacts
.5mm from each side
7.8mm long
.5mm bottom gap

18 contacts

RetroPlayer
RetroPlayer's picture

GWJax. To figure out the speeds you need to emulate, look at the datasheet for the flash chip on the cartridge. Access times especially. Also, you have the ready/busy signal to help you out here (if it is actually used by the processor.)

BTW, I didn't mean why would you want to connect it to your PC, that was obvious. :) I meant why do it by emulating the cartridge? My concern was that you are still stuck with the built in modes of operation. And the personality and voice will be Elvis again in between animations since some of his comments and animations are in the flash on the main board.

I think I mostly answered my own question, though. A continuously streaming animation and MPEG frames (even if they are blank) would trick Elvis into thinking the monologue, song, or whatever is still playing and he won't come out of it until you stop. In theory, this sounds like it will work just fine. If there was a "end of file" on every animation script, this would be perfect. You just never send the end of file and he is yours to control. But, as I mentioned, not all files have it, so I am not sure that it is being used at all. We'll have to figure out how Elvis knows when to stop. It might be the MP3 frames that do it. And that means sending fake MP3 frames to keep him under our control.

If it works, this is certainly acceptable until the main board is figured out.

Elvensynth
Elvensynth's picture

Wow! theres a lot of progress going on! very interested.

Nocturnal
Nocturnal's picture

GWJax said:
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...

Thats not the speed I am talking about.

RetroPlayer said:
To figure out the speeds you need to emulate, look at the datasheet for the flash chip on the cartridge. Access times especially. Also, you have the ready/busy signal to help you out here (if it is actually used by the processor.)

Thats the sort of speed I was thinking about.

Just for reference, the max read speed for standard xD cards is 5 megabytes a second, where as for a parallel port in EPP mode, that max speed is 2 megabits (2.5 for ECP). I doubt the Elvis NEEDS to read that cartridge that fast, so lets just hope the read speed is within range for a parralell port (or that the !busy signal isn't ignored).

RetroPlayer
RetroPlayer's picture

Well, I bit the bullet. I just ordered a tsop48 adapter for my programmer. $60, but I can't tell you how many times I have needed it and talked myself out of it (thinking I would get around to building my own.) So, I finally did it. I do have a few unfinished projects that it would be useful for, though.

When I get it, I will pull the flash off the main board and dump it. At the very least, I would like to be able to change the idle animations and audio clips so that he never returns to "Elvis" personality once he is modded.

BTW, if anyone is looking for a cheap programmer, check out:
http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=4267
I have the older parallel port version of this one, and this is the adapter I just ordered which works with either:
http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=3102

Scott M.

Nocturnal
Nocturnal's picture

By chance, do you have a photo of the inside of the cartridge?

GWJax
GWJax's picture

Nocturnal said: By chance, do you have a photo of the inside of the cartridge?

RetroPlayer
RetroPlayer's picture

Nocturnal said:

GWJax said: 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...

Thats not the speed I am talking about.

 

Since it is likely that you will need a microcontroller between the PC and the cart port to emulate the NAND flash anyway, both concepts will probably be needed. If an SRAM could be filled with enough stuff to get things going, the microcontroller could probably receive and fill the next "page" while streaming the first page to the cart port. Basically, page flipping. Chances are that a microcontroller could talk to the cart port much faster than the parallel port could, and you avoid the timing issues with the PC parallel port (it is not timing specific unless you go to DOS and write in assembly.) Whichever method will probably need to be at least (!) twice as fast as the Elvis needs to read the cart, since it will need to receive the data, format it, and emulate the NAND flash. 

There are many ways to emulate this. Probably the best way (not the easiest) would be through USB, since it has the throughput to spare. There are several micros that support USB slave, and there are even USB FIFO chips with decent sized buffers from FTDI (for example) which should allow you to bit-bang the emulation. I imagine someone could make some money off that! I see alot of requests for NAND flash emulators out there, and it would be very helpful to any hardware hacker.

With extra throughput, you have the ability to make the timing more exact, if needed

The disadvantage to using the ready/busy line (though a necessary evil) is that even if the data gets there eventually, the wait times would cause stuttering in both the audio and the animation. Just like when you try to do something on your computer while it is extremely busy. It will do it, eventually, but it isn't going to give the desired results.

Personally, I don't like this method at all, which is why I want to keep going on the mainboard. That port that is labeled G ICESDA ICESCK ICE VDD (which I incorrectly said went to the ADC chip on the other thread) is actually an in-circuit-emulator port for Sunplus processors.  This, unfortunately, probably confirms that it is a sunplus chip being used. It could just be an I2C port (or TWI) with similar names to the emulator, but things are stacking up against my assumption that this is something more powerful than the 16-bit Sunplus chips that are available.

 If we gain access to this port, supposedly (from the sunplus datasheets) it will support programming the flash and eeproms on the controller as well as allowing programming of external flash through the emulation.) Since I do not see anywhere that the emulator probe can be purchased by an end-user, it would be necessary to reverse-engineer this (unless it has already been done and I haven't found the info.) I'll try to connect something up to it and see what I can figure out. Might be a little bit though. I have never worked with I2C before.

RetroPlayer
RetroPlayer's picture

DOH! I just looked at the software for my logic analyzer and it has an I2C protocol analyzer built in. This might be helpful in reverse-engineering that debug port. I'll have to read up on I2C to see what is needed to initialize communications. I am pretty sure that I saw a application note or project to get I2C out of a FT232R USB to serial adapter from FTDI. I do have several of those lying around...

RetroPlayer
RetroPlayer's picture

I2C compatible interfaces are:

I2C
TWI (Two wire interface)
and SMBUS

The standards are somewhat loose as far as voltages, but VDD on the Elvis is 3.3V, so that's what we are working with. It appears that there is an address needed on the bus to get communication started. There are (for I2C and TWI) about 127 possible addresses available. I imagine an enumeration could be done to see what the processor responds to. The MCU would be a slave, which means we need to provide the clock (which is common for on-chip debuggers, anyway) and it looks like the CE line needs to be pulled low.

That should be enough information to get me started. Now I just need to rig up the main board so that it will run outside of Elvis so that it is easier to work on.

RetroPlayer
RetroPlayer's picture

I think I am going to start up a few different threads. Things are going to get confusing fast. Maybe we should stick to this thread for figuring out the file formats, a separate thread about the actual hardware end of the cart port (including emulating it), and a third thread about hacking the main board.

Any suggestions? Reading back over this particular thread, I see many places where I gave incorrect information while I was experimenting, only to correct them later. I'd like to clean it up with only the fresh and correct information in one spot so that is clear. I don't think I have enough information yet to write an article though. Hmm.. maybe we should just continue haphazardly until the formats are completely figured out, then move it all to an article.

Let me know what you think guys.

sevik
sevik's picture

Heh :)) Interesting discussion :))

Some points:

About animaton scripts format and executing order:

I think it's readed line by line groupping all entries for current frame number, and executing it for 200ms.

By execution I mean:
1) read command lines until frame == cur_frame
2) check current position of each involved motor and calculate direction (+/-)
3) set each motor PWM to needed speed, and H-bridge for needed direction
4) for 200 ms execute:
5) check current position of each motor and stop on target channels
6) goto to 5 if 200ms is not ended
6) cur_frame += 1
7) goto 1

It's not guaranted that motors actually arrive at target position at the and of cycle, but it will go in needed direction (this explains last frames from posted animation script with same values in target and speeds).

For detection end of script - you have a REAL filesystem on cartridge - so you EXACTLY know lenght of each file :)) So you just stop on end of file or FFFF marker if it present. So FFFF marker is optional.

Interaction between end of mp3 and end of animation script can exist in any direction or can not exist at all. (mp3 stopped at and of animation, animation stopped at end of mp3, or just each of it going to their end independently). I think interaction really not present at all and you can have mp3 and animation scripts of different length. But it will be synhronized at time of execution by exactly defined execution speeds. (200ms per frame for animation and defined by specification speed of mp3 decoding).

Emulating cartridge

I think it will be hard to emulate cartridge just in software with LPT. because you need to work with speed that elvis demands. busy/ready line can help, but busy line must be asserted very quickly after start of cycle, so at least minimal hardware helper needed. And it can be just not used in elvis. Hardware based emulation of course possible :))

But next - there is REAL filesystem on cartridge - so you cant just continue to feed frames until you think its enought.

first - access to mp3 and animation will be interleaved - so you need to check what sector number is readed now and put next mp3 or next animation script frame. And you need to emulate system structures of filesystem too - BPB, FAT, directories.

second - access is sector based - so you need to put full sector (512 bytes) of animation in advance.

512 (bytes per sector)/8 (lenght of record)/12(standart record per frame) *0.2 (lenght of frame) = 1.066666 seconds for full frames. But 512/12/8 = 5.333333 so you need to split some frames beetwen sectors and really plan for 1.2 seconds ahead.

third - you need to tell exact length of each file during initial read of directory. Of course you can emlulate cartridge with only 2 files of half-of-cartridge length.

In summary - emulation of cartridge possible for almost unlimited animated play but for real interaction it is something limited...

sevik
sevik's picture

For ICE connection reversing - i think it will be really hard...

I can't find any close relatives of SunPlus CPU's with available documentation so chances is low that it use some semi-standart ICE protocol.

Reversing onboard flash content may be possible, there is dowloadable IDE for some SunPlus MCU's - so at least we can compare some compiled code :))

sevik
sevik's picture

For splitting discussion in several threads - I think now is very early stages for splitting attention :))

And some information will be duplicated anyway.

You can simple use one permanently updated message with latest understanding of things :))

RetroPlayer
RetroPlayer's picture

sevik said: For splitting discussion in several threads - I think now is very early stages for splitting attention :)) And some information will be duplicated anyway. You can simple use one permanently updated message with latest understanding of things :))

That's kinda what I was thinking. If I had known more up front instead of being excited to reveal it so early, I probably would have done it that way. I did edit the very first post a couple of times to correct some things I discovered later.

sevik
sevik's picture

It's better to reveal your findings early - so more interested parties can be involved.

Any real reversing is really big and hard work and broad attention is a big plus :))

RetroPlayer
RetroPlayer's picture

sevik said:
For ICE connection reversing - i think it will be really hard...
I can't find any close relatives of SunPlus CPU's with available documentation so chances is low that it use some semi-standart ICE protocol.
Reversing onboard flash content may be possible, there is dowloadable IDE for some SunPlus MCU's - so at least we can compare some compiled code :))

I am not exactly sure what you mean by not being able to find datasheets for the Sunplus MCUs, there are several on the sunplus website, with pinouts, etc.. There is also a datasheet and manual for the emulator interface, and if I recall correctly, it specifically referred to the ICE port as I2C, which (usually) means that they licensed the use of that name from Philips. And to do that, they would need to be within the standards. The problem is that the standards for I2C (official) are pretty loose and this is why other standards like SMBUS were developed, to tighten them up. But, besides the voltage, speed and max address capability differences, the actual implementation of the protocol and signalling conventions "should" be the same.

The Sunplus micros have I2C master/slave ports built in them (separate from the debugger) so I see no reason why they would mess with it for the debugger.

Anyway, I think trying out all the approaches would be best. I am not going to set my success/fail simply on reverse engineering the ICE port (which I wouldn't do completely anyway, I am only concerned with using it for flashing and reading.)  The chip will still be pulled, I'll wiggle for a serial port, a JTAG port, and try to figure out the pinout of the COB board. Even a success at doing that would allow one to simply pull off the COB board and replace it with a more hacker friendly processor while leaving all the rest of the hardware alone.

And now I am off to see if I can rig the main board up on my workbench so that I can start probing it.

BTW, I got brave and actually wrote a new file to the cartridge and it worked fine. So writeability is confirmed. I can't test it in the Elvis again without desoldering it from my xD reader though, so I will try that in the next couple of days as I build the socket adapter and wrap up some of my probing. I have a 256MB xD card sitting here that I want to try out, and if that works, look out! That's probably enough to keep him animated for a week. Oh, and there is no reason that a SmartMedia card wouldn't work instead of an xD card. I just chose xD because it is (much) smaller and likely to be available longer. Finding sockets, on the other hand... The easiest and cheapest way I have found was to just buy an xD only USB reader on eBay ($7.50) I'll rip the socket off that. The socket on my current readers are SMC/xD combo sockets and is rather large. it would work fine, I am just anal about the appearance of my work.  I'll probably do an article on making the flash reader once I am done and satisfied with the look of it (no sense in leading others to make the same T&E mistakes I do.)

GWJAX, (or anyone else that has the Elvis) if you have your Elvis all hooked back up, could you check to see if he does the monologues, songs, etc... in order or if they are random? I am hoping it isn't random because then the remote could be used to add at least some control to his actions by just making it skip to the number of the animation and audio clip we want.

RetroPlayer
RetroPlayer's picture

Oh, and I2C has apparently been around a very long time. It is used in your VGA monitor as the DDC channel (which identifies your monitor and it's capabilities) on your computer, apparently both Mac and PC.

Gee, don't I sound like an expert? Just been doing some reading, that's all.

sevik
sevik's picture

i2c is low-level protocol, for reading and writing registers :))

But you need to known the meaning for registers :))

RetroPlayer
RetroPlayer's picture

sevik said:
i2c is low-level protocol, for reading and writing registers :))
But you need to known the meaning for registers :))

 

Agreed. I'll try not to get my hopes too, high. But then, I was fully preparing myself to have huge 32MB binary dump that I could never sort out on the cart, and look what happened? :)

 

BTW, I might have found a serial port... 

sevik
sevik's picture

Check other i2c devices :))

From i2c side they often look like just 2 registers - index and data, so all accesses looks like:
1) write index register with internal address
2) read or write data register

P.S. serial port with busybox prompt? :))

RetroPlayer
RetroPlayer's picture

No such luck, Sevik. What I found were a group of pins with signals that looked like serial. I do get a somewhat constant stream of garbage. I haven't tried all port settings, so it still might be.

The batteries died on my oscilloscope and I am needing to get to sleep, so tomorrow we'll try again.

RetroPlayer
RetroPlayer's picture

This is also the only pin that gives me a line feed every once in while, but seeing that it is garbage, that could really be anything.

RetroPlayer
RetroPlayer's picture

Nothing. I spent the morning pinning out as much of the CPU as I could without loosing my eyesight, then masked off all of those pins as "known" I tried several different speeds and protocols.

There is one interesting pin that I get though. When I connect to it and switch Elvis on, I get the exact same set of characters, every time. About 16 characters (I am looking at the hex, not the ascii) and then it stops and doesn't output anything again until I turn it off and on again.

This peaks my interest, because this is pretty much what a debug port would do. I doubt that what I am seeing on the my serial terminal really tells me very much about what it is, so I am not really sure where I can go with it. If it is JTAG, it is paired with other pins that would be difficult to locate, SPI the same...

So, I am going to go back to working on the animation scripts this weekend so that at least THAT part is completed. I will get Elvis hooked back up and start playing with modifying the files to see what I can come up with. I will clean up my work and write up an article to help other do the same thing.

I should get the Tsop48 adapter in a week or so since it is coming from Canada, and then I will pull of the main flash and dump it.

I am also going to keep working on pinning out the CPU. If all else fails, I would like to create a replacement controller that can be soldered where the COB board is. Quite a bit of surface mount hardware can fit there (41.05mm x 43.05mm or a little over 1.5 inches each direction), so theoretically, there should be room for an ATMEGA128 and some other goodies (like a bluetooth serial port.)

RetroPlayer
RetroPlayer's picture

Regarding the cartridge project, I am hoping to get some feedback here. There are actually several different options and I am wondering what is preferred:

1. xD socket built in to Elvis
2. Replacement Cartridge with xD socket
3. Flash reader converted to read the vanilla cartridge (which would then work with the custom cartridge)
4. All of the above
5. Any other suggestion
5a. How about the whole flash reader contraption built into the Elvis with a USB port on his back? Might be a little tougher to negotiate communications.

Since I have the parts already to do any of these options, I am mostly wondering which one you think would be the simplest for people to follow and the most convenient to use.

Oh, last thing for the day: The WE* signal to the cartridge is connected to the CPU. That means the CPU could actually write to the cartridge. I wonder why they did that? I can see having the WE* on the cart itself, but I would have thought it would just be pulled high on the Elvis board. Any thoughts?

RetroPlayer
RetroPlayer's picture

Here's what I have so far. I will update this post as I add more:

Total pins: 108

Ground (or at least grounded without a resistor):
1
29
50
52
84
87

Note: I suspect either 50 or 52 is something being grounded. Unlike any other pin, they are jumpered together with a trace, rather than the ground plane. I might cut it to see what happens and then just solder bridge it again.)

VDD:
28
51
55
56
86
108

CRYSTAL:
82
83

CPU Name Cart
-------------------
NA GND 1
106 R/B* 2
95 RE* 3
93 CE* 4
90 CLE 5
91 ALE 6
94 WE* 7
NA VCC 8
NA GND 9
103 IO0 10
102 IO1 11
101 IO2 12
100 IO3 13
99 IO4 14
98 IO5 15
97 IO6 16
96 IO7 17
NA GND 18

Others:
RESETB 92
NCSO IS CONNECTED TO CE ON CART PORT, Pin 93 on the CPU

GWJax
GWJax's picture

RetroPlayer said: Nothing. I spent the morning pinning out as much of the CPU as I could without loosing my eyesight, then masked off all of those pins as "known" I tried several different speeds and protocols. There is one interesting pin that I get though. When I connect to it and switch Elvis on, I get the exact same set of characters, every time. About 16 characters (I am looking at the hex, not the ascii) and then it stops and doesn't output anything again until I turn it off and on again.

I believe what you are seeing is the init setup codes from that pin as it would make sense that it only happen when you turn the elvis on. That would be the homming code, so now we really know that the data is around 16 characters long for a good start.

sevik
sevik's picture

JTAG is passive - it will not change outputs without explicit request, so it's definitely not a JTAG

SPI master port - may be, probing for some device on startup

What chars do you get and on which speed?

sevik
sevik's picture

WE pin needed not only for writing data to cart - it's used for any operations with nand flash - for writing commands, addresses, etc.

See signal descriptions in http://download.micron.com/pdf/technotes/nand/tn2919.pdf page 7.

Pages