Convert GDR to milcd selboot?

I offer my help for this part. I'm pretty good at this actually.

Feel free to pm me with any questions. Or post it there for everybody to be able to learn/answer.

I suggest using my pack if there's no cdda tracks used in the game. And of course this release has to be perfect, which means sorted and dummied.

Cheers,

FG

 

What size is the raw GDI?

 

Is there anyway you could work on a 32bit OS? I have yet to modify my pack to remove old 16bit executables, it won't works on x64 for now.

What to do to fix that:
1) copy the 1st_read.bin into a folder of your choice (might be named otherwise, look up ip.bin to see)
2) put binhack32 in this folder also http://shenmuesubs.sourceforge.net/rsrc/download/addons/binhack32_1.0.0.1-Win32_Linux.zip
3) of course you'd need the ip.bin there also
4) execute binhack32.exe

5) enter the name of the boot.bin (usually 1st_read.bin)
6) enter ip.hak (name of output bootsector)
7) enter 45000 as the msinfo value

8) keep the newly hacked bootsector (ip.hak) and flag it read only.
9) put it in the root folder of the pack along with ip.bin


Now remove this part of my batch file:

It should now be ok for 64bit for this game.

You can't directly burn the NRG file you get with this method, as the file is hacked dirty. Instead, I suggest mounting it in a virtual drive with daemon tools, and then making a cdi image out of the virtual drive with Discjuggler. You can also launch the virtual drive to test the backup under NullDC to see if it boots or if the video encoding works.

Now for the video encoding: is it in SFD format? I guess so. This format is audio adx multiplexed with video mpeg1 afaik. The multiplexer is called Sega Movie Creator and you can find all you need to create high quality VBR sfd in this pack by OVERRiDE: http://www.underground-gamer.com/details.php?id=29442

As for the size of the game, it's not the NRG filesize that matter, it's the amount of sector in the image. Look at the command window just after creating the 2de session with mkisofs and it should tell you how many sectors there is in the image, under 360,000 you're ok.

To save space you can also copy some data to the folder data1. COPY it though, don't move it. This folder is made so files in it will be burnt in the 1st session but will be seamlessly linked into 2de session TOC saving about 65MB on the disc.

Feel free to ask anything else!

Cheers,

FG

edit: If you want, I can make the cdi files in both 80min and 99min and document the process, given you trust me enough to hand me the files.

 

Ha, this is funny.
I have been pulling my hair out over this shit for the last few days - it seems Win7 x64 is my main problem as a lot of the needed software just wont work with it (using TuxTheWise's tutorial adapted for CDDA) and XP mode doesn't allow burning.

One problem I had was the file order within the data track, TuxTheWise's listorganizer.exe would keep crashing with some "array index -1" error.
I couldn't find out why and the game I am currently trying to convert has some 400+ files... so I wrote a new tool for that last night, maybe someone else has use for it... it's pretty self explanatory, use with exported file list from IsoBuster (or similar):
DCFileListSort.exe on Multiupload.com

About the file hacking with binhack/cdda/hack3/hack4 etc. check out http://www.bucanero.com.ar/dreamcast/ripdb/ if you haven't already.

With cdrecord audio burning went fine but every attempt at burning the data track ended in "faio_wait_on_buffer for writer timed out" and my PC locking up... so I decided to ditch cdrecord which I just can't get to work right (even the current cdrtfe-1.3.9 version).

Now it's late and I'm pretty tired but I believe I have just figured out how to get the audio/data burning done right without cdrecord, all audio tracks and the data track seem to be where they should be according to IsoBuster, the file order is right too, so all I need to do is try the different IP.BIN files I have created until I find the one that works.

If so I'll post a detailed tutorial once I've confirmed it, I could also think of a few tools to make the whole process a lot easier.

But maybe I'm on the completely wrong track and everything just seems right... I hope not though.

EDIT: TuxTheWise has also made some tutorials on downsampling audio and video, see his other posts and his blog.

 

Well, as this game requires no CDDA tracks to be on disc (only one used for padding). It's better, compatibility-wise and space-wise, to do a 45000LBA data/data backup. Using my SB pack (found in signature) and the fix I told 2 post before, it should be a matter of minutes to get a working copy, if no downsampling is needed.

If you're messing around with selfbooting games I strongly suggest you read the batch files in my pack to check out how data/data 45000LBA works. It's pretty powerful as no binaries, except of course the ip.bin mil-cd exploit, got to be hacked at all for LBA as it uses LBA45000 (so no possibilities to "forget" an occurence of a LBA reference that'd cause a bug midway through the game) [Custom copy protection still has to be cracked though] it also save some kiB of space compared to standard cdda/data SB. Furthermore you can create .nrg file directly and test them in NullDC before converting to CDI and burning to test on the "real shit" (waste less cd-r). Hell I've actually never burnt my ShenmueII releases on a real DC myself .

FG


[EDIT]
As for your problem, usually a "standard" game get cracked this way:

1) burn audio tracks and leave disc open (-multi in cdrecord)
2) cdrecord -dev=x,x,x -msinfo => Gives the 2de session starting LBA (x,x,x is the address of burner, given by "cdrecord -scanbus")
3) binhack bin files (often 1st_read.bin, some other bins might be needed) to the LBA found in 2. As bootsector name use anything (not ip.bin) for every binaries except 1st_read.bin, this will create the bootsector, delete it. For 1st_read.bin, keep the hacked bootsector file, let's call it ip.hak.
4) Create a iso with mkisofs for the game files (parameter -g ip.hak to insert hacked bootsector)
5) Burn the resulting iso after the cdda tracks.

A common confusion with ip.bin is that binhack need to be told ip.bin when it asks for bootsector. This is false. Binhack will always take ip.bin as the input bootsector. When it asks for a bootsector, it actually mean the output one. This mean binhack won't works if there's no file called ip.bin in the current workign directory. And that you can specify any file as the bootsector, binhack will create it. I personally uses ip.hak for my hacked bootsector, this way you don't overwrite the original ip.bin in case you'd need it.

Cheers,

FG

 

I tried your pack a few time Family Guy and never got a single thing to boot

For example Zombie Revenge requires almost no modification apparently, so I do the gdi2data then selfboot and per instructions and no joy I probably missed something simple and obvious but meh!

 

As said earlier, you've got to be on 32bit for my pack to work (or do what I told Kevin to do). Also non-LBA based copy protections have to be cracked manually. And finally, the resulting NRG can't be burnt directly. I suggest mounting it in daemon tools, opening the virtual drive with nullDC to test out (to open a drive simply type X:\ instead browsing for the file) and if it works use discjuggler to make a cdi image out of the virtual drive.

You've got to start with a GDI of course, not a non-selfboot or cdi release.

Most games, like ShenmueII as an exemple can be converted into SB by simply running gdi2data.bat and then selfboot.bat. The Daemon tools trick still got to be used to get a working CDI, or to try it out in nullDC. Zombie Revenge should work exactly like this ... Can you send me the gdi for testing?

Cheers,

FG

 

I'm on Vista 32 bit and the site suggested in the pack says no non-LBA protection just hack the 1st_read.bin, which your pack does anyway?

The NRG was tried in nullDC, no joy, it was also tried virtual mounted them ripped to .cdi, still no joy

 

NullDC can't boot the resulting NRG file. Try mounting the NRG file in daemon tools (not alcohol, daemon tool only) and then open the virtual drive in nullDC. Exemple, if your virtual drive is X, enter "X:\" as the file to be opened.

This should do the trick.

FG

[EDIT]

Ok so I just tried it out and Zombie Revenge works fine. I'll try to explain what I did and you could mimic it:

1) extract the original untouched GDI with gdi2data.bat (all files in the root folder of the pack)
2) run selfboot.bat and wait until it's over (if you're on 64bits, read my posts somewhere on top of this one to see how to avoid using 16bit binhack).
3) mount the resulting selfboot.nrg in daemon tools
4) open nullDC (default settings, a clean download is the best bet) and click on file then on Normal Boot
5) there'll be a white box where you can manually input the file to open or click browse, DONT BROWSE. Simply enter the letter of the mounted drive, a colon and then a backslash. Exemple: my virtual drive is Z, so I type in Z:\

Watch it boot!

This is how I made it works. Of course the game is not dummied nor sorted this way, but it's just a matter of adding the right sorttxt.txt (retreived with isobuster) file to the root folder of the pack to automatically sort it or to add a 0.0 file with right size to dummy it.

FG

 

I can't rememebr if I had anything in data1 when I made the .NRG last night, but after mounting in Daemon tools then disabling CDDA the file finally loaded in nullDC and after reripping into Disc Juggler then burning with Alcohol 120% @ 24x the disc lives (yay) - but has a ghastly now loading Zombie Revenge bit after the Sega licence info logo thing haha. Alas it lives... now to try it again and make sure I dumped it right then to find something which is more of a mindfuck to get used to it.

EDIT: I just tried again with the NTSC-U/C version of Daytona USA 2001 (as it had online support, PAL didn't). This time after using gdi2data I used IPwriter, set it to J U E region(s) then did selfboot and and mounted in daemon tools then ripped it with disc juggler then burned it with alcohol 120% @ 24x with no problems. When I copied the contents of data into data1 then tried it, I got a slightly smaller .NRG but it only produces coasters. In selfboot.bat I read to put the data stuff stuff into data1 but the readme says put 65mb in on some occasions - may want to amend that, or perhaps I'm just a tard and reading it wrong?

 

Good news!

Auto.Binhack.exe (and binhack32 for that matters, not binhack however) already makes the ip.bin region free and enables the VGA flag, so there's no reason to run IPwriter on the ip.hak.

The data1 folder can only contain 69,120,000 Bytes (~65,92 MiB) of writeable data. This is actually the first session of the disc. The second session MUST starts at 45000LBA (for the sake of the technique) the resulting iso of the data1 folder should not be over 33750 sectors.
In order for the 1st session not to be a complete waste of space, you can copy some files to data1 folder and this data will be stored there (LBA<45000). But if a file is in both data and data1 folder, when building the 2de session filesystem (LBA>45000), mkisofs will not store the duplicated file in the 2de session, it'll only reference it as being in the 1st session (saving space). Just a if you got a book with it's Table of Content at page 4 referencing the title page at page 1.

Short story: You can only put 33750 sectors of data in the data1 folder, which is approx 65MiB of data as seen by Windows. However if there's duplicated files or files that are not integer multiples of 2048 bytes in size, this value might vary. It's an indication only.

This folder should not be used if everything already fits in the second session. As an example, for ShenmueII it's a real savior space-wise, but for Zombie Apocalypse it's useless.

Cheers, feel free to ask any other questions.

FG

 

hehe your readme could do with mentioning the selfboot auto JUE region and VGA flagging

I had a stab at Maximum Pool - it boots fine but only the raw .BIN emulates - the .cdi kills nullDC once it gets under way. On disc it goes a little crazy at the start but gets over it. I had a bash with Bomberman Online but not much luck thus far - DiscJuggler was refusing to read it so I had to overburn. I may give Data1 a play with next and see what happens.

 

Well for the gd-rom drive not to look around like crazy, you've got to optimised the file sorting. Or at least retrieve it from the original disc. You should also dummy it!

FG

 

aha I figured the selfboot would do all that!

I tried padding and merging and all that crap for the audio tracks, seemed like a lot of work but I think cue sheets may save my bacon I'll try more than 3 tracks tomorrow as it is getting late now.

I got daytona usa track03.bin loaded into the virtual drive via cue sheet and I can see it in isobuster, but now where does one make your sorttxt.txt?

EDIT: listed LBA relative path into filelist.txt and dropped it onto makesort and got a slightly different order to what you spat out but meh for the most part it is similar.

Seems like an awful lot of fucking about!

 

For some games, the sorttxt.txt is the same as alphabetic order, except for 1st_read.bin which is always the last file on the disc. This is developper lazyness to optimise loading time.

Be sure the sort file has the data folder on the begining of each lines and that it gots a 0.0 file appended to it.

If it's named sorttxt.txt it'll be used by my pack, same goes for 0.0 which will be hidden from TOC but will be used as a dummy, pushing all other files to the end of the disc.

My pack is useless if you want to keep CDDA tracks. You'd ahve to do it manually. If you start working on such games and get confused, drop me a line or two.

FG

 

@Assembler

You might want to take a look at this tutorial, I never tried it myself, but I'm pretty sure that this is the right way to make a perfect DC backup:

http://snesorama.us/board/showpost.php?p=346896&postcount=1

Maybe t hese other 2 tuts will come in handy too:

http://snesorama.us/board/showpost.php?p=350901&postcount=1

and

http://snesorama.us/board/showpost.php?p=342060&postcount=1

Regards,
iCEQB