Browsing all articles from March, 2012

Flattr this!

As visitors to my office have noticed, we’ve been building a bunch of arcade machines for clients.
Here are a couple of pics of the builds in progress:

Chassis’s undergoing painting

Unfinished machine

While making those is fun, I also have an interest in what powers them.

Arcade Machines are really just a wooden box, a display, a controller board, input (buttons and joysticks), and a PSU, they’re pretty basic devices. There is an industry cabling standard – JAMMA which makes connecting them up nice and easy.

China has a number of hardware choices for powering them, ranging from PC based boards, original arcade boards, and what I think is the better solution for older games – emulation under embedded ARM/MIPS, vs dedicated boards.

We went through a number of different versions of hardware available here until I found something I liked.

Our currently build hardware du jour runs off of something called “King of Game”.
As is usual in China, no documentation, and the factory is less than forthcoming with information.

King of Arcade

Still, not unusual.

The device does have some interesting features for the would be hacker –

It has a nicely labelled “Boot” button, and the component count is quite low. Which generally means its SoC (System on a Chip) based.
The factory has done a little bit of prep work in making sure us ev1l hackorz won’t get at the juicy bits by etching off the cpu.

A quick look at the chip pin count, and the usual choice of chipset SoC more or less got me the right answer in a few minutes though.

My guess was Ingenic 4850, and it turned out to be the Ingenic 4755. This is a MIPS based X-Burst CPU

Even though they’re Chinese vendor, Ingenic does a great job in providing readily available information about their chipset(s). Kudos to the Ingenic guys in Beijing for being so open!

Datasheets for the 4755 and more importantly toolchains are readily available at the Ingenic FTP site –

Back to the board.

The King of Game board has USB onboard.
Plugging it into a computer shows the flash files available, but unfortunately not the firmware bits I need to see / change (e.g. to upgrade emulator capabilities, and change graphics).

If I hold down boot and plug in the USB, I get prompted for the Ingenic 4750 drivers.
Those are relatively easy to find on the ingenic site, so get a hold of those yourselves.

In order to connect to the board, you use a USB_BOOT.exe (there are also Linux tools available).
I downloaded usbboot-1.4b usbboot1.4b-tools, and unzipped that.

The USB Boot file needs a config file though – and the default config files supplied didn’t work 🙁

So, off to check what could be up.

The USB_Boot utility requires a bunch of settings in order to communicate with a board. After a bit of fiddling playing around with possible options I got it talking to the board.
While I’m not certain I have the settings completely correct here is what I have right now:

EXTCLK 24 ;Define the external crystal in MHz
CPUSPEED 336 ;Define the PLL output frequency
PHMDIV 3 ;Define the frequency divider ratio of PLL=CCLK:PCLK=HCLK=MCLK
BOUDRATE 57600 ;Define the uart boudrate
USEUART 0 ;Use which uart, 0/1 for jz4740,0/1/2/3 for jz4750

BUSWIDTH 16 ;The bus width of the SDRAM in bits (16|32)
BANKS 4 ;The bank number (2|4)
ROWADDR 12 ;Row address width in bits (11-13)
COLADDR 9 ;Column address width in bits (8-12)
ISMOBILE 0 ;Define whether SDRAM is mobile SDRAM, this only valid for Jz4750 ,1:yes 0:no
ISBUSSHARE 1 ;Define whether SDRAM bus share with NAND 1:shared 0:unshared

BUSWIDTH 8 ;The width of the NAND flash chip in bits (8|16|32)
ROWCYCLES 3 ;The row address cycles (2|3)
PAGESIZE 2048 ;The page size of the NAND chip in bytes(512|2048|4096)
PAGEPERBLOCK 64 ;The page number per block
FORCEERASE 0 ;The force to erase flag (0|1)
OOBSIZE 64 ;oob size in byte
ECCPOS 6 ;Specify the ECC offset inside the oob data (0-[oobsize-1])
BADBLACKPOS 0 ;Specify the badblock flag offset inside the oob (0-[oobsize-1])
BADBLACKPAGE 127 ;Specify the page number of badblock flag inside a block(0-[PAGEPERBLOCK-1])
PLANENUM 1 ;The planes number of target nand flash
BCHBIT 4 ;Specify the hardware BCH algorithm for 4750 (4|8)
WPPIN 0 ;Specify the write protect pin number
BLOCKPERCHIP 0 ;Specify the block number per chip,0 means ignore


If I put the board into USB boot mode (hold down boot button, and plug into the usb), then run the USB_TOOL.EXE file I can communicate

USB Boot Host Software!
USB Boot Software current version: 1.4b
Handling user command.
USBBoot :> list

Device number can connect :1
USBBoot :> help

Command support in current version:
help print this help;
boot boot device and make it in stage2;
list show current device number can connect;
fconfig set USB Boot config file;
nquery query NAND flash info;
nread read NAND flash data with checking bad block and ECC;
nreadraw read NAND flash data without checking bad block and ECC;
nreadoob read NAND flash oob without checking bad block and ECC;
nerase erase NAND flash;
nprog program NAND flash with data and ECC;
nmark mark a bad block in NAND flash;
go execute program in SDRAM;
version show current USB Boot software version;
exit quit from telnet session;
readnand read data from nand flash and store to SDRAM;
load load file data to SDRAM;
run run command script in file;
memtest do SDRAM test;
gpios let one GPIO to high level;
gpioc let one GPIO to low level;
sdprog program SD card;
sdread read data from SD card;
USBBoot :> boot

Usage: boot (1)
1:device index number
USBBoot :> boot 0

Checking state of No.0 device: Unboot
Now booting No.0 device:
Download stage one program and execute at 0x80002000: Pass
Download stage two program and execute at 0x80c00000: Pass
Boot success!
Now configure No.0 device:
Now checking whether all configure args valid:
Current device information: CPU is Jz4750
Crystal work at 24MHz, the CCLK up to 336MHz and PMH_CLK up to 112MHz
Total SDRAM size is 16 MB, work in 4 bank and 16 bit mode
Nand page size 2048, ECC offset 6, bad block ID 127, use 1 plane mode
Configure success!

Next up, read the firmware off the flash, and dump it to see which version of the Dingoo code they most probably ripped off 🙂

Flattr this!

Some reminder notes for myself for playing around with Bluetooth adaptors.

Note that bluetooth seems to be incredibly flaky – at least from my tests.
I would often get timeouts and failures. Results will depend on the radio environment around you…
Plus apparently the bluetooth adaptors I have all have the same mac address, so thats also an issue if you encounter the same and have > 1 plugged into various computers… Oh well, at least they were cheap!

Did some post mortem testing with a T series Thinkpad, seemed better, but still not 100% – I guess thats why people just don’t use it.

Install bluetooth –

apt-get install bluez-utils bluetooth

plug in a usb bluetooth adaptor

This will install some useful bluetooth tools.
hcitool, hciconfig, rfcomm are the basic command line bluetooth tools we’ll be using.

Hopefully at this point your device is recognized –

hcitool dev

This should return the mac address of the bluetooth adaptor:

# hcitool dev
hci0 00:1F:81:00:08:30

If the address is 00:00:00:00:00:00, then its not setup, check dmesg and see what kind of device you have.

Heres mine –

Bus 001 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

And a grep of ooth (as could be BlueTooth or Bluetooth or bluetooth…) from dmesg

dmesg | grep ooth
[ 4.845001] Bluetooth: Core ver 2.15
[ 4.845130] Bluetooth: HCI device and connection manager initialized
[ 4.845132] Bluetooth: HCI socket layer initialized
[ 4.891477] Bluetooth: Generic Bluetooth USB driver ver 0.6
[ 8.940263] Bluetooth: L2CAP ver 2.14
[ 8.940264] Bluetooth: L2CAP socket layer initialized
[ 8.943819] Bluetooth: RFCOMM TTY layer initialized
[ 8.943822] Bluetooth: RFCOMM socket layer initialized
[ 8.943823] Bluetooth: RFCOMM ver 1.11
[ 8.990134] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 8.990135] Bluetooth: BNEP filters: protocol multicast
[ 9.298370] Bluetooth: SCO (Voice Link) ver 0.6
[ 9.298372] Bluetooth: SCO socket layer initialized

If you don’t get a valid mac address, reboot, as that seemed to work for me.
Yes, its a hassle, but I didn’t delve too deeply into what modules needed to load.
If you don’t want to reboot I’ve modprobed for bluetooth and have the modules below post boot

You can try loading those with modprobe

lsmod | grep bluetooth
bluetooth 41827 9 sco,bnep,rfcomm,l2cap,btusb
rfkill 13044 2 bluetooth

You can also use hciconfig to list the name of the device (this is what you’ll see listed in another device if you enable discovery…)

hciconfig -a name
hci0: Type: BR/EDR Bus: USB
BD Address: 00:1F:81:00:08:30 ACL MTU: 1021:4 SCO MTU: 180:1
RX bytes:3551 acl:52 sco:0 events:140 errors:0
TX bytes:1243 acl:50 sco:0 commands:53 errors:7
Features: 0xff 0x3e 0x09 0x76 0x80 0x01 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Name: 'Accel-OB2'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 2.0 (0x3) Revision: 0x44
LMP Version: 2.0 (0x3) Subversion: 0x3
Manufacturer: Cambridge Silicon Radio (10)

Assuming the above is working, hcitool dev gives you a mac address, then hcitool scan should give a list of nearby bluetooth devices.
Suggest make something discoverable – eg a closeby desktop with bluetooth for testing.

hcitool scan
Scanning ...
00:1E:52:EC:A5:50 apple’s iMac

As you can see I have a device close by
Lets get some info about it

# hcitool info 00:1E:52:EC:A5:50
Requesting information ...
BD Address: 00:1E:52:EC:A5:50
Device Name: apple’s iMac
LMP Version: 2.0 (0x3) LMP Subversion: 0x7ad
Manufacturer: Cambridge Silicon Radio (10)
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
<3-slot packets> <5-slot packets>

<3-slot EDR ACL> <5-slot EDR ACL>

<3-slot EDR eSCO>

Ping it

l2ping 00:1E:52:EC:A5:50

Ping: 00:1E:52:EC:A5:50 from 00:1F:81:00:08:30 (data size 44) ...
44 bytes from 00:1E:52:EC:A5:50 id 0 time 17.76ms
44 bytes from 00:1E:52:EC:A5:50 id 1 time 31.87ms
44 bytes from 00:1E:52:EC:A5:50 id 2 time 23.92ms

Lets try to connect to it

hcitool cc 00:1E:52:EC:A5:50
hcitool auth 00:1E:52:EC:A5:50

– For auth to work, you’ll need to setup a pincode file in /var/lib/bluetooth/[mac address of the bluetooth adaptor inside your computer]/pincodes
Add the mac address of the device you want to connect to, and the pincode e.g.

cat /var/lib/bluetooth/00:1F:81:00:08:30/pincodes

#mac address of device connecting to, pin to use when connecting
00:1E:52:EC:A5:50 0000

If you want to be able to see your computer from another device, make it visible –
Make our computer visible to a bluetooth scan
hciconfig hci0 piscan

We can also setup a serial connection to our bluetooth device we want to connect to
rfcomm sets up a virtual serial port connection on the hci port specified. Then you can access the device via a serial connection – eg for gnokii or similar.

rfcomm connect 0 00:1E:52:EC:A5:50

Assuming you’ve connected to the device, and setup an rfcomm serial connection, you can use gnokii to query the device.
Gnokii is mostly for Nokia phones, but you can use AT commands to connect to other devices, such as iPhones etc.
For my test purposes, I needed to assist with integrating SMS to PHP, so was looking at setting up a bluetooth connection to a phone, then querying that for sms’s every 30 seconds or so, then passing that to a db or php script. Gnokii was the second part of that equation, as it can do some of that without too much headache.

(in gnokii – get the phone details)
gnokii --shell 2> /dev/null

> --identify

#(in gnokii - get the first sms in the phone)
> --getsms IN 1

Flattr this!

As I have been doing quite a bit of SSD updating for people who have Air’s, I have a small collection of older smaller SSD’s lying around.

Unfortunately the form factor means that they have been pretty useless in anything but a Macbook air – until now.
I’ve been able to source some small scale production samples of MicroSata -> Sata adaptors.

Photos below:

With Macbook Air SSD in situ
MacBook Air SSD to SATA Adaptor

Front and back – not much circuitry really.
MacBook Air SSD to SATA Adaptor

13.5cm length (which means can’t really be used in a laptop, sadly)
MacBook Air SSD to SATA Adaptor

Side by side comparison with populated and unpopulated adaptor
MacBook Air SSD to SATA Adaptor

Unfortunately they’re not much use in anything but a desktop at the moment due to length (13.5cm), but it does bring new life to the ones I have 🙂

Bonus, its a crapload cheaper for Air SSD’s than “normal” SSD’s – roughly half the price, so I can update some of the random desktops on the office.

Win / win!

If anyone is interested in purchasing some, let me know, and I’ll organize some more.