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?
). 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).