Señor Ventura escribió:wwwendigo escribió:NewDump escribió:Si no recuerdo mal tenían pensando un Motorola MC68000 a 10 MHz, por la CPU que finalmente integraron, un Ricoh 5A22 a 3,58 MHz basado en el Motorola WDC65816.
Para nada, de hecho el Ricoh es diametralmente opuesto a lo que es un MC68000 como cpu, no se parecen ni en el color de los ojos, tienen conceptos radicalmente opuestos como cpus CISC. El motorola tiene una arquitectura ortogonal, con una cantidad de registros alta, que tira bastante de microcódigo y demás. El ricoh está basado en una arquitectura centrada en un único registro acumulador genérico (más auxiliares varios), no usa microcódigo para nada, tiene un set de instrucciones más compacto y reducido pero muy rápidas de ejecutar (no usa microcódigo), y es casi como comparar el concepto RISC vs CISC, pero entre dos cpus CISC muy distintas.
El Ricoh 5A22 es una versión del WESTERN DESIGN CENTER WDC65c816, no tiene nada que ver con motorola, de hecho tiene que ver con las cpus de MOS Technology, y que es una evolución de justo el 6502 ya visto en la NES normal (sólo que a mayor frecuencia, en 16 bits nativos, y alguna mejora extra).
Dudo mucho que se plantearan ningún 68K para la SNES cuando el uso del Ricoh está claro que favorece el portado de código de juegos de NES a SNES, facilitando mucho la tarea para los desarrolladores acostumbrados a NES, y la reutilización de código con pocas alteraciones ya existente en las "librerías" de cada desarrolladora. No hay que olvidar que entonces básicamente se escribía todo en ensamblador, y por tanto el código estaba muy unido a la arquitectura de la cpu y sus puntos fuertes. Portar código para la línea de cpus que derivan del MOS 6502 es más o menos fácil, partiendo de él, pero en el caso del 68K de motorola, implica en muchos casos escribir de cero cada rutina, otra vez.
De hecho, para la profundidad que tenía el software de estas máquinas, un 65816 a 10mhz tiene que rendir mas que un 68000 a 10mhz.
Lo del 68000 para la snes es un bulo, pero me pregunto si no se les pasó poner un 65816 a mas frecuencia... aunque deduzco que siendo tan dependiente de su pipeline, se les tuvo que quitar las ganas al tener que incluir también una WRAM a 10mhz y una ROM a 10mhz para que el esfuerzo de meter semejante procesador tuviese sentido. Gastarse el dinero en meter un 65816 a 10mhz para mantener la WRAM a 2,68mhz, es tirar a la basura los presupuestos ^^u
Lo que hubiera sido una snes con semejante configuración... 65816 a 10mhz, WRAM a 10mhz, ROM a 10mhz, multiplicaciones del PPU1, super FX a 21mhz como PPU3...¿Hubiera sido contraproducente incrementar el precio final a cambio de esas prestaciones?, ¿cuanto hubiera supuesto para el precio final?. Solo el super fx eran 10$, pero el resto de componente no tengo ni idea de en que precios se movían...
Lo tendrían fácil, lo sacan en el 94-95 como
Super NES NEO y a vender como churros.
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
Lo del 68K claro que es un bulo, es una arquitectura muy distinta y está claro que metieron el rico porque vieron las posibilidades y facilidades para los desarrolladores de NES. Facilitar la adaptación de títulos es algo que se hace muy evidente en las intenciones de Nintendo, el 65c816 hasta podía ser binariamente compatible con el 6502 (de hecho arrancaba así, en modo 8 bits y siendo básicamente un 6502 vitaminado, había que pasarlo a modo de 16 bits después de esto para aprovechar los registros extendidos y las nuevas instrucciones).
De hecho no creo que sea coincidencia la "baja" resolución típica y más usada de la SNES, ya que es la misma que la de la NES (facilita la conversión de gráficos de una máquina a otra, reduciendo el tiempo necesario de trabajo para el desarrollador, hay que pensar que entonces no se trabajaba con máquinas tan potentes ni con soft tan capaz como ahora para retocar los gráficos etc, y había muchas cosas que se hacían básicamente a mano).
Y sí, por lo menos tiene toda la pinta que Nintendo, por lo menos con el SA1 sí pudo haberlo incorporado en la máquina como cpu principal (o coprocesador, pero por costes y facilidad tendría más sentido lo anterior), es que siendo como era un chip bastante potente y todo, ya estaba planificado como una de las principales opciones para ampliar la SNES en sus orígenes, al igual que el DSP1 (el super FX sin embargo puede ser visto como algo "inesperado", o por lo menos fuera de la pipeline de tiempo de diseño y lanzamiento de la consola), pero aumentaría algo los costes, y Nintendo no está en el negocio por amor al arte, por mucho que otra gente piense lo contrario. Y desde luego tiene alergia a eso de vender consolas a coste o pérdidas.
NewDump escribió:@eknives La mayoria de los juegos de GBA está programados usando el modo THUMB del ARM (juego instrucciones reducido de 16bit)..
solo maneja unos pocos registros de 32bits.
El bus a RAM y OAM son de 32bits pero el de los cartuchos ROM es de 16 bits. Aun asi, el ARM no puede trabajar en modo ARM 32bit y THUB simultaneamente.
@beertop
Para evitar confusión, el modo THUMB en ARM es en realidad de 32 bits, porque sigue manipulando los mismos registros y éstos son de 32 bits igualmente, no, no son unos pocos, son todos, simplemente que al reducirse el tamaño de la instrucción también se reduce en algunas instrucciones la capacidad de los opcode de elegir toda la ventana de registros de esta cpu, pero eso sólo pasa en algunas de las instrucciones, sigue pudiéndose acceder a toda esa ventana de registros, aunque eso implique que para algunas operaciones haya que ejecutar alguna instrucción extra entre registros, depende del código a ejecutar. Es tan simple como hacer un MOVE entre registros si usas instrucciones que no te permitan seleccionar los registros "altos".
Las ventajas de usar el modo thumb están en que si hay un datapath de 16 bits, el código se ejecuta más rápido al poder mantener un ratio 1:1 en vez de 1:2 de carga de instrucciones a memoria. Y que el código es mucho más compacto, lo cual es útil para ahorrar memoria y aumentar los hits en caché en caso de cpus más avanzadas que la de la mencionada consola (no es su caso, pero compactar el código le puede venir bien, indirectamente, más allá de poder cargar instrucciones a un ritmo de 1:1).
Si no me equivoco la DRAM de la GBA es de 16 bits, la memoria externa no en el mismo paquete que la cpu, la memoria interna (¿que sería la que mencionas? a mí me suena la VRAM y una región de RAM genérica especial) es la que sería de 32 bits. Si sólo fuera asunto de los cartuchos con un bus de 16 bits, seguramente trabajaría en modo de "instrucciones de 32bits" (tamaño, no cualitativamente, ambos modos lo son).
De todas formas, eso solo muestra una cosa en caso de que sea el mismo procesador pero a más mhz, el "chip de apoyo" no es apoyo un carajo, es toda una GBA que por si misma ya es una consola. Y la GBA es mucho más potente que la snes.
Sólo me pregunto con lo buena que era como es que necesitaba tanto chip extra 