What's new
By:
Filters

MK1 5.0 T-Unit hacking

Asure

Asure

Grand Master
Joined
Jul 24, 2015
Messages
622
Reaction score
778
Location
Netherlands
Midway loves obfuscating jumps.. Here's the example in MK1:

Code: 
FFCAF9C0: 09E1 DB00 000E           MOVI   EDB00h,A1
FFCAF9F0: 0D3F 00EC                CALLR  FFCB08D0h

Yes that almost spells ED Boon. ;)

Code: 
FFDB5410: 09C0 3008                MOVI   3008h,A0
FFDB5430: 0D5F AB00 FFC8           CALLA  FFC8AB00h
FFDB5460: 0D5F 9C90 FFC8           CALLA  FFC89C90h
FFDB5490: 09C0 02EE                MOVI   2EEh,A0
FFDB54B0: 0D5F B180 FFC9           CALLA  FFC9B180h
FFDB54E0: C819                     JRC    FFDB5680h
FFDB54F0: 09E0 1500 FFEB           MOVI   FFEB1500h,A0
FFDB5520: 4C01                     MOVE   A0,A1
FFDB5530: 0D01 114F FFF4           SUBI   BEEB0h,A1
FFDB5560: 4C20                     MOVE   A1,A0
FFDB5570: 09E1 55C0 FFDB           MOVI   FFDB55C0h,A1
FFDB55A0: A22F                     MOVE   A1,-*SP,1
FFDB55B0: 0160                     JUMP   A0
FFDB55C0: 4C00                     MOVE   A0,A0
FFDB55D0: CA0A                     JREQ   FFDB5680h

Basically A0 is filled with some values, juggled around into A1, then BEEB0 is subtracted, A1 is put back to A0, and finally, we jump to A0 (which is near the code below.)

Code: 
FFDF2650: 09C0 7000                MOVI   7000h,A0  ; a whole bunch of stuff to obfuscate the read from 'hidden ram' as presented 
FFDF2670: 0D5F B040 FFC9           CALLA  FFC9B040h  ; by the ASIC chip from 0x1b00000 -> 0x1b6ffff
FFDF26A0: 2480                     SLL    4h,A0
FFDF26B0: 09EE 0000 01A0           MOVI   1A00000h,A14 ; not 1B00000 right!
FFDF26E0: 400E                     ADD    A0,A14
FFDF26F0: 18E0                     MOVK   7h,A0
FFDF2700: 0D5F B040 FFC9           CALLA  FFC9B040h
FFDF2730: 1420                     DEC    A0
FFDF2740: 24C0                     SLL    6h,A0
FFDF2750: 0B20 2970 FFDF           ADDI   FFDF2970h,A0
FFDF2780: 860B                     MOVE   *A0,A11,1
FFDF2790: B601 0020                MOVE   *A0(20h),A1,1
FFDF27B0: 0BE1 FFD7                SUBI   28h,A1
FFDF27D0: 2501                     SLL    8h,A1
FFDF27E0: 0B2E 0000 0010           ADDI   100000h,A14 ; lets add 10000 to 1A00000 and end up at 1B00000 ;)
FFDF2810: 802E                     MOVE   A1,*A14,0
FFDF2820: 85C0                     MOVE   *A14,A0,0
FFDF2830: 0B80 81FF FFFF           ANDI   7E00h,A0
FFDF2860: 2EE0                     SRL    9h,A0
FFDF2870: 9561                     MOVE   *A11+,A1,0
FFDF2880: 0B41 FF00                CMPI   FFh,A1  ; check if A1 = FF
FFDF28A0: CA0A                     JREQ   FFDF2950h  ;if A1 is equal to 0xFF we go to FFDF2950 (we're done reading, and we never had a wrong answer from asic.)
FFDF28B0: 4801                     CMP    A0,A1  ; Not done reading security values. Lets compare: A0 and A1 should be the same.
FFDF28C0: CB01                     JRNE  FFDF28E0   ; this is where we goto if things are not the same.. (i.e. we trip security.)
FFDF28D0: C0F4                     JR     FFDF2820h  ; back to our checking asic loop.
FFDF28E0: 09C0 0025                MOVI   25h,A0 ;proces ID
FFDF2900: 0D5F 37D0 FFE1           CALLA  FFE137D0h ;start that process (probably a seccal_trash equivalent like we saw in NBA jam.)
FFDF2930: 1820                     MOVK   1h,A0  ; also let's shove an additinal 0x1 into A0 to let the routine that called us know we failed. 
FFDF2940: 0960                     RETS   ; back to where we came from (in failed state)
FFDF2950: 5600                     CLR    A0   ; basically our exit routine if all is well and nothing failed. Clear values in reg A0
FFDF2960: 0960                     RETS

Anyway how do we fix this if stuff goes 'wrong' on our different ASIC:

Code: 
FFDF28C0: CB01                     JRNE  FFDF28E0   ; this is where we goto if things are not zero (wrong).

Should be:

Code: 
FFDF28C0: CB08                     JRNE   FFDF2950h
FFDF2950: 5600                     CLR    A0   ; basically our exit routine if all is well and nothing failed.
FFDF2960: 0960                     RETS

I've not found any crc check yet in this one and that's one of the reasons this patch is not released, i get some strange things in regards to the Coin drop sound speed increase and Game over screen looks wierd sometimes. There is several more JUMP A0 in the code and i'm not 100% sure about this patch. The Turbo Ninja hack also leaves this check intact, maybe for the same reason. I need to look into this more some time. For now, it runs and plays..
 
I wish there was a good way to exchange data between Ghidra and MAME for stuff like this... for example the results of trace, trackmem and trackpc, so you can validate that changes don't change the program flow. And does MAME support input recording+playback so you could automate testing?
 
Asure said:
Midway loves obfuscating jumps.. Here's the example in MK1:

Code: 
FFCAF9C0: 09E1 DB00 000E           MOVI   EDB00h,A1
FFCAF9F0: 0D3F 00EC                CALLR  FFCB08D0h

Yes that almost spells ED Boon. ;)

Code: 
FFDB5410: 09C0 3008                MOVI   3008h,A0
FFDB5430: 0D5F AB00 FFC8           CALLA  FFC8AB00h
FFDB5460: 0D5F 9C90 FFC8           CALLA  FFC89C90h
FFDB5490: 09C0 02EE                MOVI   2EEh,A0
FFDB54B0: 0D5F B180 FFC9           CALLA  FFC9B180h
FFDB54E0: C819                     JRC    FFDB5680h
FFDB54F0: 09E0 1500 FFEB           MOVI   FFEB1500h,A0
FFDB5520: 4C01                     MOVE   A0,A1
FFDB5530: 0D01 114F FFF4           SUBI   BEEB0h,A1
FFDB5560: 4C20                     MOVE   A1,A0
FFDB5570: 09E1 55C0 FFDB           MOVI   FFDB55C0h,A1
FFDB55A0: A22F                     MOVE   A1,-*SP,1
FFDB55B0: 0160                     JUMP   A0
FFDB55C0: 4C00                     MOVE   A0,A0
FFDB55D0: CA0A                     JREQ   FFDB5680h

Basically A0 is filled with some values, juggled around into A1, then BEEB0 is subtracted, A1 is put back to A0, and finally, we jump to A0 (which is near the code below.)

Code: 
FFDF2650: 09C0 7000                MOVI   7000h,A0  ; a whole bunch of stuff to obfuscate the read from 'hidden ram' as presented
FFDF2670: 0D5F B040 FFC9           CALLA  FFC9B040h  ; by the ASIC chip from 0x1b00000 -> 0x1b6ffff
FFDF26A0: 2480                     SLL    4h,A0
FFDF26B0: 09EE 0000 01A0           MOVI   1A00000h,A14 ; not 1B00000 right!
FFDF26E0: 400E                     ADD    A0,A14
FFDF26F0: 18E0                     MOVK   7h,A0
FFDF2700: 0D5F B040 FFC9           CALLA  FFC9B040h
FFDF2730: 1420                     DEC    A0
FFDF2740: 24C0                     SLL    6h,A0
FFDF2750: 0B20 2970 FFDF           ADDI   FFDF2970h,A0
FFDF2780: 860B                     MOVE   *A0,A11,1
FFDF2790: B601 0020                MOVE   *A0(20h),A1,1
FFDF27B0: 0BE1 FFD7                SUBI   28h,A1
FFDF27D0: 2501                     SLL    8h,A1
FFDF27E0: 0B2E 0000 0010           ADDI   100000h,A14 ; lets add 10000 to 1A00000 and end up at 1B00000 ;)
FFDF2810: 802E                     MOVE   A1,*A14,0
FFDF2820: 85C0                     MOVE   *A14,A0,0
FFDF2830: 0B80 81FF FFFF           ANDI   7E00h,A0
FFDF2860: 2EE0                     SRL    9h,A0
FFDF2870: 9561                     MOVE   *A11+,A1,0
FFDF2880: 0B41 FF00                CMPI   FFh,A1  ; check if A1 = FF
FFDF28A0: CA0A                     JREQ   FFDF2950h  ;if A1 is equal to 0xFF we go to FFDF2950 (we're done reading, and we never had a wrong answer from asic.)
FFDF28B0: 4801                     CMP    A0,A1  ; Not done reading security values. Lets compare: A0 and A1 should be the same.
FFDF28C0: CB01                     JRNE  FFDF28E0   ; this is where we goto if things are not the same.. (i.e. we trip security.)
FFDF28D0: C0F4                     JR     FFDF2820h  ; back to our checking asic loop.
FFDF28E0: 09C0 0025                MOVI   25h,A0 ;proces ID
FFDF2900: 0D5F 37D0 FFE1           CALLA  FFE137D0h ;start that process (probably a seccal_trash equivalent like we saw in NBA jam.)
FFDF2930: 1820                     MOVK   1h,A0  ; also let's shove an additinal 0x1 into A0 to let the routine that called us know we failed.
FFDF2940: 0960                     RETS   ; back to where we came from (in failed state)
FFDF2950: 5600                     CLR    A0   ; basically our exit routine if all is well and nothing failed. Clear values in reg A0
FFDF2960: 0960                     RETS

Anyway how do we fix this if stuff goes 'wrong' on our different ASIC:

Code: 
FFDF28C0: CB01                     JRNE  FFDF28E0   ; this is where we goto if things are not zero (wrong).

Should be:

Code: 
FFDF28C0: CB08                     JRNE   FFDF2950h
FFDF2950: 5600                     CLR    A0   ; basically our exit routine if all is well and nothing failed.
FFDF2960: 0960                     RETS

I've not found any crc check yet in this one and that's one of the reasons this patch is not released, i get some strange things in regards to the Coin drop sound speed increase and Game over screen looks wierd sometimes. There is several more JUMP A0 in the code and i'm not 100% sure about this patch. The Turbo Ninja hack also leaves this check intact, maybe for the same reason. I need to look into this more some time. For now, it runs and plays..
Click to expand...
these are apparently normal with T-unit 5.0. I had bought a T-unit board many years ago and it exhibited all these behaviors and it took me back to 1993 seeing my grandpa's game. :P the coin up sound pitch just varies and I think you refer to the bottom few scores being blank on the high score table? I think also the comic book offer screen will be empty too kind of like if you disable the offer in dipswitches.

if you need any roms tested let me know, I'm nearing being able to do this.
 
One thing still bothers me on this, the sound board hidden ram. All of them have this (common in mame src.)

Code: 
    m_hidden_ram = std::make_unique<uint8_t[]>(43);
    save_pointer(NAME(m_hidden_ram), 43);

    /* sound chip protection (hidden RAM) */
    m_adpcm_sound->get_cpu()->space(AS_PROGRAM).install_ram(0xfb9c, 0xfbc6, m_hidden_ram.get());

But there is additional (different) hidden ram for games itself: (jam & te differ)
Code: 
    /* sound chip protection (hidden RAM) */
    if (!te_protection)
        m_adpcm_sound->get_cpu()->space(AS_PROGRAM).install_ram(0xfbaa, 0xfbd4, m_hidden_ram.get()); (this is JAM)
    else
        m_adpcm_sound->get_cpu()->space(AS_PROGRAM).install_ram(0xfbec, 0xfc16, m_hidden_ram.get()); (this is TE)

    /* sound chip protection (hidden RAM) */
    m_adpcm_sound->get_cpu()->space(AS_PROGRAM).install_ram(0xfbcf, 0xfbf9, m_hidden_ram.get()); (this is dredd)

    /* sound chip protection (hidden RAM) */
    m_adpcm_sound->get_cpu()->space(AS_PROGRAM).install_ram(0xfb9c, 0xfbc6, m_hidden_ram.get()); this is MK

I've swapped sound board chips etc. and never ran into issues say 10-15 years ago. But Mame clearly shows different fake ram for the sound cpu.

Anybody got any soundboards to compare?
I have PAL label A-16422 on JAM here.
What's on the boards for JAM TE (Pics online sugest A-16422)
and MK? (Pics online suggest A-5346-40025-9 (or -G) (Which i dumped some time back haha).
 
My JAM is A-126422
My MK label fell off :(
 
You must log in or register to reply here.
Back
Top