Faxtron escribió:abufa escribió:Alguien ha probado algún disco de 3TB si la PS3 se lo reconoce ahora en NTFS a la hora de cargar juegos??.
un saludo
Si; y en mi caso no lo reconocio.
¿Desde Iris Manager tampoco?
En teoría tenemos soporte para sectores de más de 512 bytes... y digo, en teoría, por que no tengo ningún disco duro de esos para probar.
Mis modificaciones del plugin iban en ese sentido e igualmente, en la librería, pero claro, tal vez el problema este en otro lado, si lo hay (lo mismo cambia algo en las particiones). Si no lo has probado con Iris, mira a ver.
alexjrock escribió:Estwald si deseas un beta tester para consolas Slim, yo me ofrezco, tengo flasher para recuperar la consola por si llega a petar.
Saludos
A ver si mañana te puedo enviar un MP con todo, que ando petado de tiempo durante el día.
He cambiado algunas cosas: ahora tenemos dos flags de instalación y otras dos nuevas.
Las flags, para evitar colisiones con el Core de MiralaTijera, se instalarán en "core_flags", mientras que la actualización del Core o del sm.self, si la hubiera, irán en "core_install"
Ahora el Core puede trabajar de la nueva manera (es decir, haciendo las cosas en paralelo con vsh.self) o a la manera de MiralaTijera (haciendo las cosas antes de cargar vsh.self).
Para ello son las dos nuevas flags: "boot_on" instala una flag en "/dev_flash" para indicarle que queremos que haga las cosas antes de cargar vsh.self, mientras que "boot_off" desactiva ese modo. Hasta el momento, yo no he visto problema en actualizar los ficheros en paralelo con vsh.self por ejemplo, pero no es mala idea poder fijar ese modo en un momento dado.
Obviamente, con "boot_on" se producirá desincronización del mando...
Basado en la misma idea, son las dos flags de instalación: "install" activa en /dev_flash una flag temporal, crea "install2" en /dev_usb000 y reinicia la consola para poder hacer la instalación antes de vsh.self (y luego otra vez, para aplicar los cambios). Esto da una idea de como pueden trabajar otras funciones que soporta el Core de MiralaTijera en el futuro, que requieren esta forma de funcionar (hay otras como por ejemplo, el "anotherlv2" que se pueden hacer directamente: yo de hecho, tengo un LV2 modificado para que lance sys_init_osd2.self en lugar del de siempre y una aplicación que carga el new_core.self debidamente en la flash y luego lanza ese LV2, para probar de forma segura el Core
).
Si solo se especifica "install2" en ese caso, se instalan los ficheros de forma paralela a vsh.self y se reinicia después, para hacer efectivos los cambios.
Las flags como "install" o "install2" se desactivan a posteriori anteponiendo "_". Lo mismo pasa con los ficheros de instalación: si no hay algún error que haya impedido la instalación, sm.self se renombrará como _sm.self y new_core.self como _new_core.self.
Esto está pensado para evitar situaciones cíclicas, reinstalaciones accidentales que puedan causar problemas de semibrick, exponeros al mínimo a ese riesgo (copiado de ficheros de forma segura y renombrado posterior, de forma rápida, para minimizar los riesgos) , pero para conservar los ficheros (MiralaTijera los borra) y también evitar el uso de las flags de forma indebida.
También hay que tener en cuenta que aunque ahora mismo, básicamente, nos limitamos a cargar sm.self y actualizar el Core, en el futuro podrían haber mas funciones y el core tiene que estar preparado para ello.
El código se compila bajo PSL1GHT, tal como está, debería se compatible con todos los CFW en principio, aunque el sm.self solo trabajará para los que esté adaptado, obviamente. También suministrare los fuentes y la liblv2 ya compilada, con lo que se precisa.
De esa forma, los que se dedican a hacer CFW, lo podrán incluir (si quieren).
EDIT:
BillGates escribió:ESTWALD te pido ayuda, quiero modificar el PKG instalador de IRIS para que lleve una pre-configuracion o sea un "manager_setup.bin" preconfigurado por mi
Tambien te daria una sugerencia para el nuevo "System Manager", no se si se te habra ocurrido pero seria interesante que sea el propio IRIS quien instale SM y permita desinstalarlo y tambien reporte su presencia ya sea en activo o no, todo desde el menu de configuracion de IRIS.
GRACIAS por tu atencion.
A lo primero, debes editar el Makefile. Te muestro por ejemplo, el código de "pkg" (sin animación)
pkg: $(BUILD) #$(OUTPUT).pkg
@$(MAKE) --no-print-directory -C $(CURDIR)/loader -f $(CURDIR)/loader/Makefile npdrm
$(VERB) echo building pkg ... $(notdir $@)
$(VERB) mkdir -p $(BUILDDIR)/pkg/USRDIR
$(VERB) cp $(ICON0) $(BUILDDIR)/pkg/ICON0.PNG
$(VERB) cp -f $(CURDIR)/loader/EBOOT.BIN $(BUILDDIR)/pkg/USRDIR/EBOOT.BIN
$(VERB) cp -f $(CURDIR)/$(TARGET).self $(BUILDDIR)/pkg/USRDIR/iris_manager.self
$(VERB) $(SFO) --title "$(TITLE)" --appid "$(APPID)" -f $(SFOXML) $(BUILDDIR)/pkg/PARAM.SFO
$(VERB) if [ -n "$(PKGFILES)" -a -d "$(PKGFILES)" ]; then cp -rf $(PKGFILES)/* $(BUILDDIR)/pkg/; fi
$(VERB) $(PKG) --contentid $(CONTENTID) $(BUILDDIR)/pkg/ $(TARGET).pkg >> /dev/null
Si te fijas, hay varios "cp" $(CURDIR) representa el directorio donde está el Makefile y $(BUILDDIR)/pkg donde se está formando el pkg. Para con animación es lo mismo, pero en ese caso "pkg2".
El parámetro -f lo que hace es forzar el copiado, por cierto.
Sobre lo que dices de instalar sm.self desde Iris... no se exactamente a que te refieres con eso:
- Si te refieres a lanzar el sm.self desde el propio Iris Manager, no se puede, o mejor dicho, si lo lanzas, tienes que salir del sm.self y de Iris Manager para poder hacer otra cosa (de hecho, en mi Core, pretendía mantenerlo en un bucle para ver si podía lanzar otros selfs en segundo plano, más adelante, mediante una treta y se quedaba vsh.self esperando a que saliera de mi Core...).
- Si te refieres a copiar el Core completo, dando una opción en Iris Manager, se puede desde el Archive Manager y si quieres mantener una copia del sys_init_osd original, lo tendrá que hacer manualmente (el problema es que yo no puedo asumir automáticamente esa tarea: si el sys_init_osd.self resulta ser el Core de MiralaTijera, no nos interesa mantener esa copia, por que habrá conflicto), pero la tarea en si de copiar el Core a su sitio la primera vez, lo puede hacer otra herramienta que luego se puede desinstalar, con menos trabajo por mi parte y de forma mas segura.
- Si te refieres a actualizar tanto el Core como el sm.self, para eso tiene el propio Core sus propias flags y es más seguro hacerlo ahí, que desde Iris y en todo caso, DEBE poder hacerse desde el Core.
Mi filosofía de trabajo no es darle a la gente lo que cree que quiere, si no lo que a mi me parece oportuno ofrecer de la forma más segura posible. Ya sabemos todos que los programas no están exentos de la posibilidad de error (que fácil es cagarla...) y lo que es peor, que se pueden interferir unos con otros... por lo que siempre es preferible que las cosas se hagan donde y cómo se tienen que hacer.
Por ejemplo, mi consola se enladrilló por culpa de que si el stage2.bin de Cobra está chungo, no tienes medio de saltártelo. Si yo cargara ese stage2.bin desde el Core, produciría un semibrick (no podrías entrar en Restaurar archivos y cosas así, por que entonces la cagarías, pero si podrías actualizar la consola!). Aún así, me vería obligado, por seguridad, a cargar desde USB o al menos, tratar de hacerlo desde HDD0, si se puede, con checkeo de protección (algo así como que si no puede montar el HDD0, borrara una flag en la flash, que hiciera que no pudieras cargar el stage2.bin), pero mucho mejor usar "Mamba" por que si ahí falla algo, se cuelga la consola, se reinicia y a otra cosa.
Yo nunca jamás metería una lista para lanzar plugins en el arranque, sin posibilidad de borrarla de ninguna manera, si algo falla, que puede fallar por que esté mal formada o por que algún plugin (algunos no respetan la posibilidad de ser desenchufados...) sea incompatible con algo. Es más, tengo cierta prudencia en liberar mi Core, pues lo normal es que funcione perfectamente, pero puede ser que no lo haga bajo ciertas condiciones (plugins rulando que no tenían que estar, por ejemplo). O el "bug" de Cobra (ocasionado según creo, para que funcione netiso) , que hace que sm.self solo pueda funcionar en un solo hilo y sin poder bajar las prioridades, con el perjuicio que ocasiona eso: no es casualidad que con 'Mamba' sí funcione en Multihilo, pues 'Mamba' es cargado DESPUES y no interfiere.
Con esto pretendo explicaros a todos que muchas veces, no es por ser aguafiestas, por lo no que no se hacen las cosas: puede no interesarme, o parecerme demasiado trabajo hacer algo para el poco provecho que le voy a sacar, pero muchas veces, hay otro tipo de razones relacionadas con la seguridad de hacer las cosas y la prudencia, lo que hace que prefiera no hacerlo (por ejemplo, el nuevo sm.self, va a tener por defecto, desactivado lo del "nosleep" y tendrá que activarlo Iris Manager, si vosotros queréis: es mas aconsejable hacerlo así, pese a que no he tenido ningún problema con eso. Pero vosotros no sois yo y os encanta meter otras mier... digo, cosas
y en principio, se metió esa opción para los que usáis Multiman mas que para otra cosa (la opción por defecto, escanea todos los dispositivos: menos óptimo y más problemático que fijar uno solo como hace Iris Manager, pero si Deank no adapta el método, solo podía ofrecer esa vía que ahora, la quiero dejar desactivada por defecto)
A fin de cuentas, no se trata de que yo me luzca haciendo programas, si no que mis programas sean compartidos con las máximas garantías posibles a mi alcance (sin pretender cubrir lo que hacen otros: ese no es mi problema, mi problema es que las cosas funcionen bien con lo que yo hago y que la gente pueda ver lo que hago, por medio del código fuente, por si ellos tienen que tener en cuenta algo, o a mi me pueden pedir algún cambio que proporcione compatibilidad mutua): me puedo equivocar, como todo el mundo o pueden surgir cosas que no haya previsto, pero lo que sería imperdonable, es que eso ocurriera por dejadez mía, o por estar en una absurda carrera por ser el primero en algo u ofrecer algo distinto sabiendo de sobras que eso puede ocasionar problemas y sin hacer nada para evitarlo (y eso lo hemos visto demasiadas veces en esta scene). Al menos, si surge algo, que quede el consuelo de que ha sido un fallo que se me escapa y que en mis pruebas no ha aparecido, ni me inducían a pensar que ocurriría.
Por algo en todos estos años, solo he tenido un brick (habiendo hecho hasta un CFW: funcionó a la primera y no, no fue suerte, sabía que iba a funcionar y aún así estuve en vilo hasta que me confirmaron que no daba problemas en el resto de máquinas, por que era mi responsabilidad hasta cierto punto y me preocupo más por vuestras consolas que vosotros mismos, que alegremente os lanzáis a hacer de betatesters con fe ciega
) fue precisamente, por modificar algo que no cumplía con los márgenes mínimos de seguridad que yo me autoimpongo (y cuanto me he fustigado yo, por haber cometido ese error de tocarlo, sin tener las máximas garantías de que podría recuperarlo y suponer que el de cobra no sería tan corto de miras para no prever algo tan básico... pero en el fondo, la culpa es mía por suponerlo o no estar en ese momento, suficientemente preparado para ello, aunque en el stage2.bin que compilé, básicamente, no había nada mal, que esa es otra
: el fallo viene por otro lado) y como de los errores se aprende, ahora tenemos 'Mamba' (y yo de cara al usuario, quiero mantener compatibilidad con Cobra que tenemos, pero si me puedo mantener en un CFW que me permita usar 'Mamba', ahí es donde voy a estar yo y no por que sea mi trabajo, si no por que Cobra no me da sensación de seguridad, después de lo que me pasó y creo que los que han pasado a CFW habib 4.53 con Cobra, ya han visto los problemas que se han presentado, todos ellos evitables con el uso de 'Mamba', por mucho que alguno lo pueda considerar un "retroceso" frente a un teórico CFW Cobra "completo".
Yo prefiero pájaro en mano, que ciento volando. Y nadie ha dicho que no se puedan lanzar emuladores desde ese pájaro en un caso hipotético, si no que se ha prescindido de ello por que no compensa (si me compensara y no estuviera con otras cosas, los emuladores estarían funcionando, si no ahora, mañana o pasado. O buscaría un método alternativo para arreglar el problema) y se prefiere apostar por una portabilidad más fácil que asegure ese pájaro, que es entre el 90% y el 100% de los usos que le van a dar la mayoría de los usuarios y tener un método mas seguro.
Por eso que expongo, hay cosas que se pueden hacer, pero no se hacen: no porque no se puedan, si no por que no se deberían hacer de esa manera, sobre todo si sabes que en un caso, puede ocasionar problemas serios...
Saludos
, pero yo me pillaria un DOCK de discos 3,5, y me lo llevo al pc (usb3.0), y a la play despues y problema resuelto a lo grande. Los DOCK no son caros, incluso puedes tener uno en el PC y otro en la PS3.. en 'negocio extremo' hay para escoger ![[decaio]](/images/smilies/nuevos2/decaido.gif "decaido")
.![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
, con eso del core Estwald, si funciona en todos los CFW, sera como una luz para los demás CFW y la gran mayoría de ps3 van estar mas que feliz. 
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
). Solo la falsa ISO de los juegos en ficheros sueltos y las ISOS de PS2 (en 4.46) van por el método antiguo de Cobra
![[tadoramo]](/images/smilies/adora.gif "Adorando")
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
![[bye]](/images/smilies/nuevos2/adio.gif "adios")