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 :D) 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?? XD) 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 :D. 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]
Muy interesante, creo que acercas el lenguaje técnico de la scene y los entresijos técnicos de la consola a gente que no esté familiarizada con este mundillo [oki]

Saludos!! [bye]
gran post.

Muy útil.

Saludos
A mi estos posts me molan,ahora entiendo un poco como funciona esta consola por dentro,y las dificultades para cargar backups :D
Siempre seran bienvenidos por mi parte :)
Saludos!![bye]
Me lo he leído entero y me ha parecido muy interesante.


Otra cosa, desconozco las tasas de transferencia del puerto ds y el puerto gba.

Si el puerto gba es más lento, ahí también tendríamos otro problema a la hora de parchear los ejecutables para que leyesen del puerto gba en vez del puerto ds, no?
Ahora veo todo mucho más claro. ¡Gracias!
Bueno gracias por los posts la verdad es que ayudan a un pobre con insomnio a sentirse mejor :P.

Sobre las tasas de transferencia, hablo de memoria, creo que es algo que ya se discutio en dslinux o gbaforum, se comentaba el hecho de las tasas de transferencia especificamente del DS port (el del gba ya esta muy machacado y salvo sorpresas la DS no sera mas rapida que cualquier gba), nadie dijo nada... si se sabe no se quiere decir y sino se sabe (al menos aproximadamente supongo que tendria que existir algo) no comprendo porque... lo maximo que encontrado yo en ndstech ha sido esto:

"Sequential access time: 140ns (max)", osease tiempo maximo de acceso secuencial, ahora mismo recuerdo que los cartuchos de DS permitian dos tipos de acceso los secuenciales y los aleatorios (si como la RAM), para el que no sepa como funciona una pequeña explicacion aunque por inet hay miles de paginas...

La memoria secuencial es aquella que debe ser leida como una secuencia, un claro ejemplo de esto seria la memoria de cintas (como los spectrum o los grandes servidores de datos .. antiguos servidores XD) asi bien tiene sus ventajas y desventajas, una ventaja es cuando necesitas un carro de datos (una secuencia) simplemente vas leyendo sin preocuparte de donde estas, la gran desventaja es que no puedes leer lo que quieres, sino lo que te da... no puedes volver atras y te tienes que comer todo lo que te viene y seleccionar.

La aleatoria, creo que lo dice su nombre, tu eres el que elige el dato (aleatorio... para la memoria no para ti claro que sabes lo que es) despues la memoria te sirve el dato y sin mas problemas.

Y ahora teorias, hablan de 140 ns maximo, eso ronda los 7Mhz, osease tenemos que nos sirve "algo" cada 140 ns, de esto no he leido mucho... la verdad, pero segun veo en NDSTech, tiene 8 bits de "Data", por lo tanto cada 140 ns segundos nos puede servir un byte, tendriamos una transferencia de unos 7*8(56) MegaBytes/s, esto y teniendo en cuenta que hablamos de 140 ns de maximo (osease que puede ser menos) es la tasa minima de transferencia que tendria un cartucho de DS. Esto teniendo en cuenta que fuera en paralelo(creo que si) ya que los pines 7 y 8 corresponden a una salida y entrada SPI (es un protocolo...) pero creo que son para enviar los comandos y recibirlos que no tiene que ver con la salida de datos. Hay que tener otro dato en la mesa para sopesar esto, aqui dice maximo tiempo, pero el DSCart tiene un modo de encriptacion y eso supongo que reducira la velocidad de transferencia... o tal vez esta sea la maxima velocidad con encriptacion... no se es que faltan muchos datos y por lo que parece ser el chip de los cartuchos de DSCart es poco conocido.

Bueno un poco mas de culturilla :D, el amigo goblino dice algo asi:

Otra cosa, desconozco las tasas de transferencia del puerto ds y el puerto gba.

Si el puerto gba es más lento, ahí también tendríamos otro problema a la hora de parchear los ejecutables para que leyesen del puerto gba en vez del puerto ds, no?


Ejem, tema delicado donde los haya, primeramente porque el puerto de gba puede dar mas de lo que da ahora, y lo que falla son los chips que se usan en la fabricacion de los flashcart (de hay que se hable que si el neoflash y el XG2turbo mejor que otros y bla bla), en cierta manera tienen razon y no, realmente por lo que se estos cartuchos tienen tasas altas de transferencia (dentro de gba quiero decir) pero tambien hay que tener en cuenta cosas, la unica diferencia de primeras seria que la carga de una backup se volveria mas lenta que desde el original en DSCart, ahora bien, podria ser y no quiero eliminar la posibilidad que si hubiera algun problema con algun tipo de juego tipo metroid, que la carga debe estar compenetrada con el juego, ya que a medida que te mueves se van cargando texturas y demas .... y ahi es donde puede joder un flashcart con respecto a un DSCart.

Aun queda mucho camino por recorrer...
Te ha quedado muy bien el post para que la gente que no controla lo entienda [oki] .

Sobre el tema de las tasas de transferencia... no seria problema, ya que la velocidad maxima del cartucho de DS accediendo en modo secuencial son 140ns con un ancho de palabra de 8 bits (en modo aleatorio es mas lento asi que damos por velocidad maxima absoluta esta), mientras que el de GBA (si no recuerdo mal) son 120ns con un ancho de palabra de 16 bits, para se entienda: DS = 140ns/byte, GBA = 60ns/byte (aunque esto ultimo no es cierto realmente, pero para que os hagais una idea), asi que el cartucho de GBA es mas o menos el doble de rapido.
Muy interesante el hilo. Siembre viene bien culturizarse.
Viene muy bien.Muchas gracias,todo muy clarito compañero imsomne.
[oki]
wizardy escribió:Te ha quedado muy bien el post para que la gente que no controla lo entienda [oki] .

Sobre el tema de las tasas de transferencia... no seria problema, ya que la velocidad maxima del cartucho de DS accediendo en modo secuencial son 140ns con un ancho de palabra de 8 bits (en modo aleatorio es mas lento asi que damos por velocidad maxima absoluta esta), mientras que el de GBA (si no recuerdo mal) son 120ns con un ancho de palabra de 16 bits, para se entienda: DS = 140ns/byte, GBA = 60ns/byte (aunque esto ultimo no es cierto realmente, pero para que os hagais una idea), asi que el cartucho de GBA es mas o menos el doble de rapido.


No te voy a contradecir porque no tengo los datos ahora contra la mesa, pero me pareceria una burrada que el cartucho de gba fuera mas rapido que el propio de DS (aunque esto no son datos constatados... sino suposiciones mias) tal vez por eso influya tanto el chip que se usa en la fabricacion de cartuchos... no se habra que mirarlo, gracias por la info :D
ddf escribió:
No te voy a contradecir porque no tengo los datos ahora contra la mesa, pero me pareceria una burrada que el cartucho de gba fuera mas rapido que el propio de DS (aunque esto no son datos constatados... sino suposiciones mias) tal vez por eso influya tanto el chip que se usa en la fabricacion de cartuchos... no se habra que mirarlo, gracias por la info :D


Me gusta este hilo ;), algo de info de los cartuchos de gba, para ver el tema de velocidad de acceso y demás.



http://www.ziegler.desaign.de/GBA/gba.htm

Salu2
Muy interesante, podrian poner el hilo fijo incluso.
El cartucho de GBA me lo conozco bien como funciona ya que me diseñe un cartucho flash y he trasteado bastante, pero sobre el cartucho de DS no se mucho. Lo que si te dire es que estube hablando con DarkFader sobre el tema, y el si sabe bastante XD. Entre las cosas que me conto dijo que los cartuchos de DS son una mierda que ha creado nintendo para abaratar costes y que los de GBA le dan patadas por todos lados, asi que puedes dar por fiable que los de GBA son mas rapidos.
wizardy escribió:El cartucho de GBA me lo conozco bien como funciona ya que me diseñe un cartucho flash y he trasteado bastante, pero sobre el cartucho de DS no se mucho. Lo que si te dire es que estube hablando con DarkFader sobre el tema, y el si sabe bastante XD. Entre las cosas que me conto dijo que los cartuchos de DS son una mierda que ha creado nintendo para abaratar costes y que los de GBA le dan patadas por todos lados, asi que puedes dar por fiable que los de GBA son mas rapidos.


Abaratar costes se llama :P, pero vamos me parece fuerte que un nuevo dispositivo, que en teoria es innvoador, sea peor que el antiguo. Que cosas oye XD

Salu2
Grandioso post, yo aunque soy informático me ha costado seguirte, pero más o menos me he enterado de todo... y tio, se ve que sabes mucho y lo más importante es que sabes trasmitir el conocimiento.

Muchas gracias por compartirlo con nosotros.
Creo que mi curso sobre NDS ha dado una gran zancada gracias a éste post.
wizardy escribió:El cartucho de GBA me lo conozco bien como funciona ya que me diseñe un cartucho flash y he trasteado bastante, pero sobre el cartucho de DS no se mucho. Lo que si te dire es que estube hablando con DarkFader sobre el tema, y el si sabe bastante XD. Entre las cosas que me conto dijo que los cartuchos de DS son una mierda que ha creado nintendo para abaratar costes y que los de GBA le dan patadas por todos lados, asi que puedes dar por fiable que los de GBA son mas rapidos.


Entonces te creo ya de buenas a primeras :D, ademas ahora viendo tu avatar, eres tu el que se curro el passme por no esperar no?.

Bueno sobre los cartuchos de DS, en cierta manera es entendible su bajo rendimiento, ya que tiene que ir criptografiando los datos al vuelo, y eso debe consumir tiempo.
Muchas gracias, gracias a este hilo me voy enterando. Me gusta como lo has explicado (hago informatica y me interesan estos temas :p )

Saludos
Muy bueno y muy interesante el hilo ddf [ok]

Lo he puesto en el indice de articulos / hilos de interes.
Bueno he editado un poco el post y añadido alguna que otra cosa, si veis alguna errata (o informacion que no es como yo creo/leo) sentiros libres de corregirme.

Por cierto, espero alguna contestacion al ultimo comentario sobre la busqueda de un compañero. Hay que mover un poquito la scene española coñeee...
interesante que he encontrado, aunque seguramente algunos ya lo conozcais..

http://www.bottledlight.com/ds/index.php/Main/HomePage

Por cierto en la parte de Hardware -> DS protocol, no viene info de ningún tipo, solamente un bonito Password required.

Pero bueno el resto de información no esta mal.

Salu2
ddf escribió:jugando con otros 16 (cuanto era el maximo de links que permitia?? )


Pues la verdad es que la gba solo soporta 4 jugadores xD
Buenisimo post, muy util [oki]
Dios mío... he entendido algo [carcajad]

Chico, vete pensando en ir a dar clases de lo que sea a Harvard [+risas]
23 respuestas