Problems when making selfbooting image. - Page 2

blast7 · October 8th, 2004

hehehe..... yeah that's where I found the Echelon selfboot tutorial and the BIN2Boot program (and it's companion BIN2BootGUI). I haven't tried the selfboot program yet, but I doubt it will work any better. There has got to be some fundamental piece of info missing in the tutorials otherwise it should work like a charm, right? Too bad the original author of this post isn't around still.... I'd love to know what he did to correct the problem (he talks about using faster CD-RW media.... but DCs can't reliably read CD-RW media (maybe he was just trying to use Chankast and not boot the games in his DC).

blast7 · October 13th, 2004

Ok.... so I'm a little sad that this thread has died........ I'm still having problems creating selfboot discs but I have some more insight on the matter. Hopefully someone can help w/ this new info.

Ok, so I used BIN2Booot and Selfboot (which is really just a wrapper for BIN2Boot and a few other utilities) and in both cases I now know why the discs refuse to boot, but I don't know how to fix the problem. It seems that the LBA of session 2 (the data session) is always set to 000150 regardless of at what address session 1 ends. I noticed on the selfboot discs I have that do work (which were created by someone else) that the starting LBA of session 2 always comes after the end of session 1, which contains all the audio. I noticed this is true for working selfboot CDs that have one or many audio tracks in session 1.

So it seems that something has caused a problem w/ the way these utilities work. My suspicion is that a win32 API function was being used by one or more of these utilities that may now be depricated or has changed so that the utilities no longer do the right thing when making these function calls.

Another reason I suspect the utilities are no longer working is that the images they create are not mountable in either Nero or DaemonTools (well, they mount, but you can't look at the contents, windows throws an error dialog when you try to view the contents in Explorer). The selfboot images I have that do work (again created by someone else) mount fine and all the data files are present when browsing the image.

One interesting note is the fact that you don't see the audio track(s) in session 1 when mounting the working selfboot image (only the data in session 2). This confused me at first until I found out that you can store bootstrap info in the first 16 sectors of an ISO9660 image, thus telling it to boot from LBA 011702 for example. In fact this is exactly how selfboot images work, you place IP.BIN in the first 16 sectors of an ISO9660 image and the DC reads those 16 sectors to determine from what LBA it should start loading data.

This leads me to an interesting discovery about the Echelon Selfboot Tutorial. Given the info I now have, I don't see how the Echelon method could ever have worked. The reason I say this is that in Echelon you hack the image file you are burning into session 2. But IP.BIN needs to be placed in the first 16 sectors of the CD, not the image being burned into session 2. Maybe burning TAO somehow corrects for this, but it doesn't seem like it could. Anyone know the answer to this one?

Anyway, I still can't succefully create a selfboot disc w/ the tools available..... Does anyone have any suggestions? Can you hack the LBA of a session in an image file?

Still bootless :-)

blast7 · October 26th, 2004

So I guess that since this thread has died w/ me that nobody really cares about hoow to create selfboot DC games.... but I did fix the problem above and I also stated some incorrect facts in my last post that I want to clear up.

As it turns out the DC boots from the first 16 sectors of THE LAST DATA TRACK on the CD or GDROM. So given that fact it's perfectly understandable how the Echelon method works. What I found out is that the second session in the Echelon method must be burned as CDRom XA mode 2, form 1, 2048 bytes. It turns out that the version of CDTools I was using had an updated version of cdrecord that had changed the meaning of the command line parameters! In the Echelon tutorial -xa1 would burn the correct type of session. In the updated version of cdrecord I was using they had changed the meaning of -xa1 to mean CDROM XA mode 2, form 1, 2056 bytes... WHICH WILL NOT WORK IN A DREAMCAST. You must burn that XA session at 2048 bytes for your DC to read the disc correctly (which turns out to be the -xa paramater in the new cdrecord). Now I could go on a diatribe about the priciples of software development but suffice to say that the developer of cdrecord has lost alot of credibility in my eyes. Under no circumstances should you change the meaning of a command line parameter between versions.... if you want to depricate it, fine...... but changing the meaning in this case caused me hours of headache trying to track down the problem w/ the Echelon selfboot tutorial. Thanks to whomever the jerk was that did that (and yes I'm a bit angry right now, but I'll get over it... no hard feelings).

Anyway, so now I'm able to create selfboot DC games from non selfboot images. The only thing that is kind of a bummer is that neither Alcohol 120% nor Nero can subsequently create an image from those selfboot disks... both spit out hundreds of read errors when trying to read the disk. But oh well I can live with that for the time being.

As far as Bin2Boot goes...... I haven't done any further investigation but I would think my initial assumptions are correct. That being said I plan to develop my own version of Bin2boot that works on WinXP SP2.... it will have a nice GUI and I'll post it somewhere for people if anyone is interested.

:guitar:

kenelad · October 28th, 2004

:bounce:

Quote:

Originally Posted by blast7

So I guess that since this thread has died w/ me that nobody really cares about hoow to create selfboot DC games.... but I did fix the problem above and I also stated some incorrect facts in my last post that I want to clear up.

As it turns out the DC boots from the first 16 sectors of THE LAST DATA TRACK on the CD or GDROM. So given that fact it's perfectly understandable how the Echelon method works. What I found out is that the second session in the Echelon method must be burned as CDRom XA mode 2, form 1, 2048 bytes. It turns out that the version of CDTools I was using had an updated version of cdrecord that had changed the meaning of the command line parameters! In the Echelon tutorial -xa1 would burn the correct type of session. In the updated version of cdrecord I was using they had changed the meaning of -xa1 to mean CDROM XA mode 2, form 1, 2056 bytes... WHICH WILL NOT WORK IN A DREAMCAST. You must burn that XA session at 2048 bytes for your DC to read the disc correctly (which turns out to be the -xa paramater in the new cdrecord). Now I could go on a diatribe about the priciples of software development but suffice to say that the developer of cdrecord has lost alot of credibility in my eyes. Under no circumstances should you change the meaning of a command line parameter between versions.... if you want to depricate it, fine...... but changing the meaning in this case caused me hours of headache trying to track down the problem w/ the Echelon selfboot tutorial. Thanks to whomever the jerk was that did that (and yes I'm a bit angry right now, but I'll get over it... no hard feelings).

Anyway, so now I'm able to create selfboot DC games from non selfboot images. The only thing that is kind of a bummer is that neither Alcohol 120% nor Nero can subsequently create an image from those selfboot disks... both spit out hundreds of read errors when trying to read the disk. But oh well I can live with that for the time being.

As far as Bin2Boot goes...... I haven't done any further investigation but I would think my initial assumptions are correct. That being said I plan to develop my own version of Bin2boot that works on WinXP SP2.... it will have a nice GUI and I'll post it somewhere for people if anyone is interested.

:guitar:

Ihave yet to create a selfboot image with any of the supplied tools. So, I for one welcome an accurate program that can. Thx

blast7 · October 28th, 2004

hehehe.... I feel your pain! Especially since cdrecord doesn't support all CD burners on the market I'm not surprised that my "fix" above didn't work for you. Hence my motivation to develop a program that creates bootable disc images so you can use whatever program you want to burn the CD.

I plan to start working on this over the weekend and I'll keep you posted (via this thread) as to my progress.

Oh, and sorry to anyone who thought my last post was a little harsh. I was frustrated after spending hours trying to figure all of this out, but I'm over it now. I actually like cdrecord quite a bit... and if it works w/ your burner then it's a great way to get CD burning for free.

hp78 · February 26th, 2005

I get the error below when I try to make Tokyo Extreme Racer bootable with Exoboot, using the Data to Image function.

BTW, I had no success with fastboot either, as it does not make the new CDI image as expected.

The image does contain the bin files (attached).

Is there a way to solve this issue?

Thanks

Attached Images

error.gif (5.9 KB, 19 views)

Attached Files

bin.zip (1.3 KB, 11 views)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

October 8th, 2004	#21 (permalink)
blast7 Registered User Join Date: Oct 2004 Location: California Posts: 11	hehehe..... yeah that's where I found the Echelon selfboot tutorial and the BIN2Boot program (and it's companion BIN2BootGUI). I haven't tried the selfboot program yet, but I doubt it will work any better. There has got to be some fundamental piece of info missing in the tutorials otherwise it should work like a charm, right? Too bad the original author of this post isn't around still.... I'd love to know what he did to correct the problem (he talks about using faster CD-RW media.... but DCs can't reliably read CD-RW media (maybe he was just trying to use Chankast and not boot the games in his DC).

October 13th, 2004	#22 (permalink)
blast7 Registered User Join Date: Oct 2004 Location: California Posts: 11	Ok.... so I'm a little sad that this thread has died........ I'm still having problems creating selfboot discs but I have some more insight on the matter. Hopefully someone can help w/ this new info. Ok, so I used BIN2Booot and Selfboot (which is really just a wrapper for BIN2Boot and a few other utilities) and in both cases I now know why the discs refuse to boot, but I don't know how to fix the problem. It seems that the LBA of session 2 (the data session) is always set to 000150 regardless of at what address session 1 ends. I noticed on the selfboot discs I have that do work (which were created by someone else) that the starting LBA of session 2 always comes after the end of session 1, which contains all the audio. I noticed this is true for working selfboot CDs that have one or many audio tracks in session 1. So it seems that something has caused a problem w/ the way these utilities work. My suspicion is that a win32 API function was being used by one or more of these utilities that may now be depricated or has changed so that the utilities no longer do the right thing when making these function calls. Another reason I suspect the utilities are no longer working is that the images they create are not mountable in either Nero or DaemonTools (well, they mount, but you can't look at the contents, windows throws an error dialog when you try to view the contents in Explorer). The selfboot images I have that do work (again created by someone else) mount fine and all the data files are present when browsing the image. One interesting note is the fact that you don't see the audio track(s) in session 1 when mounting the working selfboot image (only the data in session 2). This confused me at first until I found out that you can store bootstrap info in the first 16 sectors of an ISO9660 image, thus telling it to boot from LBA 011702 for example. In fact this is exactly how selfboot images work, you place IP.BIN in the first 16 sectors of an ISO9660 image and the DC reads those 16 sectors to determine from what LBA it should start loading data. This leads me to an interesting discovery about the Echelon Selfboot Tutorial. Given the info I now have, I don't see how the Echelon method could ever have worked. The reason I say this is that in Echelon you hack the image file you are burning into session 2. But IP.BIN needs to be placed in the first 16 sectors of the CD, not the image being burned into session 2. Maybe burning TAO somehow corrects for this, but it doesn't seem like it could. Anyone know the answer to this one? Anyway, I still can't succefully create a selfboot disc w/ the tools available..... Does anyone have any suggestions? Can you hack the LBA of a session in an image file? Still bootless :-)

October 26th, 2004	#23 (permalink)
blast7 Registered User Join Date: Oct 2004 Location: California Posts: 11	So I guess that since this thread has died w/ me that nobody really cares about hoow to create selfboot DC games.... but I did fix the problem above and I also stated some incorrect facts in my last post that I want to clear up. As it turns out the DC boots from the first 16 sectors of THE LAST DATA TRACK on the CD or GDROM. So given that fact it's perfectly understandable how the Echelon method works. What I found out is that the second session in the Echelon method must be burned as CDRom XA mode 2, form 1, 2048 bytes. It turns out that the version of CDTools I was using had an updated version of cdrecord that had changed the meaning of the command line parameters! In the Echelon tutorial -xa1 would burn the correct type of session. In the updated version of cdrecord I was using they had changed the meaning of -xa1 to mean CDROM XA mode 2, form 1, 2056 bytes... WHICH WILL NOT WORK IN A DREAMCAST. You must burn that XA session at 2048 bytes for your DC to read the disc correctly (which turns out to be the -xa paramater in the new cdrecord). Now I could go on a diatribe about the priciples of software development but suffice to say that the developer of cdrecord has lost alot of credibility in my eyes. Under no circumstances should you change the meaning of a command line parameter between versions.... if you want to depricate it, fine...... but changing the meaning in this case caused me hours of headache trying to track down the problem w/ the Echelon selfboot tutorial. Thanks to whomever the jerk was that did that (and yes I'm a bit angry right now, but I'll get over it... no hard feelings). Anyway, so now I'm able to create selfboot DC games from non selfboot images. The only thing that is kind of a bummer is that neither Alcohol 120% nor Nero can subsequently create an image from those selfboot disks... both spit out hundreds of read errors when trying to read the disk. But oh well I can live with that for the time being. As far as Bin2Boot goes...... I haven't done any further investigation but I would think my initial assumptions are correct. That being said I plan to develop my own version of Bin2boot that works on WinXP SP2.... it will have a nice GUI and I'll post it somewhere for people if anyone is interested. :guitar:

October 28th, 2004	#25 (permalink)
blast7 Registered User Join Date: Oct 2004 Location: California Posts: 11	hehehe.... I feel your pain! Especially since cdrecord doesn't support all CD burners on the market I'm not surprised that my "fix" above didn't work for you. Hence my motivation to develop a program that creates bootable disc images so you can use whatever program you want to burn the CD. I plan to start working on this over the weekend and I'll keep you posted (via this thread) as to my progress. Oh, and sorry to anyone who thought my last post was a little harsh. I was frustrated after spending hours trying to figure all of this out, but I'm over it now. I actually like cdrecord quite a bit... and if it works w/ your burner then it's a great way to get CD burning for free.