Would love help with SH4 Assembly - GD-ROM Soft-Reset Trick (ECHELON)

Hello!
I have been wondering what the actual assembly is for doing the reset trick that is patched into ip.bin by binhack and friends.

The most i could find was a nicely detailed listing of the in-place binary unscrambling routine but it doesnt talk about the rest of the code inserted.

im going to start disassembling the inserted code, but some pointers for what part im looking for would be great!

 

@yzb37859365, @megavolt85, @MetalliC, @SWAT.

 

upload

 

heres the two things. i can also add some of my own disassemblies as well, but they have no comments but are easy enough to follow

 

@Mrneo240 this is work code for scramble/descramble
i'm don't understend what need find

 

The scramble.c is just the original code Marcus comstadt wrote, the disassembly is of the same functionality present within a binhacked IP.bin, aka what ECHELON wrote to enable self booting from CD-Rs. Everything posted currently just deals with unscrambling the binary once scatter loaded.

I posted it to show where NOT to look for the gd-rom reset instructions. Sorry if it's confusing.

The bios once loading a MIL-CD locks and disables the drive after loading a binary. I'm just looking for what needs to be done to reset and unlock the gd-rom drive so games can be loaded.

This functionality may also be present in kalistios but I'm not certain, I'm only familiar to commercial binaries and 1st party compilation environments, I don't know anything about homebrew.

 

He wants to understand the remaining of what echelon added to the ip.bin, in particular the GD-ROM soft reset part.

 

Code:

mov.l .bios_last_byte, r0
mov.b @r0,r0

    .align        2
.bios_last_byte:
    .long        0xA01FFFFF

 

unlock of G1 bus access can be done in 2 ways -
1st like (used in original Mil-CDs and Bleem!):

Code:

 MOV.L     #h'A0001000, R1
 MOV.L     #h'00000CC0, R3
.l0:
 MOV.L     @R1+, R0
 DT        R3
 BF      .l0

2nd like (used in most of pirated and homebrew games):

Code:

 MOV.L     #h'A05F74E4, R1
 MOV.L     #h'001FFFFF, R0
 MOV.L    R0, @R1

 MOV.L     #h'A0000000, R1
 MOV.L     #h'00080000, R3
.l0:
 MOV.L     @R1+, R0
 DT        R3
 BF     .l0

PS: and by the way, it is not "soft reset" and not a trick. this feature was designed by DC creators and used in official Mil-CDs.

 

3 ways need read 0 from bios after 0xA00042FE
last byte in bios always 0

 

Thank you everyone! I really really appreciate, I've been working toying more with IP.bin and I didn't like the requirement of having to use binhack when I figured it could be done by hand.

 

nice trick I was more about 2 ways was used on practice in software so far.

 

Thanks! By reading those and doing more research I got my initial project working!!!

So far it's not too impressive but I'm going to grow it more tonight because I'm so excited that it's working!

At the moment I can add intros/cracktros to "any" (katana and homebrew tested) game without actually modifying any original bins or data. Its pointless and most people won't care but I just love little experiments like this.

Videos coming later, pictures aren't interesting

 

A nice feature would be to add AR codes for widescreen. This way no need to figure out the code in the bin if we can patch via the IP.BIN.

 

Always trying to make something practical...

Just kidding, that's actually a much better use of it lol. What about things that need a constant write? What's a way to hook back into code in memory and reliably get there and back? (Seems a general approach with specific addresses could be done for each game)

 

Some widescreen codes need to be written each frame IIRC, those are the harder ones to patch in the 1st_read.bin too. You'd need to check how the AR does it to run a code repeatedly, but it shouldn't be much harder than a static patch, you'd probably need to patch a participar routine, and this routine would be repeated.

 

there is a list of such games?

 

I don't remember one in particular, but IIRC there was a case in the widescreen thread of a value that was written over each frame and made it complicated to patch in the bootbin.

 

IT WORKS! Now the next big big hurdle is getting sound working, anyone know how to have the spu play an s3m? Libs3m and the libdream examples aren't working for me and it's probably a bigger issue in my framework.

 

Yep videos showing my progress on this project:


And on real hardwire (dreamshell not required but I didn't want to burn a disc)