Asure
Grand Master
Did some hacking on NBA Jam TE so it would run on any T-Unit.
The security is quite devious. And unique per ASIC. The ASIC has functions of moving around data, but it also adds some hidden ram which is visible to the main cpu.
On NBA Jam/TE this hidden ram is used in conjunction with a table inside the asic.
The flow is like this:
Main game:
This has a function called 'seccal1'
Basically this is an obfuscated jump. The first action is when the demo game starts and sits in attract..
BB.ASM
The offset is loaded into A8 and stuff resumes. Eventually it comes to this point:
BB.ASM
The JUMP A1 is basically 'jump security_check'
There is never a direct call to the routine below, all of them are obfuscated. There are several calls to this point from game flow btw.
UTIL.ASM
A big nice pointer for debugging, it seems to want A0=0 and the rets if we read this properly..
Also great, there is no 'this is checksummed' note here, so we can do as we please. (or not, more on this later.)
I had thought to replace the security tables, functions etc, but just patched this. And it seems to work fine. Except, when i tried real hardware, i would get strange random bugs.
Balls with wierd gravity, the scrolling of the playfield breaks.. But not always, I could play a game perfectly fine.
It turns out both 'seccal1' and 'security_chk' are read from rom, by rom, which is near impossible to find using the mame debugger. Also with any other debugger. Or i lack the knowledge how to do it.
This checksumming is also referred to by the comment in the code earlier. Except where was it doing this? After some more searching and debugging it turns out it's this little tidbit.
This code gets called when game is around 3rd quarter, and displays player stats. This condition is also met several times during attract loop..
I cleaned it up and left some stuff out for readability.
BB.ASM
And here's security_trashstuff
BB.ASM
This uses some macros and creates a 'process' (handled by mproc.asm) which is basically how the T-Unit handles multitasking. The games run as a sort of multitasking OS.
This code runs in a loop, can sleep, linger, awaken, get killed, die by itself when done etc.
So here's the deal. If A8 is not '-2' we do nasty stuff. Randomly between 5-9 minutes. A match is 1m30s. So around 3rd quarter, stuff starts to break. And getting into the next quarter does some auto fixing of registers, so it looks less broken, but still breaks. With some luck we have 9 minutes, and nothing breaks. Arghh. Evil.
Anyway to patch this:
- seccal1 is still the same
- security_chk is just doing CLR A0; RETS now. No calculations w/ hidden ram. Probably faster.
- security_trashstuff just does a DIE now. It still gets created as a process and ends up in the list for a few ms but then just dies.
With this patched into TE 2.1 the game runs on my standard NBA Jam board fine. (Also tested TE 2.1 Rewind roms.)
This was all very top secret. The MK2 code that was leaked did _not_ contain these routines, but they were still referenced and preventing the game to compile when i started working on it.
I guess when they gave this code to the psx developers it was sanitized.
Also in MK1 5.0 for t-unit, there is similar code, but i could not find any cksum on it yet. I also have that patched, but maybe i'll create a different topic for it some day. (It is quite simple.)
Anyway, yes, this means we can have a multi T-Unit.
MK1, Nba Jam, Nba Jam TE, NBA Jam TE Rewind. (I don't care about TROG!)
And MK2 with DCS soundboard.. or maybe aftermarket sound board? or an FPGA alternative sound board.)
Probably the Dredd proto if i find free time to look at it. I don't know how @Hammy patched it yet.
An educated hacker could now go and make some roms with the pointers above, and probably something will end up on Ebay. Should i set up a paypal donate button? Mweh. I didn't think this through when i started this for knowledge and fun. I don't even have enough eproms and t-unit boards to work with lol. I hope it at least makes for a nice read.
Edit: I Released this patched version: Use v1.2 which is here:
https://www.dropbox.com/scl/fi/8aji...v1.2.zip?rlkey=y6yurn7epa4pl90zwt8s9wl1x&dl=0
(updated link)
The security is quite devious. And unique per ASIC. The ASIC has functions of moving around data, but it also adds some hidden ram which is visible to the main cpu.
On NBA Jam/TE this hidden ram is used in conjunction with a table inside the asic.
The flow is like this:
Main game:
This has a function called 'seccal1'
Basically this is an obfuscated jump. The first action is when the demo game starts and sits in attract..
BB.ASM
Code:
SUBR demogame_start ;Demo mode entry
JSRP scrn_scaleininit ;Hide display
movi security_chk->1df60,a8The offset is loaded into A8 and stuff resumes. Eventually it comes to this point:
BB.ASM
Code:
;-----------
;This is checksummed!
seccall1
move a8,a1 ;>Check security
addi >1df60,a1
getpc a7
addi >40,a7
move a7,-*sp,L
jump a1 ;Rets: A0=0 if OK!
seccall1end
;-----------The JUMP A1 is basically 'jump security_check'
There is never a direct call to the routine below, all of them are obfuscated. There are several calls to this point from game flow btw.
UTIL.ASM
Code:
SUBR security_chk ;Note: this is at FF849B30 in rom
.if SECDB
clr a0
retsA big nice pointer for debugging, it seems to want A0=0 and the rets if we read this properly..
Also great, there is no 'this is checksummed' note here, so we can do as we please. (or not, more on this later.)
I had thought to replace the security tables, functions etc, but just patched this. And it seems to work fine. Except, when i tried real hardware, i would get strange random bugs.
Balls with wierd gravity, the scrolling of the playfield breaks.. But not always, I could play a game perfectly fine.
It turns out both 'seccal1' and 'security_chk' are read from rom, by rom, which is near impossible to find using the mame debugger. Also with any other debugger. Or i lack the knowledge how to do it.
This checksumming is also referred to by the comment in the code earlier. Except where was it doing this? After some more searching and debugging it turns out it's this little tidbit.
This code gets called when game is around 3rd quarter, and displays player stats. This condition is also met several times during attract loop..
I cleaned it up and left some stuff out for readability.
BB.ASM
Code:
#tag7
movi P4DATA,a11 ;A11=*plyr data
calla refill_turbo
calla prt_top_scores ;Update scores at scrn top
calla prt_cr_timers
movi seccall1+>3df2,a0 ;>Chksum security call code
movk (seccall1end-seccall1)/16,b0
movi ->259e0d-2,a8 ;1st value
#csumlp move *a0(->3df2),a1
add a1,a8
addk 16,a0
dsj b0,#csumlp ;>Chksum security_chk code
movi security_chk+>4bbb,a0
movi 68+128*2,b0 ;#Words
#csmlp move *a0(->4bbb),a1
add a1,a8
addk 16,a0
dsj b0,#csmlp
SLEEPK 5
calla update_scorebrd
CREATE0 security_trashstuff ;Pass A8And here's security_trashstuff
BB.ASM
Code:
#*******************************
* Trash free object list because security failed (Process)
* A8=Security status (-2=OK!)
SUBRP security_trashstuff
addk 2,a8
jrz #x ;OK?
movi TSEC*60*5+1,a0
calla RNDRNG0 ;Comment by Asure, this is a random number generator
addi TSEC*60*4-3,a0
calla PRCSLP ;Sleep 5-9 minutes
movi OFREE,a1
movk 10,a2
#lp move *a1,a1,L
dsj a2,#lp
move a0,*a1,L ;Trash 10th free objs *next (-1)
#x DIEThis uses some macros and creates a 'process' (handled by mproc.asm) which is basically how the T-Unit handles multitasking. The games run as a sort of multitasking OS.
This code runs in a loop, can sleep, linger, awaken, get killed, die by itself when done etc.
So here's the deal. If A8 is not '-2' we do nasty stuff. Randomly between 5-9 minutes. A match is 1m30s. So around 3rd quarter, stuff starts to break. And getting into the next quarter does some auto fixing of registers, so it looks less broken, but still breaks. With some luck we have 9 minutes, and nothing breaks. Arghh. Evil.
Anyway to patch this:
- seccal1 is still the same
- security_chk is just doing CLR A0; RETS now. No calculations w/ hidden ram. Probably faster.
- security_trashstuff just does a DIE now. It still gets created as a process and ends up in the list for a few ms but then just dies.
With this patched into TE 2.1 the game runs on my standard NBA Jam board fine. (Also tested TE 2.1 Rewind roms.)
This was all very top secret. The MK2 code that was leaked did _not_ contain these routines, but they were still referenced and preventing the game to compile when i started working on it.
I guess when they gave this code to the psx developers it was sanitized.
Also in MK1 5.0 for t-unit, there is similar code, but i could not find any cksum on it yet. I also have that patched, but maybe i'll create a different topic for it some day. (It is quite simple.)
Anyway, yes, this means we can have a multi T-Unit.
MK1, Nba Jam, Nba Jam TE, NBA Jam TE Rewind. (I don't care about TROG!)
And MK2 with DCS soundboard.. or maybe aftermarket sound board? or an FPGA alternative sound board.)
Probably the Dredd proto if i find free time to look at it. I don't know how @Hammy patched it yet.
An educated hacker could now go and make some roms with the pointers above, and probably something will end up on Ebay. Should i set up a paypal donate button? Mweh. I didn't think this through when i started this for knowledge and fun. I don't even have enough eproms and t-unit boards to work with lol. I hope it at least makes for a nice read.
Edit: I Released this patched version: Use v1.2 which is here:
https://www.dropbox.com/scl/fi/8aji...v1.2.zip?rlkey=y6yurn7epa4pl90zwt8s9wl1x&dl=0
(updated link)
Last edited:
