Ripping problems

@LeGit / FG

I found a way to bypass the first 45166 access:

please hex edit 1st_read.bin offset 0x211B5A from "12 D0 0B 40" to "09 00 09 00".

recreate a selfboot image and test it on NullDC. If all when well then burnt it to CDR and test on a retail DC.

Cross your fingers and be prepared for a coaster.

 

Sadly I won't be home for another 24 hours or so so I am unable to try it yet. Perhaps FG could log in and have a bash in have meantime.

 

It's always 09 00 09 00 ... Why is it?

On TOPIC: I could VNC into the machine to try it out, but my password doesn't work anymore, maybe Kevin made it temporary. I'll let you know if it worked with he modification if I can access the VNC

FG

 

GEIST FORCE

Y U NO LIEK US?

dunno if is gonna work

http://hotfile.com/dl/115586926/09b7af0/1ST_READ.BIN.html

 

Just logged in the VNC, installed some things and tried hian's idea:

It boots in NullDC, and goes in-game (was going in-game without the hack also).
Bottomline, it hasn't changed anything in a NullDC point-of view.

Maybe ASSEMbler can try to burn it just to see.

I also noticed that the mounted files doesn't boot if advanced emulation is not checked in Daemon tools. It crashes NullDC in a few seconds (reading sector 45000 according to console) ...

@hian: I still want to know why it's always 09 00 09 00 ...

FG

 

Could this be a beakthrough?? Fingers crossed. I've been following this thread everytime someone makes a new post.

 

09 00 means NOP (no operation, do nothing)
it is used to skip a line of code and no, it is not always 09 00. It is just convenient in a lot of cases.

Keep your fingers crossed but I don't expect I am that lucky.

 

Its two NOP instructions.

-ack

 

Thank you both, it makes sense ...

FG

 

I just woke up and assume FG is sleeping - I'm still not at home so my use is limited at present but I reinstalled pretty much everything else that needed installing on the VNC box, made a .cdi of FG's premade .NRG using hian's hack but sadly it is the same old shit just a different day EDIT for FG: I mean pretty much identical problem loading the .cdi into nullDC directly.

Armed with the nullDC source code and debugger it should be possible to start getting somewhere, but alas I need to learn a few things and get my ass home first, which won't be for a fair few hours yet.

No single hack will solve this problem though IMO, it is broken in so many ways. I'm starting to see why Sega couldn't be arsed to redo the whole thing. Even the .miff files use a non-standard header and won't open in the only program that uses them - ImageMagick.

 

Please be more precise by what you mean by "same old shit". I personally beleive this will get cracked eventually, if the GD-R can boot on a retail DC using a SD2, making a CD-R boots should be possible with small, but clever, modifications.

The main difficulty here seems to be the non-standard way the binaries are made. Maybe they are this way because they are still in debug format, or maybe it simply is a game that uses its own custom libraries instead of the standard ones.

@hian: Have you checked the original ip.bin for custom bootstrap? It's possible that when we overwrite the custom bootstrap with the mil-cd exploit in the ip.bin we break something that's needed for Geist to boot well.

FG

 

Standard libraries should make system calls via a "System Call Vectors table". This game makes direct system calls to the GD System calls. It will be easy for it to determine that the media inserted is in fact milCD.
With Standard lib, the hacked IP.BIN should have tricked the system into thinking that a GD is inserted

I am still looking for a way to debug IP.BIN reasonably.

The same thing applies:
Since the rip works in NullDC, I can't use normal ways of debugging to narrow down the suspects. I have to either create tons of coasters or go through the codes line by line which is way tedious and time consuming. Helps me to understand the system more thoroughly though.

 

Could you simply build your own gdi with only the original ip.bin and original bootbin. Like to create your own three tracks and make a gdi accordingly? I think the DreamcastSDK could actually let you do that (minus the gdi creation part of course) without a devkit, not sure though. Anyway the three track can easily be made with mkisofs also.

This way you could see the boot process (until another file than those two is loaded) but in gd-rom mode rather than in mil-cd mode.

Just an idea.

FG

 

@FG

the problem is not creating the image. The problem is how to make NullDC stop precisely at the beginning of the IP.BIN

 

I had the same problem the other day hian. In debugger mode I would click start then just as I see the commands about to appear where it dies I click stop and it is too late every time. I'll have to go through the source and figure out when it calls to narrow down the search so I can merely use goto.

FYI this is as close as I got before it died but my connection is being hammered by other things atm which wont help. I'm pretty sure I stopped and started it around the 8 bit VRAM writes.

 

I guess manually presing a key before each operation like in some C++ debugger would takes ages to reach ip.bin too ...

Couldn't a dump be made and THEN analysed?

 

FYI
You must use interpreter mode (disable Dynarec) for debugging to work and you need NullDC 1.03 or above for breakpoint to work.
It is simpler to debug bootbin as there is a slight delay after it is loaded. With luck, you may be able to break into the part of IP.BIN that is a few jumps away to the beginning of bootbin (usually at 0xAC010000)

I have never seen the DevKit. If it allows assembler debugging, things might get simpler.


Analyzing a dump is possible but not much simpler than debugging.
A simple statement in C++ may worth hundreds of codes in assembler and there is no convenient things such as variables and structures in assembler.

lol, you start to get a feel of what I am doing.

 

FYI hian dynarec has been disabled for debugging anyway and it is nullDC 1.04 but it also fails to load the .cdi regardless.

My connection is pretty bad today and I've been distracted elsewhere so I haven't made much progress today - I also have a lot of preparations to do for Saturday so I'm going to be pretty busy until then but I'll mke time for an hour or so a day to test whatever FG forgot to test or to check out some things myself.

 

a few silly questions:

1. does the GDR work in a retail DC? I bet yes with swap trick/SD2
2. does the .gdi work in NullDC?
3. the hack I posted does not work on a retail DC, doesn't it? Does it failed the same way as previous CDRs?

just try to make sure my assumptions are correct.


@LeGIt
I found the way to make NullDC stop right at the beginning of the IP.BIN

Hexedit IP.BIN offset 0x3800 and change the code from "06 D0 2B 40 09 00 09 00" to "06 D0 00 00 09 00 2B 40" (this example is for the original IP.BIN)

00 00 is an illegal instruction and NullDC will stop right there
Start the debugger then press skip once (to skip the illegal code)
set a breakpoint (closest is the codes 2B 40 - JMP @R0)
go to NullDC's console and press "ENTER" to get NullDC running again and it will break at the breakpoint.
Now you can start debugging. Good luck!


In the meantime, I will start debugging the bios to learn more about how the system works - back to basics. Yes, that might take me ages but in the long run, I will be better equipped to handle difficult cases like this.

 

1. Yup it was posted in video link running on a Dreamcast with a HKT-09 SYSTEM-DISC
2. Yup the .gdi works in nullDC, though it strangely gets consumed using gdi2data.bat
3. I'm not too sure on this but one would assume it if fails as .cdi with and without dynarec it will fail on retail. I'll double check with ASSEMbler though and if not burn off another, though I have my reservations on this.

Cheers for the heads up on the debugger - I see I got a lot of fun ahead of me...