HD Homebrew Project Developement (Old Thread)

Another CVS commit a little earlier today, this one freezes the hdreboot.irx module. It works, it does what it needs to do, and I am not gonna touch it again unless I absolutely have to. This last mess I waded through was pretty nasty and it took me 30 minutes just to clean up the code once I was finished. Ick. The good news is that the entire module is now under 5K in size, without stripping the symbols. Not bad, eh?

I think the next step is to start interfacing with the HDD (finally), and get things together for an actual interface. Initially, it will be compatible with HDLoader, but I may decide to remove compatibility with it at some point so that I can have higher compatibility rates and more stable operation. Any input on if I should eventually split from HDL-compatibility or should I expend the extra effort to keep it?

ok i just used demolish.elf and it scrolls the saying
Disk Read:
validPS2: Yes, disk type dvd, dual layer then a block symbol
Layer Break 2050738, Total Lenght 4062160

is that correct the disk was champions of norrath

Well, it is an older elf that you used, but yeah... Champions of Norrath is a DVD9, and that proves it read correctly. I can pretty much say with confidance that DVD9s will be supported in this app.

Krevnik - When you talk about the taking out "HDL compatibility", do you mean that once we load your app, we would need to completely reformat and reinstall the games on the HDD? If so, maybe initially that should be there, simply so more folks would be willing to try and test your app without having to wipe their HDD game collection thus far. If you can increase the game compatibility while keeping HDL format there, (so if someone wanted to switch between the two I guess?), that may be a drawing feature for alot of people to use it. However for myself, I would rather see you do your own thing, especially if it addresses the game compatibility issue, once a good stable environment is acheived. Awesome project man. Wish I could go this far

Well, it wouldn't reformat the drive, but it would make HDL-loaded games inaccessible and vice versa. There are a few things I would like the freedom to try, but keeping HDL support in the long term would only make a mess out of where I have to store things when I start breaking away from HDL's feature set. I intend to use HDL's layout for now, but I am only doing that to speed up initial development until I have desires/needs outside of what HDL's database can currently do.

I suppose I wouldnt mind reinstalling all my games to a HDDemolisher partition but I think initially (if possible) it would be good to retain HDL compatibility but if that contrains your app at all I would just drop the HDL compatability!

Hey Krevnik, awesome work.
hmm let me see... seems to me that you're claiming you can keep HDLoader games, and still be able to install Demolisher ones on the same HD without reformatting right? Then it would be just a matter of using the correct app to play the games (did I get it right?). I think you can wipe hdloader compatibility out and keep all effort on your own format/ideas.

Quote:

---

Originally Posted by Krevnik

I think the next step is to start interfacing with the HDD (finally), and get things together for an actual interface. Initially, it will be compatible with HDLoader, but I may decide to remove compatibility with it at some point so that I can have higher compatibility rates and more stable operation. Any input on if I should eventually split from HDL-compatibility or should I expend the extra effort to keep it?

---

My opinion on this subject is inevitably split, since there are some different forms of compatibility involved.

When it comes to the physical disk format, and the internal structure of the partititions, I see no reason at all to drop backwards compatibility. But even so, that standard may need to be extended to cover true PS2 dual-layer discs, as they have two iso file systems. ('Flattening' methods as presently used will not work with all games.) Apart from that change (if/when), I think the partition format should remain as-is. One big bonus from that choice would be automatic compatibility with games already installed, as well as with all the third-party HDL installers (HDL_Dump, WinHIIP, etc).

When it comes to internal methods of HDDemolisher, there is absolutely no reason to maintain ANY compatibility at all with HDLoader, except coincidentally, where similar needs may require similar methods. This is the area of change that can bring the greatest improvements, so don't let any old design hold you back.

When it comes to the user interface, I have no strong feelings either way. The current methods suffice, but there is always room for improvement, and a pretty obvious one would be to add LaunchELF-like capability to browse PS2 media and launch ELF programs. But that's for a longterm wishlist, when all the main stuff (replacing HDL functionality) has been implemented.

One more thing that needs to be mentioned is the mode flags. As long as they still remain relevant, their meaning should not be altered:
1 = Attempt to emulate true CDVD timing (slow but compatible)
2 = Allow huge disks (ignored/always allowed with your code !?!)
3 = Attempt to hide patcher from game code

Most likely these flags are stored somewhere with room for more bits that are currently unused, so if you need mode flags of your own, then those are the bits to use for them. However, adding such could break some of the compatibility with HDL installers, so that should be taken into consideration.

Best regards: dlanor

Quote:

---

Originally Posted by Krevnik

With regards to the information on Tenchu: That is rather interesting, since I don't have the game, I can't take a peek myself, but do you know what sort of route it takes with that version code? Depending on the version, does it load a new one? I am just curious as to how it responds to unfavorable version codes, so I can think of ways around it.

---

This is what I know as this moment:
IOP module code is pretty simple amd module name appears to be "ck01"

Code:

---

int start (int argc, char *argv[])
{
 int *param;
 
 return (_sceCdSC(0xFFFFFFF7, &param) == 1) ? 5 : 1;
}

---

At EE side there is code like this:

Code:

---

int run_ck01(int *result)
{
 int rc;

 /* some initialization code skipped */
 
 rc = sceSifLoadStartModuleBuffer(iop_mem, 0, 0, result);
 *result &= 0xFFFFFFFC;
 sceSifFreeIopHeap(iop_mem);

 return rc;
}

---

Function run_ck01() is called from main() and these is a branch much later in the main() which depends on whether or not IRX exit code (result) is equal to zero.
What's going on later I can't understand yet. But I don't think the game tries to reload "cdvdman" since its in IOP image.

"cdvdman: from "rom0" doesn't support sceCdSC() call with such code while "xcdvdman" from "rom0" does. All the "cdvdman" modules from IOP images I dug in support for sceCdSC call with 0xFFFFFFF7.

Quote:

---

Originally Posted by Krevnik

Well, it wouldn't reformat the drive, but it would make HDL-loaded games inaccessible and vice versa. There are a few things I would like the freedom to try, but keeping HDL support in the long term would only make a mess out of where I have to store things when I start breaking away from HDL's feature set. I intend to use HDL's layout for now, but I am only doing that to speed up initial development until I have desires/needs outside of what HDL's database can currently do.

---

I'm not sure exactly what you mean by 'database' here.

If you mean some internal database of each game, to keep track of stuff within that ISO, then we do have a real problem.

If you mean the collective database where HDL keeps track of all the games, then I'd say there is no problem at all. Unless I'm misinformed that is erased anyway when using PC-based installers, and then rebuilt when restarting HDL, so that database has nothing to do with the compatibility of the game images installed.

Of course, if you truly see a real need for changes that break compatibility, then so be it. But personally I don't think we should assume that this will be necessary until such a need is known.

Best regards: dlanor