Ripping problems

Well, i have passed it to some1 that can crack sh4 shit, i wont tell more, but trush me, he can do it, he knows more about Dreamcast than anyone else.
I just wont tell more, cause i dont want that ppl asks him everyday about that. I am confident about this

 

I completely beleive you, but I sent it to the guy who cracked bleemcast ... So I bet your "contact" can't be that much better than him ... I'd be glad though ...

This is a really special piece of Dreamcast binary, I think it'd take the best sh4 hackers out there a lot of time to crack it ...

 

Cheers on releasing those files Legit. The more working on it the better. ^^

 

This just got a little weirder - the debug window at the bottom left doesn't appear when the HKT-0120 Dev.Box is in Composhit or S-Video mode (which I have been using.) I just tried loading it again in VGA mode and lo and behold the debug window at the bottom left hand corner reappeared!

As expected through the image quality is significantly improved (RBG FTW!)

EDIT: More weirdness. The debug window isn't visible on-screen in composhit/S-Video mode, but I just took a screenshot using DC Capture (\Katakan\Utl\Gfx\Capture\dccap.exe) and sure enough the debug window is there in the bottom left. Even stranger is my TV is aligned fine.

 

If I guest right on Serantes contact, he is another TOP guy, and he know SH4 asm and DC VERY VERY well. Let's see :thumbsup::thumbsup:

 

Fingers crossed that this guy can do the magic ray:

 

BTW the .gdi was already posted - there is nothing out of the oridinary, it uses 3 tracks and the +150 offset in httpd-ack too but as people want to see it again, here it is. Granted tracks 1 and 2 are a little larger than 4 seconds, but this has no bearing on the data (track 3) as it is exactly where it should be. It is strange the .gdi is destroyed when using gdi2data.bat though!

3
1 0 4 2352 track01.bin 0
2 1007 0 2352 track02.raw 0
3 45000 4 2352 track03.bin 0

Also to clarify, the binaries are clean, dumped, unhacked versions. The only hacked file is FG's IP.hak

I do wonder if this is one of the few games to use subchannel data though but I doubt it, though as an early project, you never know, but with all the other weirdness it may not matter I guess.

 

Hi Any
yes, its the one you are thinking about, he is on it ...

also, are you guys sure this 1stread.bin is good ?
its not multiple of 32

 

It's the 1ST_READ.BN that was extracted from the GD-R using FG's pack, put it that way though I thought I already made it clear but yes it is the correct, original size, even if it is a little weird (there is a LOT weird with this game!)

I did notice GD Workshop reads an extra extent though which would then make the file 3,395,584 bytes which would then be divisble by 32 but I'm unable to test this theory at the minute as I abused my 'net connection today - I figure it just reads an extra extent usually for overlap/checking though but maybe not.

EDIT: 3,393,893 divided by 2048 = 1657.17431640625, which isn't a whole number of extents. Perhaps GD Workshop rounds it up to 1658? IPMaker does have the option to set the IP.BIN floating point to round nearest or round zero but I don't know if it affects this - there is also an option for play logging too.

Would our mystery man be DJDUBZ per chance?

To confirm:

 

LeGIT, I've seen a log from GD-Workshop of Geist booting on the "bare necessity" thread you made, can we see the complete log until the dev menu is launched or isn't there more?

Also, is there anyway to hardware debug a game using the devkit? Some kind of syscall dump or something? If the bootbin ain't a multiple of 32 it might not be a bad idead to pad it out ... Unless it's crypted it shouldn't hurt.

Cheers,

FG

 

There is more - it will search through each directory one LBA at a time. The more directories are present, the more LBA it will check. If there are certain files in the sub directories, it will 'preload' them but have no initial use for them - the log I posted is accurate, or at least accurate enough for our needs at present.

EDIT: It won't work unless it loads 4 of the many fonts though and there is no reference to MIFFVIEWER.MINI loading at all - yet clearly it does as the fonts are .MIFF files! (I neglected to mention this)

One of the 'preloaded' files is the armcom.drv another is a sound file (which the menu doesn't really use, unless perhaps you enter Nimai's room, but it doesn't appear to work anyway, though perhaps because I didn't want to ninja the in-game voices) and third is a file which references these two files to preload. The other two I'm not 100% on to be honest, but their removal did not have any adverse effect.

The only way to be 100% sure there isn't more than 5 preloaded files is to ninja the whole game onto a 5.24, but I didn't fancy making a mistake with an accidental leak and being responsible for another angry mob. I did ninja pretty much everything but the level data, videos and voices though so I'm confident enough that those extra preloaded files are likely to be only ones, as even the sega and duck logos and title isn't preloaded.

I can rework it tomorrow with the extra known preloaded files for release if need be though?

As for a larger GD Workshop log, the biggest ballache is I will have to manually create and sort every single directory and file arf. It will add multiple files at a time, but only within a directory. A new directory is a whole new piece of work doh.

 

could dreamshell possibly circumvent any problems you may be having with getting the game to boot? Compile the rip so that it can be bootable through dreamshell and see if it gets any further than before?

Sorry if that is a really dumb suggestion. just figured I throw it out there.

 

One thing though: with SYSTEM-DISC 2 trick you won't have to take the lid off.

I doubt it will make much difference to be honest, though it would be nice to get a second dump to checksum with the original.

Also I think it may be worthwhile doing a third dump for subchannel data too, to be thorough. Basically no known games used it, but no known game was as weird as this one!

 

That is a really good idea actually. I was thinking of it in the back of my mind, but the idea hadn't matured enough to suggest it.

Worth a try anyway guys.

 

Whether you compile in one method or not is irrelvent as they all require the LBA reference to be hacked and this dosn't really have many. Same deal as boot disc, self boot or Dreamshell.

Also sadly I do not have an SD adapter, but more importantly now you have the files you can compile and test them in whichever way you see fit - if it gets to the debug menu at the start without daemon tools advanced emulation you sorta cracked one issue, though ultimately it is the cd version which will need to work as I doubt ASSEMbler is going to ship 100 SD adapters with the game preloaded (if the Dreamshell method works)

 

I'll see what I can do.

I can't get it to boot my iso, somebody else want to take a gander at this? I hacked it to run from Dreamshell but no joy.

My 32gb sd card however is notorious for no booting working iso's others have tested, and I have to move the iso to a PSP card and transfer that to my brothers PC which supports my sdhc card, so something might be getting corrupt on my card.

This is not the first time I have had this problem on a katana game. I can however get working homebrew iso's created 99% of the time though.

I'll message my friend Vasiliy and see if he can take a crack at it.

 

I could help you with that if you supply the link, since there is not point of making another hacked iso if one is already made.

 

The problem is that sdiso require the files to be binhacked to LBA0, and this game got no binhack-like lba references...

Still worth trying of course!

FG

 

Yeah, it gave me an error in Dreamshell just saying that it needed Boot bin.