Seeing as the firmware for the HDD-enabled browser is stored on the memory card, is it possible to have HDD Utility Disc 1.0 FW on one memory card, and PSBBN 0.32 on another? This way you could boot into either FW depending on which memory card you used. Or is the HDD formatted to only recognise one type of FW on memory card? I remember having to edit the HDD 1.0 data with the PSBBN disc when I got it so perhaps this isn't possible. I prefer the PSBBN front end and how it auto connects to the internet for SNK games etc, but I've always liked how HDD 1.0 allows you to have 8 memory cards recognised by the browser if you are using multitaps. I could try this out myself of course, but I can't get at my PS2 for 2 weeks or so.
You're mistaken: PSBBN is launched from the HDD partition "__system". The memory card contains an updater for the PS2 ROM and is not needed on consoles with the SSBUS (Expansion bay) connection and network adapter because these contain an already updated PS2 ROM. There's three types of OSD loader: osd100 (HDD Utility disc 1.0, which exists for JPN and US consoles) osd110 (HDD Utility disc 1.10, which exists only for US consoles) pl2boot (PSBBN launcher) It's possible to swap them around by accessing the "_system" partition and adding/renaming the files. If for example you have PSBBN .32 installed and want to revert for OSD100 you need the japanese osd100 files from somewhere else. Then you paste them on the __system partition, rename "pl2boot" to for example something like "pl2boot_" and then rename osd100 as "pl2boot". Inside this new "pl2boot" directory you rename "hosdsys.elf" as "osdboot.elf" because it's what the HDD MBR will attempt to launch. There is no need to touch the memory card data so leave that alone. Without it you can't boot either PSBBN or HOSDSYS.
Wow, I can't really fully understand all of that. I have original discs of HDD Utility 1.0 and PSBBN 0.32. 0.32 is what is currently running. If I want to go back to HDD 1.0 I'd need to re-format the HDD using the disc? Is there no way of having a choice of the two seperate Browsers whenever I like?
Well I put a version of uLE on PSX scene that can be used to access the system partition and do the renaming. So I would advice you to install the OSD100 on the console, then copy the files to USB, install PSBBN, update it and then put the OSD100 files back on the __system partition, making swaping them around just a matter of file renaming. MUCH simpler than reinstalling PSBBN completely every time you want it back.
I suppose that was a bit technical. I'll try to translate l_oliveira repsonse for you. In order for either the HDD Browser or the BBN Browser to work the boot rom chip must have instructions to search and load files off the HDD. The very first model (SCPH-10000) did not have this built in to the chip (as well as the DVD driver for what it's worth) so the HDD utility disc creates this boot file on the memory card. The very first PS2 will search the memory card and load this file if present and then use that boot file to search the HDD for the updated browser (this is the same for both BBN and the HDD browser). Somewhere between the very first PS2 and the first models with the expansion bay (SCPH-30000) Sony updated the boot rom to not need the memory card anymore. Now as far as the switching back and forth between the two. I believe there is an option on the HDD to install the drivers (or browser) without reformatting the HDD. It's been a while since I've used the 1.0 disc so I could be wrong but I do know that the US 1.10 disc had this option. There is also a similar option I believe on the PSBBN disc. It's not the most convenient I suppose but it's easier if you don't want to get too technical.
From what I understand the boot file is found on the memory card, but then either the HDD or BBN browser is found on the HDD. The boot file tells the HDD what browser to launch. I guess it's not possible to swap at will by using two seperate memory cards with different sets of boot files on them. It doesn't work how I first thought it did. Thanx for the help all.
... Boot files are on the HDD and one can swap them around. I've done it and it works. Keberasky gave an excellent non technical explanation for why the memory card update files exists. If you take the HDD out from your case and put on a SCPH-30000 it will BOOT without the "bootfiles" you mention your memory card having. Like I said I'll repeat myself and mention again that the files are an update so the PS2 boot ROM is updated and that's required for any HDD software be usable on that PS2 model. Only SCPH-10000 and SCPH-15000 need it. SCPH-18000 won't start the hard disk without the memory card files but if you for example put Final Fantasty XI disc in it, the disc will auto boot into PlayOnline viewer without need the memory card files. for the 10000 it would refuse to start and show a error message telling that the memory card with the files are required.
Now, a few months later, the "main" reason for the memory card "boot files" was discovered: ExecPS2 and LoadExecPS2 require updates be applied on the system kernel to be able to run the HDD OSD and newer software (DNAS security stuff). :thumbsup:
In case somebody is interested, here is some background on these patches. In newer PS2 BIOSes, LoadExecPS2 and ExecPS2 are almost identical, as both of them hand over control of the system to another program. The difference is that LoadExecPS2 clears user memory and loads the new program from secondary storage, whereas ExecPS2 expects it to have already been loaded into memory, so it can be invoked directly. For this to work correctly, both routines reset hardware and kernel state: all threads are terminated, semaphores are freed, and the lists of registered interrupt and DMAC handlers are cleared. Interestingly, the ExecPS2 implementation is different in the very first kernel version (which is used in both the retail SCPH-10000 (ROMVER=0100JC20000117) as well as the DTL-H10000 TEST unit (ROMVER=0101XD20000224)), as it skips the hardware and kernel reset: it just invokes the new program in the context of the calling thread, with all the old stuff still in place. I think you can guess what's going to happen once the kernel invokes one of those old handlers... :gravedigging: With this in mind, it should be quite obvious what the patch for the old kernel does: insert a new implementation of ExecPS2 that mimics the behaviour of later versions. As there is only one kernel version that includes the misbehaving ExecPS2, existing helper functions (e.g., to reset thread priorities, terminate threads, reinitialize the semaphore control blocks and so on) can be called directly, so this patch isn't really that big. What's more interesting is how to check whether it needs to be applied. The contents of ROMVER provides no direct indication whether the old kernel is in use (for example, TOOLs use something like 0100TD... as ROMVER regardless of SDK version, but include a much more recent kernel), so Sony decided to use a different detection method instead. There is a certain set of system calls (Get/SetOsdConfigParam) that is used by OSDSYS to save its configuration while the system is running, and it turns out that a certain field of the configuration structure cannot be changed by the old implementation; it will always read back as zero, regardless of which value has been specified in the last call to SetOsdConfigParam. So detection goes as follows: query config param (to be able to restore it later), set config param to attempt to change that special field, query config param again, then restore original config. If the second query call returns a non-zero value for the special field, an original old kernel is running and the ExecPS2 patch needs to be applied. This patch detection is perfectly safe; the ExecPS2 patch can be applied repeatedly, even by different programs, without having to fear any crashes caused by different versions of the patcher binary. The original Sony patcher also contains replacements for Get/SetOsdConfigParam that disable the detection method mentioned above (as they allow changing the entire configuration value). However, they are not installed by default, and the only program I know of that installs them is the HDD-enabled OSDSYS. On the other hand, I have seen the ExecPS2 patch getting invoked as part of Sony's LIBC initialization code in various retail games.
