The CPU inside the VCI-100

DJ Gear & Hardware Hardware: Controllers, Mods and Gear
1

The CPU inside the VCI-100

I checked out the controller inside the VCI-100, and according to Ean’s upgrade video, it’s a Hitachi H8/3052:

http://www.nuhorizons.com/developmenttools/renesas/H8_Tiny_brochure.pdf
http://www.datasheet4u.com/download.php?id=527539

That thing has way more features than strictly necessary - 512K flash ROM, 8K RAM, programmable DMA (not used), timers and clock pulse generators galore (not used). It only has two ADC channels on the chip so it must be polling the knobs and using an analog multiplexer, but it has 70+8 digital inputs/outputs! (8 of the channels are output only) That means it can read 70 switches without needing any extra hardware, or control 78 output LEDs.

The part is sold by Hitachi’s IC arm called Renesas, and the GNU based toolchain is available here:

http://tool-support.renesas.com/eng/toolnews/h8_1.htm
http://tool-support.renesas.com/eng/toolnews/h8.html

FYI, Renesas are having a developer conference in October in San Diego (http://devconrenesas.com/index.html) where you can meet the Mythbusters (http://devconrenesas.com/schedule/speakers/jamie_adam.html)

WTF?

2

This could potentially lead to some serious DIY jobs, awesome job on your research. I really hope we can make something of this. gets reading

3

Alrighty.

I decided to take a look at the 1.3 binary to see what’s in there. The first thing any reverse engineer does is run the tool “strings” on any binary to see what’s embedded in there. And, surprise! The whole damn thing is strings:

S113025000FFEF666AA800FFEF6501006D7554703A
S11302605E0063D47937000A19CC7A0600FFEF6682
S113027028E84AFC7FE872500DC819005E0006B8F1
S11302800DC8790000015E0006B80DC879000002AF
S11302905E0006B80DC8790000035E0006B8188831
S11302A05A0003AA686838CBF81738E87FE870501A

Can’t find any documentatino on the “.MOT” file format, so I took a look around and it seems the fields are an “S1”, a 1-byte count of the number of following bytes, a 16-bit address. four 32-bit instructions and a single byte checksum:

S0 0E 0000 7663 69 31 30 30 20 20 6D 6F 74 8E
S1 13 0000 00003FD2 00003FFC 00003FFC 00003FFC 2A
S1 13 0010 00003FFC 00003FFC 00003FFC 00003FFC F0
S1 13 0020 00003FFC 00003FFC 00003FFC 00003FFC E0
S1 13 0030 0000364C 00003FFC 00003FFC 00003FFC 89
S1 13 0040 00003FFC 00005AF2 00000000 00000000 25
S1 13 0050 00000000 00000000 00000000 00000000 9C
S1 13 0060 00004F44 00004F50 00000000 00000000 5A
S1 13 0070 0000503E 00000000 00000000 00000000 EE
S1 07 0080 0000552E F5

The first few lines look like an interrupt jump table. However, I could be wrong about the 32-bit instructions thing looking at the last few words:

S1 13 9A8C 00730074 00610078 00200043 004F004E 06
S1 13 9A9C 00540052 004F004C 004C0045 0052000A 88
S1 0C 9AAC 03300030 00300030 00 EA
S9 03 00 00 FC

There are also some pretty patterns in there towards the end with tables of rising values:

S1 13 9000 0000010202030404050606070808090A 11
S1 13 9010 0A0B0C0C0D0E0E0F10101112 2131314 58
S1 13 9020 14151516161717181819191A1A1B1B1C BC
S1 13 9030 1C1D1D1E1E1F1F202021212222232324 2C
S1 13 9040 24252526262727282829292A2A2B2B2C 9C
S1 13 9050 2C2D2D2E2E2F2F303031313232333334 0C
S1 13 9060 34353536363737383839393A3A3B3B3C 7C
S1 13 9070 3C3D3D3E3E3F3FFFFFFFFFFFFFFFFFFF 45
S1 13 9080 FFFFFFFFFFFFFFFF4040414142424343 D8

That should help to work out the checksum algorithm.

All in all I’d guess about 6k of code to decompile that fits into 512K of flash ROM! It must be echoy in there. :slight_smile:

4

Looking at the 1.3 binary in the free Flash toolkit shows the contents. The format guess looks correct, 16-bit addresses where untouched addresses are zeroed out. Next job is to run these bytes through a disassembler.

5

tell you what that looks impressive - but a right 747!

straight over my head!

6

Does this mean autogain will work better?

:stuck_out_tongue:

You guys are ahead of your time!

7

What?

HAHAHAH!

8

Here’s a disassembler, plus a handy “s2bin” application that reads the .mot files and converts them to binary files.

H8 Disassembler: dasmh83.zip

Here’s the first few instructions:

C:\Temp\h8disassemble> dasmh83 vci.bin 0x0200,0x600
H8/300H (I:24bit/D:24bit)  Disassemble valid address 0x0-0x9AB4
000200  0100 6DF5                 MOV.L    ER5,@-ER7
000204  1911                      SUB.W    R1,R1
000206  1900                      SUB.W    R0,R0
000208  17F1                      EXTS.L   ER1
00020A  0F95                      MOV.L    ER1,ER5
00020C  7850 6AA8 00FF EF2B       MOV.B    R0L,@(H'FFFFEF2B:24,ER5)
000214  1035                      SHLL.L   ER5
000216  7850 6BA0 00FF EF22       MOV.W    R0,@(H'FFFFEF22:24,ER5)
00021E  0B51                      INC.W    #1,R1
000220  7921 0004                 CMP.W    #H'0004,R1
000224  4DE2                      BLT      H'000208:8
000226  F813                      MOV.B    #H'13,R0L
000228  38E8                      MOV.B    R0L,@H'FFFFE8:8
00022A  7FE8 7050                 BSET     #5,@H'FFFFE8:8
00022E  1911                      SUB.W    R1,R1
000230  1888                      SUB.B    R0L,R0L
000232  17F1                      EXTS.L   ER1
000234  0F95                      MOV.L    ER1,ER5
000236  7850 6AA8 00FF EF2F       MOV.B    R0L,@(H'FFFFEF2F:24,ER5)
00023E  7850 6AA8 00FF EF4A       MOV.B    R0L,@(H'FFFFEF4A:24,ER5)
000246  0B51                      INC.W    #1,R1
000248  7921 001B                 CMP.W    #H'001B,R1
00024C  4DE4                      BLT      H'000232:8
00024E  6AA8 00FF EF66            MOV.B    R0L,@H'FFEF66:24
000254  6AA8 00FF EF65            MOV.B    R0L,@H'FFEF65:24
00025A  0100 6D75                 MOV.L    @ER7+,ER5
00025E  5470                      RTS
000260  5E00 63D4                 JSR      @H'0063D4:24
000264  7937 000A                 SUB.W    #H'000A,R7
000268  19CC                      SUB.W    E4,E4
00026A  7A06 00FF EF66            MOV.L    #H'00FFEF66,ER6
000270  28E8                      MOV.B    @H'FFFFE8:8,R0L
000272  4AFC                      BPL      H'000270:8
000274  7FE8 7250                 BCLR     #5,@H'FFFFE8:8
000278  0DC8                      MOV.W    E4,E0
00027A  1900                      SUB.W    R0,R0
00027C  5E00 06B8                 JSR      @H'0006B8:24
000280  0DC8                      MOV.W    E4,E0
000282  7900 0001                 MOV.W    #H'0001,R0
000286  5E00 06B8                 JSR      @H'0006B8:24
00028A  0DC8                      MOV.W    E4,E0
00028C  7900 0002                 MOV.W    #H'0002,R0
000290  5E00 06B8                 JSR      @H'0006B8:24
9

According to Page 84 of this book:

the address at 0x0000 is where the program will start. So start disassembling from 0x00007663.

10

The data is formatted as “Motorola S-Record” datastreams, and the format is described here:

http://www.amelek.gda.pl/avr/uisp/srecord.htm

We have one “S0” header record, lots of “S1” 16-bit address records and a single “S9” termination record. Our S0 header reads:

S00E000076636931303020206D6F748E

Which is interpreted as:

S0 0E 0000 76 63 69 31 30 30 20 20 6D 6F 74 8E

Dropping the address (always 0000) and the checksum gives us the ascii string “vci100 mot” (vci100 mot).

The S9 record:

S9 03 0000 FC

tells us the starting address is 0x0000.

11

if i’m studying informatics, wtf r u ? :disappointed:

12

It’s just basic low-level hacking. You try to understand a block of memory from the processor’s point of view. You start with the entry point and look for Jump and Return commands, use this to break the source into subroutines, then for each subroutine try to understand what it does, specifically what it’s side effects are. What parts of memory is it writing to, what parts is it reading from? When do the IO pins get written to and read from?

You’re building up a map of what each block does, inexactly the same way you would explore an unknown territory. There are a few key instructions to search for that control IO pins, send standard USB messages and reset the Analog-Digital converter and we can use these as landmarks. We then search outwards from these. We know it sends MIDI commands, so we need to find out where these are generated and where they are sent out. We know that certain MIDI messages turn on lights, so there has to be some storage used for these, we need to find the data structure that holds these states.

I guess they don’t teach low-level reverse engineering these days. Too “dangerous”. It’s the same techniques that crackers use to chase down copy protection code, or virus writers use to find interesting places to hide their payloads.

Go learn some assembly code, my friend. It will set you free!

P.S. Anyone want to help? The ultimate goal is to recreate the effect of this code in C, then extend it.

13

1.2 firmware

The 1.2 firmware might be better to hack on because it should have less subroutines than 1.3.

14

The filename says v1.02, but thanks. Good idea!

15

Fascinating work!

My knowledge of assembler is minimal, but Ill help out where I can.

Vestax should really release the source though, they must realize by now they have a future classic in their hands, by being the first major company to release source, even to a select few developers they will cement that.

16

What do they really have to lose for giving that information out?

that wouldnt be copyright infrindgement(or something like it) would it?

17

Fat Limey you are the man! I could probably help out with some C work down the road but i haven’t dabbled in Assembler before. Exciting stuff though!!!

(WORD UP THE NERDS!!!)

18

Whoa i got some sleep and went to work and get back to find you guys are all over this :stuck_out_tongue: Sweet !

You are so very right, the Ean Golden SE is just a taste of what could be.

Time to start decompiling this baby :wink:

19

Your a legend i was looking for something like this last night but had to goto bed, you know your stuff way better than i do but ill help where i can and hopefully learn some stuff along the way :slight_smile:

20

I am no big fan of dissasembling assembly.

But if needed, I can try to help out?