Ripping problems

VNC is back online after MUCH fucking about due to multiboot problems and a full format - though it is on ASSEMbler's main (again) so frequent access may be limited for the time being due to him needing to make use of it and the fact it draws near a gigawatt of power which isn't cheap!

Not to worry though I m attaching some files for your perusal - it is possible with these extents the VNC may be redundant as some speculation can go out of the window and the community has everything it needs.

Attached is an IsoBuster extraction from track 3 of LBA 45016 - 45020 which covers much of the CD001 info to remove some doubts.

FYI 1ST_READ.BIN starts at LBA 547,342 referenced as 08 5A 0E but it is also mirrored/encrypted as 0E 5A 08 - this can be observed in LBA 45020 as 0E 5A 08 00 00 08 5A 0E.

 

Given the two references in the toc you're talking about is of the form AABBCC and CCBBAA, I'd guess there's two endianess TOC, one in big endian (used by dreamcast) and one in little endian used by most OS. Look up endianess on wiki.

 

I am already familair with the concept on endianness, just not the practical use Arf 4 hours sleep FTL. I wanted to stay up to get enough done to get that out there though.

 

Are you guys having any problems with VNC? I was trying to use a selection of VNC-based systems a few weeks ago, and what with slowdown and broken colours, I ended up switching to LogMeIn Free.

 

@FG
I am not sure how VNC works here. If I can only access the files from the server, then I will need tools for hex editing, self-booting and a way to test the image just like a retail DC (NullDC won't do as it ignores the protection)

If VNC doesn't work out, then I will have to wait till the .nrg or better yet the .gdi is available - be it months/years later

@LeGit
The segment dump doesn't look radically different from other GDI dumps.
the TOC starts from 45018 is also common for other GDI.
The iso I created starts from 45023 might just be my iso-maker. Where do the TOC of your .nrg and .cdi start ?

-----
The fact that there is no "CD001" in 1st_read.bin just mean it does not use "common" lib that other games were using - may or may not be protection related.

I have found 45166 is first accessed via a call at 0C221A68 which is close to the 6E B0 00 00 3C 17 22 0C string
The second access together with root access is at 0C1EB3A8 which is close to the 6E B0 00 00 60 58 34 0C string.

I don't know if the first access is protection related yet. Even if it is, there are still "millions" of codes in between to decipher.

 

I personally use LogMeIn but no VNC works just fine, just the server is offline a lot. Besides, now the troublemaking files have been posted there is significantly less need to log in, only to test the hacks.

The only things I did forget to do was a 5 sector .iso of the selfboot .cdi for comparison with the original that was posted.

Also I forgot to state pretty much every executable is in encased within .miff file format with the file MIFFVIEWER.MINI at LBA 547,342 holding the keys to read them. Yup, it is just one sector before the 1ST_READ.BIN and mentioned almost nowhere! I have a feeling the LBA digits have been swopped around as a form of encryption which is a different form of the endian thing used previously.

EDIT: I need arrange to shovel some food into my brother so I had to be quick, but I have extracted LBA 45016-20 from the GDI, NRG and CDI in both 2352 and 2048 modes (a little extreme but meh you never know!) At first glance I haven't spotted anything too unusual either, which makes you wonder why it dies on the CDI TOC.

Please see attached

 

@Hykan

VNC works fine using any client (I use tightVNC). Or simply on a web browser by entering the ip floowed by :5800 (=> example : 012.345.678.910:5800). You'd would need java installed for that.

I'm pretty sure you can send ASSEMbler the files/softwares you need. My selfboot pack is already there with tools, a hex editor, deamon tool, latest nullDC and some other things.

Cheers,

FG

 

I tried ripping HDR-008 Geist Force with different Padus DiscJuggler settings to see if they had any effect on the nullDC errors. The list is not extensive as I tested other variations I neglected to add, but basically the only thing that made any difference was setting PQ to on - and correct me if I am wrong but even then it should only affect subchannel data which AFAIK the Dreamcast doesn't use.

Scan Gaps Ignore Errors PQ RAW DAE Jitter nullDC Error

0 0 0 0 Native Verify Failed : area--SingleDensity in cdi_DriveGetTocInfo -> cdi.cpp : 231
0 0 0 0 Overlap Verify Failed : area--SingleDensity in cdi_DriveGetTocInfo -> cdi.cpp : 231
0 0 0 0 Redundant Verify Failed : area--SingleDensity in cdi_DriveGetTocInfo -> cdi.cpp : 231

0 0 0 1 Native Verify Failed : area--SingleDensity in cdi_DriveGetTocInfo -> cdi.cpp : 231

0 0 1 0 Native Verify Failed : <from==2448> ¦¦ <from==2336> in ConvertSector -> common.cpp : 140

0 1 0 0 Native Verify Failed : area--SingleDensity in cdi_DriveGetTocInfo -> cdi.cpp : 231

1 0 0 0 Native Verify Failed : area--SingleDensity in cdi_DriveGetTocInfo -> cdi.cpp : 231

Given as the hexa codes keep bullshitting between different styles, on the main crash I noticed one of the possible hex values is spookily representative of the Data1.iso file size (from a certain point of view, probebly a coincidence). Removing 150 bytes as FG suggested earlier though only served to make the image file invalid, which meant Daemon tools wouldn't mount the .NRG which in turn meant there was no way in hell Padus DiscJuggler was going to .CDI it!

I suspect the usefulness of the PQ error log will be somewhat limited but I have included it regardless.

I'm hoping ASSEMbler can dump some SYSTEM-DISC 2, HKT-06 GD-R and SYSTEM-DISC 2 + HKT-06 GD-R syscalls later too - they will possibly be like looking for a needle in a haystack as there is likely to be little variation between files but I'm hoping if they do not provide greater insight into a specific problem they my provide some enlightenment of the broader picture of the disc access function.

Sadly between doing mostly labourious testing I haven't had the chance to try anything exciting today. It doesn't help that I am incredibly tired so I am working slowly. I've had to delete and merge some posts and reprimand as well as ban users too which ll takes time. I'll be away for the weekend but hopefully on my return on Sunday evening I'll be refreshed with new ideas and new suggestions and help move the project along... well that is only if you lot don't beat me too it

 

In the log somewhere, it says there's an unknown Sega Packet Interface (SPI) command: 0x71 (also called 71h for 71 in HEX)

Command 71h isn't defined in the docs I have on the SPI. Also, the ATA standard, on which SPI is based) states 71h is a "retired" command. Before it was some kind of SEEK command. It was tagged obsolete in ATA3 and retired in ATA4.

Just though it might help!

 

I tried a whole bunch of games and I can get that unknown SPI code to appear in most if not all of them whether I use GDI or CDI. I wouldn't focus on that too much. You have to pause nullDC or be quick to see it as it will keep reading excerpts and bump the log, but that particular SPI error is replicable.

In other news I tried Chankast... lol (no offense!) and Makaron... well I never did like it to be honest and it isn't helped by lack of GUI, lack of readme and lack of clear download locations but I found a nice redist with a GUI (MakaronEX 3.2). Sadly it looks like I had good reason to dislike Makaron - loading from the GDI dies sooner or later and loading the CDI it dies instantly.

There were however some interesting side affects from using Makaron - one which was annoying was that every time the game died I had to keep entering the time and date FFS, which was made worse by VNC lag. On the other hand, HDR-0008 Geist Force plays but the texture loading fails, so you get to play in wireframe mode - not that it is easy with VNC lag and a broken keyboard!

 

This message is actually quite common in NullDC but normally won't affect gameplay. It appears even before game booting.
Don't know if this is what makes the .nrg to boot in NullDC but locks the retail DC

 

did you test it on lxdream? i know that it's not the best emu, but the autor always help when something didn't work fine. He may give some good help (at least he helped me a lot of times)

 

I just had a thought - I can't believe I didn't think of this earlier.

It is a) struggling with the TOC and b) in the single density area. Why oh why did I not check LBA 00000-00023 (at least)

I feel like such an idiot now. I guess waking up with a fresh mind my help, but I wonder if it will make any difference.

Also if anyone can reccomend a good hex difference engine (as I do ll my searching manually) <3

Also no lxdream testing - I never heard of it, but no linux or OS X.

Lastly nullDC source code for .ci in conjunction wth the errors may be useful. I'm looking through it myself on and off (still quite tired) but here you go:

http://code.google.com/p/nulldc/source/browse/trunk/nulldc/plugins/ImgReader/cdi.cpp?spec=svn66&r=66

 

ultra compare profesional

 

Another problem is staring at me right in the face now which should have been obvious from the start:

Verify Failed : area--SingleDensity in cdi_DriveGetTocInfo -> cdi.cpp : 231 is line 231 of cdi.cpp aka:

return cdi_Disctype;

It also looks like the disc type is being returned as void possibly due to:

verify(area==SingleDensity);
memcpy(toc,&cdi_toc,sizeof(TocInfo));

Only IP.BIN works, which is odd in a way as it also lists the --GD toc info start-- correctly. I'm guessing for whatever reason the cdi_toc or TOC size is being advertised differently so the verification fails and the disc dies once it has cleared IP.BIN.

Related nullDC source code links:

cdi.h
common.h
gd_driver.h
ImgReader.h
pftoc.h

and

sb.cpp (less useful due to nullDC having a lot of memory address unknowns)

 

Too bad it can't be as easy as the swap discs from before selfboot games.

 

Even non selfboot games need to be hacked. The only difference is that they got to be hacked for LBA0 and require a BootDisc.

 

Just a quick aside here, can a homeburned .CDI of the System Disc 2 boot GD-R's or does it need to be an original? I was just curious in case this piece of software can't be cracked and the only chance of its limited edition release was on a GD-R disc.

 

I don't think it can. I had a go a while ago when I got a GD-R of Jet Set Radio.
Perhaps I burned it wrong or downloaded the wrong image but it didn't work for be. Got the disc playing in the end with the swap trick.

 

No it can't, sorry. It seems the SD2 magic is in the special ring it got. This ring can't be reproduced, sorry.

However, there's a swap trick that could be used to play this game fine, given there's no CDDA tracks it should works flawlessly.