Driver with Bleem! ?
 

Hi,
I don't know if this is a taboo topic or not... if so, just let me know and I'll drop it.

I've been making some selfbooting PSX games for my Dreamcast using the PSX game as the 1st session and the Bleem.bin as the second. I have "heard" that Driver works with the Bleem! beta, so I made a disc of this. It loads up till the memory card check screen and goes no further. Has anyone been able to use Driver with Bleem!? If so, how?

Thanks,
-Ex

I'm not completely certain but it seems certain versions of some games do not work. For example, some people say that their Castlevania symphony of the night does not work, some people say that it does work (it works for me).

It could be that there are different revisions of the same game (In your case Driver) and that's why people are claiming that the same game works/doesn't work. I have Driver, but I haven't tried it with the bleem beta. I'll try it when I get home and let you know.

Also sometimes you will need to skip certain screens. For example, if you try playing Strider 2 and let the game run by itself, it will hang before it gets to the title screen. If you rapidly press start to skip that screen, the game wil work.


BTW, did you make your disc using Clone CD or another program?

Thanks for the response.

I extracted the files with isobuster and made an iso (lba=0) keeping the original file order with a sort.txt.

mkisofs -C 0,0 -V "DRIVER" -sort driver.txt -l -o driver.iso driver

I burned that iso as the 1st session with cdrecord like this:

cdrecord dev=x,x,x speed=4 -multi -xa1 driver.iso

cdrecord dev=x,x,x -msinfo

Then I made an iso of the bleem.bin using that lba, inserted the IP.BIN and burned it with:

cdrecord dev=x,x,x speed=4 -xa1 bleem.iso

That's it... A selfbooting PSX game for ur DC. :)
Also, you can use this same disc to boot any other PSX game by doing a soft reset without the disc in the DC. It will flash the bleem! screen and u pop in any other PSX game.

Thanks for checking on that. So far I've tried using my brother's disc of Driver and my own disc... same thing with each. Never checked for a version tho.


Later,
-Ex

Thanks for the info. BTW, I couldn't get Driver to work either. sorry.

HHHHEEEEEYYYYY !!!!
What ???
What a driver ???
Bleem.bin ?? or ...?

Man really crazy :-) .

Does it really go this way?

quote:

Thanks for the response.

I extracted the files with isobuster and made an iso (lba=0) keeping the original file order with a sort.txt.

mkisofs -C 0,0 -V "DRIVER" -sort driver.txt -l -o driver.iso driver

I burned that iso as the 1st session with cdrecord like this:

cdrecord dev=x,x,x speed=4 -multi -xa1 driver.iso

cdrecord dev=x,x,x -msinfo

Then I made an iso of the bleem.bin using that lba, inserted the IP.BIN and burned it with:

cdrecord dev=x,x,x speed=4 -xa1 bleem.iso

That's it... A selfbooting PSX game for ur DC.
Also, you can use this same disc to boot any other PSX game by doing a soft reset without the disc in the DC. It will flash the bleem! screen and u pop in any other PSX game.

Thanks for checking on that. So far I've tried using my brother's disc of Driver and my own disc... same thing with each. Never checked for a version tho.


That is all ?!?!


Kind regards soldiaz

Yes it goes that way. And No Driver doesn't seem to work (I got stuck at the screen that checks the memory cards).

Pavlik, what the hell are you talking about?

Thanks again for checking ur Driver.
Do you suppose there is any way to edit it so that it bypasses the memory card check/doesn't look for the memory card at all?

-Ex

There must be a way. Take alook at the link below. They modified Strider 2 to work with bleem normally so that you don't have to skip any screens. The NFO says they ripped nothing. What is it exactly that they modifed I can't say.

http://www.angelfire.com/clone/dcnfos/tb-str2.txt

They modifed a few more games that are not listed in that site, I only know of Time crisis. There may be more.

swank
 

Friend's been asking me to write a tutorial on that for him since he doesn't understand a lot of that

In doing so, is it possible that you could make that a little more detail? Or may email me about it (if admins wont like it)

Sure, I could do a step by step when I get some time.

I'm using games that I own the original of, so there shouldn't be a problem. I don't even have a modchip for my PSX so all my PSX games are originals anyhow. Bleem! was announced here, but you couldn't put a link to it, so I don't think that's an issue either.

If a mod let's me know I'm wrong on this, I'll drop the subject immediately.

Later,
-Ex

I don't think the mods have a problem with this thread. Otherwise they would have locked or deleted it already.

BTW, I'm stuck on something. For the sort file what did you do to get it? Did you use Isobuster to copy the Tree-info to a file and use that as your sort file? Or did you use something afterwards to sort out the files?

Yeah, I used isobuster and right cilcked - copy tree info to file / lba relative path. That spits out a txt file with all the lba's. You have to convert that with a tool called f2s.exe. The file you get from that is your sort.txt. You can call that txt file whatever you want.

-Ex

OK cool. But it seems things are just not going my way lately. Binhack automatically exits when I try to binhack 1bleem.bin and the ip.bin. I have never had a problem problem with binhack before. And no the attributes are not read-only. Weird.

Could you send me those 2 binaries off one of your working discs?
Hacker3nine********com

Thanks.

Hey guys !

I am really interested in doing some selfboot psx games for dc too.

i would be glad 'bout a step by step tutorial - thr idea is pretty cool!

i mean how to change the lba and so on

I'd post a tutorial since it's really not that hard. I understand everything Ex wrote but I can't seem to be able to Binhack the 1bleem.bin file. I don't understand why. Any ideas Ex?

Ah, finally... PC access. I know ppl post here with Planetweb, but I don't know how. I tried using PW3, but wasn't able to.

I should have mentioned this when I first posted on it, but you don't binhack the 1bleem.bin. The reason it can't be binhacked is because it has no reference to cd001. There is no reference to the session lba at all. All you need to do is use the IP.BIN that came with the bleem! beta you have. If you try using another IP.BIN, you'll have problems. If you don't have the IP.BIN, you can extract it. I like using megalexxx's tool IPCDEXPL. You can find it in the sticky topic on this forum.

Just make an iso of the 1bleem.bin and insert the ip.bin, then burn it as the 2nd session. :)

-Ex

Thanks:)

No wonder I couldn't binhack it.

Everything went ok but the game didn't completely work. Bleem loaded, the it attempted to load the game but after the disclaimer screen it hung.

Maybe I screwed up somewhere. I think the problem is with the sort file. I looked at the game with Isobuster and saw the LBA values are different than in the sort file. I copied the tree info to a file then with Isobuster. Then I used F2S on the text file to get my sort file. The LBAs are still diffferent. Did I miss something?

ok i will try to make a selfbooting psx game myself.
few questions remain.
Wich ip.bin do i have to use?
and
where do i get this f2s.exe ?

Use the ip.bin that is on the bleem! disc to avoid problems like Excalibur suggested.

You can get F2S.exe here

darkfalz.hypermart.net/sortproj/tutorial.htm

But I have used this to sort my files and the LBAs are different than on the original playstation disc. So I don't see the point in sorting them with this.

yea man thats what i think about...most psx isos start at LBA 0.

So there is no need to unpack them.

Everyone speaks about an ip.bin.

I do not have any ip.bin on my bleem disc nor the megalexxx tool to extract the ip.bin works ......

The page above is down.

Can anyone provide the extracted ip.bin ?

You will not see the ip.bin on the bleem disc.

Get IP CD Explorer to extract it from your bleem disc.


Hey Ex, I think I found my problem. The sort option in MKISOFS does not seem to be working for me. I know because I made another copy of KOF 2000 and the energy bars are missing. I used a sort file to fix this and it worked before but now no adding the sort option does not work.

What wrong with this?

mkisofs -C 0,0 -J -R -V KOF_2000 -l -o data.iso -sort KOF2K_sort.txt data

It might be silly, but DOS only takes 8 characters for file names.
Maybe if you try to use a shorter name for your sort file...

Yeah, megalexxx is right, and take out the -R. Katana apps don't support Rockridge anyway.

I use a line like this:
mkisofs -C 0,0, -V "NAME" -sort name.txt -l -o name.iso name

You really don't even need the "-C 0,0" since you're starting at 0 lba anyway.

-Ex

BTW, Driver 2 works ok with bleem! beta. You just need to select the option "above" the one you actually want in the menus.

ok guys bihack does not work! am getting an error message. Megalexx told me to look for CD001 but there is no such entry !

So how do you change the LBA of 1bleem.bin ??

Still nothing. I made it as short as possible

mkisofs -V KOF2K -sort 2k.txt -l -o data.iso data

Does mkisofs have an option to ignore sort files? I don't see the problem not to mention it worked fine before.


Soldiaz: we already mentioned to NOT binhack 1bleem.bin. Read
Excalibur's post (9 posts above this).

Thanks Hakker999.

I will extract the ip.bin and just ipins...and burn the iso

I've been doing some reading up on using sort.txt files with mkisofs. It seems that it's kind of faulty. It will place the files where it wants to rather than where you place it in your sort.txt anyway. I've played around with it a lot in the past and gotten mixed results. I've never actually gotten a dummy to be placed at the beginning of a iso image when using the -sort option. It usually ends up somewhere toward the middle. Other files in the sort.txt are placed in different places than specified as well.
This question has been asked on many forums and I've not yet seen an answer, but is there a way to make mkisofs accurately sort files when building an iso?

-Ex

i guess the files are packed according to their names.

i thought about that was well :-).
The question is if files or directories are burned first.

if you have game data without any directory then naming your dummy to 000DUMMY.dat or just 00000.00 should work well. because the 1st_read.bin starts with the letter 1, 1 comes after 0.

In case that your game directory contains dirs i think your dummy should be named like this 000DUMMY without extension, but i am not really sure if this will work.

Furthermore i think the echelon selfboot method saying to just place a 000dummy.dat onto a disc to speedup the cd is wrong

Maybe you check it out

If you name your dummy starting with a "0" and don't use a sort.txt, it will be placed first on the disc. If you DO use a sort.txt it won't. It will most likely be placed somewhere toward the middle. I've tried it several different ways. I even tried placing it in a folder named "000". It was placed at the very end of the image like this.
And yes, using a dummy DOES speed up the load time of your games. An example of this is Half-Life. The load times are cut by 10 seconds or more when you use a dummy. I timed it.

-Ex

ups sorry :-) im wrong. Of course the dummy will speed up gamespeed, but only if the dummy.dat is burned correctly as the first file, so that the other files are burned after this.
In this case the game data would be shifted towards the middle of the disc and loading time will be limited.

i noticed that about -sort option. i made an iso using mkisofs with a sorttxt.txt and then opened the iso in isobuster and the files appeared in alphabeticle(spelling) order, including the lba for each file.

so about the dummy files. if it is named with 3 zeros ahead of it, 000dummy.dat, it will be the first file burned. other game data will come after that. some games have an 0GDTEX.PVR file so its better to name a dummy with 3 zeros.

It seems to me that since using a sort.txt is unreliable, it's better to not even use one if you are going to add a dummy, (I usually name my dummy "000.0" simply for aesthetic reasons). I suppose sort.txt could be useful if you want to just sort the rest of the files, but they still won't be put in the order you dictate with the sort.txt. That is, unless someone knows how to make mkisofs use a sort.txt reliably, which leads me back to the question...

Does anyone know how to make mkisofs accurately sort files?

-Ex

i did a search on google and found out that using the -sort option in mkisofs doesn't sort the filenames, but it sorts the way the data is written to the cd image.

i can't copy and paste on DC pw browser, but go to google and type, mkisofs README.sort, then scroll down and click the link to the burnatonce forums. the readme is a .txt attachment.

to sum it up. the command line is correct,

-sort sorttxt.txt

the files in the sorttxt are sorted like so,

filename weight

the higher the weight number, the file will be burned first. the lowest number will be burned last. so in most sorttxt files, the 1st_read.bin has a weight of " 1 ", which means it will it burned last on the disc since it has the lowest weight number. so if a sorttxt looked like,

data/1st_read.bin 1
data/file.1 2
data/file.4 3
data/file.2 4
data/file.3 5
data/000dummy.dat 6

then i will be burned like this, first to last,

000dummy.dat
file.3
file.2
file.4
file.1
1st_read.bin

this is what i get by reading the readme. so maybe we are burning it correctly...???

but then again, do the lba's on the discs dictate the data being sorted...??

A sort.txt is supposed to sort the files by where you place them according to your numbers. You "should" be able to even place a higher weighted file at the top of the list and it should be burned first (as long as you give it a higher number), so the actual placement in the list in not what's supposed to matter, but rather the number you give it in the sort.txt.

However, this is not the case. You can have 1256 files in your sort.txt and you can number the 1st_read.bin "1" and the dummy "1256" and the dummy will still end up somewhere toward the middle and the 1st_read.bin will probably end up somewhere toward the beginning, (exactly the opposite of where you placed it).

The way the lba comes into play is this. If you're making a sort.txt using the structure of a CDROM, you "copy tree info to file releative path", and it will save that info in the directory you specify as "filelist.txt". This file has all the lba's of the files. When you run F2S.exe on it, the files will ba placed in order of lba's from the highest to the lowest and numbered from 1 to ???.

It has been my experience as well as the experience of many others, that the -sort option in mkisofs is not reliable. Just do a google search for "mkisofs sort" and see how many results you get that are ppl asking the same question I posed earlier.

Is there a way to make mkisofs sort the files accurately, (meaning the way ACTUALLY DICTATED by the sort.txt)?

-Ex

I tried this and it worked. Except I did not use a dummy file since the game loads fast in the order that I put it in. You guys should try it.

And to think, all this time I was trying the complete opposite. :p

you sure it works? does the gd drive go to read something on the outside of the disc right after the sega screen?

Yep it definately works. I got KOF 2000 working properly again.

This is how it's "supposed" to work. This is what I've been saying all along. However, it doesn't actually work properly like this. Hacker999, I'm sure it didn't just sort aphabetically, but I doubt it actually sorted it according to the sort.txt. Get a filelist of the new CD and make another sort.txt to see if it matches the one you used to make that CD. I almost garauntee that it's not the same.
Let me know what you find on that.

This brings me back to... is there way to make mkisofs sort files accurately?
I use a sort.txt in my betas of Psilocybin Dreams 2.0. It works much better after being sorted, but it still doesn't sort accurately according to the sort.txt. For example: I have a trial version of MSR (speedster vs vx220) on that disc. I put my own music in there, but to keep the music from skipping, the *.afs file needs to be closer to the outside of the disc. I place it at a value of 1895 out of a total of 3824 files. It's after the midis, mpeg clips, and homebrew binaries, but before the rest of the DPWWW folder. The sound DOES work properly because it DOESN'T get placed too close to the center of the disc like it would if I didn't use a sort.txt, but it DOESN'T place it where I actually dictated. This is just ONE example of how mkisofs doesn't sort accurately.

-Ex