HD Homebrew Project Developement (Old Thread)

i think that launchelf is about the best ps2 app ( no chip) out thier so if can also boot elf how could it ever be beat LOL

Quote:

---

Originally Posted by dlanor

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).

---

Here is the problem. The current database layout for HDL/HDA is restrictive, and I already have to resort to some other way of storing information for my database. Specifically, I don't have any information on how to flag a partition as being a DVD9 partition to make my search easier. (HDL seems to store all its information on disc type/etc in its database) Also, the partition format is kinda bizarre because not only is each partition an ISO by itself, but it has a 4MB header whose contents I am not entirely familiar with yet. Conforming to this is tricky at best. As a compromise, I might simply have support for importing from HDLoader, but not for exporting /to/ HDLoader. That way games that need my special attention to work (DVD9s, games that might work under some new compatibility mode) don't wind up in some horrid mess.

Quote:

---

Originally Posted by dlanor

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.

---

Not planning on it.

Quote:

---

Originally Posted by crazyc

>1) cdvdman contains some some functions like sceCdReadClock, sceCdRI, etc which aren't closely related to C/DVD emulation;

Some of those functions are reimplemented in hdloader. They even missed that cdvdman contains two copies of sceCdReadClock thus causing some timestamps on the memory card to be wrong. If hdloader just patched cdvdman, that problem never would have happened. Also remember, the clock, ilnkid and machineid are located in the mecacon.

>2) other module "cdvdfsv" (which supports libcdvd calls from EE) not only uses "cdvdman" functions but also accesses C/DVD hardware registers.

I could be missing something, but a quick look at hdloader's cdvdfsv, I don't see any place where it accesses the mecacon registers.

---

"cdvdman" modules from IOP images don't support all that functions thier "old brothers" from system BIOS can provide. I noticed versions from redistributable IOP images don't allow to write iLinkID or MachineID and call "ReadAudio" function or set new system time also. But they have new functions for DualLayer DVD support and some more interesting things. So its easy and hard to reimplement "cdvdman" functions at same time since program rather aimed just to support games. :)

Just look at "cdvdfsv" a little closely. It can be found even in few RPC handler callbacks. Module accesses memory locations 0xBF402005 and 0xBF40200A at least.

My thoughts about compatibility with HD loader&HD Advance:
I believe people do not want a revolution.
1) Many people have decades of games already installed on their HDDs, so who wants to reinstall them all ?
2) There are many game compatibilty databases (supported games, HDL modes, patches and so on) around the world, so who wants to use totally new unknown application then ?
3) Many third party software for HDL like FapLink and others are available already but why it can't be used with new application ?

I think Demolisher should support all HD loader installed games as well and do it as good as it can be done at a moment. All extra features should be implemented to not interfere HD loader's duty. Users should have option to install games in two modes: compatible with HDL for most games and so called native mode (if it really needed) for games incompatible with HDL by default such as DVD9 games.

If someday most people consider to use only Demolisher instead of HDL then it will be time to split Demolisher from HDL compatibility by starting new branch. But nowdays HD loader users community is too large and can't be ignored.

PS: Personally I even want Demolisher's support for lba48 will be optional feature since I use old version of HD loader and want my HDD to be compatible with few games which has native hard drive support. ;)

Quote:

---

Code:

---

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

---

---

That's weird, hdloader's impementation of sceCdSC (assuming its cdvdman:50) is

Code:

---

int sceCdSC()
{
 return 1;
}

---

Quote:

---

Just look at "cdvdfsv" a little closely. It can be found even in few RPC handler callbacks. Module accesses memory locations 0xBF402005 and 0xBF40200A at least.

---

I see that Sony's cdvdfsv accesses those registers, but I don't see where hdloader's does.

Here is an idea.... a running database file that can be downloaded for the program to use for auto shrinking ISO images... the database tells the program what files to remove and so on.... thus saving automagically craploads of HDD space...

Quote:

---

Originally Posted by crazyc

That's weird, hdloader's impementation of sceCdSC (assuming its cdvdman:50) is

Code:

---

int sceCdSC()
{
 return 1;
}

---

---

So it must be an anti-HDL protection then. I doubt any standard "cdvdman" has version number 0x1 because it usually begins with 0x100. I have more to say, there is another game with such stuff found recently. Its a "Neo Contra". I didn't extact that irx yet but it looks very same in hex-editor.

Quote:

---

Originally Posted by crazyc

I see that Sony's cdvdfsv accesses those registers, but I don't see where hdloader's does.

---

Oops. I thought you talked about Sony's cdvdfsv.

Quote:

---

Originally Posted by romz

So it must be an anti-HDL protection then. I doubt any standard "cdvdman" has version number 0x1 because it usually begins with 0x100. I have more to say, there is another game with such stuff found recently. Its a "Neo Contra". I didn't extact that irx yet but it looks very same in hex-editor.

---

But, according to your code, it's expecting a return value of 1 with the version number in the param field?

Quote:

---

Oops. I thought you talked about Sony's cdvdfsv.

---

It really isn't an important point, but to show that hdl's cdvdfsv is a very simple wrapper that does nothing but forward calls to cdvdman.

Krevnik: How are you planning on handling cdvdman, by patching it's export table or replacing it altogther?

forget hdloader... people will change do demolisher if you have a good reason to start...
if u have like Gran Turismo 4 workin or a game like that than people will gladly switch over...

Quote:

---

Originally Posted by crazyc

But, according to your code, it's expecting a return value of 1 with the version number in the param field?

---

Parameter doesn't matter, only value of "v0" register is used:

Code:

---

return (_sceCdSC(0xFFFFFFF7, &param) == 1) ? 5 : 1;

---

Second argument is formal.