Ripping problems

Try to actually burn that mds for fun sakes.

 

I think he is one of persons who really can help this situation. I know how to contact him - contact me by pm .


pm sent .

 

Tried with another drive, cd record spits out new shit haha but ultimately refuses to burn data2.iso for different reasons (see below).

ASSEMbler trundled off to dig out another SATA drive (EDIT: found it is read only) and I've just ordered another chcken vindaloo for tea (5th day in a row, training for fireproof arse haha).

Also burning a .mdf ripped from the .cdi didn't work but we sorta knew that before we tried eh

 

Try to remove the last 150 sectors (307,200 bytes) of data1.iso

 

Is that drive in DMA or PIO mode?

 

It might also be worth trying the following settings when burning with DiscJuggler:

- Load the CDI
- Click on the advanced tab, and set the following value's
Mode: Mode 2
Block: 2048
Offset: 0
TOC: CD-DA
and check Add post-gap to 3rd party images and RAW write.

Now press the Start button.

-----
Perhaps it's worth a shot. With my old burner I could burn every DC CDI file. But when I changed to a different type of burner, every DC disc I tried to burn became an toaster.... untill I used above settings.

 

You guys use Alcohol 120%?
I use it to burn all my Dreamcast collection in Nrg/Cdi format, 80/99 min CDR at 16x. No problem at all.
If a mounted image worked in NullDC, there is probably not much can be done in debugging. We just need to wait and see how it work in a real Dreamcast.

 

A lot of people hate Alcohol...I swear by it as a burner.

Worth a shot but reading this back this seems to be a huge huge problem.

It's giving me a headache just reading it. I used to be pretty hard core into Cdi burning and DC hacking but this is all beyond me. Such weird errors.

 

I don't think it's a software issue. The disc seems to burn fine, and the files are accessible. I believe it's a software check problem.

 

I am confused:

1. LeGIt prepared a .nrg and mounting that to x:\ works in NullDC
2. LeGIt and ASSEMBLER failed to burn it to CDR

This should mean the rip is successful at least with NullDC
There are cases where a rip will work in NullDC but not in a real Dreamcast. If this is the case, then it will be real hard to debug/code trace using NullDc

3. Did any one successfully burnt the .nrg and tested on a real Dreamcast?
Forget about .cdi. Burnt whatever worked in NullDC. Converting formats may introduce errors.
If you have problem burning .nrg and if you trust me, I can burn it and test it for you

4. If some one (FamilyGuy ?) have burnt the .nrg to CDR but that wont boot on a real Dreamcast then it is either burning issues or protection issues that get ignored in NullDC.

Like I mentioned above, protection issues in this case will be hard to debug using NullDC.

 

At this point it seems likely that there is copy protection deliberate or inadvertantly applied to Geist Force that Nulldc simply doesn't support due to not being a 1:1 recreation of the Dreamcast. If this is the case then the DC is rejecting the disc due to the protection kicking in where as Nulldc simply doesn't do anything with it and continues along business as usual.

That is assuming something isn't going wrong in the transition phase between iso and CD-R as well as Daemon Tools accurately presenting the image as a disc to Nulldc.

<Thanks Captain Obvious!>

You're welcome. :thumbsup:

 

1. .nrg and .cdi both work on nullDC via Daemon Tools X:\

2. We didn't fail to burn it to CD-R, infact there are many burns done in many ways just none of them boot past the licence screen hehe - the only type that wouldn't burn is using that command line program cdrecord.

3. Of course we burned the naked .nrg too but didn't expect it to work because this method rarely works. As Family Guy calls it the .nrg is barely legal - it needs mounting via Daemon Tools and ripping via Disc Juggler to make it legal - except it crashed nullDC and fails to load on a retail DC. We burned through a cakebox of different variations all tested on a retail DC no joy.

4. It is probably something as daft as a couple of bytes need changing - but when for example the IP.bin alone has 16 pages of gargage to sift through - it really is like a needle in a haystack unless you have the cipher, but it is not impossible - I cracked Phantasy Star Online hexadecimal codes back in the day with just a pen and paper and no PC etc! Though in fairness I needed basic codes to reverse engineer to begin with.

We know for a fact the .cdi dies because it struggles to read the TOC (without Daemon Tools X:\) but sadly no more experiments until the server becomes available and I'm off to bed now now anyway.

The biggest shame is people crack things then don't spread the knowledge (forget GeoHot) - If I had bothered to dump my dozens of GD-R years ago before I sold them I could have learned this all several times over =/ Hopefully the other members with GD-R will have a bash at copying theirs even if they don't release them to spread the knowledge

EDIT: Can't sleep having a nosy at reverse enginering K-Projct as it looks to be made closer to the current method.

 

Just a silly question, have you actually tried to use bootdreams? Every time i've tried to make a working disc manually with mkisofs and cdrecord it failed horribly, but bootdreams usually worked pretty well...

 

I know you guys are going for a selfboot image but would it be possible to make a none selfboot image and load it with the Ecelon (was it them who made it?) boot disc? At least that way it would be playable in a retail DC.

Yakumo

 

Utopia Boot Disc

 

The binarires of this game are not normal. Maybe because it's still in debug format. The normal LBA references found in every single dreamcast games I've ever seen are not present in this game. So, hacking it to LBA 0 or 11702 is not possible, wich makes bootdreams, utopia or any standard other non-45000 method useless. If it was as easy as some of you seems to think I'd have done it already, I'm kind of not bad at selfbooting games without never-seen-before copy protections.

FG

 

I know you quite well FG, and you know me too, no hard feelings, that's why i told it was a silly question

already tried with hack3/hack4?

 

No hard feelings at all, just wanted to make it clear that we know what we're doing. This is a weird game, but I beleive it's posible to do! Damn I should learn SH4 assembly ...

On the 2de half of your post:
hack3 only hack LBA references, wich aren't present in that game.
hack4 is hack3+2copyProtections, for hack3 see above line, the two copy protections aren't present either.

 

would be interesting to see what happens if the app detects there IS a LBA protection (when of course there's none) and try to fix it anyway. maybe the 1st_read.bin is encrypted and that's why it doesn't show ***ANY*** LBA checks (when every game, even betas have them?)

 

If it's encrypted, decryption would happen in ip.bin, this should be "easy" to crack for "Patriot".

binhack, gd_fixer, hack* and <me_through a_hex_editor> can't find LBA refenreces in this file.