[UTILIDAD] Control Fan Utility v1.7 (CFW 3.41, 3.55, 4.21, 4.30, 4.31, 4.40 y 4.41)

Instalación, fabricación o programación de chips, jailbreaks, custom firmwares, etc.
Estwald
MegaAdicto!!!
4.321 mensajes
desde abr 2011

Antes de nada, abro éste hilo aquí por tratarse de una modificación de firmware muy concreta (que trabaja sobre CFW CEX 3.41, 3.55, 4.21, 4.30, 4.31 y 4.40), destinada principalmente a trabajar bajo el entorno de los juegos. No se trata de un simple ajuste de la velocidad del ventilador, si no de un payload que cumple su cometido regulando la velocidad del ventilador en función de las temperaturas del sistema, para tratar de evitar un sobrecalentamiento excesivo en lo posible. Por esa razón lo abro aquí y no en Scene, donde también podría tener cabida..

El hilo tendrá dos cometidos: por un lado, el exponer el desarrollo, investigación y los aportes propios o que hagáis vosotros y por otro lado, la parte práctica para quienes solo quieren usar la utilidad.

Empecemos pues por la parte del desarrollo (si a alguien no le interesa, que salte a "La Aaplicación Control Fan")

El Desarrollo: Investigación y Descripción

Cómo ya comenté en otro hilo, existe una syscall llamada sys_sm_set_fan_policy() que permite controlar el ventilado. En concreto, descubrí que tiene al menos, 3 modos de operación que se resumen en:

sys_sm_set_fan_policy(0, 0, 0); // ventilador a toda potencia (velocidad 0xff)

sys_sm_set_fan_policy(0, 1, x) ; // ventilador controlado por el SYSCON (la x no parece usarse de forma directa o es ignorada por que se autoajuste, pero puede que influya cuando se reinicia/apaga el sistema)

sys_sm_set_fan_policy(0, 2, x) ; // ventilador controlado de forma manual.

Este último modo, el 2, es el que nos interesa a nosotros: la x se mueve en el rango de 0x33 (un valor menor se puede escribir, pero se corrige automáticamente en el SYSCON) a 0xFF, que sería la máxima potencia. Este modo tiene sus peligros, si no se maneja debidamente, ya que por ejemplo, si ajustamos 0x33, la velocidad es insuficiente y la temperatura alcanzará temperaturas muy peligrosas. Así que ojo con esto.

Según parece, cuando se reinicia el sistema, el SYSCON cambia a Modo 1 pero al apagarse la consola (piloto rojo) el Modo sigue siendo 2 pero el SYSCON fija el valor a 0x4D, cómo medida de seguridad, seguramente, pues con este valor la consola mantiene niveles aceptables de refrigeración.

De hecho el SYSCON utiliza valores mucho más bajos, usualmente. Que yo haya visto, empieza con el mínimo 0x33, luego sube a 0x40, 0x44, 0x48 y rara vez sube de ahí, por que al SYSCON manejarse en el rango de 70º a 75º en las FAT (al menos en la mía), le parece aceptable y prefiere menos ruido y mayor temperatura, cuando a nosotros nos puede interesar lo contrario.

Todo esto se puede ver mediante la syscall sys_sm_get_fan_policy() que cuenta con cinco parámetros que yo los he llamado así:

int sys_sm_get_fan_policy(u8 id, u8 *st, u8 *mode, u8 *speed, u8 *unknown)


- id es 0

- st y mode: reflejan el modo actual

- speed: como su nombre indica, refleja el valor x de velocidad que ajustamos nosotros o el SYSCON, dependiendo del modo.

- unknown: que yo haya visto (y vosotros mediante la presente aplicación) siempre es 0: ignoro si tiene un uso concreto.

Esta syscall la utilizo únicamente con fines informativos en la utilidad, pero el payload no hace uso de ella.

Una vez que podemos regular la velocidad del ventilador, lo siguiente, pero no menos importante, es conocer la temperatura que queremos regular.

Para ello, tenemos la syscall sys_game_get_temperature() que recibe como primer parámetro 0 si queremos medir la temperatura de la CPU y 1, para el RSX, mientras que el segundo parámetro es una variable que almacenará el valor de temperatura.

Por último, aunque de forma decorativa, hacemos uso de la syscall sys_set_leds() la cual nos permite poner los leds en el estado que queramos.

El problema de éstas syscalls es que requieren un tipo de permiso que nuestras aplicaciones y sobre todo los juegos, no suelen tener: algunas requieren flags PM cómo las relacionadas con el ventilador y otras permisos ROOT. Así que no queda más remedio que desactivar esos chequeos mediante "pokes" como éste:

// enables sys_game_get_temperature
lv2poke32(0x800000000000C694ULL, 0x38600000);


y esa es la razón por la que la utilidad está limitada a esos CFW: faltan los parches necesarios para los otros XD.

Bien, con todo lo dicho hasta ahora, se puede montar una aplicación que ajuste los modos a nuestro antojo, lo cual puede estar bien si solo se pretende ajustar el ventilador a una velocidad fija y ya está (al estilo de los que hacéis el mod del potenciómetro), pero si se pretende algo más "regulable" entonces la cosa se complica, por que requiere que nuestro código esté funcionando a nivel de sistema y eso requiere, por la vía elegida, hacer un payload y pinchar algunas syscalls.

El Payload

¿Y que debe de hacer el payload?. Pues en principio, debe tomar muestras de temperatura, ajustar la velocidad del ventilador, si procede y luego avisarnos de alguna manera (mediante LEDS) si la temperatura está dentro de unos parámetros y tal.

Así dicho suena muy fácil, pero ¿como hacemos todo esto y cómo averiguamos que syscalls pinchar?

Inicialmente, yo opté por pinchar la syscall usleep() pero esa opción no resultó ser buena al final y tuve que recurrir a otra, que es la que voy a describir a continuación (y prestadle atención, que es importante XD)

Antes de nada, conviene saber varias cosas o al menos, es lo que yo se (si alguien sabe otras cosas, que nos lo cuente)

- Las aplicaciones corren en modo usuario y cuando llamas a la syscalls, entras en modo supervisor, kernel, LV2 o llámalo como más te guste.

- Las aplicaciones usan memoria virtual, por lo que no podemos estar seguro si un determinado bloque de memoria está mapeado o lo que es peor, que permita escrituras.

- Cualquier intento de pasar memoria de LV2 cómo variable, retornará con error o simplemente... no retornará

- Dentro de LV2, sólo conocemos esto cuando una determinada syscall, utiliza variables entre sus parámetros. Lo cual tiene sus problemas, si las que necesitamos utilizar sólo reciben valores, pero ninguna dirección de memoria aprovechable. Por lo que necesitamos adquirir dicha información de forma indirecta y eso es un embrollo XD .

- Obviamente, si obtenemos un área de memoria que podamos "modificar" tenemos que asegurarnos que la modificación no afecta, o que de cara a la aplicación, lo datos no se hayan modificados (es decir: preservar los valores)

- Pues bien, nuestra syscall de medir la temperatura, requiere una puta variable XD y eso plantea éstas dificultades.

- Por otro lado, dentro de LV2 es posible llamar a ciertas syscalls o mas concretamente, a las funciones que manejan dichas syscalls, pero hay otras que no se puede (por ejemplo, las de acceso a fichero bloquean el sistema, si por ejemplo, haces un open y luego un read, sin salir a modo usuario)

Con todos estos problemas, encima necesitamos una syscall que se llame con regularidad para poder hacer nuestras lecturas/ajustes y tuve que descartar usleep().

La "salvación" vino en forma de eventos: los eventos del sistema nos permiten, cómo su nombre indica, recibir sucesos dentro del sistema, recibiendo una serie de datos.

La syscall sysEventQueueReceive() es la encargada de recibirlos y además, nos proporciona una variable que podemos utilizar para la medida de temperatura. La syscall en su último parámetro especifica el tiempo en microsegundos durante el cual esperará un evento (0 indica infinito).

Una cosa a tener en cuenta es que ésta syscall recibe TODOS los eventos que se producen vía aplicaciones y es bien posible que mientras estemos procesando uno, se reciba OTRO evento, si nos demoramos en nuestras tareas, por lo que conviene proteger contra ellos.

De hecho, la toma de temperatura requiere entre 7ms y 20ms y volví a encontrarme con problemas, debido a que se sobrepasaba la velocidad de respuesta. en un determinado momento, produciéndose un bloqueo.

Así que cambié de estrategia e intenté averiguar donde se generaban los eventos para que si se debía producir demora, fuese allí y no en el receptor. A todo esto, tengo que decir que ni siquiera conozco de primera mano QUIEN, DONDE Y PORQUE genera los eventos: simplemente, se que algo genera eventos en cadencia suficiente para permitirme hacer mis lecturas y que la naturaleza de esos eventos se producen en el XMB, en los juegos, en el emulador de PSX y en el de PSP. En PS2, al menos en la retrocompatibilidad por hardware de mi PS2 se que no, por que el LV2 que conocemos desaparece y con ello, mi payload

Existen varias formas de producir eventos, pero la más accesible, son los EventPort.

Pinchándolo pude ver que efectivamente, es el origen de las llamadas. La syscall sysEventPortSend() envía en los registros la siguiente información

sysEventPortSend(sys_event_port_t portId,u64 data0,u64 data1,u64 data2)


Cómo vemos, ninguna variable, solo datos, con lo cual, seguimos necesitando el concurso de sysEventQueueReceive() para recibir una variable que podamos modificar.

El problema es que la modificación la debemos hacer en el llamante y no en el llamado, que es el que recibe la variable del programa. Es decir, que necesitamos la gallina para poner el huevo, pero no hay gallina hasta que nazca del huevo [sonrisa]

Para saltar ese obstáculo, recurrí al PID: si conocemos el process ID, podemos comparar, si el envío y la recepción están en el mismo proceso y podemos por tanto, pasar la gallina al huevo, desde la propia gallina [+risas] . O para no liar el asunto, pasar la variable de sysEventQueueReceive() para que la usen nuestros procedimientos en sysEventPortSend() (tambien es necesario por que en principio, no sabemos si el EventPort tendía cómo destinatario ESE QueueReceive, debido a que se relaciona de forma indirecta con el evento!)

Perfecto, hecho eso, mediante unas comprobaciones de seguridad de los respectivos PIDs, podemos asegurar que "mem_app" (en el payload) contiene una dirección de memoria para escritura que podemos usar.

Una vez que cerramos el circuito y vemos que funciona, nos interesa intentar discriminar para encontrar los eventos que nos resultan útiles y descartas otros que no lo son y solo pueden acarrear problemas. Haciendo varias pruebas, resulta que se que la recepción del evento no es bloqueable (o sea, que tiene un tiempo límite) y que el evento que se genera y recibe, útil, tiene todos los datos a 0 (por lo general, un evento contiene una serie de datos con información útil y necesaria para los programas. Por ejemplo, los eventos relacionados con los dispositivos, reciben el tipo de dispositivo en data2).

Ahora necesitamos hacer dos cosas: si nuestros eventos tienen una caducidad y una capacidad de respuesta corta, por un lado, necesitamos una base de tiempo para saber cada cuanto tiempo leer la temperatura, etc, sin lastrar al sistema y también necesitamos dividir las tareas a realizar para que cumplan su cometido sin lastrar al sistema.

Después de éxitos y penurias, al final, de base de tiempo utilizo un registro del procesador (nota: suponía que tenía que haber uno con ese cometido, pero ni idea de como se usaba en CELL [+risas] ) que cuenta los ticks desde el arranque del sistema (con eso podemos conocer cuanto tiempo lleva la consola encendida XD. De hecho, en la utilidad muestro esa información como "PS3 Start Time")

La base de tiempo que utiliza, ni idea [+risas] . Lo que hice al final, es hacer un par de bucles combinados con el reloj de tiempo real para primero sincronizar y luego tomar una lectura durante 60 segundos, con la cual obtener los ticks por segundo que se generan. La cifra: 0x4c1a6bd o 79799997 como gustéis. Tampoco se necesita una precisión del copón, solo algo que que cuente el tiempo de forma razonable [+risas]

Si alguien tiene curiosidad en saber como se obtiene los ticks, ésta es la función:

Código: Seleccionar todo
static inline u64 get_ticks(void)
{
    u64 ticks;
    asm volatile("mftb %0" : "=r" (ticks));
    return ticks;
}


Se supone que en un punto puede dar cero y que habría que entrar en bucle hasta obtener una lectura válida. De hecho, en el payload se hace así:

get_ticks:
mftb %r4 // get tick counter 1s = 79799997 ticks aprox
cmpldi %r4, 0
beq get_ticks
srdi %r4, %r4, 12 // ticks/4096 0 => 1s 0x4C1A ticks aprox



En este caso, utilizo un desplazamiento de 12 bits desde la derecha para obtener un número de ticks con el que comparar de forma "razonable" desde ensamblador

Al final, la rutina trabaja así:

- Se dividen las tareas a realizar de forma que primero, se hace una lectura de temperatura que se va alternando entre CPU y RSX. Esta tarea requiere mucho tiempo en términos de eventos por lo que es importante dividirla

- Cómo segunda tarea está mirar si se necesita corregir la temperatura y ajustar los leds (cosa que la mayor parte del tiempo, no se necesita)

- El temporizador se ajusta para que responda cada 1,5 segundos. Es decir, el proceso de medir la temperatura de la CPU y hacer ajustes, lleva 3 segundo y otros tantos para el RSX, por lo que el total, se de 6 segundos, que es una buena cifra.

- Esta temporización puede ser saltada si el tiempo expiró pero no se pudo producir lectura de temperatura por que no coinciden los PIDS o mem_app está a cero.

- Los PIDs se suelen ajustar a cero en ciertos momentos después de su uso para prevenir problemas (recordad que hablamos de syscalls que se usan por TODO el sistema y tenemos casos donde huevo da lugar a gallina y gallina da lugar a huevo y a veces, la gallina muere y el huevo cuando nace, se equivoca de madre y la lía [+risas] )

- Un detalle MUY importante que no he mencionado, es que para evitar una serie de problemas, me veo obligado a mandar ANTES el evento (o sea, dejar pasar la syscall) que las acciones que estoy realizando por lo que no puedo estar seguro si el sistema, que recordemos que soporta dos hilos por hardware y tal, pueda estar recepcionando el evento mientras uno se piensa que hasta que no salga de la syscall no ocurre nada. Este tipo de pensamientos "monotarea" en el que solemos incurrir, puede hacer que nos roben la cartera y ni siquiera nos hayamos enterado. Por ello, intento cubrirme con el flag "in_use" tambien de forma que se ignoren las llamadas que puedan ser problemáticas (de hecho, ya ignoramos muchas por el uso del contador de ticks)

A grandes líneas, este es el funcionamiento, los problemas que uno se encuentra y como resolverlos sobre la marcha: no tiene por qué ser el enfoque más correcto o incorrecto, si no que simplemente, es cómo yo he resuelto el problema y curiosamente, no en base a lo que sabía, si no en base a lo que no se y voy descubriendo por mi cuenta.

Uso Del Payload

Una característica del payload es que permite ser ubicado en cualquier parte del sistema: se ha elegido la dirección 0xF70 de LV2 (recordad que hay que añadir un 0x80....000 para formar la dirección de 64 bits) pero podría alojarse en cualquier otra parte (usando el método write_htab() que se incluye en los fuente Iris Manager, podemos habilitar la ejecución de las partes prohibidas de LV2) y es compatible con cualquier CFW teóricamente.

Como ya he comentado antes, los parches para habilitar las syscalls que requieren permisos, son la razón por la que la que esto se presenta para CFW 4.31 y 4.40 .

De hecho, solo he testeado en 4.40 por lo que espero no haber metido la pata con los partes para 4.31 XD

En la aplicación, la función load_ps3_controlfan_payload() carga el payload uniendo las diferentes syscalls (el loop y los sleeps son para "garantizar" que el payload se carga bien)

El inicio del payload contiene la ID 'PFAN' (0x5046414E) en los primeros 4 bytes. Los 4 bytes siguientes, contienen en el offset dentro del payload (bajo este punto de vista, el payload comienza en 0) donde encontrar los datos fan_control.

Todos los datos que menciono a continuación son de 32 bits:

En fan_control - 8 bytes podemos cambiar el comparador actual de velocidad (esto solo es útil si deshabilitas el payload y lo quieres volver a habilitar, provocando que se actualice).

En fan_control - 4 podemos deshabilitar o habilitar el payload: 0- >deshabilita, 1- habilita sin leds y 2 - con leds

En fan_control + 0 podemos ajustar la velocidad que se fijará si se llama a la syscall sys_sm_shutdown() para algo que no sea un Reset o Apagado normal (por ejemplo, cuando se activa el emulador de PS2 en la consolas retrocompatibles, al menos). Se supone que con 0x5F la velocidad es suficiente (de hecho, alta) para evitar problemas, pero claro, todo dependerá de la temperatura ambiente y de lo que se caliente vuestra PS3 [+risas]

Dicha syscall es intervenida para que en caso contrario, fije el Modo 1, con la idea de dotaros de algo de protección adicional si no se vuelve a activar la aplicación (si en ese caso, está en Modo 2, carecerá de regulación y dependerá de lo suficiente que sea la velocidad 0x4D)

A partir de fan_control + 4 (inclusive) está la tabla de velocidades que se relacionan con las temperaturas de temp_control0 a temp_control4

Las temperaturas (todas en ºC) temp_control0 a temp_control1 conforman un abanico en el que se tiene en cuenta si la temperatura partía por debajo de temp_control0 y va subiendo o se está bajando desde temp_control1 (si se está calentando, la velocidad es menor que si está viendo la necesidad de enfriar)

temp_control2 supone un cambio de marcha, mientras que temp_control3 supone el punto de inflexión. En el caso por defecto de 70º el led parpadeará en amarillo/verde si la temperatura es mayor o igual de 70º

temp_control4 representa la temperatura de la alarma: en ese caso, el led parpadeará en modo "discoteca" (amarillo, rojo y verde) y la velocidad se ha ajustado en 0xA0, que es ruidos y enfría bastante [+risas]

Un detalle importante cada 11-12 segundos o así, el led se ilumina en verde durante 1,5 segundos (excepto si estamos en temperatura de emergencia). Es la forma que tiene el payload de deciros que está trabajando (sobre todo se nota si está el LED en amarillo fijo)

Y creo que no me olvido de nada importante en este apartado XD (el fuente del payload ya tiene bastantes comentarios)

La Aplicación Control Fan

La aplicación es bastante sencilla (si alguien la quiere compilar, puede usar éste entorno de compilación hilo_psdk3v2-windows-ps3-sdk-con-psl1ght-v2-tiny3d-y-ps3-soundilb_1867760) y muestra en forma de texto toda la información.

Nada más arrancar se fija el modo "#Payload" que es de lo que hemos estado hablando.

La información en pantalla es la siguiente:

Temperatura de la CPU/ temperatura de RSX y Tiempo transcurrido desde el encendido de PS3

Las temperaturas parpedearán en amarillo cuando alcancen los 70 grados y en rojo cuando alcancen los 75 grados

sys_sm_get_fan_policy aquí indica el modo y la velocidad que tiene fijado el SYSCON

Current Mode Indica el modo actual y la velocidad del ventilador fijada (modo 2 y payload)

Los modos vienen resumidos abajo. En el Modo 2, con UP/ARRIBA subimos la velocidad y con DOWN/ABAJO la bajamos. Recordad que el modo 2 es un modo con velocidad fija y no varía en función de la temperatura. El Modo 1 es el normal del sistema.

Para cambiar de Modo se usa SQUARE/CUADRADO e irá cambiando en sentido ascendente (eso permite por ejemplo, fijar una velocidad muy baja en Modo 2 para que la consola se caliente y luego activar el Modo Payload para ver como responde XD)

Con el botón TRIANGULO se sale de la aplicación. Recomiendo usar éste botón para salir y no desde PS

Protecciones de la aplicación

- Desde el Modo Payload, protección anti-shutdown, para que ajuste el modo de protección

- Si se apaga la consola en Modo 2, se conservará al encenderlo, ojo a esto, aunque en principio, el SYSCON fija una velocidad supuestamente apropiada.

- El SYSCON corrige los valores fijados por debajo de 0x33. Aún así, se ha limitado el Modo 2 a 0x30 cómo mínimo y cuando la velocidad baja de 0x4D Current Mode parpadeará en azul

- Si se sale de la aplicación en Modo 2, la velocidad mínima se ajustará a 0x5f, independientemente de la que hubiera sido fijada (a modo de seguridad y por que el Modo 2, no debiera ser fijado, a menos que lo que se pretenda es que el ventilador trabaje a velocidad alta y en ese caso, ese mínimo es correcto :p )

- Independientemente del modo, si la temperatura es mayor o igual a 80 grados, se activará el Modo 0 hasta que la temperatura baje por debajo de los 60 grados (momento en que conectará el Modo Payload) o vosotros mismos cambiéis de modo cuando la temperatura baje de ese límite.

Cómo veis la aplicación tiene sistema de seguridad para evitar que dejéis frita la consola, independientemente de las protecciones que pueda tener el sistema. Ya me contaréis que os parece el tema (seguramente acabe integrándolo en Iris Manager, pero por el momento, estamos en fase de pruebas)

Descarga

http://mods.elotrolado.net/~hermes/ps3/ ... y_v1.7.rar

System Manager para CFW Miralatijera 4.40 y core 3.2.0 +

Mas info en:

hilo_update3-cfw-4-40-miralatijera-100-core-3-2-0-integrado-qaflag_1880798

v1.1:

viewtopic.php?p=1732436068

Lo nuevo en SM v1.1:

- Se han hecho unas correcciones de tiempo para evitar demoras excesivas a la hora de cambiar el modo de trabajo para el Fan y el USB Wakeup.

- Se han reducido las prioridades al mínimo para intentar que el System Manager interrumpa lo menos posible a otros procesos en marcha y solo utilice sus tiempos muertos.

- Se ha añadido la posibilidad de cambiar a prioridad y el tiempo de actualización de main() (esto sirve para tener la posibilidad de toquetear cosas, si resulta necesario, pero en principio, debería valer como está)

Descarga:

http://mods.elotrolado.net/~hermes/ps3/ ... 0_v1.1.rar

Instalación:

- Si ya tenías la versión previa, simplemente, copia sm.self en raíz del dispositivo USB, ponlo en USB000 (el mas cercano al lector) y reinicia.

- Si no tienes el core 3.2.0 entonces ve aquí:
hilo_update3-cfw-4-40-miralatijera-100-core-3-2-0-integrado-qaflag_1880798

y siguiendo las instrucciones, reemplaza el viejo sm.self por el nuevo

Desinstalación:

- Copia la carpeta "flags" que hay dentro del RAR al dispositivo y reinicia con éste enchufado en USB000

USB Wakeup:

- Crea un fichero de nombre "nosleep" (sin extensión, que ya os veo venir XD) en raíz del dispositivo que queráis que cada cierto tiempo, se acceda en escritura para mantenerlo alerta
Ultima edición por Estwald el 15 may 2013 16:22, editado 13 veces
Esta firma ha sido modificada porque incumplía la normativa sobre utilización de firmas.

moro_musa
MegaAdicto!!!
2.352 mensajes
desde feb 2011

gracias tio joder si que hay que leer :) :)

varicela
MegaAdicto!!!
3.099 mensajes
desde ene 2005
en Tarragona

Como Siempre
IMPRESIONANTE

Saludos Maestro
Mis artilugios para grabar/leer Nand's de Wii y PS3 desoldadas
Imagen

Imagen

Uploaded with ImageShack.us

http://img245.imageshack.us/img245/3376/dsc02524cj.jpg
http://imageshack.us/photo/my-images/269/infectusdual.jpg/

03/03/2011 Downgrade PS3 desde OFW3.56 (service) http://www.elotrolado.net/viewtopic.php?p=1724046120
[idea]
Las maquinas no se equivocan
¡ Que bueno es ser Humano ! ¡ Aunque a veces nos cuesta reconocer el error !

ssecarlos
Gamer Adicto!!!
950 mensajes
desde oct 2007
en En El Infinito y Mas Alla

ssecarlos está baneado por "Crearse un clon para saltarse un baneo"
Estwald chapó! [tadoramo] [tadoramo]
PS3 Slim 320 Gb CFW 4.40 MLT
PS VITA wifi + Memory 4gb
PSP GO BLANCA 6.60 Pro-B10

"No nos importa como funcionan las cosas, mientras funcionan"
"El baneo es símbolo de independencia de un Troll"

egarrote
Erizo Sónico
Colaborador wiki
3.050 mensajes
desde ene 2006
en Green Hill Zone

Enhorabuena por el currazo!
A probarlo [beer]

Salu2!
ImagenImagen



23º
ANIVERSARIO





Estwald
MegaAdicto!!!
4.321 mensajes
desde abr 2011

Bueno, he corregido alguna cosa y sigue habiendo alguna letra comida y cosas así, pero ya lo tocaré en otro momento XD

El texto es largo, pero la parte de la aplicación en si, es a partir de
La Aplicación Control Fan


De todas formas, si os interesa el tema de scene o una explicación mas extensa de cómo funciona el "mecanismo", os resultará interesante el resto.

Espero que al final, el fruto merezca la pena: a mi por lo menos, me está resultando muy útil, pero cómo solo yo la he probado, pues mi punto de vista es limitado en ese sentido.

Por lo general, el mayor problema de todos es la lectura de temperatura: requiere de una variable que "cuesta" conseguir y se toma un tiempo considerable y al menos, la primera vez que se llama, se tira sus buenos 20 ms de tiempo y puede que de vez en cuando necesite tomarse ese tiempo por que vete tu a saber que motivo..
Esta firma ha sido modificada porque incumplía la normativa sobre utilización de firmas.

Perfect Ardamax
MegaAdicto!!!
2.231 mensajes
desde ene 2011
en Dentro del Universo

Ya te vi comentarlo hace una semana pero jamas pensé que lo tendrías tan rápido :O
Solo puedo decir que me has alegrado el día. UN TRABAJO IMPRESIONANTE [tadoramo] [tadoramo] [tadoramo] [tadoramo]

Saludos
El Conocimiento Humano Pertenece al Mundo

Imagen

sefirot_bnk
I ♥ Rubalcabra
2.544 mensajes
desde jul 2007
en Sevilla sity DF

enhorabuena!!! ésto ayudará a alargar muchisimo la vida de nuestras ps3. Muchas gracias!!

nabunocosor
MegaAdicto!!!
1.394 mensajes
desde may 2007

Con CFW Rebug 4.41 da pantallazo negro, ya sé que solo es para CFW 4.31 y 4.40 CEX pero lo tenia que intentar! Refirmar el eboot para solucionar esto?
castellsera, en referencia a GT5 escribió:
... este juego no merece la pena si no puedes fardar de tener 10 Red bulls X2010 ...
Mi 1ª contribución en la wiki!!
wiki/Censo_de_usuarios_para_LINK

kikeadsl
Adicto
351 mensajes
desde mar 2008

Estoy probandolo y me funciona de lujo,el unico pero que le veo (no se si lo has avisado o no) es que al volver a entrar por segunda vez al pkg en cuestion,pega blackscreen y se te queda colgada la consola de manera que tienes k apagarla (al menos en mi slim),no se si crashea al intentar leer la syscall o que...
"Quien con monstruos lucha cuidese a su vez de no convertirse en monstruo."

Siguiente

Volver a Modchips y Softmods

¿Quién está conectado?

Usuarios navegando por este foro: No hay usuarios registrados visitando el foro y 0 invitados