Si je comprends bien, on est plus obligé de faire affiché les partitions dans le navigateur ?
Citation:
Envoyé par FHDB readme
Although the HDDOSD is a requirement for using FHDB, it is possible to use FHDB without the HDDOSD. However, if no valid HDDOSD installation is detected, FHDB will power-off the HDD Unit and attempt to use the ROM OSD instead.
Citation:
Envoyé par FHDB Changelog
*If a valid HDD OSD installation cannot be loaded, FHDB will attempt to use the ROM OSD instead.
(dsl pour l'anglais )
Non tu n'es pas obligé d'avoir le navigateur 2.00, c'est juste un plus esthétique et pratique. Si FHDB ne détecte pas de navigateur en 2.00, il te renvoie sur le menu FHDB (OSDSYS hacké) et la seule chose visible dans le navigateur, ce sont les cartes mémoires. S'il en détecte un, tu as en revanche accès et au navigateur 2.00, et au menu FHDB - ce que ne permettait pas FMCB1.8c.
Citation:
Donc, on peut se permettre un HDD supérieur aux 40Go de départ, nan ?
Oui, pas de soucis, je n'ai rien lu concernant une limitation de taille.
En utilisant le navigateur 2.00, tu peux aller jusqu'à 120Go de jeux d'affichés, si tu dépasses : lag + plus rien de visible (je crois).
Cet utilisateur dit Merci à ShaoliAss pour ce poste utile:
If you can't/won't get a 48-bit LBA-patched HDDOSD, you could also just not use the HDD OSD. FHDB will use your console's ROM OSD in the event that it doesn't find a HDD OSD installation. At least, you will be able to access your memory card from the browser (And you should still be able to launch stuff that are stored on the HDD unit, from the hacked OSD's menu).
Donc si le HDD est de taille supérieure à 137 GB, enlevez le HDDOSD. FHDB patchera OSDSYS et vous permettra de booter les ELFs que vous avez installé sur le HDD.
Comme l'a indiqué ShaoliAss, le HDDOSD est surtout pour l'esthétique et pour la jouissance d'une fonctionnalité supplémentaire. Mais plus on y installe de trucs, plus ça devient chiant à utiliser. Sans oublier que chaque installation bootable bouffe un minimum de 128 MB. Le HDDOSD/OSDSYS hacké par FHDB offre la possibilité de lancer des ELFs de la même manière que FMCB. C'est simple, rapide, customisable, et sans les maudites restrictions du HDDOSD.
Cet utilisateur dit Merci à krHACKen pour ce poste utile:
Tiens j'ai oublié de parler de qq chose d'important pour les utilisateurs de FMCB (installation sur CM dc):
Citation:
Envoyé par SP193 (changelog-installer)
What's the difference between a multi-install and a normal cross-region installation?
-------------------------------------------------------------------------------------
A long time ago when FMCB v1.8b was just released, only the multi-installation mode existed. It allowed users to make an installation of FMCB that worked on all consoles within the same region by introducing crosslinking (controlled corruption) into the memory card's filesystem. That was to save space, because it used to create about 20 crosslinked files due to the developers not knowing which exact boot ROMs will look for version-specific update files.
The older PlayStation 2 consoles were coded to boot an update for only its ROM version, meaning that a console with v1.20 will only boot osd130.elf. Newer consoles will look for a different file. This practice was scrapped by Sony later on (at boot ROM v1.60), but such older consoles still exist on this planet.
The multi-installation of v1.8C now allows cross-regional installations to be done, but still uses controlled filesystem corruption.
However, with the discovery of exactly which boot ROMs will look for version-specific update files, it has been found that only a handful of models actually have this need. The number of times the FMCB binary needs to be copied has been reduced to 5. With the small binary size of v1.8c, the amount of space required for a cross-regional installation without crosslinking has been greatly reduced.
Basically, a normal cross-regional installation does exactly the same thing as a multi-installation, but duplicates the FMCB binary instead of crosslinking entries. It's safer and does not go against the limitations (and design) of the memory card filesystem.
En résumé, vous avez 2 modes d'install multi qui sont différents :
- "Installer FMCB sur la carte mémoire.", choix qui se subdivise en :
1) Normale : l'installation marchera uniquement sur la PS2/Two à partir de laquelle FMCB a été installé
2) Multi-modèle : l'installation marchera pour n'importe quelle PS2/Two de la même région à partir de laquelle FMCB a été installé.
3) Multi-région : l'installation marchera pour n'importe quelle PS2/Two quelque soit la région.
- "Installer FMCB pour n'importe quelle PS2. (ancien mode multi)" (texte original anglais : Install FMCB for all consoles.)
Lorsque j'ai été amené à traduire l'installer, j'ai choisi de rajouter "(ancien mode multi)" pour bien marquer la nouveauté introduite par l'installer, un type d'installation multi (choix 2 & 3) plus sûr, plus stable, mais qui occupe un peu plus de place que le précédent/ancien mode multi. Bien sûr, ils font la même chose.
Ce ne serait pas aller contre l'idée de SP193 que de dire que les choix 1 + 2 +3 sont les choix recommandés, tandis que l'ancien mode multi est déconseillé. SP193 a été amené malgré lui à le conserver, pour une unique raison : "haters gonna hate".
Si vous avez une install multi à faire, vous savez maintenant quoi faire
Cet utilisateur dit Merci à ShaoliAss pour ce poste utile:
meaning that a console with v1.20 will only boot osd130.elf.
LOL, j'savais pas ça. Je croyais que cette là bootait osdsys.elf (le patch Kernel) quand les autres bootent osdmain.elf (30k+). Mais ça me parait legit, vu que si 5ony a intégré l'update du kernel en ROM (18k), elles n'ont plus besoin de charger l'updater (conçu pour les 10k et 15k), juste l'update OSD. Puis le package d'update OSD officiel se compose du osdsys.elf (kernel updater + bootstrap), osd110.elf (update OSD, invoqué après l'update du kernel et le reboot) et osd130.elf (doublon de osd110.elf, pour la 18k).
Dernière modification par krHACKen ; 20/08/2013 à 09h25.
Cet utilisateur dit Merci à krHACKen pour ce poste utile:
Qqn a testé d'installer la 1.91 pour une PSTwo SCPH-700XX? Il y aurait un pb apparemment, 2 cas où FMCB n'arriverait pas à booter.
Citation:
Envoyé par SP193
Looks like there's a difference in the boot ROM of the SCPH-70000 series (boot ROM v2.00). When FMCB is started, the IOP contains NCDVDMAN... which has a number of functions replaced with dummy functions (Who knows why Sony did that...?).
It's likely that your consoles are getting stuck at the OSD configuration initialization step, before the logo is shown. If that's true, then all SCPH-70000 series units will be affected as the boot ROM is the same across all console models within the same series. :X
--------------------------------
Citation:
Envoyé par kHn
J'ai mis les fichiers du 1.00J, du 1.00U et du 1.10U dans le Pastie 8248383
Les fsck ne sont pas inclus, ni le MBR, mais on s'en tape. À coller à la racine de la partition __system une fois que FHDB est installé.
1.00J testé et fonctionnel sur un HDD non-sony.
Dernière modification par ShaoliAss ; 20/08/2013 à 12h32.
Fix for the SCPH-70000 series consoles: Added a IOP reset at the start of FMCB, so that the IOP will contain the same modules across all console models.
Fixed the kernel patch (See PS2SDK updates for today and yesterday) for the SCPH-10000 and SCPH-15000.
Removed IOP reset from the EE ELF loader, as some homebrew software depend on the loaded modules for file access.
The patch for sceCdForbidDVDP() will now be specially invoked earlier on for the Protokernel OSD, as the bulk of the patch code is run after sceCdForbidDVDP() is run by the OSD. This solves DVD booting.
Adjusted DVD video/ESR-patched disc booting code, so that a definite result will result (Either a BootError or the disc boots).
Optimized code.
Fixed OSDSYS patch for the SCPH-10000 with boot ROM v1.00. The HDD modules should now be loaded when the card is inserted in slot 1.
Added code that kills all threads but the main thread. When control is wrenched from the hacked OSD, any thread created by the OSD is left behind and that can result in weird behaviour (e.g. if the stray thread(s) reinitializes a RPC connection with the IOP, especially during an IOP reset). This fixes ELF launching on the SCPH-10000 and SCPH-15000, when the OSD is reloaded.
Changelog:
Fixed support for the PSX (DVR unit). It will now boot properly, and sets the EE and CD/DVD drive into "PS2 mode".
Changed the way arguments are passed to the OSD program. FMCB will no longer parse and repeat the arguments, but passes the arguments directly to the OSD program "as-is".
Recompiled the FMCB configurator to have the updated FMCB release version number. Also, with this recompilation, the Protokernel patch within it has been updated (Note: This doesn't really matter because the patch from the FMCB binary would have already been applied).
The MBR program's EELOAD module had it's argument storage widened, so that it can take in 16 user arguments (To avoid buffer overflows, since the code within it was always limiting the number of accepted arguments to 16).
Added a clone of the kernel update for the SCPH-10000 (v1.01) and SCPH-15000.
Fixed OSD configuration setup for the SCPH-50009. Its OSD sets its "region" field to 2 instead of 1, despite this console being in the NTSC region.
Modified the "inner browser" setting to allow the user to specify how FMCB/FHDB will handle booting into the OSD (Either always boot into the browser or not, or just let the browser have its default behaviour).
For those who wish to edit this setting by hand, the valid values are as follows: 0 = AUTO, 1 = force ON (always boot into the browser), 2 = force OFF (always stay out of the browser). It was made this way for backward compatibility.
Removed the "return to loader" option, since I had no intent on maintaining it. The user can put uLaunchELF basically anywhere, and uLaunchELF isn't part of FMCB anyway.
FMCB will now no longer display the FMCB logo when software like the DVD player quits, to match the behaviour of the OSD program.
)
Mode linéaire
