V-Rally 2 - Expert Edition v0.002 (PAL) CDDA Problems

This forum is for discussing Dumpcast or the TOSEC project itself. Post suggestions or ask questions about the project or the website here.

Moderator: Moderators

Xiaopang
Posts: 17
Joined: Tue Jul 24, 2007 4:50 am

Post by Xiaopang » Wed Jul 25, 2007 4:31 pm

ok, lets finish this discussion once and for all...
Majinseed wrote: i wouldn't jump to conclusions too fast...
first thing: if you found an all in one tool for ripping a DC backup then plz tell me where ;)
in fact, those guys here did a lot of stuff. another fact is that NOT only echelon had/have the knowledge to rip/selfboot CDDA games (in all different favors - WINCE or not).
megagames is full of it...cdda.exe, dahack, hack0, hack1, hack2, hack3, hack4...there are other programs out there that hack the 1032 protection scheme for you etc... look at the tools section of this site and you can grab hack4. for everything else use google...there are tons of programs out there to hack dc-games for you. whether you need what they have to offer is another question.


Majinseed wrote:what darcagn wanted to say (at least i think so) is that nullDC just "sees" that the game you feed to it is CDDA and then jumps to LBA 0 (or 150, which on an GD as 45150 would be IP.BIN start), which is the default procedure for ripped DC games. no mystic AI there, just "routine".
i know what he wanted to say and i clearly stated that this is not the case. i changed the according code to kill that specific behavior of nulldc. is that so hard to get?


Majinseed wrote: furthermore, nothing is "skipped" or whatever you want to call it by echelon or someone else.
i know the details on ripping...can we just get to the point now? ok...
i was talking about darcagns understanding of hacking and how it influences nulldc...i never said that binhacking is skipping code. thats what you imply. i analyzed a buttload of scene rips so i have seen plenty of hacks. the cdda hack to skip the cdda code would be one example where code is skipped...there are others, like echelons hacked vanishing point bin, that skipped some heavy portions of code right in the beginning of the game...i won't go into details, because i'm tired of this...

Majinseed wrote: on CDDA games of course also CDDA LBA, and (in some cases?) also some kind of "CDDA protection".
on SOME games there IS a copy protection of different kinds (like sonic adventure 2), but thats NOT for all games.
don't know why you start with copy protections because this was not the topic. some people say that this game has cdda copy protection. may be thats what you wanted to tell me. anyway, the protection is not the problem, since i've already managed to boot the game.


Majinseed wrote:did you get V-Rally to work on real hardware? - don't jump into my face now, just lets make sure that its not a problem with the basics ;)
it's a valid question and the answer is no. i won't waste one of my rare 99min cd-rs just to see that the game doesn't behave like it is supposed to be. i'm far beyond the basics. i can pretty much judge when my rips are ready for burning. i got the same responses when i was asking for information regarding vanishing point. answers like those were all i got. i still went my own way...it needed its time, but in the end everything worked out just as i expected it to be. sometimes you have to give it a try, sometimes you have to work a little harder to make things work correctly. this case is the latter.


Majinseed wrote: edit---> oh, and just to have this being said:
the GDI's are totally correct, just open them in any texteditor and take a look yourself, nothing points to LBA0.
LOOOL thats not how it works, but thanks for the support :lol:
User avatar
darcagn
Site Founder & Admin
Site Founder & Admin
Posts: 332
Joined: Fri Apr 06, 2007 11:12 am

Post by darcagn » Wed Jul 25, 2007 5:56 pm

Xiaopang wrote:
darcagn wrote: I never said nullDC expects that everything is hacked. Perhaps I was misleading in my previous post. nullDC's CDDA implmentation is bugged where it assumes that every disc it is given behaves like a cracked backup disc.
Yeah the audio code is buggy, but it is perfectly usable to tell whether or not a CDDA-rip will work on a real DC. So far my experience proves me right. I worked two months on Vanishing Point, which showed a similar behavior like V-Rally 2, but I managed to fix that eventually. I also first assumed that nullDc was too buggy and that my disc would work in a real DC, but my logic and Echelon proved me wrong and after perfecting my rip I know that the mentioned V-Rally 2-issue is not related to nullDc but to the V-Rally 2 code itself.
nullDC uses different code for its GD-ROM implementation than it does for its Mil-CD implementation. It appears that the Mil-CD implementation works properly.
Xiaopang wrote:The Echelon intros are not hacks, but hacked in programs. I wasn't clear enough there. Or to be more exact, they are inserted prior to the game code.
Where the code is placed and calling them "hacks" is completely irrelevant to whether or not nullDC will properly emulate them. nullDC simply doesn't properly support the functions the code uses, so they don't work properly, regardless of their status as "hacks."
Xiaopang wrote:And still I ask you how a nullDC-version which wouldn't expect cracked content would behave? The only thing I can think of that is backup-specific about nulldc is, that it accepts mil-discs, but so does the DC. In fact those "cracked" backups don't behave much different from unaltered originals, except for the skipped copy-protection routines. A good backup is as compatible as an original and thus behaves as such, regardless if it's "cracked" or not.
It would properly find the location of the tracks.
Xiaopang wrote:nullDCs attempts to accurately emulate the hardware.
It attempts to, but does not. It is a very early version so it is quite incomplete and it uses many shortcuts.
Xiaopang wrote:Next thing is that Microsofts attempt is a violation of standards, but the hacks in DC-games are not, otherwise the DC couldn't interprete them. The code is executed in a very limited system. You can't just force new standards on it. You have to bow to the system's standards. That's how it works for consoles.
You quite clearly are still misinterpreting what I am trying to say.

First, I never claimed that the hacks within a game are a violation of standards, because they're not, they're simply a disabled or modified function, which is perfectly legitimate code. What I am claiming is that nullDC is a violation of standards, because it doesn't do what it's supposed to do.

Look up the theory of "High Level Emulation," in which emulator authors may choose not to perfectly emulate a platform, but instead provide high level functions on the new platform comparable to the ones on the old platform.
Xiaopang wrote:The next error is that you treat so called "hacks" and "cracks" as if they would put an extra problem on the emulator, for which the coder needs to implement a solution right from the beginning for the game to work. And this isn't the case. You speak of effects and that shows me that you never hacked a DC-game, except may be by using a program that does it for you. These so called effects are nothing more but little jumps most of the time to bypass code. There's nothing for the coder to consider here. In fact, you'll even find bypassed code in many original games (Hot Coffee Mod anyone? :P). That doesn't have any effect on the emu, its performance or its stability. There are only very few examples where real cracking on DC-games was done, e.g. implementing loaders and decompressors, but since these also comply to the DC's standards they have good chances of working with the emu.
I never claimed that the emulator would require special support for cracked content. I resent the fact that you are trying to say that I have no experience in dealing with the Dreamcast. I have been working with this system for many years. I understand quite well that a crack is an absent function, not an additional function.


Xiaopang wrote:The audio in the gdi also starts at LBA 0 and that is clearly wrong. As you mentioned, the audio tracks are placed much more in the middle of the disc. So, the original rip makes nullDC believe that the audio tracks are at LBA 0, while on a real DC it would jump to LBA *insert really high number here* (=irhnh).

After I ripped this game, it still behaved the same way, sending nullDC to LBA 0. The conclusion is that if I burn that now, the DC will go to LBA irhnh and will start playing back the totally wrong audio track or even the data track.
The audio in the GDI does not start at LBA 0. Observe the GDI's contents:

[track number] [starting lba] [track type] [sector count] [filename] [offset]

Code: Select all

10
1 0 4 2352 track01.bin -8
2 450 0 2352 track02.raw 0
3 45000 4 2352 track03.bin -8
4 144635 0 2352 track04.raw 0
5 151632 0 2352 track05.raw 0
6 169946 0 2352 track06.raw 0
7 184495 0 2352 track07.raw 0
8 200208 0 2352 track08.raw 0
9 220655 0 2352 track09.raw 0
10 236348 4 2352 track10.bin -8
It quite clearly states that the data track belongs at the beginning of the disc, and that the GDDA starts at LBA 144635.
Xiaopang wrote:
darcagn wrote: This means that a CD-R backup has CDDA starting at LBA 0.
Wrong. Did you ever see a game which looked at LBA 0 for an audio track? I haven't and that has a reason. All CDDA-games start looking at LBA 150 for the audio data. If you send them to LBA 0, you'll hear terrible noise for the first two seconds because of the pregap data....I know because I tried it...
Are you trying to catch me being incorrect on any teensy-weensy little thing? Pregaps are irrelevant, the CD-R backup still has CDDA starting at LBA 0. Pregaps are still CDDA data.
Xiaopang wrote:Who says that? Who backs you up on this? Why I'm asking? Because as I already said for the umptenth time: I managed to alter Vanishing Point's CDDA-code before. It behaved the exact same way like V-Rally did. I changed it and nullDC picked the tracks up at their right locations.
But once you alter the game, you're using the emulator's Mil-CD code, which is correct.
Xiaopang wrote:nullDC doesn't have a built scanner that detects what treatment a game needs. The game code handles. If it had that kind of artificial intelligence then why does it jump at LBA 0 (which is also the wrong one, as you know by now) but doesn't start playing?? If nullDC were that smart then it would treat my rip and echelons both the same, but it doesn't.
I never stated that nullDC has intelligent CDDA-finding code, in fact it's quite the opposite as I claimed that it always started at LBA 0 and never changes this behavior for GDIs.

And if you think LBA 0 is the "wrong one," then you're suggesting that nullDC has an intelligent CDDA playback overrider, because if the emulator is reporting that the game's CDDA starts at 0, then shouldn't the emulator start playback at 150 if the game decides to skip 2 seconds in?

Now, I know what you're thinking--"well, if GDI code is handled separately, then why would they assume that the GDI would be cracked?" and this is where I am indeed incorrect. See the next answer for details.
Xiaopang wrote:nullDc doesn't just jump because it assumes that all CDDA-games start there. It has to do what the game code tells it!
There are SDKs and developer tools and extra hardware chips for a reason--every developer, for example, should not be expected to write their own Sofdec decoder to playback a movie for their game. This sort of functionality is provided by standard libraries and hardware chips. Not all of the running code is on the game disc. Some of it is in the hardware and in the emulator.

The bad function in question is SPI_GETTOC, the function by which the game grabs the disc's TOC in order to find the LBA the CDDA tracks are at in order to determine which sectors need to be played back. Just to give you a little insight on how poorly this function is implemented, here's the source for it:

Code: Select all

void iso_DriveGetTocInfo(TocInfo* toc,DiskArea area)
{
printf("GDROM toc\n");
memset(toc,0,sizeof(TocInfo));
}
The emulator reports back to the game that the disc size is 0 and that all tracks start at 0. Therefore the game starts playing CDDA at LBA 0 (which proves that the game does not skip 150 sectors to play CDDA, because otherwise it would start playing at 150).

Anyway, I spoke to Raziel, and this has just been fixed in nullDC, and CDDA now plays back properly, and games that have copy protections based on the disc's TOC now work properly (this includes Rez and Ikaruga).
Majinseed
Posts: 17
Joined: Wed Apr 11, 2007 4:01 pm

Post by Majinseed » Thu Jul 26, 2007 10:24 am

Xiaopang wrote: megagames is full of it...cdda.exe, dahack, hack0, hack1, hack2, hack3, hack4...there are other programs out there that hack the 1032 protection scheme for you etc... look at the tools section of this site and you can grab hack4. for everything else use google...there are tons of programs out there to hack dc-games for you. whether you need what they have to offer is another question.
none of those is a aio, you still have to apply a combination for your very game, you still have to do convertion etc. so now easy "let a app work for you, as you implied.

i know what he wanted to say and i clearly stated that this is not the case. i changed the according code to kill that specific behavior of nulldc. is that so hard to get?
since at least I (and i think darcagn might too) didn't see/understand you clearly stating that you don't seem to be clearly enough...



i know the details on ripping...can we just get to the point now? ok...
i was talking about darcagns understanding of hacking and how it influences nulldc...i never said that binhacking is skipping code. thats what you imply. i analyzed a buttload of scene rips so i have seen plenty of hacks. the cdda hack to skip the cdda code would be one example where code is skipped...there are others, like echelons hacked vanishing point bin, that skipped some heavy portions of code right in the beginning of the game...i won't go into details, because i'm tired of this...
hmm... oO...
you're contradicting yourself, didn't you mention that while writing?
Majinseed wrote: edit---> oh, and just to have this being said:
the GDI's are totally correct, just open them in any texteditor and take a look yourself, nothing points to LBA0.
LOOOL thats not how it works, but thanks for the support :lol:[/quote]

thats JUST the way it works. this IS the original layout, so this also IS the information given to nullDC by the dump - if you want to say it like that...

how else should it work? everything pointing to LBA0 is nullDCs fault, just read darcagns answer... ;)

anway, i'm out of this i think...
Post Reply