Culturilla general [Lenguaje de scene]

Edito: Viendo que tiene interes el hilo he añadido algun comentario con noticias frescas y alguna que otra correcion.

Viendo que no me puedo dormir me aventuro a entrar un poco en el mundo EOL de la DS, aunque no soy feliz propietario de una, si ronda una por casa y ya le he metido mano, un poco de programacion en OpenGl y tal, viendo un poco de desconcierto de ciertas palabras voy a intentar dar algo de luz.

Algo de hardware:

La DS se compone en si de dos procesadores un ARM7 y un ARM9, cada uno tiene acceso a ciertas partes del hardware que el otro no posee. Asi comparten ambos 4 Mb de memoria principal, accesible por ambos pero nunca al mismo tiempo, el hardware se ocupa de proteger la memoria de un acceso simultaneo de ambos procesadores (exclusion mutua), mediante un registro de la consola se puede dar prioridad a un procesador sobre el otro (suponiendo dos peticiones simultaneas).

El mapa de la memoria: http://www.bottledlight.com/ds/index.php/Memory/Layout

Algo del funcionamiento:

La DS tiene varias BIOS(*), exactamente, 3, Una para cada procesador (ARM9Bios y ARM7Bios) y otra practicamente identica a la que contiene una gba (difere en un bit). El funcionamiento de la DS mas o menos es el siguiente, teniendo dos modos, al encender, se comienza a ejecutar el firmware que carga en memoria todos los menus (esos que vemos al inicio) detecta los cartuchos (gba y ds), y lo deja a eleccion del usuario, cuando ejecutamos un juego de ds, simplemente se comienza a leer la cabecera de este juego y se procede con normalidad, ya que al encender la consola por defecto estamos en el denominado modo DS (ya veremos que ventajas tiene), ahora bien, si señalamos un cartucho de gba, la consola sobre un reset, pone el procesador ARM7 a la mitad de su velocidad y solo permite "ver" el 25% de la memoria original (*No estoy muy seguro si es un 25% o un 0.25Mb*) pasando al modo gba. Ahora vienen las preguntas:

(*)BIOS, en lenguaje muy resumido seria parte de un codigo que nos da acceso a ciertas funcionalidades de la consola.

desde el modo DS puedo pasar al gba? SI
desde el gba puedo pasar al DS? NO
desde un cartucho de gba puedo ejecutar codigo de la DS? NO (es cierto y no es cierto)

Es sencillo, toda aplicacion que se ejecute desde el cartucho de gba, sera en modo gba, y toda la que se ejecute desde el puerto DS, sera en DS (o gba si activamos este modo con un pequeño codigo antes de ejecutar lo que vayamos a ejecutar).

Problemas, desde el modo DS, tenemos acceso a todas las funcionalidades de esta, Wifi, botones X,Y, microfono, pantalla tactil, etc..., desde el modo gba, esto es imposible, mediante hardware se protegen todos los registros y no se permite el acceso a este hardware desde gba. Que implica esto? pues que tenemos una gba donde podemos ejecutar codigo casero, como cualquier otra gameboy. Algunos llegados a este punto, se preguntaran ( y sino lo digo yo ), bien pues compramos una DS flashcart y ejecutamos codigo desde ahi, hay un problema, evitando el hecho de que aun no existen, esta el de la proteccion RSA(*), tanto las firmas como el protocolo del puerto DS estan cifrados mediante alguna proteccion que aun no se entiende/comprende, osease que aunque tubieramos la posibilidad de emular algo para servirle los datos al puerto de DS, sino conocemos el cifrado no podremos servirle datos utiles.

(*)Parece ser que no es tal encriptacion y la RSA (que viene debajo de la DS indicado) es solo para el wifi, parece algun tipo de criptografia pseudo-aleatoria, que viene a significar que los datos que salen del cartucho hacia la DS no parecen tener sentido (aleatoria) pero para la DS si lo tienen usando el algoritmo que desconocemos (pseudo), es algo mas complicado de explicar pero creo que queda claro.

Aqui es cuando entro en funcionamiento el PassThrought, cuando se entiendio la forma con la que el puerto de la DS funcionaba, se dieron cuenta que lo primero que se leia del cartucho de DS, era el header, pero en un modo no cifrado, osease, los datos que podias ver eran exactamente los que la DS veia, despues se activaba la proteccion y todos los datos del juego quedaban cifrados y inservibles, lo que no permitia ni ejecutar codigo (enviandoselo...) ni leer lo que enviaba (porque no conocemos la manera de desencriptarlo), pero el tener el header abierto abria algun que otro camino, de primeras DarkFader comprendio la estructura de la cabecera (header), tenia alguna que otra puerta abierta, pero antes hacer un pequeño incapie..., la DS para tener total compatibilidad con la GBA, hace uso de una tecnica que redirecciona toda la memoria ROM del cartucho de GBA como parte de la memoria, que puede ser accedida y por lo tanto leida por los procesadores, como si su memoria principal se tratara. Asi bien, mientras la memoria principal de la DS comienza en 0x02000000, todo el cartucho de gba esta en 0x08000000. Llegado hasta aqui, y si tienes unos conocimientos algo avanzados de informatica me habras seguido, sino tendras una sopa en la cabeza de aupa, pero voy a intentar hacerlo mas facil.

Cuando vas a ejecutar un juego de DS, la consola lee la cabecera del archivo del cartucho, este contiene varios datos, de los mas importantes son, el comienzo del codigo del ARM9, ARM7, tamaños de ambos y direccion para el alojamiento en memoria. Vale, para hacernos una idea, un buen simil de ejecutable de DS, seria como tener dos Exe's de windows juntos, okis?. Pero claro, como cada procesador va ejecutar uno (y no se puede elegir por azar, sino por algo determinado) la cabecera es la que nos va dar la informacion necesaria para colocar estos ejecutables en la memoria de la DS.

Seguimos con el PassThrought, DarkFader lo que hizo basicamente, fue sustituir uno de los datos del header en vuelo, osease mientras la DS recibia los datos del cartucho del puerto de la DS, habia una interfaz (un FPGA programable), que iba visualizando los datos, cuando llegaba el momento, invalidaba los del cartucho de la DS y enviaba los suyos. Principalmente lo que se hacia, era cambiar la posicion de uno de los ejecutables, de la memoria principal, a la memoria del cartucho de GBA (un error de nintendo permitir esto), al hacer esto no invalidaba el modo DS y iba a ejecutar codigo desde el cartucho en modo DS. Ya teniamos nuestro famoso PassMe, pero con mucho por medio (un FPGA muy complicado...), natrium42 fue el que se ocupo de diseñar el passme y simplificarlo a esa pequeña escala. Bueno, de esta tecnica mas o menos derivan las otras dos, flashme y wifime, el wifime basicamente carga unos ejecutables propios que redirijen al cartucho flash (desde modo DS) y el flashme, mas o menos igual, simplemente al arranque si detecta un cartucho flash metido, con una serie de caracteristicas (botones A+B+X+Y, nombre de la rom DSBoot o el titulo PASS dentro de una zona especifica), cambia la posicion de ejecucion al cartucho flash, sin ni si quiera ejecutar el menu.

Principalmente, esta es la historia, todo lo demas es algo mas lioso, pero si has leido hasta aqui, seguire (aun no tengo sueño...), la ejecucion se redirije exactamente a 0x080000C0, es justamente donde esta el logo de GBA (si, para un juego de GBA), una vez alli, por motivos que no vienen al caso, la DS da prioridad de ejecucion al ARM7, y aqui entra en juego el "loader", es una pequeña aplicacion, que lo que hace basicamente es dejar las cosas en su sitio y como si de una ejecucion desde un cartucho de ds se tratara. Al redirijir la ejecucion, lo que tenemos ahora mismo en memoria no es util, y ejecutar desde el cartucho los binarios no es util, el loader lo que hace mas o menos es copiar ambos ejecutables en sus posiciones de memoria, (todo esto desde el ARM7), una vez lo tiene todo copiado, manda al ARM9 a la posicion inicial de su ejecutable, y el mismo se auto manda a la posicion de su ejecutable (el de ARM7).

Todas las aplicaciones Homebrew, y demos, funcionan con esta tecnica, por una serie de razones. Ahora bien, las backups, porque no? es muy sencillo una vez llegado aqui ver porque razon no va funcionar una backup de un juego original, la informacion que se copia a la memoria de la DS es la de los ejecutables (de ahi que solo necesitemos 4 megas, bueno realmente necesitamos mucha mucha menos), los datos, textos, mapas, graficos, etc... todo todo queda almacenado en el cartucho ds, asi bien, cuando el juego necesite algun dato, simplemente hara una peticion al cartucho(de ds), y este le dara lo que quiera, el metera en memoria lo que necesite y a funcionar, cuando no lo necesite lo borrara y pondra los datos nuevos. Si por alguna razon, los ejecutables estan bien en memoria, pero en el puerto de DS no hay ningun cartucho, la informacion que piden es nula, y la ejecucion del juego se aborta. Los datos estan contenidos en la flashcart, osease el puerto de gba, no el de ds, y esto el juego no lo sabe. La explicacion de porque un demo si va, es muy sencilla, los demos estan preparados para contener dentro de la memoria todos los datos que vayan a necesitar (son demos, se lo pueden permitir) cualquier dato, ya sea, texto, grafico o como le parezca, estara en memoria y no debera perdirlo, asi bien funciona con cualquier metodo conocido.

Un simil de esto, seria como tener un ordenador con dos discos duros, y el sistema ejecute desde el segundo, pero todos los datos necesarios para el arranque (configuraciones, drivers.. etc.. ) esten en el primer disco. Intenta arrancar el sistema sin el primer disco...

La solucion pasa por crear un parcheador que arregle todo el codigo de los ejecutables para direccionar el acceso del puerto de DS a cartucho de GBA, esto primeramente no es algo trivial, no se sabe si todos los juegos usan el mismo codigo (algun SDK de nintendo como podria ser el Nitro), o va por implementaciones de cada desarrollador o compañia, osease que seria un trabajo individual para cada backup. Y segundamente, esto solo trae consigo consecuencias malas a la scene, alguien que quiera desarrollar homebrew o ejecutar una demo, jamas necesitara este parcheador porque el homebrew ya se desarrolla partiendo de la base de la flashcart, y por lo tanto el uso del parcheador solo seria util para los juegos comerciales, y fomentaria la pirateria. Igual que hablo de un patcher, hablo de un loader, algo mas gordo en codigo que los que hay ahora, que en ejecucion (al vuelo..) fuera arreglando el codigo volviendolo algo mas "universal".

Unf... hay tanto que decir de esta pequeña consola y del juego que da que unf... no pararia ... pero creo que es un buen resumen de la historia hasta ahora de esta figurita.

Trabajando la DS:

Bueno, visto que el hilo tiene un poco de tiron voy añadir algunas cosas que se estan comentando por los foros.

Parece ser, y no es mala idea que se quiere usar la DS como una gameboy pero con las funcionalidades de DS, que ventajas tendria esto? la primera y obvia, tener mas potencia de ejecucion que las antiguas gb[a], poder usar ciertas funcionalidades de la DS en algunos juegos de gba, y algunas cosas muy interesantes... (juegos gba multijugador sin el cable link.. etc..etc..). El problema pasa por lo que ya he comentado a lo largo del post, un juego de gba, se ejecuta en modo gba y no hay modo de evitarlo, y aunque (en modo DS) se consiga copiar el codigo de la rom a ARM7 (es practicamente identico al procesador de GBA salvo que puede ir mas rapido), la ejecucion no funcionaria, porque la BIOS del ARM7 no seria la misma y habria que parchear las roms (bueno realmente traeria otros quebraderos de cabeza bastante mas complicados). Hay un par de tarados (sisi tarados ) que estan programando un emulador de gba para la propia DS, nos va dar muchas ventajas, pero muchas muchas, la primera, al tener ya un procesador totalmente compatible solo tenemos que ejecutar la instruccion tal cual sin preocuparnos de traducciones ni nada por el estilo (mejora de rendimiento), podremos hacer salvados instanteneos como en otros tantos emuladores (lo que no se muy bien donde podremos grabarlos, alguna interfaz PC-DS?), tendremos alguna que otra posibilidad de acelerar el juego (tipico de los emuladores dejarte poner el juego al 200%), algun tipo de ventaja con la tactil, fijo que alguien tiene alguna idea para esa maravillosa pantalla que tan buenos ratos nos va dar, otra fundamental va ser el juego multijugador, al tener un emulador de fondo, vamos a poder crear un "control wireless" como ya tienen algunos emuladores de PC (de gba) que permiten jugar por internet, y con un poco de suerte, con una DS podran jugar muchas DS a una rom de gba (todo es liarse con el protocolo). Vamos una maravilla, un tio con un flash con el FZero, jugando con otros 16 (cuanto era el maximo de links que permitia?? ) creo que no hay forma de explicar lo que se debe sentir...

Wifi:

Bueno, el llamado Ni-Fi por la comunidad, no es mas que un enlace IEEE 802.11b en el canal 1 (puede usar otros), pero con algunas caracteristicas "by nintendo", voy a intentar explicar un poco el funcionamiento del protocolo Wi-Fi en si, cuando por ejemplo un punto de acceso esta sirviendo Wi-Fi, este envia periodicamente los datos, SSID(nombre de la red), canal, si funciona WEP o WPA (cifrados wifi). Bien, que ocurre con la DS, pues que estos paquetes los ignora, aunque si los recibe, lo que ella necesita es otra serie de datos, o hasta donde se sabe, los mismos con algun tipo de caracteristica añadida, lo demas lo desecha. Aun un problema, nosotros podemos elegir lo que enviar en una tarjeta Wi-Fi, o recibir, pero estos datos parece ser que son intocables a nivel software y no se nos va permitir elegir si emitir esto o alguna otra cosa en concreto (Viene del driver, al menos en las compatibles con el WifiMe), lo que ocurrio mas o menos fue lo siguiente, no tiene porque se cronologicamente, pero si asi, alguien diseño un driver para la Ralink (chip que llevan las tarjetas compatibles con el Wifime), alguien con su portatil en el E3 (capturando los datos de los servidores que pusieron por alli), o en algun sitio donde nintendo esta ofreciendo Demos mediante Wifi con un portatil saco los datos que eran necesarios, se estudio y se supo que se podia hacer.

Bien, la pregunta es, que diferencias tenemos entre el driver normal y el no normal?, la diferencia basicamente es que el driver que permite la conexion con nuestra DS, es un driver que permite el envio RAW (osease un control absoluto sobre lo que envia la tarjeta), pudiendo enviar tramas (carros de datos, conjuntos como querais llamarlos...) sin que la tarjeta modifique ni un bit de esa trama esto nos permite darle a la DS lo que quiere y la DS asi lo demuestra. Detectar estos datos es mucho mas facil, es mas se usaba de hace tiempo para romper la criptografia WEP o WPA, la tarjeta al no estar conectada al punto que ofrecia los datos, no era capaz de leer los "paquetes" pero capturando estos paquetes en modo promiscuo (suena mal... pero es asi, significa que se pilla todo lo que llega) puedes capturar cosas que de otra manera se ignoraban. De este modo supongo (si supongo porque Fir3Fly el papa de todo esto nunca a dicho ni mu(*) que se pudo sacar los datos que enviaban las estaciones de nintendo ofreciendo las "demos". Luego se programo el Wireless Multiboot, poco mas hay que contar, porque es casi del mismo estilo que el passme, cargar datos en memoria y ejecutar...

(*) Hay otra rama de investigacion, que se cree que se tubo acceso a los NitroSDK (facil pero dificil sacar nada de eso..) o algo de hardware de nintendo para DS.

Actualmente, se ha pedido a Fir3Fly que libere el codigo para abrirlo a linux, pero no quiere, el lo unico que argumenta es que si alguien programa el driver para enviar paquetes RAW en linux, el portara el codigo. Eso me da que pensar, debe a ver algo en ese codigo que no le gustaria que viera la luz....

Por cierto, actualmente, se esta ofreciendo 1200$ al que ofrezca las librerias de Ni-Fi para DS (bueno piden algo mas, una aplicacion PC - DS que permita recibir y enviar datos)

Natrium42 y sus modificaciones:

Bueno, natrium42, el reductor del PassThrought, y transformado a PassMe . Bueno este señor parece que le ha dado por intentar añadir cosas a la DS, lo ultimo y mas importante es mediante el PassMe añadir comunicacion serial a la DS, no ha publicado nada de codigo(*) supongo que estara estudiandolo, pero seria una buena opcion, porque la DS no tiene ningun puerto de salida que nos permita comunicarnos con ella (ni enviar, ni recibir... datos). Basicamente, la DS se comunica con el cartucho de DS mediante comandos (los ultimos dos bit que se usan para los datos son justamente para eso, SPI) el CPLD que lleva entre medias el cartucho puede (es mas... lo hace) interceder estos comandos, asi que ya tenemos un chip al que le podemos enviar un comando y cualquier dato que nos plazca con suma facilidad, teniendo en cuenta eso y que podemos usar cualquiera de las patillas que usa, ya tenemos nuestra comunicacion, ahora solo un poco de software a la DS y ya podemos funcionar con cualquier dispositivo que use comunicacion serie, asi que se ha dedicado a conectar un teclado, un GPS (para leerle el posicionamiento supongo), un pequeño cacharrin que da acceso bluethoot.

(*)Si si, el señor Natrium42 ha publicado el codigo tanto para el CPLD y el ARM7 y enviar comandos, es mas o menos como he comentado pero un poco mas complejo.

Bueno busco un compañero (uno? ... xD) que se atreva con la electronica, porque tengo ganas de meterle al puerto de DS algun pic (es lo unico que podemos encontrar por españa) y dedicarme a enviarle comandos al pic. El problema mas grande que tengo es que no comprendo (no hay tampoco mucha info) el protocolo de la DS para el puerto de DS, asi que si alguien ya ha trasteado un poco con el, yo tambien quiero. [Modo elucubraciones ON] Aun asi, si la DS usa el SPI para comandos, no debe ser muy dificil de ponerlo a funcionar, simplemente coger el pic que soporte SPI y conectarlo a esos pines y a tirar[/OFF]