[Entrevista a Marcan] Sus planes y proyectos

Genial entrevista Piratepila, y tambien se agradece mucho el trabajo y la dedicacion de todos los twizers

ArangeL escribió:

Marcan: Por cierto, he de recalcar que todo este código es completamente nuevo. No usamos código ni servicios del boot2 o IOS original.

Te felicito marcan; pues yo soy de las pocas personas que consideran que la actual "scene" de Wii es una falsa, pues se está usando IOS a nivel interno para I/O de la consola. Se "agradece" que se monte un sistema base en código puro PPC, sin tener que usar IOS.

ArangeL, si no tengo mal entendido el IOS corre sobre el Starlet, con lo cual es independiente del codigo PPC, sirve mas bien como una interfaz de este a ciertas partes del sistema. Ni boot2 ni IOS original son PPC, son ARM, que es de lo que se esta hablando. Y lo de I/O de la consola no va todo por el IOS, por ejemplo al video no tiene acceso directo el Starlet, de ahi que marcan use un LCD de los tipicos de electronica para trabajar. En la consola casi siempre tendra que correr codigo ARM y PPC, y el ARM suele ser un IOS, otra cosa es que hasta ahora se hallan usado los originales. Es decir, todo esto desde mi (aun corto) entendimiento, Ahora estan trabajando a bajo nivel sobre el Starlet, en ARM, y en la parte de codigo puro PPC es la que ya esta implementada en Libogc, que siemrpe se tendra que comunicar con algun IOS, aunque no sea original.

Muy buena la entrevista

marcansoft escribió:

ArangeL escribió:[...]

[...]

Soy de los que piensan que es mejor dar soporte nativo a la plataforma, que darlo sobre una capa; y más aún depender de una capa propietaria y con derechos restringidos por su creador (Nintendo). Creo que ha sido un paso en falso haber sacado de forma oficial el libogc haciendo uso de los IOS de Nintendo en vez de usar código nativo PPC. Sé que hacía falta "incentivar" a las personas para que la scene empezara temprano, pero creo que no se debería de haber usado IOS salvo para lo estrictamente necesario (liberar la plataforma restringida, para instalar una base libre).

---
technik:
"y el ARM suele ser un IOS".

Ese es el fallo; el IOS es una capa de abstracción para programar "más fácilmente". Pero es código propietario y restringido; por lo que no me parece factible usarlo para la scene. Es como realizar un driver para linux que necesita el firmware original para que funcione el dispositivo; eso ni es driver ni es nada; pues vete tú a saber si el "dueño" de ese firmware te da su permiso para usarlo, o si es legal en tu país distribuirlo "por ahí".
---

Scene es sinónimo de romper barreras a plataformas restringidas y dar soporte libre de desarrollo. Y homebrew los programas creados gracias a la scene. Lo que se está haciendo a día de hoy, no es scene; pues se está usando como base "un IOS" que es una base propietaria y restringida (se ha desvirtualizado el término scene, como sinónimo de crear una aplicación no comercial sobre una plataforma restringida, como ya se vió en estos foros, que no importaba el camino recorrido, sino si se llegó a la meta; crear homebrew con herramientas propietarias). Lo apropiado huviera sido empezar a desarrollar un "IOS" libre y sin restricciones, que es lo que marcan a dado a entender que es la idea que tienen en mente (muy simple, pero por algo habrá que empezar).

ArangeL escribió:Soy de los que piensan que es mejor dar soporte nativo a la plataforma, que darlo sobre una capa; y más aún depender de una capa propietaria y con derechos restringidos por su creador (Nintendo). Creo que ha sido un paso en falso haber sacado de forma oficial el libogc haciendo uso de los IOS de Nintendo en vez de usar código nativo PPC. Sé que hacía falta "incentivar" a las personas para que la scene empezara temprano, pero creo que no se debería de haber usado IOS salvo para lo estrictamente necesario (liberar la plataforma restringida, para instalar una base libre).

No usar IOS no es una opción viable de momento - y usar IOS es una opción perfectamente legal y válida. Todo usuario de Wii Homebrew ha comprado una Wii y por lo tanto tiene licencia para los IOS, así que no es problema - igualmente, tu compras un PC con una BIOS a través de la cual arranca el SO, y la BIOS no es libre. La scene de Wii practicamente no existiría sin el soporte de IOS -es mas- tampoco tendríamos tanto interés nosotros porque no habría scene. Hay muy poquita gente dispuesta a trastear con IOS, y de momento es muy engorroso probar las cosas. Además, todo código de IOS necesita ser instalado en la consola para correr, con lo que sería obligatorio hacer instalaciones para usar homebrew, lo quieras o no. Estaría muy bien tener un reeplazo de IOS libre, pero realmente, ¿que ganamos con eso? Nintendo nos da parte del trabajo hecho. No tenemos por qué usarlo (por eso estamos haciendo un IOS alternativo con mas control), pero tampoco tenemos por qué rechazar las partes que funcionan perfectamente. Los drivers de tu tarjeta gráfica probablemente no sean libres, pero ¿eso implica que no debamos crear juegos libres que los usen?

Recuerda, Starlet es una plataforma nueva y sin documentación alguna. Se va a tardar muchos, muchos meses en conseguir lo mismo que ya hace el IOS oficial. Y hasta entonces, no tendríamos, por ejemplo, soporte del Wiimote.

En comparación con un driver para Linux que use un firmware, aquí el firmware ya está hecho y cargado. ¿Acaso tienes un firmware libre en tu teclado, tu ratón, o tu grabadora de DVD?

Recuerda que la Scene de Wii ahora mismo, aunque dependa de un código propietario, ese código ya está ahí y no se combina de ninguna forma con el resto de la aplicación homebrew. La comunicación es a través de una interfaz claramente delimitada. Al menos por nuestra parte, todas las herramientas de desarrollo son completamente libres. El IOS no se usa para desarrollar, sólo se usa a la hora de ejecutar el programa.

marcansoft escribió:

ArangeL escribió:Soy de los que piensan que es mejor dar soporte nativo a la plataforma, que darlo sobre una capa; y más aún depender de una capa propietaria y con derechos restringidos por su creador (Nintendo). Creo que ha sido un paso en falso haber sacado de forma oficial el libogc haciendo uso de los IOS de Nintendo en vez de usar código nativo PPC. Sé que hacía falta "incentivar" a las personas para que la scene empezara temprano, pero creo que no se debería de haber usado IOS salvo para lo estrictamente necesario (liberar la plataforma restringida, para instalar una base libre).

No usar IOS no es una opción viable de momento - y usar IOS es una opción perfectamente legal y válida. Todo usuario de Wii Homebrew ha comprado una Wii y por lo tanto tiene licencia para los IOS, así que no es problema - igualmente, tu compras un PC con una BIOS a través de la cual arranca el SO, y la BIOS no es libre. La scene de Wii practicamente no existiría sin el soporte de IOS -es mas- tampoco tendríamos tanto interés nosotros porque no habría scene. Hay muy poquita gente dispuesta a trastear con IOS, y de momento es muy engorroso probar las cosas. Además, todo código de IOS necesita ser instalado en la consola para correr, con lo que sería obligatorio hacer instalaciones para usar homebrew, lo quieras o no. Estaría muy bien tener un reeplazo de IOS libre, pero realmente, ¿que ganamos con eso? Nintendo nos da parte del trabajo hecho. No tenemos por qué usarlo (por eso estamos haciendo un IOS alternativo con mas control), pero tampoco tenemos por qué rechazar las partes que funcionan perfectamente. Los drivers de tu tarjeta gráfica probablemente no sean libres, pero ¿eso implica que no debamos crear juegos libres que los usen?

Recuerda, Starlet es una plataforma nueva y sin documentación alguna. Se va a tardar muchos, muchos meses en conseguir lo mismo que ya hace el IOS oficial. Y hasta entonces, no tendríamos, por ejemplo, soporte del Wiimote.

En comparación con un driver para Linux que use un firmware, aquí el firmware ya está hecho y cargado. ¿Acaso tienes un firmware libre en tu teclado, tu ratón, o tu grabadora de DVD?

Recuerda que la Scene de Wii ahora mismo, aunque dependa de un código propietario, ese código ya está ahí y no se combina de ninguna forma con el resto de la aplicación homebrew. La comunicación es a través de una interfaz claramente delimitada. Al menos por nuestra parte, todas las herramientas de desarrollo son completamente libres. El IOS no se usa para desarrollar, sólo se usa a la hora de ejecutar el programa.

Mas clarito pa donde xD... Eres un duro marcan!!
Gracias a los dos por la entrevista, estuvo genial, y gracias al team twizers por su gran aportacion a la wii..

marcansoft escribió:

Redbird escribió:Por cierto, Marcan, el emulador de NAND que comentas, ¿lo vas a desarrollar sobre FPGAs? ¿Se trata del proyecto sobre la placa de Spartan III?

Sip. A ver si saco un poco de tiempo para eso también

Esa FPGA tenía poca memoria interna y teníais que montar un servidor o algo así para conectar con el PC. ¿No sería posible acceder a una placa con más memoria? Los 512MB+16KB que se necesitan para la NAND no son muchos... En Xilinx no estoy muy al corriente, pero en Altera tienes placas como esta http://www.altera.com/products/devkits/ ... 2C20N.html que ya lleva toda la memoria que quieras (8MB SDRAM, 4MB Flash, 512K SRAM) , por sólo 150$ y me imagino que eso ahorraría un montón de tiempo de desarrollo.

Redbird escribió:

marcansoft escribió:

Redbird escribió:Por cierto, Marcan, el emulador de NAND que comentas, ¿lo vas a desarrollar sobre FPGAs? ¿Se trata del proyecto sobre la placa de Spartan III?

Sip. A ver si saco un poco de tiempo para eso también

Esa FPGA tenía poca memoria interna y teníais que montar un servidor o algo así para conectar con el PC. ¿No sería posible acceder a una placa con más memoria? Los 512MB+16KB que se necesitan para la NAND no son muchos... En Xilinx no estoy muy al corriente, pero en Altera tienes placas como esta http://www.altera.com/products/devkits/ ... 2C20N.html que ya lleva toda la memoria que quieras (8MB SDRAM, 4MB Flash, 512K SRAM) , por sólo 150$ y me imagino que eso ahorraría un montón de tiempo de desarrollo.

No se cómo pasas de 8MB a 512MB (Y la NAND tiene bastante mas de 16KB de spares)

La placa de S3E (que por cierto también cuesta 150$ y que ya tengo de todas formas ) tiene 64MB de DDR incorporados. Si consigo hacer un controlador de DRAM, usaremos eso como bufer para las partes mas cambiantes. En cualquier caso, seguimos queriendo tener el PC como servidor, porque de eso se trata: poder trabajar con las NANDs directamente como archivos en el PC, sin tener que grabar o leer. La placa ya tiene controlador Ethernet y tengo código que lo utiliza, así que eso no debería ser problema.

marcansoft escribió:No se cómo pasas de 8MB a 512MB (Y la NAND tiene bastante mas de 16KB de spares)

jeje ¿no has oído hablar de la multiplicación de panes y peces? Lo mismo, pero en RAM.

Nada, que estoy espeso y estaba pensado en 512K en lugar de 512M (por eso me salían 16K extra en lugar de 16MB).

Para compensar un poco el desastre anterior , mírate esto:
https://roulette.das-labor.org/bzrtrac/wiki/wb_ddr
https://roulette.das-labor.org/bzrtrac/wiki/ddr_ctrl

No sé si os puede servir, y quizá ya los conozcas. Están en Verilog. ¿Vosotros desarrolláis en Verilog, VHDL, o ambos?

graciasp por la entrevista.

interesante todo esto, me imagino que los de anti bircks mas que nada es para que los programadores puedan estar testeando tanquilamente todo lo que quieran.

Gracias por hacerle esta gran entrevista y desvelarnos los entresijos que se llevan entre manos estos máquinas
Y gracias tambien a Marcan por prestarse y por su tiempo.
Un saludo compañeros.