The above video goes away if you are a member and logged in, so log in now!
If you were a developer, then you wouldn't have to ask the question if we could do it, now would you? And if it was 99.9% like you say, then we would probably have a higher compatibility rate with HD Loader right now. Not all incompatibilities are because of protections.
Originally Posted by Golden Helmet
There is the problem, the start position is not irrelevant in some CD games. The reason being that direct access to the LBA of the file is faster than loading the TOC, searching it and then seeking to the LBA. And loading/seeking from CD is pretty slow. (Hence the LBA table tutorials on backup threads) Another thing is that while it is developed in a manner similar to PS2Link for awhile, they do have to start testing on final media at some point, and this is when the LBA tables, protections and the like are inserted into the code.
The actual start position on the disc is pretty much irrelevant.
How do you think PS2 games are developed? on HDD's :-)
With regard to your actual question through: No. No pfs. First off, I want this to be compatible (mostly) with how HD Loader does things. Secondly, using an ISO filesystem retains more compatibility and simplifies my code (since I can forgo having HDD libs on the IO Processor, just the ATAD/DEV9 libs). So when a read starts, I can just add the 4MB offset of the odd partition header HD Loader uses, and then read. (Not to mention some disk checks work by doing raw reads without searching for a file)
In spite of games developed using hdd many of them change into weird forms in retail version. As far as I know it is serious task to make game work from cd or dvd even if it works fine from hdd already. Besides low level file system support in "cdvdman" module operates with logical sectors so it's easy to work with disc image or at least I think so. Such functions as sceCdSearchFile() and sceCdLayerSearchFile() return lsn for specified file which will be used with sceCdRead(). Why should HDL software use files instead of images then?
For example take a look at Final Fantasy X-2 (JAP):
3700636 - SLPS_252.50
57 - SYSTEM.CNF
7353 - MCSERV.IRX
90533 - MCMAN.IRX
151721 - IOPSOUND.IRX
27173 - LIBSD.IRX
43861 - PADMAN.IRX
6161 - SIO2MAN.IRX
9197 - DEV9.IRX
11781 - ATAD.IRX
30405 - HDD.IRX
49665 - PFS.IRX
247 641 - IOPRP234.IMG
13 files 4 376 184 bytes
There are only 13 files visible on disc. So do anyone think this game fits in 4 megabytes ?
Well, just did another large commit to the CVS, no new ELF yet (other than some bloat added by merging the atad, hdd, and dev9 IRXs into the ELF). This new commit has the entire REBOOT module disassembled and turned into a nice readable C-form. I also did a little work on SIFCMD and created a decompiled form of sceSifDelCmdHandler(). Very interesting, as this means I might be able to hijack the entire reboot process via a single patch to modload's export table, and patching the Sif Command handler table to use my module instead of REBOOT. The only catch is how to let the IOP reset, and then reload all my stuff afterwards.
One method that comes to mind is that I could get my routine setup on the EE, catch the IOP reset... and then unhook my IRX from the IOP and repatch it to function correctly. Then I could trigger an interrupt to the EE which my routine sits, which will then continue the IOP reset on behalf of the game, and goes to work in interrupt mode. Since the game still needs to sync, I can sync while in interrupt mode, cause my modules to get loaded, and then do what I need to do to exit.
The only really tricky part to all this is that I cannot do my work entirely inside the IOP. Theoretically, I could, but that would mean implementing a version of IOPBOOT from scratch and overriding the entire reset functionality with my own, but it will be the most compatible way to trick it... ouch.
I only asked guys :-)
Your reason for using ISO, and explanation were enough to answer my original question, thank you.
Just a note: reversed module sifcmd.c can be found in file "modules08.zip" at ps2dev.psx-scene.com
Funny thing is that there was also a reversed reboot.c in there.
Anyways, this was still good practice for me, and I managed to write up an IRX, that is fairly large because of all the IRX import tables, but still works. Anyways, what it does is hijack the reboot command coming from the EE, and then starts up the reboot anyways, sending an interrupt over to the EE first. This interrupt is then caught and handled on the EE (although the ELF currently locks up at the end of the SBUS handler).
For those curious, you can checkout this updated source now, which includes the latest ELF which demonstrates that it is indeed possible to hijack the IOP Reset command and insert your own functionality in place of it. Currently, the only difference is that my code uses a semaphore instead of event flags to pass information, and that I trigger an SBUS interrupt which is caught by the EE and starts executing code there (and then promptly FREEZES, whoops). So, I can actually send some sort of signal to the EE and execute code there, and I can even sync up to the IO processor as well. The catch really seems to be that my function doesn't quite work right. Anyone know a little more about the SBUS interrupt handler routines and if they need to have an Assembly wrapper to function properly?
hey krevnik.. this hdloader is too much wizzely doodah, way to hard man. i hope you know how to reverse engineer,, cause.. man.. hdloader is very hardcore shit. you could make a killer media player. dead set. and that would kick ass. nice open xvid player... you could borrow from ps2mp3. man.
dont get me wrong. i want to encourage you in your deving/hacking efforts. but a media player would deifnlty KICK ASS. i can do gfx design for you, whatever you need. i am a uni student so i have a few hours up my sleeve to waste.
oh, and you should icq/irc me..
hyprsonic EFNET / 8797135
Last edited by HypERSoniC; 03-09-2005 at 09:40 AM.
IMO something like HDL would be way easier than a mediaplayer. You only need to understand how to pass data from place a to place b. With mediaplayer it's all about getting the best working codecs and then adapting them to a new environment and lots and lots of optimizing.
--- Signatures are just lame excuse to waste bandwidth ---
I love how some stupid n00bs are asking questions in this thread completely unrelated to any kind of dev in this project. Keep that crap out of this thread from now on.
Uh, you haven't been paying attention, have you? I reverse engineered the REBOOT module, a chunk of MODLOAD, and a piece of SIFCMD (mostly for verification)... BEFORE looking at the stufff [RO]man has already done. I really should have checked out his work first before spending 2 days dumping and disassembling.
Originally Posted by HypERSoniC
Not to mention that I have /successfully/ hijacked the RebootByEE command for my own purposes. From here, I have two choices: I can write up my module loader on the EE which I am currently testing out, or I can write up a new reboot sequence on the IOP. If I do the second one, it will cause problems with games that attempt load an IOP image, if I do the first, it will cause problems with games that clear out kernel memory. The magical third option is that I create a sort of reinforcing duo that allows me to reload the EE code, triggered by the IOP before the reset, and the EE code reloads my hijacker. I could also patch my EE code into the game's memory space on the stack or the heap. (depending on how big the stack can be) This way, the game can't clear it out and I get higher compatibility than HDAdvance.
This is hard, yes... but not impossible. Talking to the HDD for ripping games and displaying what is on the HDD: really easy. Ripping games: easy now, since I have working DVD9 detection. Playback? Well, that is trickier, since I need to load two modules at least: CDVDMAN (my own version), and ATAD (from ps2sdk). The hardest part of all is actually getting the modules injected during a game-induced reset. I think I have that one in the bag now, it is just a matter of time.