Thursday, April 11, 2013

Mattel HyperScan Hacking Update - Part 1



This will likely be a multi-part series. So as people may, or may not know (likely the latter.) I have restarted work on an old project of mine that involves reverse engineering/hacking the Mattel HyperScan. I'm mainly going to make this post as a more comprehensive form of a document that I wrote and posted on a now defunct website. That document apparently got picked up on a few sites and made it's rounds on the internet as some sort of informational piece, when it wasn't really intended to be such. So hopefully this will work out better, since I have better foresight now.


What is a Mattel HyperScan?:

This has been gone over many, many times, so I'll keep this short. The Mattel HyperScan was (it is now defunct as of 2007) a system designed to allow users to play games (not many, mind you) while also feeding to the craze of game card collecting at the same time. The system used CD-based media, coupled with RFID cards that you could scan at key points in the game to achieve certain advances, and even save these advances back to the cards. It has some l.e.d lights, and USB, though the USB was never actually used in production. There are also 2 controller ports on the "front" of the console, as well as your usual composite video, and sound cable, and power input. 


Hardware:

From an outside visual glance of the system you wouldn't expect much, but internally there is actually some pretty interesting things. The system contains a Sunplus SPG290 SoC (System-on-a-Chip) which is part of the Sunplus S+Core series architecture. 

The SPG290 is capable of clock speeds of 162MHZ, but in the Mattel HyperScan production run models, the chip has been clocked to 108MHZ. The SPG290 has support for USB, I2C, SPI, UART, NAND/SD memories, NOR memories, PWM, GPIOs, ADC, video, sound, and more. 

There is actually an un-populated, yet labeled SD card and UART interface internal to the system. I had pictures of my current setup that I have wired to both of these interfaces, but as of now, they sit on a dead phone. There is a pin header at the bottom left of the board, This is JTAG, and if I'm correct, I believe the wiring goes something like below.

JTAG Wiring:


8 - GND
7 - JTAG_TRSTN
6 - JTAG_TDI
5 - JTAG_TDO
4 - JTAG_TMS
3 - JTAG_TCK
2 - RESET_FOR_IN_CIRCUIT_EMULATOR (tied to physical reset)
1 - GND
J9 (label)

The controllers are actually a bit interesting. They appear to use I2C, and have a wire used for arbitration, or rather, bus mastering. There also appears to be another line that comes out of the controller port that ties into physical reset. My theory here is that this is done in order to sync up the starting of the system, and the controller. 

The controller itself contains a SPC11122a MCU, which appears to be a SPC11128 series type MCU with 128KB of OTP (One-Time-Programmable) memory. If I have time in the future, I might see if there is possibly a way of dumping the ROM from the MCU in the controller. The controller also contains a Winbond W55AD808 ADC (Analog-to-Digital-Converter) that's used for translating the variable resistance from the analog joystick, and translating them over to a digital value that the SPC11122A can handle. Below I'll list a multiple view configuration of the controller pin-out.


Controller Pinouts:

controller male connector:

     3     4
   2    I    5  
     1  I  6

1:brown : GND
2:yellow : DATA
3:grey : CLK
4:green : ENABLE
5:blue : RESET
6:red : VCC 3.3v

Controller mainboard male connector port:

J1
1:brown : GND
2:yellow : DATA
3:grey : CLK
4:green : ENABLE
5:blue : RESET
6:red : VCC 3.3v

Analog joystick board:

1: brown : GND
2: red : VCC 3.3v
3: orange : DATA 
4: yellow : CLK
5: green : ENABLE

Analog joystick mainboard connector:
 ---
|x_x|
  |1|
  |2|
  |3|
  |4|
  |5|
  
1: red : VCC 3.3v 
2: brown : GND 
3: green : ENABLE : IOD2 on SPC MCU
4: orange : DATA : IOD4 on SPC MCU
5: yellow : CLK : IOD3 on SPC MCU

Analog Joystick:
X -> A0 on ADC
Y -> A1 on ADC

The ADC appears to communicate with the main SPC MCU through I2C. I've wrote a working driver for Arduino that can read the input from the analog stick itself and spit the result out through serial, and that is located @ https://github.com/ppcasm/ADCdriver

As far as communication goes from the SPC to the HyperScan, it appears as though it uses I2C too. It appears that when the controllers are being "polled", the "chip select" pins get arbitrated back and forth, effectively allowing reading input from both controllers. 

The video hardware does not do any sort of 3D acceleration from what I can ascertain. It does do basic frame-buffer access, hardware pallete support, sprite support, and a few other niceties such has hardware supported page flipping. 

In order to facilitate quick code testing while reverse engineering, I have implemented a programming system that uses a micro-controller, PC application, and an application that runs on the HyperScan itself that essentially turns into a quick deployment code testing environment. It works through the controller port. For more information on it, go here: https://github.com/ppcasm/HYCU

Video of it in action here (NOTE: It is not this slow; this was a testing phase!! Also, my antiquated laptop was being pushed hard. :p): 



The USB doesn't seem to be used, but I do know from my firmware reverse engineering endeavors on the device (probably will be in the next installment) that there is a "testing mode" in the firmware that appears to activate the USB into "Mass Storage Mode" when it's testing device mode. This leads me to believe that the firmware actually holds code to externalize an SD card hooked up to the internal interface, over USB, as a Mass Storage Device. 

I have a library that I'm still working on getting set up. So far this includes basic frame-buffer access functions, basic printing functions, l.e.d, as well as functions that work together with doing communications and protocol accesses. 

I haven't done much with RFID outside of patching games to write different values to the cards. I do have working knowledge of the sound, and video so far. 

I guess that's it for part 1. I'm not sure when I'll get around to part 2, but hopefully this will at least answer some basic questions about the system, as well as give a slightly more in depth view of the components at hand. 







6 comments:

  1. Thank you! I am trying to get just the controller to work with the arduino. Do you happen to have any code to help me do this? (I've been trying for hours using PS/2 keyboard and mice code, but to no anvil).

    ReplyDelete
  2. Didn't realize someone left a message here for me, sorry for the belated response. I haven't messed with anything related to programming in a while. The last I remember I do believe I made headway on the controller. I do know for a fact that I have code that you can sort of tie together and use to read the analog stick directly. I believe I have it posted on my github at https://github.com/ppcasm/ADCdriver but be careful because it's extremely messy. I was actually considering not even releasing it when I did, but I feared I'd lose it somehow and released it just for posterity. PS/2 code most certainly will not work. :p If I ever somehow get around to programming again, I'll update this posting with even more in depth stuff. Thanks for reading.

    ReplyDelete
  3. Also, something else that's interesting. If you read the code I wrote on the loader, and check out the wiring I used, I kept a similar wiring setup for the loader that I wrote that works through the controller port. This wasn't by accident. As such, I've noticed that during certain times when the loader is being used, and the system is expecting controller input, the loader will mimic certain button presses. All of this was done purposely. I also used the reset line coming out of the controller port with the loader I wrote so that you could reset the system remotely from arduino (in case you're interested.) I believe the reason for them tying the reset and all through the controller port was so that they could sync up the resetting/powering on of the system with the controllers by resetting the SPC MCU in the controller at the same time.

    ReplyDelete
  4. Hey I was wondering if there's any sort of manual or something out there to code for the damn thing. After seeing the hello world program I figured this system has promise for text adventures until someone made something more graphical.

    ReplyDelete
  5. I would love to develop some homebrew for the HyperScan. Been wanting to for a long time, and then found this page a while back. Any chance you'd be up for creating that part 2? ;)

    ReplyDelete
    Replies
    1. I have a hyperscan unit and 3 controllers with X-man disc for sale if your interested. $10 + shipping. no power supply so i don't know if any of it works jirocz2@comcast.net Jim

      Delete