Here's a list of p0stp0ned releases. These are titles which were a tad harder than usual t0 hack, but t0 be h0nest, instead of depr0gramming them myself, I will just take Echelon's binary whenever p0ssible. L00king at the list again, I can 0nly say that I still haven't tried the steal-0ther-binary-meth0d with m0st games. There is still h0pe.
1. Project Justice Rival Schools 2
There's tw0 weird files:
First, 3SYS.BIN. PSI fr0m Echelon someh0w reduced this 200MB file t0 a 2MB file. My Haxx0r skills revealed that they 0nly t00k certain parts 0f the 0riginal 3SYS.BIN. If y0u replace the binary with a 2kb dummy file (and apply the is0 header-hack) the game freezes, s0 my best guess is that it either handles the pr0tecti0n 0r is at least a substantial part 0f it. I'd prefer t0 keep it unt0uched t0 prevent game freezes and ensure stability.
This is why I'm interested in file 2: A ridicul0usly huge (and ridicul0usly weird) AFS file. Well, it's a l0t, but n0t an AFS file. N0 AFS extract0r can extract the data inside, hell, this thing even lacks an AFS header. (Searching f0r the string AFS with a HEX-edit0r results in 0 hits as well). In additi0n to that, the file's size is 450[B][U],0[/U][/B]MB. ,0? It just smells like a dummy file. Well, it's a g00d 0ne at that. When I is0-header-hacked it, the game b00ted fine, I can even play a versus match with n0 pr0blem. Everything's mell0w, I even started upl0ading it already. That's when I felt the sudden urge t0 try st0ry m0de. Just when epis0de 1 was supp0sed t0 start, the game freezes -_-
S0 apparently, this "AFS" c0ntains data related t0 the st0ry m0de. I'm still n0t perfectly c0ntent with this file, I'm pretty sure even if all the story data (Textures, text, well that's ab0ut it) it w0n't be 450MB. It w0uld take an incredible am0unt of PVRs t0 reach this value. My best guess is, that like with 3SYS.BIN, certain parts 0f the file 0nly serve for "dec0ration" and "dummyati0n" and can be rem0ved. If I was t0 reduce b0th 3SYS.BIN and the AFS in size, I c0uld n0t 0nly leave the audi0 unt0uched, I c0uld als0 increase l0ading times A L0T. Well, either way, it's p0stp0ned till I kn0w which parts were made f0r dummying.
(Maybe a g00d 0l' disassembler w0rks w0nders? ;P)
P.S.: I've kept the st0ry-less game disc and named it Project Justice: Tournament Edition. Yeah. And I've already written the nf0 :D
2. BANG! Gunship Elite
WINCEDA.
F0r th0se 0f y0u wh0 d0n't kn0w, that's the c0dew0rd f0r:
Wr0ng
Indexed
N0w0rking
CDDA
Every
DAMN
ATTEMPT!!
... In 0ther w0rds, music d0esn't play right. Acc0rding to Megalexx, the fix w0uld be different f0r each game, th0ugh I'm pers0nally n0t that sure, since fr0m what I have learned fr0m the WINCE devkit, it may either be fixed by rewriting a certain DLL in the WINCE f0lder (th0ugh n0t every game has that f0lder -_-) 0r replacing a certain functi0n which checks b0th the first sessi0n and the sec0nd session T0C, but m0re details 0n that in a later p0st.
S0me WINCEDA games D0 w0rk (e.g. Worms Armageddon), but acc0rding t0 my research that either is just luck, 0r the main executable (.exe, N0T the 0WINCEOS.BIN!!!). Either way, it wasn't p0ssible t0 fix the br0ken WINCEDA games with the w0rking 0ne, s0 it's n0t that easy.
3. Deep Fighter
Hm, that 0ne's kinda weird, it always g0es back t0 the menu when it's supp0sed t0 b00t. LBA 45000 is n0t p0ssible thanks t0 the fact that DiscJuggler cann0t handle CDDA and data in the same sessi0n. Unpr0tect m0de isn't the s0lution either. Well, using hack3 (dahack) 0n the binary (0r binaries? I can't remember if it had m0re than 0ne) wasn't en0ugh. Maybe I sh0uld try burning at LBA 45000 with0ut CDDA...
I'll be taking a l00k at the 0riginal release later 0n, maybe I can use the binary t0 find 0ut why my release didn't w0rk.
4. Ducati World
WINCEDA. You kn0w the rest.
5. Exhibition of Speed
This game b00ts fine.
CDDA n0t.
After using CDDA patcher/CDDA.exe, the 0nly thing I hear is silence. Is it the same pr0blem like with Giga Wing? Maybe I sh0uld fire up my Hex editor and give it a g00d l00k myself... And if all fails, I bet there's still a w0rking release t0 get... inspirati0n
6. The King of Fighters '99: Evolution
After displaying the licence screen, the c0ns0le resets.
LBA 45000 fails.
Unpr0tect m0de [CD E4 blablabla] is n0t present.
I've seen this kind 0f pr0tecti0n bef0re, I just can't put my finger 0n it >_<
I als0 tried c0mparing it to the 0riginal release, but s0me sect0rs are c0rrupted s0 I can neither extract their 1ST_READ.BIN n0r 0pen it in a Hex Edit0r.
This 0ne might be p0stp0ned f0r a l0000000000000000000000000000
000000000000000000000000000
0000000000000000000000000000
00000000000000000000000000000ng time.
F0r n0w you'll have t0 play my KOF '99 Dream Match release. Just s0 y0u kn0w, that 0ne's awes0me.
This list will be updated 0n a regular basis. Unlike the Captain, I d0n't need hundres 0f entries f0r my stuff.
10/28/2010
Reintroducing the Log
Heeeeeeeeeeeeeeere's Johnny!
...I've switched from overly-awesome Space Channel 5 to equally-awesome Shadow Man references. It was time for a change.
Hey, but that's not what this log entry is about. Partially inspired by Jean-Luc Picard's Captain's Log, this piece of logging gold not only portrays the "New Adventures of Captain DC", but also features guest appearances from other members of the Dream Team. Every once in a while, the Deprogrammer and Dr.Eamcast will share their knowledge here, about Cracking and Hardware respectively.
The new and restylized log is basically a continuation of the old one (Bet you didn't see THAT one coming, eh?), but it's got a better structure and doesn't have the whole "shady" feeling the other log had. Naturally, I can't really take the shadiness out of the Deprogrammer, it's kind of his thing, y'know?
He's already been mentioned on numerous occasions, but I finally managed to recruit none other than the fabulous Doc Eamcast for the Dream Team. Sure took a while to get him convinced, more on that in a later log entry, but now the old geezer has finally joined the party.
Well, looking at the current statistic (125 log entries, only #105 written down), there's a whole lot of stuff that needs to be done. First things first, the next entries will be about introducing the Dream Team, Dr. Eamcast as well me an' the good old Deprogrammer fetching the stuff from the old log.
So, Ta-daaaaaaaa, the log is reintroduced.
...I've switched from overly-awesome Space Channel 5 to equally-awesome Shadow Man references. It was time for a change.
Hey, but that's not what this log entry is about. Partially inspired by Jean-Luc Picard's Captain's Log, this piece of logging gold not only portrays the "New Adventures of Captain DC", but also features guest appearances from other members of the Dream Team. Every once in a while, the Deprogrammer and Dr.Eamcast will share their knowledge here, about Cracking and Hardware respectively.
The new and restylized log is basically a continuation of the old one (Bet you didn't see THAT one coming, eh?), but it's got a better structure and doesn't have the whole "shady" feeling the other log had. Naturally, I can't really take the shadiness out of the Deprogrammer, it's kind of his thing, y'know?
He's already been mentioned on numerous occasions, but I finally managed to recruit none other than the fabulous Doc Eamcast for the Dream Team. Sure took a while to get him convinced, more on that in a later log entry, but now the old geezer has finally joined the party.
Well, looking at the current statistic (125 log entries, only #105 written down), there's a whole lot of stuff that needs to be done. First things first, the next entries will be about introducing the Dream Team, Dr. Eamcast as well me an' the good old Deprogrammer fetching the stuff from the old log.
So, Ta-daaaaaaaa, the log is reintroduced.
10/22/2010
Optimizing your Homebrew Release
Hey there Space Cats!
It's time for my most important guide yet, how to optimize your homebrew resulting in a perfect release, just like the Deprogrammer would make it.
NOTE: This guide is geared towards Windows. It most likely works for other OS as well, though.
First, let's make clear WHY you want to optimize your release:
You see, Dreamcast discs spin at a constant speed, ~12x on the outer part of the disc to be exact. Thus we can say it takes more space in the inside of the disc than on the outside. This is probably best explained with a diagram, behold, my MS Paint powerz:
YES, let's assume that the red and the green part cover the same area. In order to read the same amount of data, the laser has to move way less if the data is in the green area! This results in faster loading times and less noise coming from the laser. So, using common sense, you want to put data that's used often, like the main binary or streamed data on the outside, but more on that later.
In case you're thinking: "Pah!! I bet this only saves a splitsecond or two!!", think again: Some games' difference has been reported to be 10 seconds. So quit jabbin' and start reading the rest of this guide.
Like every new padawan, you'll need some tools, so get this pack. It includes everything you need for making an optimized release, from the IP.BIN to a dummy file creator. Just give it a download instead of googling for 4 hours. And while you're still downloading, let's start:
Most homebrew developers use programs like BootDreams to make their games selfbootable. The skilled ones even include a dummy file (usually called 000DUMMY.DAT, 000.000 or 0.0) Do you wanna know why they always start with 0? Because those programs use alphabetical file order.
Yes, it really is that horrible. So guess where it puts your precious 1ST_READ.BIN: Right after your dummy file, in the center of the disc. For those of you unaware of the effects, since this file is accessed pretty much ALWAYS, it increases your loading times by far. The programs also use audio/data layout, which is sooooo 2007, so this guide explains how to make a data/data image as well, also increasing loading times.
The pack should be done downloading for now, so let's get to the good stuff. It is advised that you make a folder C:\selfboot and extract the content of the archive there.
Next, put your game data (scrambled binary, just the way you'd hand your data to a program) in the folder named "data".
Now, this is where we make a split: Releases with CDDA cannot be made using data/data layout and will be dealt with later.
Dummying for Games without CDDA
Now, in order to calculate a dummy file, you can either use my other tutorial, or use the easier approach which is explained here:
Start by putting a 1MB dummy file in the folder named "dummy". You do this by using DummyFileGen.exe in the "others" folder. You can name your file whatever you want, it won't be visible in your file system later on, unless someone uses Isobuster or another advanced program.
Next you need to use a command line tool named mkisofs. For those of you unfamiliar with the command line, it's situated in the Program files subfolder accessories, right next to M$ Paint. To get to the folder with command line use
chdir C:\selfboot
Now that you're in the right folder, you can use mkisofs.exe in this way:
mkisofs -V NAME_OF_YOUR_DUMMY_SESSION -l -o dummy.iso dummy
This will create dummy.iso. Make sure NOT to close the command line yet, we need a number:
11402 sectors is the space between the two sessions, NEVER FORGET TO ADD THEM!
Now we can conclude that the second session starts at 536+11402 --> 11938
Here's what we need it for, if you use the same way to make an iso for the second session, (e.g: your data), you'll burn a coaster. Here, we also include the rockridge (-R) and Joliet (-J) filesystems. They're not necessary, but BootDreams uses them, so I've included them as well. You need to include the parameter -C in this way:
mkisofs -C 0,SECOND_SESSION_START -V GAME_TITLE_HERE -R -J -l -o data.iso data
so for our value 11938 it would be:
mkisofs -C 0,11938 -V TITLE -R -J -l -o data.iso data
and it would look like this:
456 MB, not quite what a CD-R can handle (701MB). After subtracting the 1MB our dummy file had before, we have 701 - 455 = 246MB, the size of the Dummy file we'd need! See, it's that easy to calculate a good dummy file! After replacing the old dummy file with the new one, just do everything like you did before, making the dummy.iso, calculating the second session start, etc...
In the end it should say ca.359200 extents written <701 Mb>
Some CDs have errors when you use all 360000 sectors, so always leave at least 500 sectors unused!!
Note: This is not your final data.iso, there's more steps that need to be done which will be explained after the CDDA tutorial. Feel free to delete the data.iso you now have.
Dummying Games with CDDA
When using CDDA, you always have a fixed second session start, because only the CDDA is in the first session. First, you have to burn the CDDA using a program called CDRECORD. Getting CDRECORD to run is a bitch, since you have to install an ASPI layer and other funky stuff. From my own experience, the easiest way to get a good ASPI layer going is installing a program called CDRWin: The trial version can be found here. After installing, it sets up ASPI all on its own, so there's no need to worry about anything. Haha, this is probably the hardest part of this whole tutorial.
To test if everything worked, run this command line in the selfboot folder:
cdrecord -scanbus
It'll search for CD-Recorders and stuff, everything that's connected to a scsi-bus. Search for the CD-Recorder you wanna use for burning and note the three numbers in front of it:
These three numbers will be referred to as a,b,c now.
If you get errors, your ASPI is screwed. Good luck with fixing it, there's nothing more annoying. -_-
However, if everything works fine, use this command line to burn your CDDA:
cdrecord -dev=a,b,c -multi -pad -audio track01.wav track02.wav track03.wav ... trackXY.wav -speed=x
After it's done burning, you need to find out the second session start again, this time you use cdrecord in this way:
cdrecord -dev=a,b,c -msinfo
It will output two numbers: 0 and the second session start.
You should be able to figure out the rest from now on, but let's go it through again:
First you use mkisofs on your data folder WITHOUT a dummy file:
mkisofs -C 0,SECOND_SESSION_START -V GAME_TITLE_HERE -R -J -l -o data.iso data
Yes, now you calculate your dummy file using 701MB minus the value mkisofs outputs. The only difference is that you have to put the Dummy file in your data folder this time. In case you want to be professional, you can name the Dummy file 0.0 and use one of DarkFalz' tools, the DummyHider.exe. How to use it is explained in a later step though, for now all you have to do is name your file 0.0, 'kay?
And there you go, a shiny new dummy file, state-of-the-art. Congrats, now you've mastered kindergarden, let's move on to elementary school:
FILE ORDER
This section is dedicated to DarkFalz, grandmaster of the sorttxt project.
This is the alpha and the omega. A bad file order can break a game, a good fileorder can make a game. Including file order is actually pretty simple, just add a new parameter to mkisofs:
-sort sorttxt.txt
Your sorttxt has to look like this:
data/0.0 30000
data/file3 29000
data/file2 28000
data/file1 27000
data/1ST_READ.BIN 26000
The higher the number, the farther on the inside of the disc the file is situated.
What do you say? "But Captain, I have 154453 files and can't manually write the down like that!!"
Well, do you still have the data.iso? You can extract the Alphabetical file order from there, that way you only have to change the values and don't have to jot everything down. You're gonna need isofix.exe (included) and Isobuster (Download here).
First, use isofix with this command line:
isofix data.iso SECOND_SESSION_START
for example
isofix data.iso 45000
This will create a fixed.iso you can open in Isobuster:
Now, select this:
This will create a Filelist.txt. Use TuxTheWise's listorganizer.exe (in the others folder) to output output.txt. This is not correct yet, you still need to make some changes, so open output.txt in a text editor. Use the "replace" function and replace every " <:\" with "data/" and every "\" with "/". Take care that you type " >:\" instead of ">:\", if you don't replace the space before the >, it's Game Over for you!
Now, about how you should order the files:
This is the step no program in the world can do for you, and honestly, it differs from game to game. Here are some rules of the thumb you should think about:
-The main binary should ALWAYS be the farthest file away from the center,
-Videos and music always go to the center of the disc, you just have to watch out that they stream fast enough.
-Wallpapers and bonus stuff go to the center, naturally.
-The more often a file is accessed the farther to the outside the file goes.
Your best bet is to experiment around a bit and see what happens if you change the file order. As long as you stick to the basic rules above, your loading speed should improve.
Give your sorttxt a simple name, like for example list.txt.
Now, once you're done with file ordering it's time for
THE GRAND FINAL!
Now, use mkisofs for the final time:
mkisofs -C 0,SECOND_SESSION_START -V TITLE -R -J -sort list.txt -l -o data.iso data
This will create your data.iso. Check for a final time, did you dummy it right? Any errors? If you want to make your 0.0 invisible, now is the time to use DarkFalz' DummyHider.exe from the others folder.
Once that's done and over with, it's time for the IPINS step, which uses (you guessed it) ipins.exe
Just type ipins.exe in your command line.
Your Bootsector is "IP.BIN"
Your iso is "data.iso"
This is it. Your data.iso is done. All that's left is for you to burn. When burning, it is best advised to use CD-RWs first and test it on an emulator before wasting a CD-R. Unless you're the CD-R king, if that's the case, wear yourself out.
If you have a dummy.iso, you still have to burn it. Use cdrecord like this:
cdrecord -dev=a,b,c -multi -xa1 dummy.iso -speed=x
In case you have a game with CDDA, you should have burned it already, so all that's left is the final step...
Burning your data:
cdrecord -dev=a,b,c -xa1 data.iso -speed=x
Congrats, you made it. Wait for the burning to finish and test it afterwards. If it doesn't work, make sure you have followed every step very carefully! And if you still can't figure it out, send me a message and I'll try to help you.
Good luck!!
P.S.: I'll add an appendix as time permits where I'll explain such cool things as IPBIN4WIN and the super special Fastload file order. So stay tuned!
Credits
DarkFalz, TuxTheWise and Echelon for their tools
Jörg Schilling for cdrecord
Nikko Cheng for the Dummy File Generator
It's time for my most important guide yet, how to optimize your homebrew resulting in a perfect release, just like the Deprogrammer would make it.
NOTE: This guide is geared towards Windows. It most likely works for other OS as well, though.
First, let's make clear WHY you want to optimize your release:
You see, Dreamcast discs spin at a constant speed, ~12x on the outer part of the disc to be exact. Thus we can say it takes more space in the inside of the disc than on the outside. This is probably best explained with a diagram, behold, my MS Paint powerz:
YES, let's assume that the red and the green part cover the same area. In order to read the same amount of data, the laser has to move way less if the data is in the green area! This results in faster loading times and less noise coming from the laser. So, using common sense, you want to put data that's used often, like the main binary or streamed data on the outside, but more on that later.
In case you're thinking: "Pah!! I bet this only saves a splitsecond or two!!", think again: Some games' difference has been reported to be 10 seconds. So quit jabbin' and start reading the rest of this guide.
Like every new padawan, you'll need some tools, so get this pack. It includes everything you need for making an optimized release, from the IP.BIN to a dummy file creator. Just give it a download instead of googling for 4 hours. And while you're still downloading, let's start:
Most homebrew developers use programs like BootDreams to make their games selfbootable. The skilled ones even include a dummy file (usually called 000DUMMY.DAT, 000.000 or 0.0) Do you wanna know why they always start with 0? Because those programs use alphabetical file order.
 |
| Alphabetical file order? |
Yes, it really is that horrible. So guess where it puts your precious 1ST_READ.BIN: Right after your dummy file, in the center of the disc. For those of you unaware of the effects, since this file is accessed pretty much ALWAYS, it increases your loading times by far. The programs also use audio/data layout, which is sooooo 2007, so this guide explains how to make a data/data image as well, also increasing loading times.
The pack should be done downloading for now, so let's get to the good stuff. It is advised that you make a folder C:\selfboot and extract the content of the archive there.
Next, put your game data (scrambled binary, just the way you'd hand your data to a program) in the folder named "data".
Now, this is where we make a split: Releases with CDDA cannot be made using data/data layout and will be dealt with later.
Dummying for Games without CDDA
Now, in order to calculate a dummy file, you can either use my other tutorial, or use the easier approach which is explained here:
Start by putting a 1MB dummy file in the folder named "dummy". You do this by using DummyFileGen.exe in the "others" folder. You can name your file whatever you want, it won't be visible in your file system later on, unless someone uses Isobuster or another advanced program.
Next you need to use a command line tool named mkisofs. For those of you unfamiliar with the command line, it's situated in the Program files subfolder accessories, right next to M$ Paint. To get to the folder with command line use
chdir C:\selfboot
Now that you're in the right folder, you can use mkisofs.exe in this way:
mkisofs -V NAME_OF_YOUR_DUMMY_SESSION -l -o dummy.iso dummy
This will create dummy.iso. Make sure NOT to close the command line yet, we need a number:
11402 sectors is the space between the two sessions, NEVER FORGET TO ADD THEM!
Now we can conclude that the second session starts at 536+11402 --> 11938
Here's what we need it for, if you use the same way to make an iso for the second session, (e.g: your data), you'll burn a coaster. Here, we also include the rockridge (-R) and Joliet (-J) filesystems. They're not necessary, but BootDreams uses them, so I've included them as well. You need to include the parameter -C in this way:
mkisofs -C 0,SECOND_SESSION_START -V GAME_TITLE_HERE -R -J -l -o data.iso data
so for our value 11938 it would be:
mkisofs -C 0,11938 -V TITLE -R -J -l -o data.iso data
and it would look like this:
456 MB, not quite what a CD-R can handle (701MB). After subtracting the 1MB our dummy file had before, we have 701 - 455 = 246MB, the size of the Dummy file we'd need! See, it's that easy to calculate a good dummy file! After replacing the old dummy file with the new one, just do everything like you did before, making the dummy.iso, calculating the second session start, etc...
In the end it should say ca.359200 extents written <701 Mb>
Some CDs have errors when you use all 360000 sectors, so always leave at least 500 sectors unused!!
Note: This is not your final data.iso, there's more steps that need to be done which will be explained after the CDDA tutorial. Feel free to delete the data.iso you now have.
Dummying Games with CDDA
When using CDDA, you always have a fixed second session start, because only the CDDA is in the first session. First, you have to burn the CDDA using a program called CDRECORD. Getting CDRECORD to run is a bitch, since you have to install an ASPI layer and other funky stuff. From my own experience, the easiest way to get a good ASPI layer going is installing a program called CDRWin: The trial version can be found here. After installing, it sets up ASPI all on its own, so there's no need to worry about anything. Haha, this is probably the hardest part of this whole tutorial.
To test if everything worked, run this command line in the selfboot folder:
cdrecord -scanbus
It'll search for CD-Recorders and stuff, everything that's connected to a scsi-bus. Search for the CD-Recorder you wanna use for burning and note the three numbers in front of it:
 |
| My three numbers are 1,0,0 |
These three numbers will be referred to as a,b,c now.
If you get errors, your ASPI is screwed. Good luck with fixing it, there's nothing more annoying. -_-
However, if everything works fine, use this command line to burn your CDDA:
cdrecord -dev=a,b,c -multi -pad -audio track01.wav track02.wav track03.wav ... trackXY.wav -speed=x
After it's done burning, you need to find out the second session start again, this time you use cdrecord in this way:
cdrecord -dev=a,b,c -msinfo
It will output two numbers: 0 and the second session start.
You should be able to figure out the rest from now on, but let's go it through again:
First you use mkisofs on your data folder WITHOUT a dummy file:
mkisofs -C 0,SECOND_SESSION_START -V GAME_TITLE_HERE -R -J -l -o data.iso data
Yes, now you calculate your dummy file using 701MB minus the value mkisofs outputs. The only difference is that you have to put the Dummy file in your data folder this time. In case you want to be professional, you can name the Dummy file 0.0 and use one of DarkFalz' tools, the DummyHider.exe. How to use it is explained in a later step though, for now all you have to do is name your file 0.0, 'kay?
And there you go, a shiny new dummy file, state-of-the-art. Congrats, now you've mastered kindergarden, let's move on to elementary school:
FILE ORDER
This section is dedicated to DarkFalz, grandmaster of the sorttxt project.
This is the alpha and the omega. A bad file order can break a game, a good fileorder can make a game. Including file order is actually pretty simple, just add a new parameter to mkisofs:
-sort sorttxt.txt
Your sorttxt has to look like this:
data/0.0 30000
data/file3 29000
data/file2 28000
data/file1 27000
data/1ST_READ.BIN 26000
The higher the number, the farther on the inside of the disc the file is situated.
What do you say? "But Captain, I have 154453 files and can't manually write the down like that!!"
Well, do you still have the data.iso? You can extract the Alphabetical file order from there, that way you only have to change the values and don't have to jot everything down. You're gonna need isofix.exe (included) and Isobuster (Download here).
First, use isofix with this command line:
isofix data.iso SECOND_SESSION_START
for example
isofix data.iso 45000
This will create a fixed.iso you can open in Isobuster:
Now, select this:
 |
| Right-click on the iso name. Just in case you wondered. |
This will create a Filelist.txt. Use TuxTheWise's listorganizer.exe (in the others folder) to output output.txt. This is not correct yet, you still need to make some changes, so open output.txt in a text editor. Use the "replace" function and replace every " <:\" with "data/" and every "\" with "/". Take care that you type " >:\" instead of ">:\", if you don't replace the space before the >, it's Game Over for you!
Now, about how you should order the files:
This is the step no program in the world can do for you, and honestly, it differs from game to game. Here are some rules of the thumb you should think about:
-The main binary should ALWAYS be the farthest file away from the center,
-Videos and music always go to the center of the disc, you just have to watch out that they stream fast enough.
-Wallpapers and bonus stuff go to the center, naturally.
-The more often a file is accessed the farther to the outside the file goes.
Your best bet is to experiment around a bit and see what happens if you change the file order. As long as you stick to the basic rules above, your loading speed should improve.
Give your sorttxt a simple name, like for example list.txt.
Now, once you're done with file ordering it's time for
THE GRAND FINAL!
Now, use mkisofs for the final time:
mkisofs -C 0,SECOND_SESSION_START -V TITLE -R -J -sort list.txt -l -o data.iso data
This will create your data.iso. Check for a final time, did you dummy it right? Any errors? If you want to make your 0.0 invisible, now is the time to use DarkFalz' DummyHider.exe from the others folder.
Once that's done and over with, it's time for the IPINS step, which uses (you guessed it) ipins.exe
Just type ipins.exe in your command line.
Your Bootsector is "IP.BIN"
Your iso is "data.iso"
This is it. Your data.iso is done. All that's left is for you to burn. When burning, it is best advised to use CD-RWs first and test it on an emulator before wasting a CD-R. Unless you're the CD-R king, if that's the case, wear yourself out.
If you have a dummy.iso, you still have to burn it. Use cdrecord like this:
cdrecord -dev=a,b,c -multi -xa1 dummy.iso -speed=x
In case you have a game with CDDA, you should have burned it already, so all that's left is the final step...
Burning your data:
cdrecord -dev=a,b,c -xa1 data.iso -speed=x
Congrats, you made it. Wait for the burning to finish and test it afterwards. If it doesn't work, make sure you have followed every step very carefully! And if you still can't figure it out, send me a message and I'll try to help you.
Good luck!!
P.S.: I'll add an appendix as time permits where I'll explain such cool things as IPBIN4WIN and the super special Fastload file order. So stay tuned!
Credits
DarkFalz, TuxTheWise and Echelon for their tools
Jörg Schilling for cdrecord
Nikko Cheng for the Dummy File Generator
Abonnieren
Posts (Atom)