Jimmyhoo escribió:sobre GBA, se te a ocurrido que tal vez(y digo tal vez, desconozco el hard de la GBA) que esta lee los estados por medio de una comunicación especifica que no varia entre revisiones y que el arreglo de comunicación con los chips de cada revision es a nivel hardware y que es la comunicación con los chips a nivel hardware la que varia? y que entonces el chip dice hey hola aqui hay una cruzeta y el gba mapea una cruzeta virtual llamada "cruzeta 0" y esta atenta a los cambios de estado de indique el chip y cada boton que se encuentra en secuencia es asignado como boton 0 = start, boton1 = a, boton 2 = b, etc, digo eso permitiría agregar mas botones a gusto de nintendo(si fuera necesario) y los juegos deciden que botones usan asumiendo que cuando menos existe la cruzeta 0 y n botones, por que si cada juego esta programado para una comunicación especifica con un chip, ¿entonces dejarian de funcionar en revisiones posteriores no crees?
te recomiendo que leas la sección "BIOS Halt Functions" del link que incluiste
Si solo son botones es muy fácil asignar una dirección de memoria a cierto botón a pesar de que los circuitos son distintos. Si lo pones por infrarrojos ya se complica muchísimo la cosa.
Si haces una revisión, te aseguras de que funcione exactamente igual que la consola anterior, no hay mas que hablar. Cada juego está programado para leer el estado del controlador de una direccion de memoria, el chip que uses es indiferente mientras trabaje igual que el anterior.
Si, la función de la bios de halt funciona distinto en una ds en modo gba y en una gba real, pero es el único caso en el que sucede algo parecido, y porque el procesador no es exactamente igual. No tiene nada que ver con un controlador extra o no.
Jimmyhoo escribió:los mandos generalmente trabajan por sobre una especificación, es decir ellos "dicen" ser un mando al aparato y mencionan lo que tienen(botones, crucetas, joysticks), por ejemplo en PS3 puedes conectar un mando de PC y funciona(salvo que exista un problema con la identificación del dispositivo), los juegos se configuran en base a lo que se indica que esta disponible, existe un control 0? un control 1? tiene una cruzeta? y se asginan a ellos el como este conectados, los juegos pueden no usar los botones o no usar controles con identificadores desconocidos(evitar usar la guitarra de rockband por ejemplo)
los archivos que mencionas io.c e io_wii.c asi en una vista rapida(no son muy grandes) funcionan parecido a por ejemplo SDL, tienen a donde referirse como control, leen el id del joystick y se configuran como tal, tienen estructuras, leen eventos, etc, me pare normal y no me parece que exige el uso especifico de un puerto, por ejemplo "wm->handshake_state" lee de una estructura un estado del control y esta estructura "wm" es usada en ambos archivos para leer los estados, esto es independiente de si es por bluetoot, usb, etc, revisa si no te equivocaste de archivo o si me equivoque ¿podrías decírmelo y decirme que linea no revise?
En una consola portatil no tiene ningún sentido trabajar así, mas que nada porque ya sabes exactamente los controles que tienes. Nintendo en ningún momento pensó en añadir el segundo stick mientras la diseñaba, es absurdo meter un cacho de código que complique a los desarrolladores cuando no es ni necesario.
Si te fijas, esas estructuras hay que pasarlas como argumentos. El programador reserva ram para que le pasen los datos ahí, no es que estén fijas en algún lugar de la memoria. En io_wii.c hay funciones (wiiuse_io_write, __wiiuse_connected) que usan otras con el prefijo bte_, que son las funciones que están en el archivo bte.c de
aquí y son las correspondientes al bluetooth. Para un programador de juegos, esto es indiferente, solo le importan las structs de las que hablas, pero todo el código de bluetooth sigue estando incluido en el juego aunque no se de cuenta.
Recuerdo que cuando empezó la scene en Wii hubo que esperar un par de meses a que se programara el código necesario para comunicarse por bluetooth con los mandos. Si solo hubiera que leer de una dirección de memoria no se hubiera tardado nada, ¿no?
Jimmyhoo escribió:que bueno que no fueron tan "tontos" de agregar la lectura de un periferico al firmware por medio de un update ..................
Daría igual, los juegos que salieran antes de la revisión no usarían el firmware para leer del periférico o de la propia consola.
Jimmyhoo escribió:¿me puedes pasar el link donde leiste eso?
No lo he leido en ningún lado, es una deducción mía viendo lo que ha hecho nintendo anteriormente. Si en la Wii tenía sentido hacerlo como dices (se podía actualizar para dar soporte a otros dispositivos) y no lo hicieron, en una portátil, que siempre es igual, que si hay un dispositivo nuevo lo van a usar 2 o 3 juegos, es mucho menos probable que lo hicieran. Vamos, es que es ridículo que algo que ocupe unas pocas líneas de código lo metas en la bios, ejecutar codigo de la bios suele ser bastante mas lento que de la ram, y si encima solo hay que poner 2 lecturas y 2 operaciones, no tiene ningún sentido ponerlo en la bios, tardas mas en llegar al código que en ejecutar el codigo.
El circle pad pro es un extra. No es imprescindible para jugar, y mucho menos necesario para la consola. Los juegos que lo usan llevan librerías extra para darle soporte. Si sale un aparato como en el guitar hero de DS, habría librerías extra para usarlo. No tiene mas misterio. Si tu no me das argumentos para que saque otras conclusiones, doy por buenas las mias, ya que tengo suficientes argumentos para apoyarlas. No me vale como ejemplo un ordenador, que tiene que dar soporte a miles de aparatos. Tampoco me vale como ejemplo una consola de sobremesa de la competencia, Nintendo siempre trabaja a su manera. Estamos hablando de una consola portátil, que es así, y que va a seguir siendo así. ¿Por qué habría que complicar las cosas desde el principio si no sabes que van a querer añadir mas botones? ¿Por que vas a acceder a los botones por identificadores cuando puedes saber exactamente el estado de todos los botones por su nombre real? Si no hubiera llegado ninguna compañía dando por saco pidiendo mas botones no se hubiera puesto ningún segundo stick. Si una compañía pide eso, que se apañe y añada el código extra, ya ves tu que problema...
Por tanto, poner el stick en la propia consola sería bastante mas lioso que simplemente conectar un par de cables.
![[chiu]](/images/smilies/nuevos2/karateka.gif "karateka")
![[rtfm]](/images/smilies/rtfm.gif "Lee!")
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
![[ayay]](/images/smilies/nuevos/sonrojado_ani1.gif "enrojecido")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[angelito]](/images/smilies/nuevos/angelito.gif "angelito")
