Oh, so if I yank out the USB connector it will still boot the old BOOT.ELF in my mc0:/BEDATA-SYSTEM/ folder. That's really neat!
Originally Posted by ubergeek42
The main difference is very simple, as shown in the following two lines, the first being from FF7 CD1, and the second from FFXII, both PAL versions.
Whoops, guess I worded that wrong, I meant that the program just opens the system.cnf file on the disk in the drive, but since ps2 disks have a system.cnf file as well, it will probably read the id from it. There is probably something fundamentaly different in the 2 system.cnf files, so I should be able to prevent it from taking an id from anything but a ps1 disk.
BOOT = cdrom:\SCES_008.67;1
BOOT2 = cdrom0:\SLES_543.54;1
As you can see the main difference is the use of the BOOT2 keyword for a PS2 disc instead of just BOOT for a PS1 disc. So if your titledbmaker sees that the file contains no BOOT directive, though it may have a BOOT2 one, then it can issue a warning to the user that this disc is unsuitable for exploit use.
Note however that I have seen some ISOs that contain BOTH a BOOT and a BOOT2 directive (pointing to different files) in the SYSTEM.CNF file. Presumably those discs can boot one way on a PS1 and another on a PS2 console, but I've never been able to test that as my PS1 won't boot CD-R. However, assuming that such discs will boot as PS2 discs on a PS2 (thus ignoring TITLE.DB), then your program should issue the same warning about the disc being unsuitable for exploit whenever the BOOT2 directive is found.
So there are three possible error cases where this warning should be given:
1: No SYSTEM.CNF found. (Probably not a PlayStation disc of any kind.)
2: BOOT2 directive found in SYSTEM.CNF (must be a PS2 disc)
3: BOOT directive missing in SYSTEM.CNF (really weird disc... :))
----- snip ----- re: HDD boot support
That is the standard partition, and trying to add some new standard would just open another can of worms. It's better to go with the standard we have.
I agree, and I may yet add it, probably booting from the __boot partition since I seem to remember that thats where dev2 boots from as well, but I'm open to suggestions.
I don't really think it's a good idea to put BOOT.ELF in the root of a USB drive either. There has never been any standard for booting from a device root before, so why start now? That can also get messy with applications that use multiple config files. I normally have four of them for my uLE test setup, and would like to keep the whole set in a folder of its own. So I'd prefer a launch path like: "mass:/BOOT/BOOT.ELF"
Yes, I noticed that, but it's still negligible compared to having to store a full-fledged application on the MC instead of the USB drive, like we have to do with the traditional exploit.
As you probably guessed, by adding in the additional usb modules, the TITLE.DB file is larger then the default one, about 152kb, vs the original 73kb.
The normal ELF packer can hardly do it, since the exploit code is not invoked in a 'normal' manner. You'd have to write a lot of new packer/unpacker code to do this, unless you want to split the code into two parts. One would essentially be identical to the old exploit and the other would be a new separate BOOT.ELF stored on the MC beside TITLE.DB. But I don't like that approach, as it would also split the ELF launching into two consecutive launches. One for the packed 'helper' BOOT.ELF on MC, and another for the real boot application on USB (or wherever). I prefer it the way it is now, even if it is twice the size of the old exploit file.
I may be able to reduce the size some, I havn't really played around with it too much yet(possibly packing the loader, I don't know if that would work though)
Well, since I'm always going to use uLE as the main boot application, such copying abilities seem a bit redundant to me. But I guess it could be useful for those who want to boot SMS, and want to do it from MC like with the traditional exploit.
I have also toyed with the idea of supporting autoupdate, something like you put a file UPDATE.ELF on the usb drive, and it copies it to the memory card as BOOT.ELF, then loads it, and removes the update.elf file from the usb drive...still just a thought I've been pondering.
But with the new exploit I think most would want to run SMS (or uLE) directly from USB, and then there's no need for such an update method. Just copy the new BOOT.ELF to the USB drive on the PC and you're done with it. It will boot normally when that USB drive is in the PS2 without any extra 'update' work at boot time. So adding such code seems redundant for that case as well.
Best regards: dlanor