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 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.
