new_core (v1.2): sm.self desde PSL1GHT y abierto a todos los CFW

Estwald escribió:Creo que ya se cual es el problema con Rebug: peta el sm.self, seguramente, por que no deshabilitan la protección de LV2...

Efectivamente, era ESO: los de rebug no deshabilitan la protección de LV2 de serie, usad este sm.self que adjunto (en breve, actualizaré el post principal, pero solo tenéis que instalar este sm.self que adjunto, que añade soporte para esas versiones de Rebug que añado)

PD: Mola estar en una versión de CFW donde gracias a 'Mamba' hay ISOs y con el sm.self rulando

nascar escribió:Muchas Gracias Sing, yo uso el de Estwald y se nota que los ventiladores hacen un pelin mas de ruido, A ver si con este tuyo me aclaro y lo se instalar asi lo pruebo. (Si quieres puedes subir el sm para poder catarlo).

Saludos y feliz año 2014 .

plasticos201193 escribió:Pues yo instale Habib 4.46 Cobra, enseguida puse el Core con mi SM modificado y funciona excelente.

Despues de eso quise probar el WebMan de Deank y Pum! reinicio la consola y se queda en las ondas del XMB, supongo que hay alguna incompatibilidad entre el SM y el plugin de Webman, pero obviamente prefiero tener rulando el SM que el webman.

Si alguien quiere probar y verificar la incopatibilidad lo que hice fue:
1.-Instalar Habib 4.46 y el Core de Estwald.
2.-Copiar el archivo webftserver.sprx y bootplugins.txt a la raiz del disco duro.
3.-Copiar el category_game.xml a la ruta de la flash del PS3.
4.-Cambiar la opcion del navegador web a "confirmar salida:NO"
5.-Reinicio y Congelada en el XMB

abufa escribió:hi:

I think this will not be possible, because they use different philosophies of work:

Estwald is open source
Deank is closed source

Although it would be ideal to work together but it's hard work with a person who does not share code.

a greeting

pd: sorry for my English

RudiRastelli escribió:

abufa escribió:hi:

I think this will not be possible, because they use different philosophies of work:

Estwald is open source
Deank is closed source

Although it would be ideal to work together but it's hard work with a person who does not share code.

a greeting

pd: sorry for my English

You are right with multiMAN... it's still closed source.
But webMAN is open source !... Take a look at http://www.deanbg.com/webMAN_1.27.zip

Regards
Rudi

Tothelimit escribió:Tengo una pregunta, estoy en Habib 4.53 cobra y tenía instalado el Control fan utility 2.02, de forma que cada vez que encendía la ps3 lo ejecutaba y lo ponía en manual al 0x60.

Acabo de instalar el instal_core.pkg y funciona todo bien. Mi duda es para configurar la velocidad del ventilador de forma que sea todo automático y no tenga que entrar al control fan utility cada vez que arranque la ps3 qué tengo que hacer?

Gracias!

RudiRastelli escribió:

plasticos201193 escribió:Pues yo instale Habib 4.46 Cobra, enseguida puse el Core con mi SM modificado y funciona excelente.

Despues de eso quise probar el WebMan de Deank y Pum! reinicio la consola y se queda en las ondas del XMB, supongo que hay alguna incompatibilidad entre el SM y el plugin de Webman, pero obviamente prefiero tener rulando el SM que el webman.

Si alguien quiere probar y verificar la incopatibilidad lo que hice fue:
1.-Instalar Habib 4.46 y el Core de Estwald.
2.-Copiar el archivo webftserver.sprx y bootplugins.txt a la raiz del disco duro.
3.-Copiar el category_game.xml a la ruta de la flash del PS3.
4.-Cambiar la opcion del navegador web a "confirmar salida:NO"
5.-Reinicio y Congelada en el XMB

Hi !

I'd experimented with MLT's CORE + SM + webMAN a while ago and first ended up with these waves not booting completly into XMB. Same as you.
But i figured out that, while PS3 stucks with these waves, i have access to webMANs settings via pc-browser. I disabled USB-scan and LAN-scan in webMANs settings, save settings, restart PS3 (all via pc-browser) and then PS3 boots to XMB and SM + webMAN works at least with games on the internal drive.
Didn't try that with the new core yet.

My wish is that talented developers like @Estwald, @deank and @habib should work together, because CORE+SM, webMAN and Cobra are big steps forward in PS3 development leading the way to the future (from my point of view) and should work together without a problem.

My guess is that the days of Iris or multiMAN as game managers are counted. But don't get me wrong... they will be still useful for their additional functions.
It also gives my wonders that no one else so far adapted the concept behind webMAN for mounting games.
Now... go ahead and throw stones at me because of these last words ... i'll go to cover

Regards
Rudi

PS: Forgive me i can't write in spanish language, but i'm german and so either spanish nor english is my native language. But i guess writing in german would'nt help anyone here so i decided to choose english.

Aracnoid escribió:¿Alguien tiene un sm.self hecho que le meta un poco más de caña al ventilador?

El de Estwald va bien y me mantien mi ps3 a unos 60ºC, pero desearía que bajase un poco más, hasta los 40-45 más o menos.

Gracias

YONAN23 escribió:En mi opinión y no es que valga de mucho creo que si todo carga bien desde Iris que se quede en Iris, es tú sello, sello por el cual nos has traido a otro nivel de la scene. Quien quiera una aplicación externa a Iris que se moje y tú descansa que bastante camino has abierto. Toca descansar y que otro Iluminado (que no seré yo porque no teengo los conocimientos necesarios)
saque algo. Por mi parte con la carga de isos en ntfs te has ganado un 10.
Es mi opinión, así que si descansas un poco despues de todo no creo que se acabe el mundo.

ERMaCDR escribió:Lo de Rebug es que siempre hay que habilitar LV2 Memory Protection Patch desde el Rebug Toolbox en cada reinicio de la PS3.

ERMaCDR escribió:Con respecto a que quieres que el usuario tenga la posibilidad de recuperar el control sin correr muchos riesgos, pero durante mucho tiempo ha hecho bastante y eso está entre tus posibilidades de si se puede o no. Me gusta la idea de que quieres abrir el paso hacia otras aplicaciones, pero si se complica no te enredes la cabeza.

ERMaCDR escribió:Por cierto Deank eliminó tu payload de fan control en webMAN y según él todos deberían estar agradecidos contigo de poder controlar el ventilador de PS3 de la manera que queramos. El motivo para retirar el payload no es porque es malo o cause problemas, sino porque fue creado hace meses, cuando no había otra manera de ejecutar programas residentes, debido a la forma en que el método original de control de ventiladores opera (interceptando gran parte de los sysevents “eventos del sistema”/ communication “comunicación”) la PS3 tiene que trabajar más para casi ninguna razón, lo que da lugar a altas temperaturas de la CPU. Ahora según él, después de haber hecho las cosas más simples (verificar la temperatura, ajustar la velocidad del ventilador) el sistema de PS3 es menos estresado y las temperaturas son más bajas.

PLIS-PLAS escribió:Vas a tener que hacer tu propio cfw, ya lo sabes.

Estwald escribió:El caso es que el core en mi opinión, deber cumplir una función protectora, además de proporcionar servicios, por que a ese nivel, es cierto que en principio se puede recuperar la consola actualizando, pero también puedes entrar en bucle si accedes a las utilidades de disco con un brick a ese nivel (a mi me pasó una vez) del que solo se sale cambiando el HDD o formateando el que tienes (por suerte, yo tenía el HDD original y fue cosa de actualizar un par de veces )

Además, actualizar tiene sus peligros... en mi caso, con un SAI de respaldo, no es mucho problema que se vaya la luz en el proceso, pero coño, me parece que los usuarios merecen que pensemos un poco las cosas en ese sentido (como usuario que tuvo la consola brickeada por el simple motivo de que no podía borrar o renombrar un puñetero fichero en /dev_flash, entiendo perfectamente el problema y como desarrollador intento evitar que eso vuelva a pasar y dotar a otros desarrolladores de vías alternativas para que nadie tenga que volver a pasar por eso... incluso si la probabilidad de que ocurra sea mínima: un stage2.bin lanzado desde el Core, sin flags que lo controlen, es más seguro y recuperable que lanzarlo desde el punto actual, desde donde lo lanza Cobra)

Saludos

Mejorada la estabilidad del sistema

changelog:
1.ps2 for semi-bc ps3 working as per user by using this method:
--1-Start ps3 with the controller via usb.
--2-Launch ps2 iso.
--3-The game starts and the controller loses the sync but i'm able to resync it.
although its been said its buggy and sometimes games launch and sometime not..

2.ps2 for non-bc ps3
3.not tested ps2 support for bc console
4.used estwalds new core edited by me,check below for changelog....

NOTE:
ps2 will have controller synch if used modded emu(see below)

CORE:
in this cfw i have by default added original ps2_emus for ps3 so that if you are disturbed with controller sync problem,you can use original emu for ps2.to enable/disable modded ps2 emu,use ps2 flag ive created.put a 0 byte file named "ps2" in usb/core_flags/ .then put the usb in the rightest port of ps3 and turn ps3 on,if everything goes right,the ps3 should restart and flag ps2 will rename to _ps2
if ps2 emu for bc or semi-bc console doesnt work or you see them buggy,use ps2 flag and swap back to original emu....

Caos1 escribió:Buenas, tengo algunas dudas y una petición

-¿La configuración del ventilador de este sm.self se activa al encender la ps3 o hay que iniciar el iris m. para ello?

-¿Cual es la configuración de temperaturas y rangos de este archivo?

-¿El payload del antiguo iris m. o del control fan utility es "compatible" con esta modificación y se puede cargar? supongo que si pero prefiero asegurarme.

Y ahora la petición:

-¿Seria mucho pedir la creación de alguna herramienta ejecutable en pc que te cree/modifique la configuración del ventilador de el sm.self de forma sencilla para los que no nos atrevemos/sabemos crearnos el archivo (que supongo se hace compilandolo)?

Gracias

Estwald escribió:Subido sm.self compatible con CFW 4.55

Saludos

Estwald escribió:Antes de nada, esto en teoría, puede trabajar con los CFW3.41, 3.55, 4.21. 4.30. 4.31, 4.40, 4.46, 4.50, 4.53 y 4.55 CEX, así como está. En principio, el core no hace nada que invite a pensar de que es incompatible con otros CFW, pero solo ha sido probado en 4.46 y 4.53 CEX y además,el sm.self solo está preparado para los CFW que menciono (no conozco los parches o los tocs de otros CFW). En todo caso, yo no me hago responsable de enladrillamiento alguno: en teoría, si esto no va, se puede entrar en modo recovery y actualizar (si os pasa eso, ni se os ocurra restaurar nada, ya que las herramientas de disco, etc, pasarían por ésta aplicación). Pero lo mejor sería que alguno que disponga de flasher lo pruebe primero en un CFW de los no probados (4.46 y 4.53 y si estás en estos, pero una aplicación externa peta, a mi no me pidáis cuentas, pecadores ) y luego reporte si va o no va, por precaución.

¿Que es lo que hace el nuevo core?. En principio, su utilidad es simplemente, lanzar sm.self, instalarlo y poder actualizarlo y actualizar el core. He procurado tener especial cuidado en el proceso de instalación os exponga el menor tiempo posible a un posible semibrick (por ejemplo, la actualización del core, es decir, de sys_init_osd.self, se hace en base renombrar rápidamente los ficheros en el momento oportuno, sin que haya riesgo alguno hasta ese momento). Más adelante, podrían implementarse otras funciones del Core de MiralaTijera, si este aparece y no le parece mal (de momento, está con las funciones mínimas). Aparte de eso, en su modo normal trabaja en segundo plano con la carga de VSH.SELF por lo que no se desincronizan los mandos, pero SI puede responder a las distintas flags, cosa que no ocurría con el "nosearch" de MiralaTijera.

¿Por qué un core ahora?. Hace tiempo, MiralaTijera me pasó el código fuente de su core, para que lo viera y portarlo hacia PSL1GHT y hacerlo open source (lleva meses con esa idea). En ese momento yo estaba en otras cosas y tampoco tenía forma segura para trabajar en ello. Además, lo suyo es que lo hiciera el . Más adelante me pasó el export que es la base y la razón de este nuevo core, para que lo añadiera en Iris Manager (y así que todo el mundo lo pudiera disfrutar). Lamentablemente, el uso de ese export solo funcionaba bien desde el core, por lo que solo los CFW MiralaTijera que incluyen el método, se beneficiaban del sm.self a pesar de ser una aplicación open source (por cierto, a mi nadie me ha preguntado nunca nada, sobre este tema )

Como ahora tengo un método más seguro de probarlo, he decidido matar dos pájaros de un tiro: por un lado, proporcionar un core básico que permita la carga de sm.self y otras cosas que les pueda interesar a otros desarrolladores en los CFW que no lo soportan y por otro, proporcionar una base para que MiralaTijera (cuando aparezca, que está desaparecido en combate desde que se ha mudado de casa ) pueda hacer open source el resto de cosas que soporta su core (yo solo he metido lo básico y lo que creo que podía hacer sin interferir en su trabajo ) o que otros hagan lo que les de la gana (yo de momento, no voy a hacer nada más salvo que surjan ideas nuevas para el core)

No tengo lector: ¿Puedo usar este core?

No, ya que no soporta "bdemu". Si estás en CFW MiralaTijera, usa su core (y no metas este!)

Tengo core de MiralaTijera, ¿debería meter el tuyo?

Depende: si no necesitas bdemu, ni ninguna función especial del core de MiralaTijera y lo único que te interesa es el sm.self, este lo carga igual, como si tuviera la flag "nosearch" (no se le va la olla a los mandos) pero SI explora el dispositivo USB en busca de flags en segundo plano, si no activas "boot_on" (en ese caso, trabajaría con el de MiralaTijera: antes de VSH.SELF)

Lo que si tienes que saber es que en ese caso, NO debes renombrar el sys_init_osdxxxx.self como sys_init_osd_orig.self

¿Como funciona el core?

El core (new_core.self) reemplaza sys_init_osd.self (que está en /dev_flash/sys/internal).

la verdad es que no se cual es la función exacta de éste ejecutable, pero parece que todo funciona si te lo saltas y cargas vsh.self directamente (Es como lo hace MiralaTijera ). Aún así, he previsto que desde el Core, se pueda lanzar sys_init_osd_orig.self si existe (si quieres usar el original, tendrás que copiarlo tu ahí con ese nombre, por ejemplo, montando /dev_rewrite desde Iris Manager y procediendo a copiarlo). En caso contrario, usaría vsh.self y si este no carga, opcionalmente puede cargar emergency.self montando dev_usb000 para arreglar el desaguisado (se supone que sería una aplicación externa con capacidad de restaurar archivos)

La característica principal de este core, es que puede trabajar en segundo con vsh.self para hacer las cosas y así los mandos no se desincronizan. Con la flag "install2" puedes instalar el sm.self o el new_core.self (una actualización) de esa manera y luego reiniciar para aplicar los cambios.

Para trabajar como el core de MiralaTijera, que hace las cosas antes de cargar vsh.self tenemos dos maneras: una temporal, que sería con la flag "install" que escribe una flag temporalmente en /dev_flash, para que instale las actualizaciones sin que vsh.self pueda interferir de alguna manera y la otra permanente, activando "boot_on", que deja escrita una flag en /dev_flash para saber que tiene que proceder de esa manera.

En principio, yo no he tenido problemas en usar "install2" para actualizar y en parte todo éste mecanismo es por seguridad y en parte para señalar como pueden trabajar futuras flags antes/después de la carga de VSH.SELF

Sobre las flags

Para hacer la aplicación he tomado notas de una serie de inconvenientes que en mi opinión, tiene el core de MiralaTijera. Por ejemplo, a mi me asusta que si metes un fichero en raíz de /dev_usb000, se instale automáticamente al arrancar, pudiendo ocasionar un problema, por un olvido.

Por ese motivo, se han añadido las flags "install" e "install2" (esta es la que verdaderamente instala las cosas). Sin dichas flags, ignorará los ficheros y además, el nuevo core renombra las flags anteponiendo el carácter '_' al usarlas. También hace lo mismo con sm.self o con new_core.self, después de instalarlos, pasando a llamarse _sm.self y _new_core.self respectivamente.

El objetivo de esto es reducir al mínimo el riesgo de instalaciones erróneas y al mismo tiempo, conservar copia de todo y poder activar las flags y las aplicaciones con solo borrar desde el Archive Manager de Iris Manager, por ejemplo, el carácter añadido.

Para evitar interferencias con las flags de MiralaTijera, se utiliza la carpeta "core_flags" en lugar de "flags". Así mismo, las aplicaciones a instalar deben estar en "core_install", en raíz del dispositivo USB que vayamos a usar (es preferible que sea una pendrive, porque se inician más rápidamente). De esta forma quitamos "basura" del directorio raíz, evitamos riesgos y queda mas clara la función de las carpetas y lo que hay dentro.

El core puede generar tres tipos de logs en /dev_usb000: emergency_log.txt solo ocurriría si no pudiera cargar vsh.self por algún motivo, install_log.txt se crea cuando se instalan ficheros con install/install2 y core_log.txt es el log normal. En principio, el core, evita generar logs en /dev_usb000 salvo en los casos importantes (install/emergency) o que añadamos la flag "verbose". Esto es así por que por lo general, los logs no son importantes y los dispositivos flash tienen ciclos de escritura limitados.

Por cierto, existe una posibilidad de usar sm.self de forma externa: consiste en copiar "sm.self" como "sm_external.self " en raíz de /dev_usb000. Lógicamente, requiere que no esté activo "ignoresm" y la presencia del dispositivo /dev_usb000, pero es otra posibilidad más para el desarrollador o para ejecutar otras cosas en segundo plano.

Este es un resumen de las flags actuales:

boot_on : habilita que el core trabaje antes de cargar VSH.SELF (como el de MiralaTijera)

boot_off : hace que el core vuelva a trabajar en segundo plano con VSH.SELF (a mi estilo )

install : procede a instalar ficheros antes de cargar VSH.SELF (forma mas segura)

install2 : procede a instalar ficheros en segundo plano con VSH.SELF

removesm : borra sm.self de /dev_flash

ignoresm : ignora la carga de sm.self (puede servir de test, si sm.self provoca un cuelgue o algo o simplemente, para saltárselo, sin necesidad de borrarlo)

verbose : activa el log completo.

¿Y como instalamos tu nuevo Core?

En el RAR adjunto un PKG: copia "install_core.pkg", "core_flags" y "core_install" en raíz de una pendrive, lo introduces en /dev_usb000 (el puerto USB mas cercano al lector), instala el PKG y lo ejecutas (New Core Installer)

Si el sistema reinicia, es que todo ha ido bien y habrá copiado el new_core.self que lleva dentro como sys_init_osd.self y el antiguo lo habrá renombrado como sys_init_osd_old.self
(si no estas en CFW MiralaTijera con Core, si quieres, puedes renombrar sys_init_osd_old.self como sys_init_osd_orig.self. Si en el futuro actualizas el Core, esa copia se borrará, ojo)

Al reiniciar cargará el XMB y se producirá un nuevo reinicio (ya que acabáis de instalar sm.self con "install2" y el core fuerza ese reinicio)

Si queréis, podéis desinstalar el "New Core Installer": los futuros updates, se harán desde la carpeta "core_install". El PKG es solamente para realizar la primera vez la instalación del core, de la forma más segura posible para vosotros y en un tiempo mínimo:

Código fuente de todo el proyecto (new_core, install_core y sm):

https://github.com/Estwald/new_core

Descarga (binarios):

http://mods.elotrolado.net/~hermes/ps3/ ... e_v1.2.rar

v1.2: añadido soporte en sm.self para CEX 4.55
v1.1: añadido soporte en sm.self para Rebug CEX 4.21, 4.30 y 4.46

Aracnoid escribió:Buenos dias a tod@s, mi pregunta es para Estwald en especial o para cualquier usuario q sepa la respuesta. Vereis, uso en mi PS3 un disco externo sin alimentacion externa, y tiende a "dormirse" cada cierto poco espacio de tiempo, me consta q tambien sucede con hdd's externos con alimetación. Mi pregunta és: ¿Podria instalar la flag de miralatijera "nosleep" en este core? si no tengo mal entendido esto haría q el disco no se durmiese y no tendria los fallos q me da al jugar por ejemplo al MGS4. No he usado nunca ningún CFW de miralatijera, así q no estoy muy familiarizado con esto del core, ahora lo tengo el de Estwald en habib 4.46 cobra con el sm y va de lujo.

Saludos y gracias por el currazo q os pegais algunos.