The CPU inside the VCI-100

[BentoSan]

I am no big fan of dissasembling assembly.

But if needed, I can try to help out?

Grab the ean golden 1.3 firmware and the decompiler fatlimey posted and start going for it

[Fatlimey]

Grab the ean golden 1.3 firmware and the decompiler fatlimey posted and start going for it

Next comes the painful, boring bit.

We do know that the 1.3 firmware contains two separate systems, the 1.2 and the 1.3 which are switchable at bootup. So the first thing to do is start from the boot address and look for this decision point - once you find that it should be possible to break the map into to sections and then cross-match their shared subroutines.

The other thing to do to build a memory map of the H8 processor to find out what addresses hold the IO pins and ADC registers, so that we can recognize button reads and highlight them. Currently the assembler just prints out "load register from address FFFFblah" which could mean anything. It's time to start attaching meaning to specific addresses.

Usually I'd do this on paper - print out the whole dump, pin it up on a wall and have at it with highlighters and notes, but that's not so easily shareable. Not sure how to proceed in a shareable manner. I think I'll just do what I can and report back.

Can anyone find a concise summary of the instruction set that doesn't involve buying a book?

[Fatlimey]

The next step- a manual for the H8/3052 chip itself:

http://documentation.renesas.com/eng...2_3052bfhm.pdf

Or the more condensed programming guide the chip family (300H):

http://documentation.renesas.com/eng...213_h8300h.pdf

Bit of light reading for you.

[Aanrii]

Great stuff Fatlimey. Got me interested right away and I'll help the way I can.

Bento said it, get this baby to next lvl.

[Sunshine]

Umm... Does Google or Babelfish have a translation for this thread?

It looks really complicated and exciting, but it's way beyond my comprehension.

Anyhow, enjoy - seems like some people are having fun.

[Fatlimey]

Been browsing through some assembly tonight. The instruction set has almost no surprises - your basic 16-bit RISC machine with 24-bit addresses.

The precise memory map depends on some pin settings (MD0,MD1,MD2) that select whether the CPU has external ram, and if so what the address space looks like. Without cracking open my machine (again, I'm such a hardware slut) I can't tell which mode the machine is set to use, but it has to be one of 5,6 or 7 as the BIN file writes ROM to the jump tables and ROM. I'm guessing it's using mode 7, the super-special chip-only design with no external RAM, just 8K internal Static RAM and heaps of ROM, but that's just a guess.

The address maps are on page 95 of 845 in the 3052.pdf document (I had to shorten the PDF name to save my sanity). The other PDF, the "h8300.pdf" file has a useful list of instructions in section 2.2. Having both docs open to crossreference works well.

So, back to the code. I'm using the 1.3 code to start with as I know there has to be a crucial decision point when the OS chooses between the 1.2 and 1.3 codebases, and that's what I'm looking for initially. It's an exercise in familarize myself with the code layout. The jump table at address 0x0000 says the code starts at 0x3FD2 - slap bang in the middle of the ROM in the memory map.

Some notes on the code.

003FD2  7A07 00FF FF10            MOV.L    #H'00FFFF10,ER7
003FD8  7A00 0000 8000            MOV.L    #H'00008000,ER0
003FDE  7A01 00FF EF10            MOV.L    #H'00FFEF10,ER1
003FE4  7A02 00FF F296            MOV.L    #H'00FFF296,ER2

Moving some fixed 32-bit addresses to the extended registers. 0x008000 is the end of the ROM area, 0xFFFF10 is the beginning of the External Address Space, 0xFFEF10 is an address that was important on the old 3048 chip - maybe they're testing which processor is being used? 0xFFF296 is a point in RAM that, on boot, hasn't been initialised yet.

003FEA  1F92                      CMP.L    ER1,ER2
003FEC  5870 0008                 BEQ      H'003FF8:16

If ER1 and ER2 are the same, skip the next bit.

003FF0  6C0B                      MOV.B    @ER0+,R3L
003FF2  689B                      MOV.B    R3L,@ER1
003FF4  0B71                      INC.L    #1,ER1
003FF6  40F2                      BRA      H'003FEA:8

Get a byte from 0x8000 (increment the pointer afterwards)
Write that byte to 0xEF10, add 1 to the pointer.
Branch always to somewhere above this starting point...

003FF8  5E00 3952                 JSR      @H'003952:24
003FFC  5670                      RTE

Jump to the routine at 0x3952, pushing the Condition register (CC) and PC to the stack.
When you return, pop the CC and PC from the stack. (strange. The SP contains nothing at this pooint, so the function above had better fill it with something)

003FFE  0100 6DF0                 MOV.L    ER0,@-ER7
004002  0100 6DF1                 MOV.L    ER1,@-ER7
004006  0100 6DF2                 MOV.L    ER2,@-ER7
00400A  0100 6DF3                 MOV.L    ER3,@-ER7
00400E  0100 6DF4                 MOV.L    ER4,@-ER7
004012  0100 6DF5                 MOV.L    ER5,@-ER7
004016  0100 6DF6                 MOV.L    ER6,@-ER7
00401A  5E00 5AF2                 JSR      @H'005AF2:24
00401E  0100 6D76                 MOV.L    @ER7+,ER6
004022  0100 6D75                 MOV.L    @ER7+,ER5
004026  0100 6D74                 MOV.L    @ER7+,ER4
00402A  0100 6D73                 MOV.L    @ER7+,ER3
00402E  0100 6D72                 MOV.L    @ER7+,ER2
004032  0100 6D71                 MOV.L    @ER7+,ER1
004036  0100 6D70                 MOV.L    @ER7+,ER0
00403A  5670                      RTE

Looks like ER7 is the stack pointer then, judging by the pre-decrement and post-increment ops it's a the top of memory growing downwards. This is a typical memory layout and function call as generated by a C compiler - push all the registers on the stack, jump to a routine, on return, restore the work. So the caller does the work, good to know. Looks like the RTE recovers the CC and mangles the PC? Not quite understanding that bit...


So that's the beginning of work. The function we jump to at 0x3952 is interesting.

003952  7A03 00FF F052            MOV.L    #H'00FFF052,ER3
003958  7A05 0000 37BE            MOV.L    #H'000037BE,ER5
00395E  7906 0001                 MOV.W    #H'0001,R6

Load some constants into the registers.

003962  1900                      SUB.W    R0,R0
003964  0B50                      INC.W    #1,R0
003966  7920 7FFF                 CMP.W    #H'7FFF,R0
00396A  4DF8                      BLT      H'003964:8

Clear R0(subtract it from itself)
Add 1 to R0
Compare R0 to 0x7FFFF
If it's less then branch to the increment - it's a loop that does nothing!
Maybe it creates a necessary delay? 0x7ffff is a typical value. Who can say.

Next comes a BIGASS block of function calls.

00396C  5E00 3B4E                 JSR      @H'003B4E:24
003970  5E00 3F02                 JSR      @H'003F02:24
003974  5E00 4F0C                 JSR      @H'004F0C:24
003978  5E00 0200                 JSR      @H'000200:24
00397C  5E00 2AA4                 JSR      @H'002AA4:24
003980  5E00 3636                 JSR      @H'003636:24
003984  5E00 0870                 JSR      @H'000870:24
003988  5E00 4FDE                 JSR      @H'004FDE:24
00398C  5E00 54CE                 JSR      @H'0054CE:24
003990  5E00 59C2                 JSR      @H'0059C2:24
003994  5E00 413A                 JSR      @H'00413A:24
003998  5E00 372A                 JSR      @H'00372A:24
00399C  5E00 3B76                 JSR      @H'003B76:24
0039A0  5E00 4178                 JSR      @H'004178:24

Yup. That's where the machine gets initialised! Someone had a function here that calls a bunch of functions one after the other, each one with no arguments. Looks like the program map is filling out nicely. The "JSR 0x0200" in that block is jumping to the first instruction in the ROM after the Vector addresses. Interesting..

Also notehow all the JSRs so far are to addresses less than the starting address - a typical layout for functions inside the same C file, jumping to functions that have already been defined. This won't hold for much longer.

OK, bedtime.

[BentoSan]

Wow nice Fatlimey, thats some impressive work. Your way ahead of me i am still reading about the basics of assembly Ive done some light coding and memory hacking in the past but nothing as deep as assembly :eek: This is a great opportunity to learn though and your posts are certainly helping out *thumbs up*

[2dfruit]

I'm no programmer, so I don't have a notion as to what you fellas are talking about here.

What sort of things are possible if you complete what you's are trying to do?

[Kaon]

big ups to you guys

[BentoSan]

I'm no programmer, so I don't have a notion as to what you fellas are talking about here.

What sort of things are possible if you complete what you's are trying to do?

Alot of things, we could increase the midi resolution on the pitch faders, make all the lights work, fix the issues in the 1.2 firmware, remake the Ean Golden edition/add extra functionality add extra buttons, knobs, faders to the device.