Pienso que ha llegado el momento de revelar el plan maestro. Ha sido planeado desde hace ya algo de tiempo y pronto empezará el testeo (fase beta).
YAOSM como actualmente es y como lo conocemos hasta ahora dejará de serlo. Casi todo el código ha sido reescrito para que se ejecute desde la unidad lectora (lo llamaré drivecode en adelante) y para el usuario final parecerá y funcionará prácticamente igual que el actual YAOSM 2.0 pero internamente será muy diferente.
Algunas características tendrán que desaparecer por que ocuparía más espacio del que disponemos y estoy seguro que muchos de vosotros preferiréis perder estás obsoletas características, citadas a continuación para seguir manteniendo la compatibilidad con los chips con menor capacidad:
-Detección automática de la región. Bueno…. Existe el disco de configuración para elegir la región, e incluso podemos ponerla antes de programar el pic por primera vez. Por tanto no debería de ser demasiada complicación. Cierto ?
-Velocidad alternativa. Su implementación como drivecode requeriría demasiado espacio. Y lo cierto, es que podemos cambiar la velocidad con el disco de configuración o antes de programar el chip, y por lo que parece, incluso empleando la velocidad baja todo el tiempo, no se ha observado un mal comportamiento de la wii.
-Capacidad de configurar el LED. Estaría casi siempre encendido por defecto. Como casi todo el comportamiento de YAOSM será desde la unidad lectora el LED parpadeará con menor frecuencia, ahora ya no estará parpadeando todo el tiempo. Por tanto el LED estará encendido, pero se apagará momentáneamente cuando un cambio de disco es detectado. Eso es todo.
Bueno y cuales son las ventajas entonces? Perder algunas características no parece un buen cambio a pesar de todo, lo es?
Bueno no son muchas las ventajas que se obtendrían pero si son importantes:
-Portabilidad. Por su principio de funcionamiento, portar YAOSM, por ejemplo a la plataforma OPENWii no debería ser difícil.
-Capacidad de actualizar YAOSM por DVD. No hablamos de una capacidad de actualización completa desde luego, por que los pics que empleamos no lo permiten, pero si que tendríamos 250 bytes en los pics grandes (y 122 bytes en los de menor capacidad) en la eprom, que serán dedicados para los parches/actualizaciones futuras. Vamos es un sistema muy similar al que usa Wiinja deluxe. Dispondrá inclusive de una función de recuperación en caso de que la actualización no sea correcta.
Antes del fin de semana se lanzará la primera beta, por lo menos así está previsto, será importante el testeo realizado por todos los usuarios que lo deseen , por que las siguientes actualizaciones resultantes de los fallos encontrados serán reflejadas en la versión final.
Bueno y después de todo este rollo, me preguntareis, si bueno, pero por que ejecutar YAOSM desde la unidad lectora (drivecode) es mejor que la actual forma? (inyectar a través del puerto serie la información necesaria en el momento adecuado).
- Algunas de las características actuales de YAOSM están hechas con drivecode, por que el puerto serie es demasiado lento para algunas de ellas, como son, por ejemplo la característica de audiofix y la protección para juegos tipo SMG.
De cualquier modo, YAOSM 2.0 hace su trabajo, y lo hace muy bien, entonces por que usar drive code?
- La cuestión es que el código dentro del pic no puede ser sustituido una vez ha sido programado, es por esto que YAOSM actualmente necesita un programador externo para ser reprogramado. Usando drivecode, el código YAOSM existe en la memoria RAM del DVD, y la memoria RAM si puede ser modificada. Si usamos el área eprom del pic para albergar un parche que modifique el código YAOSM albergado en la memoria RAM, permite hacer posible la actualización de YAOSM. El área eprom es la única parte de los pic que usamos que permite ser modificada sin el uso de un programador externo. Pero no puede ser usada para cambiar el código del área de programa del pic.
Básicamente toda modificación efectuada en el drivecode puede ser actualizada usando software casero de game cube. De una forma tan fácil como actualmente configuramos YAOSM con el disco de configuración.
Esto supone una gran ventaja, pero otra de ellas es que con la mayoría del código en un solo archivo binario y con mucho menos código en el PIC, es mucho más fácil de portar. De hecho con pequeñas modificaciones en el actual código de OpenWii todos sus usuarios serán capaces de reemplazar su propio drivecode por el de YAOSM. Lo único que necesitas es leer y escribir a través del puerto serie. WABmodcheap que fácilmente puede ser usado como base para cargar y activar el drivecode YAOSM. En el futuro, en caso de que WIIKEY cese con el soporte a sus usuarios, es muy probable que fuera posible reprogramarlos con el código YAOSM ( necesariamente con un programador externo, a no ser que alguien nos ilumine sobre su método de actualización.)
De hecho, como los lectores DMS/D2A/D2B se están haciendo cada vez más obsoletos, es probable que algunos de los fabricantes de chips cesen su soporte.
De cualquier modo, no está planeado hacer esas portabilidades, pero como YAOSM es gratuito y su código fuente está disponible, no sería sorprendente ver portabilidades a otros mods, realizados por terceros. De hecho ya existe un port de YAOSM 2.0 a cyclowiz y ya se han anunciado algunas peticiones ahora y en el pasado para portar YAOSM a OpenWii y WiiKey.
Para todos aquellos que no deseéis o estéis en desacuerdo con la pérdida de algunas de las características YAOSM, os invito a entrar al foro oficial YAOSM, y que costeéis vuestro desagrado, indicando que características no deseáis perder de las citadas, y el motivo por el cual no queréis perderlas.
También se está pensando si ponerle un nuevo nombre al nuevo proyecto, o simplemente ponerlo como YAOSM 3.0, vosotros que opináis ?
Como creo que todo esto es importante, lo añado también y de forma temporal, al primer post del hilo. Espero que también os guste el ligero cambio de diseño del mismo.
Sin más pretexto que el indicado y con el mismo ánimo que el primer día, os mano un cordial saludo.
error404