Ricoh 65C816 vs Motorola 68000 desde la OBJETIVIDAD (patio de colegio OFF)

Yo empecé a programar ensamblador en el 680020 de 32 bits (tanto en ALU interna como en buses externos), que es el que se usaba en mi escuela de teleco allá por el 2000. La verdad es que sí es cómodo de utilizar, ya que tiene muchos registros (creo que 16, la mitad de direcciones y la mitad de datos) y se parece bastante al paradigma de programación CISC de los micros de Intel (sobre todo x86).
Lo de la latencia externa era una ventaja en su época, ya que permitía conectar toda una variedad de SDRAM que no hubiera sido posible de otro modo. Y lo de que es compatible con Linux, sólo lo es si tiene MMU, creo que sólo con el modo "supervisor" no vale.

El 65C816 es un micro de ir por casa, bastante más parecido a un microcontrolador con instrucciones RISC que a un microprocesador de verdad. Solo tiene 3 registros, lo cual implica hacer demasiadas operaciones intermedias para llevar a cabo tareas simples. La latencia de los buses externos depende de la longitud del operando, y como el bus de datos es de 8 bits, pues traerte un byte de una dirección de 24 bits implica traer primero los 3 bytes de la dirección, y luego ya acceder al dato. En el Motorola podrías tener la dirección dentro de un registro y hacer indirección, lo cual es más rápido a priori, pero tiene el inconveniente de que traer ese dato de la memoria tarda varios ciclos.

La verdad es que ambos micros no son comparables, el 68000 para mí es mucho más versátil, pero para el caso que nos ocupa de las consolas, no sirve de nada la versatilidad si luego no está acompañado del hardware que saque la potencia máxima. Es decir, el 65816 es menos potente pero la PPU que lo acompaña hace auténticas virguerías.

Estaría interesante tener una SNES en una FPGA y poder cambiar el microprocesador 65816 por un 68000 a ver cómo se comportaba. Claro que eso implicaría tener el código fuente de algún juego accesible para compilarlo con el 68000...

Lo ideal sería programar algún test sintético (como por ejemplo Dhrystone) para ambos procesadores
y ver los resultados.

Aquí aparece una pequeña comparación:
http://westerndesigncenter.com/wdc/AN-0 ... risons.cfm

Respecto al tema de porqué se utilizó más el M68000 pues supongo que porque sería más fácil
encontrar a gente que programara para ese chip, por modas, por precio, disponibilidad... en esos niveles
no creo que nadie tenga en cuenta si un procesador es mejor o peor para programarlo (que ya sufran
las consecuencias de nuestras decisiones los desarrolladores jaja)

zarkon escribió:Aquí aparece una pequeña comparación:
http://westerndesigncenter.com/wdc/AN-0 ... risons.cfm

No la conocía, pero es muy interesante; los resultados que se ven al final reflejan la diferencia entre arquitecturas RISC (65C816) y CISC (68000), pero es una comparación sintética, puesto que no tiene en cuenta el algoritmo que estás programando.
Por ejemplo, una rutina VWF que se puede ver en cualquier juego de ROL necesita de muchos accesos a RAM para traer cada línea de píxeles de la letra; con el 68000 podrías traerte la línea de píxeles con mayor lentitud que el 65C816, pero una vez almacenada en el registro R0 del 68000, podrías desplazarla, hacer su sombra por arriba, por abajo y por la derecha y almacenar cada resultado en R1, R2 y R3. Luego almacenas el resultado en la salida de RAM, y la siguiente línea de píxeles que te traes ya tiene los resultados de la sombra de la línea superior en R2. Así te ahorras almacenar los 2 planos de píxeles en 2 ciclos como haría el 65C816, y para cada línea de píxeles, te ahorras traerte la sombra de la línea superior, por lo que en 68000 te podrías ahorrar 2 ciclos de acceso a RAM almacenando resultados intermedios en los registros disponibles, por lo que hace más ligero el algoritmo.

magno escribió:Estaría interesante tener una SNES en una FPGA y poder cambiar el microprocesador 65816 por un 68000 a ver cómo se comportaba. Claro que eso implicaría tener el código fuente de algún juego accesible para compilarlo con el 68000...

Y luego hacer la misma prueba con el 65816 funcionando a la misma frecuencia que el 68000.

@Sexy MotherFucker una pregunta y mi opinion acerca de las cpus ,despus con otra pregunta
¿mega drive ,neo geo y x68000 comparten cpus verdad?

@titorino sí, a diferentes frecuencias, pero en este hilo harías mejor en dirigir tus dudas hacia gente como magno, gasega, o wwendigo, que son los que tienen experiencia de primera mano con el M68k.

Cuando pueda opino, muy didáctico e interesante todo lo expuesto.

Sexy MotherFucker escribió:@titorino sí, a diferentes frecuencias, pero en este hilo harías mejor en dirigir tus dudas hacia gente como magno, gasega, o wwendigo, que son los que tienen experiencia de primera mano con el M68k.

Por la noche opino, muy didáctico e interesante todo lo expuesto.

La pregunta es muy simple.
Veo que haces mucho incapie en la cpu, que aunque es importante, opino que no es lo más importante, si no como esta acompañada esa cpu.
Veo juegos de neo geo o x68000 y el resultado es muy muy superior a lo que veo en megadrive.
Y si, la frecuencia es más alta en esas dos máquinas.
¿Pero no es fundamental con que lo acompañes?
Esto viene a relación a la cpu de Snes, que si no estoy mal informado se complementa con otros chips o microprocesadores.

@titorino de eso no va este hilo, sino de hablar en bruto sobre el potencial real de estos procesadores en cualquier tipo de hardware al margen de sus complementos. Por eso no he iniciado este debate en el patio de colegio, para no andar comparando consolas fanboys sino micros, y si acaso puntuales usos exclusivos en algún hardware concreto.

Pero vamos; por supuesto que es más importante un diseño global equilibrado que una CPU, o GPU tochas descompensadas. Concretamente lo que asfixipa tanto a SNES como a MD son sus DMAs limitantes, a lo que en la consola de SEGA se suma el agravante de la escasa paleta. Neo Geo a diferencia de ellas se folla directamente las roms del cartucho como quiere, y estrella los gráficos contra el monitor sin preocuparse del ancho banda, el cual le sobra, y sudando de la vram para poco más que las nametables.

Y ahora reconduzcamos el tema please.

@Sexy MotherFucker gracias por aclarar la duda.
Perdón si he cometido algún off-topic

@magno , pues yo tengo una curiosidad sobre lo que has dicho de probar con el Motorola en la SNES. Se que si no lo pruebas, no lo puedes saber, pero bajo tu propia experiencia y conocimientos, ¿cómo sería una SNES con el Motorola de la MD?, ¿Ganaría?, ¿Perdería?, ¿No nos daríamos cuenta?

Gracias!.

Joder, ya me estáis metiendo en fregados...

Sexy MotherFucker escribió:@wwwendigo @gasega68k @magno , os invoco a este hilo para despejar algunas dudas y enterrar ciertos retro-mitos aprovechando que sois personas con experiencia y conocimiento sobre estos dos procesadores, ya que el seguir repitiendo dogmas fanboys desde la ignorancia no nos hace ningún bien a ciertas edades, ni al foro en general.

He querido debatir este tema en un hilo aparte para alejarnos del tóxico contexto SNES vs MD, dejando a un lado el ambiente de «patio de colegio», y estudiar a estos procesadores desde un punto de vista genérico como micros dentro del contexto de la época en que eran usados masivamente por muchos dispositivos. A vosotros os pido ante todo HONESTIDAD, y que no os dejéis llevar por animadversiones o preferencias personales.

Si bien he leído mucho sobre ambos chips, y debatido por épocas en foros de retroinformática, no voy a extenderme mucho; simplemente enumeraré las afirmaciones que desde mi (aún) básico conocimiento entiendo que son indiscutibles, y a partir de ahí vosotros expandís, corregís, o respondéis en la medida de lo que queráis/podáis.

Vamos al lío.

Venga, mi opinión será sincera por lo que he visto de ambas cpus.

MOTOROLA-68.000:

Ventajas

- Lenguaje Ensamblador amigable. Todos los programadores con los que he hablado del M68k, entre ellos David Senabre Albujer (creador de los reportajes «La Carrera de los Bit y los Mhz») me han acabado diciendo lo mismo; el ensamblador del 68000 es muy cómodo, fiable, y relativamente fácil de pulir código a bajo nivel en comparación a otros más complicados, hubo un tipo en un foro anglosajón que lo describió como; «un buen lugar en el que estar a la hora de programar».

- No penaliza demasiado en C, por lo que se consiguen resultados aceptablemente óptimos con este lenguaje.

- Tiene un juego de instrucciones muy completo teniendo en cuenta su antiguedad, lo que lo hacía versátil y cómodo, además de ser compatible con sistemas operativos más modernos como Linux.

- Tiene un bus externo de 16 bits, lo cual hace que pueda llevar desde una memoria hasta la cpu valores de 16 bits con los que operar en un solo viaje. Entiendo que también lo vuelve más práctico a la hora de acoplarse a placas de la época.

- Sus registros de 32 bits son útiles para... ¿Cargas de trabajo muy pesadas?

- Las operaciones de punto fijo la hacen apta para optener resultados decentes en materia poligonal a una buena frecuencia, mismamente me parece loable lo que consiguió Gasega en su demo de StarFox usando un M68k a unos irrisorios 7,67 Mhz. Ya a 16 mhz, el ordenador Sharp X-68.000 consigue esto en videojuegos como Geograph Seal:

https://youtu.be/pNYLREOG52k

Ahí ya vemos colisiones, una velocidad de movimiento notable, cierta IA enemiga, y físicas; aunque ni idea de hasta qué punto tiene que ver el rendimiento vectorial con el sistema gráfico del Sharp.

Contesto punto a punto:

1.- Más que el lenguaje ensamblador amigable lo que tiene es una arquitectura amigable para programarla en ensamblador, que no es lo mismo. Es una cpu con un número de registros, un conjunto de instrucciones y una ortogonalidad en las instrucciones que no era para nada típico en los CISC, por lo que era fácil aprender dado que no te exigía aprender que tal operación usaba como acumulador tal registro porque sí, y una variante estaba penalizada si usabas otros registros diferentes a X, etc. Tenía 16 registros generales y 16 registros para direccionamiento, lo cual lo hacía más flexible, y de aquí parte la respuesta al segundo punto:

2.- No hacía falta compiladores C sofisticados para obtener buenos resultados dada la riqueza de registros y ortogonalidad de la cpu.

3.- El bus de 16 bits era típico en cpus de la época, no era una "feature" especial, de hecho si no me equivoco había un 68000 que se montaba en un bus de 8 bits para datos (¿el 68008?), tiene que ver más con el tema de ahorro de costes y "normalmente" no influía negativamente en el rendimiento (por ejemplo, la comparación del 8086 contra el 8088, normalmente iban igual en casi todo tipo de escenarios, ojo, casi pero no todos).

4.- Los registros de 32 bits están ahí para dar soporte a las instrucciones de 32 bits. Es una arquitectura que estaba pensada desde cero para saltar a los 32 bits (de hecho técnicamente ya estaba ahí desde el primer día), eso sí el coste es que rinda más o menos la mitad de lo que rinde en 16 bits, y gracias. No están ahí para juegos precisamente, este tipo de registros son útiles para programas de corte más profesional, es bueno tenerlos desde el punto del desarrollo de aplicaciones avanzadas, pero en casos particulares y más en juegos no sirven para nada (por lo menos no aún en esa época).

5.- Sí y no. Hay formas de hacer render 3D sin usar punto fijo y usando enteros, pero entiendo que al usar punto fijo es más fácil y directo. De todas formas decir que el punto fijo es la coma flotante de los pobres, realmente no es muy preciso y hasta se puede sufrir una cierta pérdida de precisión por reducir la densidad informativa del tipo de dato (muchas veces se combina el uso de BCD con el formato de punto fijo, y ahí se pierde precisión extra y limita el rango de valores posibles).

Pero sin duda para máquinas de por sí limitadas es una ventaja para estas labores. Otro asunto es que la potencia pura y dura no sea muy para allá para al final usar 3D con estos procesadores.

Si además hablamos de consolas metemos en la ecuación el pedazo de embrollo de usar un sistema de sprites para mostrar la pantalla, lo cual complica y mete carga extra a la cpu con conversiones de bitmap a sprites. En ese sentido si quieres máquinas basadas en el 68000 para ver juegos en 3D, mejor te vas al Amiga o al AtariST.

DESVENTAJAS

- Sufre de una latencia horrible, es unànime donde trate de informarme. Tarda hasta 4 ciclos externos (32 mhz) en operar externamente; ¿Esto es así con cualquier tipo de memorias o bus externo? Internamente también he leído que necesita muchos ciclos para ejecutar multiplicaciones y divisiones, mismamente Fonzie (programador de Paprium) dijo en una entrevista que el 68.000 que monta la Megadrive era extremadamente lento (7,67 Mhz) para aprovechar esas instrucciones pragmáticamente, concretamente dijo; «olvidaos de utilizar la multiplicación mejor». ¿Estáis de acuerdo con él, consideráis que en un M68k a tan baja frecuencia no es conveniente usar m/d? ¿A qué velocidad creéis que debe estar clockeado para que esas instrucciones se ejecuten con la ligereza y solvencia adecuadas? ¿Qué se supone que puede hacer una MD con multis/divs; scaling, rotaciones por software, qué? Tened presente que Fonzie programa principalmente en C, aunque toca el ASM cuando lo ve conveniente.

Tarda un mínimo de 4 ciclos de reloj en hacer una simple suma entre dos registros de enteros, y a partir de ahí sube la cuenta en número de ciclos necesarios. Las operaciones de mul y div son increíblemente lentas ya que se van a cientos de ciclos de reloj para ejecutarlas. NO son usables por tanto para nada que exiga algo de potencia de mul o div (las divisiones de todas formas siempre se han evitado, incluso hoy en día no son recomendables usarlas demasiado, pero no hay punto de comparación entre antes y ahora).

Yo NUNCA usaría ambas, más que nada porque la cpu es de una frecuencia bastante modesta y básicamente tiene un multiplicador muy básico para ahorrar transistores (ya habían gastado muchísimos transistores para el resto del diseño, e incorporar un multiplicador sofisticado en la cpu disparaba aún más la cuenta, así que metieron un multiplicador muy básico de muy pocos bits por pasada que necesitaba a su vez hacer muuchas pasadas, o sea, NO lo uses si no lo necesitas o hay otro camino).

A ver, para documentar un poco el tema:

http://oldwww.nvg.ntnu.no/amiga/MC680x0 ... ndard.HTML

Pues ya se ven los tiempos necesarios. unos 150 ciclos para una división y 70 ciclos para una multiplicación. Los tiempos mínimos para la multiplicación comienzan en casi 40 ciclos, si tienes suerte, demasiado lentas.

Para comparar la cpu SA1 basada en el 65c816 necesita entre 5 y 6 ciclos para ambas instrucciones, mucho más rápida en este caso (el SA1 es un "SoC" en cierto aspecto, e incluía una unidad especializada para realizar esto, por cierto SE SUPONE que con la SNES se puede usar los SPPU para realizar estas operaciones, y además con baja latencia, lo que pasa es que no es una característica muy documentada y evidentemente debe ser complejo tener que usar el procesador gráfico para que te machaque multiplicaciones mientras haces otras cosas ).

Está claro que la multiplicación y división están para dar soporte a programas avanzados que la necesiten para cálculos esporádicos, pero no para usar de forma masiva.

- Por lo visto es un poco rígida para las microinterrupciones y no sé qué más. Tengo entendido que 68010 se lanzó para subsanar parcialmente algunas de estas taras, consiguiendo un 10% más de rendimiento que su predecesor a la misma frecuencia.

Pregunta; ¿Por qué en vuestra opinión fué el procesador de 16 bits más célebre, popular, y utilizado?

- Lo eligieron ATARI, AMIGA, o SHARP, para montar sus ordenadores personales de 16 bits. Y APPLE creo recordar que también lo incluyó en algún modelo.

- SEGA los incluyó en todas sus recreativas de 16 bits (hasta 2 y 3 micros para las especializadas en scaling), también en la placas de 32 bits como la STV, y en sistemas domésticos como la Megadrive, el Mega CD, o la propia Saturn.

- SNK y CAPCOM coronaron sus placas de 16 bits más potentes con Motorolas a diversas frecuencias; amén de muchas otras compañías para construirse sus propios custom en arcades.

¿Hubos más usos destacables del procesador fuera de los videojuegos y la informática?

Fuera de lo de las microinterrupciones, que no lo sé, fue elegido por su juego de instrucciones y registros, y porque seguía el diseño de lo que se soñaba a finales de los 70 de: "A mainframe on a chip". Motorola tenía ya prestigio por su 6800 (con el que no tenía NADA en común, de hecho la cpu de la SNES sí lo tiene ), porque permitía en sistemas de 16 bits acceder a las ventajas del soft de 32 bits si era necesario, y.... como si fuera esto poco para elegirlo. Con chapuzas como el 8086 campando y reinando, lo raro sería que no hubiera triunfado y más viniendo de la mano de motorola.

Ricoh 65816

Ventajas

- Tiene una latencia extremadamente baja, ya que sólo necesita 1 ciclo de espera (8 Mhz) para poder operar externamente, e igualmente necesita muy pocos ciclos para ejecutar eficientemente su reducido set de instrucciones.

- Por lo visto es muy flexible y rápida realizando microinterrupciones.

- Opera con instruciones de 8 bits muy eficientemente.

No conozco más ventajas.

Latencias de ejecución de instrucciones MUY baja, es normal que sólo necesite 2-3 ciclos de reloj para terminar ciertas instrucciones básicas mientras otras cpus se iban al doble o más allá (CISC).

Es consecuencia de su diseño "hardwired" contra microcódigo, NO tiene ni un sólo opcode que vaya contra microcódigo, todas y cada una de las instrucciones que puede ejecutar están codificadas directamente en el hard y se ejecutan sin necesidad de realizar varias operaciones comandadas por un "miniprograma" (por llamarlo de alguna forma) que sería el microcódigo usado para ejecutar muchas instrucciones en otras cpus CISC (el 68000 mismamente).

Por eso también tiene muchos menos transistores, por no depender de microcódigo y limitarse a instrucciones necesarias y no dar soporte a instrucciones complementarias que se pueden realizar por el programador con las otras más simples.

Página cero. Una zona de memoria especial con poca penalización para usar instrucciones directamente contra memoria (+1 de latencia contra usar sólo registros). Se puede ver como una ventana enorme de registros (cientos), por lo que lo precario que es el procesador a primera vista (sólo un registro acumulador) cambia radicalmente cuando miras la página directa / cero del mismo. Desde el 6800 hasta esta cpu han seguido un diseño de trabajo directo contra memoria en vez de registros que es lo que diferencia radicalmente a esta cpu de la de motorola, y desde el 6800 pasando por el 6502 y pasando por esta cpu han seguido la misma filosofía de crear cpus que funcionan "síncronas" con la memoria (entonces era normal que la memoria fuera igual o más rápida que las cpus) y que usaran esta sincronía para acceder muy rápido a ésta y usando esta área especial de memoria como "registros" totalmente reprogramables (ya que es un área de datos que tú usas como datos que a ti te apetezca definir, char, int o struct, etc).

Si no se sabe o entiende bien cómo usar la página cero estás tirando a la basura el rendimiento de esta cpu, está pensada para usarla y es un cambio radical respecto a 68000 o incluso x86.

Muy bajo consumo, por su diseño hardwired, y facilidad de integración por varias razones (frecuencia, modo de funcionamiento contra memoria, etc).

Desventajas

- Tiene un bus de 8 bits, lo cual limita su rendimiento potencial a la mitad cuando tiene que llevar valores de 16 bits con los que operar, ya que tiene que leer dos veces la memoria.

- Poco rendimiento bajo C.

- Está capado de instrucciones.

No conozco más desventajas

Pregunta; ¿Por qué el micro de 16 bits menos empleado y más vilipendiado de su generación?

El bus de 8 bits limita según qué programa, el hecho de que esta cpu saliera con él y sin implementación especial para usar bus de 16 bits apunta a que no era muy necesario, por lo menos no con la mayoría de programas usados. Ya te digo que había otros antecedentes incluso con variantes del 68000. Su rendimiento no se reduce a la mitad por usar datos de 16 bits, ya que realmente sólo se añade un ciclo de reloj como máximo extra para cargar el dato, y en realidad esta cpu es especialmente rápida accediendo a memoria y sobre todo a la página cero. Si puede realizar en paralelo la carga de un dato mientras procesa una instrucción anterior aún menos (no lo sé, pero el 68000 tiene algo parecido, aunque le viene bien dado que ésta tarda más ciclos en acceder a memoria ).

Las instrucciones no están capadas, es que no usa microcódigo, todas las instrucciones implementadas están de una forma que se intenta optimizar al máximo con la circuitería necesaria, no hay secuencias de operaciones comandadas por instrucciones que vayan por microcódigo. Es un diseño que pretende una cpu de 16 bits lo más rápida posible con los mínimos transistores posibles y prescindiendo de todo aquello que no sea estrictamente necesario. Sí, puede recordar a la filosofía RISC, pero NO es RISC.

Sobre lo de C, depende todo del compilador. La cpu tiene sus peculiaridades como su único registro acumulador y en general no demasiados registros para otras cosas (pero ahí era más "normal que con los registros generalistas al mirar a otras cpus de 16 bits), y un buen compilador debería de ser capaz de generar código bueno con esta cpu si tiene en cuenta cosas como la página directa. Pero si no tiene en cuenta estas cosas evidentemente puede dar mal código, en principio C no es tan distinto del ensamblador una vez te fijes un poco en cómo funciona el lenguaje, cómo se llama a las funciones en realidad, cómo funciona la pila, etc. Así que no es un problema muy real, lo que sí podía ser es que hubiera malos compiladores C en esa época para esta cpu. Un mal compilador o directamente uno muy básico y genérico haría peor trabajo con el 65c816 que con el 68000, que era más fácil de aprovechar por su abundancia de registros.

También si un compilador tenía un código de mierda para implementar instrucciones como mul, pues penalizaría de forma extra. La mayoría de operaciones en C tenían una correspondiente en ensamblador del 65c816, pero en caso de usar operadores como el de multiplicación evidentemente en este caso tenía que generar una secuencia de instrucciones muy larga para simular la multiplicación. Si no estaba optimizada podía dar peores resultados que picando el código directamente en ensamblador, y aún mucho peor que usando la implementación pobre pero existente de mul del 68000. De hecho esta cpu era bastante buena con operadores de bits así que en realidad con un compilador C medio decente debería ser bastante buena (eso no quiere decir que mejor que el 68000, sólo que el problema no está en la cpu).

Si alguien me dijera un lenguaje de programación de más alto nivel que C, pues aún lo entendería, pero es que casi puedes imaginar el código ensamblador que se genera de una función en C ahí te fijes, vamos. Al 68000 lo que sí que le ayuda es su gran número de registros de direcciones para esto, pero de todas formas, si x86 funcionaba bien con C teniendo la arquitectura que tenía..... pues eso. xD

¿Menos usado, vilipendiado? Fuera de los forofos de sega (y sólo porque lo usó nintendo, no nos engañemos) no fue precisamente vilipendiado. De hecho sigue habiendo foros de gente que le siguen dando caña ahora, ya sea para programar para Apple II u otra máquina.

Se usó en ordenadores tan populares como el ya mencionado Apple II, y muchos otros productos, después durante los 80 fue tomando un papel como microcontrolador gracias a su sencillez, pocos transistores necesarios y muy bajo consumo. Eso y que el tema de la página directa de memoria... qué cojones, es que parece que eso se adaptaba como anillo al dedo para microcontrodores.

Perdió popularidad antes que el 68000 porque era una cpu de 16 bits pura, no una mezcla de 16 y 32 bits, y porque no tuvo una serie de sucesores como sí tuvo el motorola explotando la capacidad de ampliación a 32 bits. Y porque era una cpu un poco "dura" de aprender en un inicio si venías de cpus CISC más normales que siempre acababan intentando mejorar ofreciendo más registros, más instrucciones, más de todo aunque fuera a costa del rendimiento.

Micros poco utilizados o vilipendiados son otros, el Z80000 a pesar de que técnicamente era muy notable, o incluso el Z8000 (que era buena cpu pero no se usó como se esperaba y más viniendo de una Zilog exitosa con el Z80).



Como balance final, el motorola es la cpu más flexible en general y más pensada para multitud de potenciales usos, en un tiempo donde las arquitecturas CISC tenían muchos peros según cuál mirases, introdujo una arquitectura bonita y elegante. No fue el único, Zilog lo hizo pero fracasó donde motorola triunfó, pero eso ya es otra historia.

Al final a pesar de toda la elegancia de su arquitectura acabó comiéndose los mocos, porque intel con su x86 poco a poco, limando un mal punto de partida, le fue superando primero en rendimiento y después en la elegancia de cómo evolucionaba su arquitectura, que "parche a parche" iba eliminando los problemas iniciales.

El 65c816 es una arquitectura de 16 bits elegante a su manera, centrada en el minimalismo y eficiencia, pero pensada para su momento y no para expandirse fácilmente. Principios de diseño como el uso directo de memoria contra el aumento de registros requerían cosas que eran normales en aquel entonces (accceso&latencia a memoria casi a la par de a registros) pero el tiempo demostraría que era algo sólo posible en ese momento, que se evolucionaría en otro sentido. De todas formas WDC ya apuntaba maneras hacia el mercado de microcontroladores, así que se puede decir que su diseño fue un éxito a largo plazo por ajustarse a este mercado también.

@Sexy MotherFucker Con el 68k olvídate de multiplicar y dividir durante el gameplay, salvo que te sobre CPU claro jeje, por eso se usan desplazamientos de bits, luts y trucos varios. Aquí el coste de todas instrucciones del 68k: http://md.squee.co/68k_Instruction_Reference

PD: el coste de usar valores de 32 bits es un 50% superior a usar 8 y 16 bits, hay que evitarlo siempre que se pueda, pero también hay que ver que a veces es rápido y útil, como por ejemplo cuando quieres usar coma fija con un dword en lugar de 2 words.

@wwwendigo Bestial tu aportación.

Que respeto infunde el hilo, viendo como ha salido escaldado titorino ya no hay cojones a postear

Techies only

Voy a meter la zarpa en este post basándome en mi limitada experiencia, así que nadie se lo tome con un post lapidario ni catedralicio xD

Sexy MotherFucker escribió:- Lenguaje Ensamblador amigable.

La arquitectura es la que es amigable. Hace el ASM bonito, estiloso y asequible.

Sexy MotherFucker escribió:- No penaliza demasiado en C, por lo que se consiguen resultados aceptablemente óptimos con este lenguaje.

Bueno, eso depende de muchos factores, empezado por el compilador. No es lo mismo compilar usando GCC con target 68k, que usar, por ejemplo, SAS C, en Amiga.

La eficiencia del mismo código compilado en uno y en otro es bastante bestia, mejorando mucho el SAS C.

Sexy MotherFucker escribió:además de ser compatible con sistemas operativos más modernos como Linux.

Ya hay que tener cuajo para llamar moderno a Linux.

68K fue la primera arquitectura donde se portó Linux una vez que salió del X86. Fue en un Amiga 040.

Idealmente requiere un micro completo, con mmu y fpu, pero te lo puedes compilar sin ello. No conozco su utilidad práctica (dudosa en el mejor de los casos)

Sexy MotherFucker escribió:- Sus registros de 32 bits son útiles para... ¿Cargas de trabajo muy pesadas?

Puedes por ejemplo hacer rutinas que hagan la mayoría de los cálculos directamente en los registros, solo usando el bus para leer los datos iniciales y escribir el resultado final.

También puedes arrastrar 32bit de la memoria de un solo viaje aunque por debajo se hagan dos accesos al bus.

Sexy MotherFucker escribió:- Sufre de una latencia horrible, es unànime donde trate de informarme. Tarda hasta 4 ciclos externos (32 mhz) en operar externamente;

Pues hablamos de 4 o 5 ciclos una suma, unos 80 mul y más de 150 un div con signo.

Siempre que puedo evito multiplicación y división.
Si estás usando múltiplos de 2, puedes usar desplazamiento a izquierda multiplica, a derecha divide.

Samus de Arán escribió:Que respeto infunde el hilo, viendo como ha salido escaldado titorino ya no hay cojones a postear

Techies only

Estaras de coña no?
Solo tenía una duda, que por cierto no era para crear otro versus y ya se me ha resuelto.

Me ha venido a la mente porque hoy he estado jugando al x68000.
Para que yo salga escaldao hace falta más que eso y estoy seguro que sexy no lo ha hecho con esa intención, es más he comprendido perfectamente su postura y no Le quería Joder el hilo.
Mejor dejarlo para gente que sepa

Manveru Ainu escribió:@Sexy MotherFucker Con el 68k olvídate de multiplicar y dividir durante el gameplay, salvo que te sobre CPU claro jeje, por eso se usan desplazamientos de bits, luts y trucos varios. Aquí el coste de todas instrucciones del 68k: http://md.squee.co/68k_Instruction_Reference

PD: el coste de usar valores de 32 bits es un 50% superior a usar 8 y 16 bits, hay que evitarlo siempre que se pueda, pero también hay que ver que a veces es rápido y útil, como por ejemplo cuando quieres usar coma fija con un dword en lugar de 2 words.

Muy interesante ese link. En su momento había mirado documentación para ambas cpus, pero la verdad no sabía que había tanta diferencia a favor del 65c816 en temas como branching, pasmado me ha dejado que sea tan eficiente con esto (porque es algo que debería ser importante precisamente para juegos y el control de IA, físicas, etc). Está claro que si la cpu le limita en algo no es justo con ese tipo de instrucciones, sino otra cosa.

Hay que entender que es a igualdad de reloj, y por tanto lo normal y más en un subforo de consolas clásicas es pensar en ambas cpus con las frecuencias "típicas" en consolas o las habituales al montarlas en sistemas, y en este caso pensar que la de motorola funciona al doble de frecuencia es tanto lógico como conveniente para la comparación. Así se puede adaptar mejor las tablas a los rendimientos que podríamos esperar en dos sistemas que no quiero mencionar (me habéis leído la mente, me refiero a la Neo Geo contra la NES, jajaja).

Está claro que WDC está señalando los mejores casos con su chip (no indica todo tipo de ops) pero sí muestra lo bien que trabaja usando la memoria directamente con operaciones básicas (lo que decía de la página cero o directa) o lo rápido que carga datos desde memoria. El trabajo entre registros internos es el esperable, similar al 68000 excepto cuando hablamos de registros de 32 bits donde lógicamente el 68000 es el doble de rápido porque tiene soporte directo de éstos.

Pero muy curioso el tema del código condicional y que ahí llega a ser más rápido que el 68000 incluso si comparamos a sus frecuencias nominales en las consolas que todos estamos pensando.

Y las interrupciones muy rápidas, la verdad. Pero tiene sentido si se piensa, es una cpu con muy pocos registros y eso ayuda a guardar el contexto al llegar una interrupción.

Aún así seguramente el MC68000 será más rápido en términos generales, pero lo que yo había apuntado antes sobre que no hay que menospreciar a la 65c816 porque es una cpu muy rápida para su baja frecuencia (aunque básica en instrucciones posibles).

titorino escribió:

Samus de Arán escribió:Que respeto infunde el hilo, viendo como ha salido escaldado titorino ya no hay cojones a postear

Techies only

Estaras de coña no?
Solo tenía una duda, que por cierto no era para crear otro versus y ya se me ha resuelto.

Me ha venido a la mente porque hoy he estado jugando al x68000.
Para que yo salga escaldao hace falta más que eso y estoy seguro que sexy no lo ha hecho con esa intención, es más he comprendido perfectamente su postura y no Le quería Joder el hilo.
Mejor dejarlo para gente que sepa

Hombre, que me parece que Samus sí te lo dijo de coña, ¿eh?

Está bien tu pregunta (ya bien contestada) porque sirve para aclarar que las cpus pintan una xxx mierda en muchos de los hechos diferenciadores entre consolas. Que es bueno empezar a pensar que la cpu importa algo, sí, pero no es la que marca esas diferencias que después se ven en funcionamiento.

Que ya lo he dicho antes con otro ejemplo pero lo repito, un Macintosh original contra un Amiga en una demostración de podería gráfico se come un mojón calentito, directamente, no tiene nada que hacer. Y ambos llevan la misma cpu, lo que importa en esos casos son los demás chips que rodean al sistema.

@wwwendigo me imagino que si estará de coña.
Solo decirte que chapó, como dominas.
No sabía que era tan complejo este mundo.
Y que muchas veces ponemos algún juego y programa y no tenemos ni idea la mayoría el trabajo que supone hasta hacer algo chungo de calidad.
Yo sigo leyendo

@titorino

Son tan importantes los chips que rodean la CPU, que de hecho ya en algún hilo ya pusimos que "jugando a ser dios" en la mega, puedes usar el Z80 como CPU principal, y controlar el VDP de mega (básicamente hacer un juego de master system con gráficos de mega)

Muy interesante el hilo. Se agradece todas las aportaciones, sois muy cracks.

Al final el tema es el de siempre: no se pueden comparar los Mhz de dos
procesadores con arquitecturas diferentes.

Es como comparar las r.p.m de dos motores diferentes sin tener en cuenta su curva de par o su relación en la caja de cambios por ejemplo. Más r.p.m no significan por si solas ni más velocidad ni mayor fuerza.

Supongo que en la realidad el M68000 es un poco más rápido pero no el doble de rápido.

Por supuesto, y además del conjunto del hw, influyen los kits de desarrollo,y si no que se lo digan a la Saturn/Play1.

zarkon escribió:Supongo que en la realidad el M68000 es un poco más rápido pero no el doble de rápido.

Básicamente eso es lo que pasa. La diferencia entre ambas cpu's a 3,58 y 7,67mhz, no es del doble, sino de bastantre menos, y solo en los casos mas extremos (en otros directamente hay un empate, y en otros el 65816 obtiene mas rendimiento).

Lo que esto significa es que dependiendo de como programes, y de lo que quieras conseguir, obtendrás rendimientos parejos en ambas cpu's, o todo lo contrario.


Interrumpir el dibujado del line buffer para cambiar paletas de colores y obtener mas colores, es costoso si la cpu no es buena efectuando irq's, y esa es una ventaja palpable de la snes, por no hablar de lo que implica para cuestiones de diseño el poder dividir la pantalla en varias secciones verticalmente. Eso te lo da el 65816 con soltura, mientras que el 68000 se ahoga.

O mismamente un programa que no necesite emplear muchas instrucciones con palabras de mas de 8 bits, pero que sin embargo sature todo el tiempo de reloj con ese tipo de funciones, como por ejemplo guardar todo lo que necesites en una memoria muy pequeña, pero que igualmente su contenido se emplea accediendo a el de forma intensiva, y procesándolo de forma compleja (ya con instrucciones hasta de 16 bits si procede, e incluso de 24). De nuevo el 68000 no solo sería mas lento, sino totalmente vapuleado.

En definitiva, es cierto que el 68000 es mejor, pero no mejor en todos los casos.


P.D: Esta es solo una opinión basada en mis limitados conocimientos.

@Señor Ventura

En definitiva, es cierto que el 68000 es mejor, pero no mejor en todos los casos.

Imagino que esta conclusión abarca un contexto más allá de SNES vs MD y sus frecuencias, porque mi intención era que conociésemos un poco más estos micros fuera de estos diseños. Si es así yo opino igual que tú de acuerdo a lo expuesto por los expertos, sobre todo en lo infravalorado que está el 65816; me ha sorprendido que fuera del ámbito de las consolas tenga su pequeña parcela de público.

Tengo muchas más preguntas y algunas respuestas a todo lo que habéis aportado. Voy a ir a un cyber a alquilar un rato un ordenador sólo para participar aquí.

La culpa es mía por meterme en debates interesantes en una época donde no dispongo de Pc xD

@Sexy MotherFucker Igual tampoco debería haber metido la zarpa por aquí, porque mas allá de obviedades y generalizaciones poco mas puedo aportar (además de aerriesgarme a desinformar donde encarecidamente no tiene cabida).

Lo típico, que con la mitad de bus alcanza el 87,9% del ancho de banda de la megadrive, y cosas de ese estilo, pero desde luego que el 68000 de la mega no dobla el rendimiento del 65816 de la snes.

De todos modos insisto en que las ventajas del 65816, o los campos en los que habla de tu a tu al motorola aún con la mitad de frecuencia, son solo algunas excepciones. Por ejemplo un cartuchito con 8 memorias de 2 megabit, que puedas direccionar con palabras de 8 bits, imagino que obligatoriamente con un mapper para poder "empezar de cero" con cada rom, y ya está, la ventaja está servida, automáticamente lees de la rom 4 veces mas rápido que la megadrive, y lees y escribes en la wram entre 2 y 3 veces mas rápido también (puesto que en estos casos la frecuencia baja hasta los 2,68mhz).

En teoría debería ser algo así, pero no me fío mucho de mi.

@Señor Ventura qué pesado con SNES y MD, de verdad, puta obsesión...

Yo creo que por lo expuesto aquí, en líneas generales, aún a la misma frecuencia, el M68k es un micro algo más potente, versátil, y atractivo para el programador.

Y que en campos y aplicaciones concretas (perfectamente aplicables en videojuegos) el 65816 es extraordinariamente más eficiente que el 68000, y que ha sido un procesador muy infravalorado en foros de consolas.

¿Estás de acuerdo hasta aquí o no?

@Sexy MotherFucker Que si coño xD

Por eso digo que no voy a participar en el hilo, es que no tengo mucho mas que decir.


P.D: Ojito con eso de "a la misma frecuencia", que te equivocas.

@Señor Ventura entonces no estamos de acuerdo.

Ya postearé.

Sexy MotherFucker escribió:@Señor Ventura entonces no estamos de acuerdo.

Ya postearé.

En el terreno del 65816, a igualdad de frecuencia destroza al 68000. El resto ya se ha estado diciendo en el hilo, el 68000 tiene una arquitectura mas moderna, mas orientada a funciones complejas, y su éxito es que claramente era el puente hacia las próximas evoluciones del mundo informático.

Señor Ventura escribió:Interrumpir el dibujado del line buffer para cambiar paletas de colores y obtener mas colores, es costoso si la cpu no es buena efectuando irq's, y esa es una ventaja palpable de la snes, por no hablar de lo que implica para cuestiones de diseño el poder dividir la pantalla en varias secciones verticalmente. Eso te lo da el 65816 con soltura, mientras que el 68000 se ahoga.

En ese ejemplo que has puesto no gana el 65816 porque la interrupción a la que te refieres debe de ser el HDMA, y en ella no interviene el micro. Al micro de la SNES sólo se le puede interrumpir por IRQ y por NMI, uno que salta por los contadores verticales y horizontales, y el NMI que salta cuando la pantalla ha terminado de dibujarse.

magno escribió:

Señor Ventura escribió:Interrumpir el dibujado del line buffer para cambiar paletas de colores y obtener mas colores, es costoso si la cpu no es buena efectuando irq's, y esa es una ventaja palpable de la snes, por no hablar de lo que implica para cuestiones de diseño el poder dividir la pantalla en varias secciones verticalmente. Eso te lo da el 65816 con soltura, mientras que el 68000 se ahoga.

En ese ejemplo que has puesto no gana el 65816 porque la interrupción a la que te refieres debe de ser el HDMA, y en ella no interviene el micro. Al micro de la SNES sólo se le puede interrumpir por IRQ y por NMI, uno que salta por los contadores verticales y horizontales, y el NMI que salta cuando la pantalla ha terminado de dibujarse.

Ahora entiendo lo de que dijiste sobre que podrías aspirar a ganar solo un color mas por scanline... es que el hdma solo dispone de 4 bytes, y estoy pensando que el número de interrupciones por línea es limitado, no se si va en ese sentido...

No se me ocurre de que otra forma podrías lograr este efecto que interrumpiendo un scanline un buen número de veces:
https://youtu.be/MdBHjR1LMzI?t=1484

Señor Ventura escribió:Ahora entiendo lo de que dijiste sobre que podrías aspirar a ganar solo un color mas por scanline... es que el hdma solo dispone de 4 bytes

Eso es.

Señor Ventura escribió:, y estoy pensando que el número de interrupciones por línea es limitado, no se si va en ese sentido...

Y tan limitado... Acabo de comentarte en mi anterior post que no puedes interrumpir en una línea al micro para cambiar ningún color, porque la OAM, VRAM y CGRAM sólo se deben cambiar durante el VBlank y HBlank. Puedes interrumpir al micro con el HCounter (eso hace que salte la otra interrupción de la que hablaba, la llamada IRQ) a mitad de una línea si quieres, pero no para cambiar ningún contenido de esas 3 memorias. La única excpeción es una especie de bug que permite actualizar la OAM a mitad de frame, con efectos que pueden ser "peculiares".

Señor Ventura escribió:No se me ocurre de que otra forma podrías lograr este efecto que interrumpiendo un scanline un buen número de veces:
https://youtu.be/MdBHjR1LMzI?t=1484

Fácil, con un HMDA que cambia el BGScroll horizontal del plano donde esté el fondo ése de color turquesa. Así puedes cambiar en cada línea independientemente el offset horiztonal y dar ese efecto de zigzag. Tiene esa pinta, aunque como el movimiento es muy repetitivo, simplemente podría ser un BG que va cambiando con esa forma, sin necesidad de HDMA.

Un poco de pimienta en este hilo, hay demasiado buen rollo jajaja

Mucho rollo con que el 65816 a menos frecuencia iguala al Motorola, que si es más eficiente, que si patatin, que si patatan... Saliendo la Snes más tarde que la MD, ¿Por qué no aumento Nintendo su frecuencia para pasar por encima a la MD? Porque son unos rácanos con el HW.
Sí las consolas hubiesen salido a la vez... pero no fue el caso.

Es muy interesante que el funcionamiento de ambos chips sea tan distinto.
Hoy día programando a alto nivel estas cosas no se ven, a la velocidad que se mueve la industria "no vale la pena" tratar de sacar rendimiento, porque salen chips nuevos más baratos y potentes cada poco tiempo.

Recuerdo la época del Spectrum, amstrad, etc
Todos con un Z80 y qué diferentes parecían

En cualquier caso grandes procesadores ambos.

danibus escribió:Un poco de pimienta en este hilo, hay demasiado buen rollo jajaja

Mucho rollo con que el 65816 a menos frecuencia iguala al Motorola, que si es más eficiente, que si patatin, que si patatan... Saliendo la Snes más tarde que la MD, ¿Por qué no aumento Nintendo su frecuencia para pasar por encima a la MD? Porque son unos rácanos con el HW.
Sí las consolas hubiesen salido a la vez... pero no fue el caso.

Ya lo hemos comentado en alguno de estos hilos técnicos que tanto le gustan a @Señor Ventura y a @Sexy MotherFucker; la frecuencia de reloj de la CPU viene determinada desde "detrás hacia adelante", es decir, la PPU tenía que funcionar a 21.47MHz para que pudiera tener listo cada frame con todo el procesamiento de video necesario. Con un PLL entero (no fraccional), sacas divisores de reloj de 2, 3, 4, 5, 6, 7 ú 8 (podrías más, pero no tiene sentido), así que tendrías para elegir 10.7 MHz, 7.15MHz, 5.36MHz, 4.29MHz, 3.578MHz, 3.06MHz y 2.68MHz.
Por culpa de cómo el 65C816 saca los 24 bits del bus de direcciones, que lo fracciona en dos ciclos de acceso, uno con el flanco de subida del reloj (donde saca los 16 bits inferiores del bus) y otro con el siguiente flanco de bajada del reloj (llamado PHI2 y donde sale el byte de banco), hay que poner un latch externo para que los 24 bits completos estén en algún momento presentes A LA VEZ en el bus de direcciones. El retardo de propagación de lógica combinacional de aquella época, más el latch del bus de direcciones, más el precio de las ROMs con tiempos de acceso muy bajo determinó que se usaran los divisores del reloj maestro x6 y x8 y por tanto, determinan a qué frecuencia funciona el micro.

En un hilo de NesDev hice unas simulaciones en Modelsim de los retardos del bus de datos y direcciones del 65C816. En esas simulaciones se ve que también tiene algo de influencia el decodificador de direcciones para meter SRAM y varios chips de ROM en la placa (un 74LS139 o los MAD-1).

danibus escribió:Hoy día programando a alto nivel estas cosas no se ven, a la velocidad que se mueve la industria "no vale la pena" tratar de sacar rendimiento, porque salen chips nuevos más baratos y potentes cada poco tiempo.

Recuerdo la época del Spectrum, amstrad, etc
Todos con un Z80 y qué diferentes parecían

Estoy totalmente de acuerdo.

A sus pies, menuda explicación más currada.

De la misma forma, podemos fantasear con que el Motorola de MD estuviese a 10-12 MHz en vez de 7.8MHz, pero eso implica que el resto del sistema pudiese trabajar también con dicha frecuencia.
La gente que overclokea la MD la suele poner, por lo que tengo entendido, a 10MHz, a más se ralla.

Según he leído el VDP de MD no está pensado para trabajar tan rápido y se hace la picha un lío.

Luego está el tema de la frq max nominal garantizada, el fabricante garantiza poder trabajar dentro de unos límites, desconozco si el Ricoh podéis trabajar a más velocidad con garantías.

magno escribió:Fácil, con un HMDA que cambia el BGScroll horizontal del plano donde esté el fondo ése de color turquesa. Así puedes cambiar en cada línea independientemente el offset horiztonal y dar ese efecto de zigzag. Tiene esa pinta, aunque como el movimiento es muy repetitivo, simplemente podría ser un BG que va cambiando con esa forma, sin necesidad de HDMA.

Pero no solo tiene un zig zag, sino que el plano está dividido en varias secciones ¡verticalmente!, eso obliga en teoría a interrumpir cada scanline un buen número de veces, hacer un desplazamiento, y volver a empezar. Me parece complejísimo.

danibus escribió:desconozco si el Ricoh podéis trabajar a más velocidad con garantías.

Ni idea de si el chip lo soportaría físicamente, pero como ha dicho magno, el resto de las memorias y el sistema de vídeo también deberían aumentar su frecuencia de forma que coincida con la frecuencia nominal de su divisor.


@magno... dividor por 6?, influyendo en el sistema de vídeo?, esto es nuevo para mi... pero excluyendo al dma, no?.

Estoy obsesionado con el ancho de banda. Se que tarda 8 master cycles en transferirse un byte a la memoria de vídeo, pero es que veo una chispita y me ilusiono...

P.D: Claro, divisor x6 a 3.58mhz, y divisor x8 accediendo a wram y vram (2.68mhz).

@magno

la PPU tenía que funcionar a 21.47MHz para que pudiera tener listo cada frame con todo el procesamiento de video necesario. Con un PLL entero (no fraccional), sacas divisores de reloj de 2, 3, 4, 5, 6, 7 ú 8 (podrías más, pero no tiene sentido), así que tendrías para elegir 10.7 MHz, 7.15MHz, 5.36MHz, 4.29MHz, 3.578MHz, 3.06MHz y 2.68MHz.

Interesante, entiendo por lo remarcado en negrita que esa regla se aplica también a la ram; ¿Quiere decirse que la SNES perfectamente podría haber tenido una wram a 3,58 mhz que no le hiciese penalizar un ciclo interno al WDC para acceder a ella? Porque entonces a mi entender un 65816 standard a 5,36 Mhz con la memoria pareja hubiese sido una opción ideal para ese diseño, no creo que lo hubiese encarecido en exceso como si digamos le calzas un SA-1 a 10.7 mhz, el cual recuerdo que una vez explicaste no podía ser usado de CPU para la placa tal cual está diseñado actualmente.

¿Y en Megadrive qué tal van los accesos a la memoria desde la CPU? Partiendo de la base de que el 68000 tiene una latencia nativa de 4 ciclos externos (32 mhz entiendo), y de la baja frecuencia a la que va clockeado (7.67 mhz), el diseño de la 16 bits de SEGA es curioso porque tiene memorias rapidísimas para una consola de 1988:

FPM DRAM (16-bit, 5.263157 MHz): 64 KB workram. BANDWITCH: 10.526314 MB/s (5 MB/s CPU access) CPU access per frame: 81 KB (NTSC), 98 KB (PAL) (WTF?, imagino que no se refiere al ancho de banda nominal del DMA, sino a la comunicación Cpu-ram, ¿¿??).

VRAM: 64 kb dual external. VDP internal cache: 232 bytes.

CPU External data bus clock rate: 5 MHz ram/rom (5 MB/s external data access bandwidth)

W-T-F? Me he perdido, ¿Qué lugar juega la latencia del Motorola en estas cifras? Sacadas de Segaretro:

https://segaretro.org/Sega_Mega_Drive#T ... ifications

Teniendo en cuenta que para realizar rotaciones y scaling por software, el M68k accede a las memorias para manipular tiles, todo esto tiene que tener algún tipo dede orden...

P.D: Mira que no quería meter a las dos Marías mucho en este hilo, pero de perdidos a rio

danibus escribió:De la misma forma, podemos fantasear con que el Motorola de MD estuviese a 10-12 MHz en vez de 7.8MHz, pero eso implica que el resto del sistema pudiese trabajar también con dicha frecuencia.
La gente que overclokea la MD la suele poner, por lo que tengo entendido, a 10MHz, a más se ralla.

Según he leído el VDP de MD no está pensado para trabajar tan rápido y se hace la picha un lío.

Yo tengo la mía con un overclock a 10 Mhz, y juegos como Gunstar Heroes y ThunderForce IV van finos filipinos sin ralentización alguna, son todo ganancias. En cambio con juegos en los que el M68k carga parcialmente con el engine de sonido se producen bugs; por ejemplo en el Sonic 1 se acelera la música, a veces parpadea la pantalla, y se rompe por algunas zonas.

Pero en Gunstar Heroes (el que más juego con el overclock activado) ningún problema; ¡Todo lo contrario!

Según veo en Youtube los que más ganan con los overclocking son los juegos poligonales:

https://youtu.be/_BfdqVEoC_Y

Literalmente a mayor frecuencia más rápido corren.

Luego en otro tipo de juegos no noto ninguna diferencia.

Señor Ventura escribió:Pero no solo tiene un zig zag, sino que el plano está dividido en varias secciones ¡verticalmente!, eso obliga en teoría a interrumpir cada scanline un buen número de veces, hacer un desplazamiento, y volver a empezar. Me parece complejísimo.

No veo ese efecto que dices, macho... O no entiendo lo que dices... A mí lo que me parece es que el efecto es como si tuvieras un cañon, desfiladero o fosa debajo del avión; imaginate que un desfiladero recto, sin esquinas o curvas... pues eso es lo que se vería desplazándose la nave hacia arriba, pero si por HDMA cambias el scroll horizontal de cada línea, entonces el efecto es como si el desfiladero fuera sinuoso.
Las secciones verticales no las veo

danibus escribió:desconozco si el Ricoh podéis trabajar a más velocidad con garantías.

Sí, de hecho el SA-1 lo hace. Pero claro, habían pasado algunos años de mejora tecnológica y además, el SA-1 puede mostar el bus de direcciones todo del tirón, y no necesita un decodificador de direcciones externo para acceder a ROM o SRAM.

Señor Ventura escribió:@magno... dividor por 6?, influyendo en el sistema de vídeo?, esto es nuevo para mi... pero excluyendo al dma, no?.

No, he dicho justo lo contrario... la frecuencia del sistema de video influye en la frecuencia del reloj dividido.

El DMA no tiene nada que ver aquí; el DMA va entre el bus B (PPU) y el bus A (el de la CPU, que incluye RAM y ROM), así que su frecuencia se tiene que adaptar al más lento de los actores del DMA, que en este caso es la ROM externa. Como la ROM más lenta es de 200ns, pues el DMA funciona limitado por ese tiempo de acceso.
Con los cálculos que he hecho antes, sale que el caso más lento implica divisor x8, por tanto, 2.68MHz y por tanto el DMA ha de funcionar a 2.68MHz siempre.

Sexy MotherFucker escribió:Interesante, entiendo por lo remarcado en negrita que esa regla se aplica también a la ram; ¿Quiere decirse que la SNES perfectamente podría haber tenido una wram a 3,58 mhz que no le hiciese penalizar un ciclo interno al WDC para acceder a ella? Porque entonces a mi entender un 65816 standard a 5,36 Mhz con la memoria pareja hubiese sido una opción ideal para ese diseño, no creo que lo hubiese encarecido en exceso como si digamos le calzas un SA-1 a 10.7 mhz, el cual recuerdo que una vez explicaste no podía ser usado de CPU para la placa tal cual está diseñado actualmente.

Como poder, podría tener una WRAM a 3.58MHz, pero eso requiere una DRAM con mucho menor tiempo de acceso de la que hay ahora, menos de 100ns, aunque tendría que echar las cuentas.

Sexy MotherFucker escribió:¿Y en Megadrive qué tal van los accesos a la memoria desde la CPU? Partiendo de la base de que el 68000 tiene una latencia nativa de 4 ciclos externos (32 mhz entiendo), y de la baja frecuencia a la que va clockeado (7.67 mhz), el diseño de la 16 bits de SEGA es curioso porque tiene memorias rapidísimas para una consola de 1988:

FPM DRAM (16-bit, 5.263157 MHz): 64 KB workram. BANDWITCH: 10.526314 MB/s (5 MB/s CPU access) CPU access per frame: 81 KB (NTSC), 98 KB (PAL) (WTF?, imagino que no se refiere al ancho de banda nominal del DMA, sino a la comunicación Cpu-ram, ¿¿??).

VRAM: 64 kb dual external. VDP internal cache: 232 bytes.

CPU External data bus clock rate: 5 MHz ram/rom (5 MB/s external data access bandwidth)

W-T-F? Me he perdido, ¿Qué lugar juega la latencia del Motorola en estas cifras? Sacadas de Segaretro:

https://segaretro.org/Sega_Mega_Drive#T ... ifications

Teniendo en cuenta que para realizar rotaciones y scaling por software, el M68k accede a las memorias para manipular tiles, todo esto tiene que tener algún tipo dede orden...

Lo de la latencia precisamente ayuda a aumentar la frecuencia de reloj. Piensa que la DRAM tiene un tiempo de acceso fijo, digamos 70 ns. Si la CPU espera el dato al ciclo siguiente de que ponga la dirección en el bus, la máxima frecuencia del micro es 14,285 MHz; la CPU espera el dato 2 ciclos después de que ponga la dirección, entonces 2 periodos de reloj han de ser menor de 70ns, por lo que tu máxima frecuencia de reloj sería 28,571 MHz.
Con 4 ciclos como el 68000, pues echa cuentas. Lo que pasa es que tiempos de 70ns en DRAM los teníamos hace 10~15 años, hace 30 no sé en cuánto estaríamos, pero supongo que mucho más.
Es por esto que la Megadrive puede tener un reloj más alto de funcionamiento sin penalizar lo rápido que hayan de ser las DRAM o las ROM.
A la frecuencia del 68000, con esos 4 ciclos de acceso, podrías tener ROM o DRAM de 500 ns de tiempo de acceso, aunque a eso hay que restar lo que tarden los decodificadores externos de memoria para mapear los periféricos.

De esos datos que das, lo de

Sexy MotherFucker escribió:CPU External data bus clock rate: 5 MHz ram/rom (5 MB/s external data access bandwidth)

me mosquea porque yo tenía entendido que las ROMs en los cartuchos eran de 16 bits de bus de datos, lo cual implica 10MBytes/seg, no 5. Tampoco tengo muy claro qué son esos 5MHz, ya que normalmente se da en tiempo de acceso o en ciclos maestros del reloj (53.69 MHz en la Megadrive).

Por cierto, mira esto acerca del overclock:

http://www.sega-16.com/forum/archive/in ... -7138.html

El 68000 usado en la mega está especificado para 8MHz de frecuencia máxima... Meterle 10MHz es acortarle la vida a lo bestia.

magno escribió:No veo ese efecto que dices, macho... O no entiendo lo que dices... A mí lo que me parece es que el efecto es como si tuvieras un cañon, desfiladero o fosa debajo del avión; imaginate que un desfiladero recto, sin esquinas o curvas... pues eso es lo que se vería desplazándose la nave hacia arriba, pero si por HDMA cambias el scroll horizontal de cada línea, entonces el efecto es como si el desfiladero fuera sinuoso.
Las secciones verticales no las veo

A lo mejor me equivoco y el efecto de desplazamiento vertical es una simple animación (el desplazamiento vertical, no el serpenteo), de he hecho, que sea tan angosto ayuda a no tener que actualizar demasiados tiles. Luego se repiten de artiba a abajo, y listo).

Pero vamos, que hay dos efectos diferentes ahí, el de serpenteo, y el del desplazamiento vertical del terreno a diferentes velocidades (el serpenteo es horizontal, y el desplazamiento es vertical).

magno escribió:No, he dicho justo lo contrario... la frecuencia del sistema de video influye en la frecuencia del reloj dividido.

Me refería a que el dma tarda 8 ciclos del ppu en transferir 1 Byte. A lo mejor es una councidencia, pero a 3.58mhz serían 6 ciclos, y ya que hablamos de división según la frecuencia de memorias/cpu, y que el dma se ve influido en todo su "pipeline" por la mas lenta... no se, lo relacioné todo

magno escribió:El DMA no tiene nada que ver aquí; el DMA va entre el bus B (PPU) y el bus A (el de la CPU, que incluye RAM y ROM), así que su frecuencia se tiene que adaptar al más lento de los actores del DMA, que en este caso es la ROM externa. Como la ROM más lenta es de 200ns, pues el DMA funciona limitado por ese tiempo de acceso.
Con los cálculos que he hecho antes, sale que el caso más lento implica divisor x8, por tanto, 2.68MHz y por tanto el DMA ha de funcionar a 2.68MHz siempre.

Y si la rom de 80ns, ¿la wram también bloquea el dma por tener una frecuencia de 2,68mhz?.

Señor Ventura escribió:Pero vamos, que hay dos efectos diferentes ahí, el de serpenteo, y el del desplazamiento vertical del terreno a diferentes velocidades (el serpenteo es horizontal, y el desplazamiento es vertical).

Claro, hay dos efectos, el de desplazamiento vertical es el scroll de toda la vida, el de serpenteo podría ser una animación del BG simplemente, pero apuesto que lo logran cambiando el scroll horizontal en cada línea usando HDMA.

Señor Ventura escribió:Y si la rom de 80ns, ¿la wram también bloquea el dma por tener una frecuencia de 2,68mhz?.

Si la ROM es de 80 ns es más rápida que la FatROM (120ns) o la SlowROM (200 ns), por lo que sí, claro, el DMA sigue estnado limitado por el más lento, la WRAM.

magno escribió:Lo de la latencia precisamente ayuda a aumentar la frecuencia de reloj. Piensa que la DRAM tiene un tiempo de acceso fijo, digamos 70 ns. Si la CPU espera el dato al ciclo siguiente de que ponga la dirección en el bus, la máxima frecuencia del micro es 14,285 MHz; la CPU espera el dato 2 ciclos después de que ponga la dirección, entonces 2 periodos de reloj han de ser menor de 70ns, por lo que tu máxima frecuencia de reloj sería 28,571 MHz.
Con 4 ciclos como el 68000, pues echa cuentas. Lo que pasa es que tiempos de 70ns en DRAM los teníamos hace 10~15 años, hace 30 no sé en cuánto estaríamos, pero supongo que mucho más.
Es por esto que la Megadrive puede tener un reloj más alto de funcionamiento sin penalizar lo rápido que hayan de ser las DRAM o las ROM.
A la frecuencia del 68000, con esos 4 ciclos de acceso, podrías tener ROM o DRAM de 500 ns de tiempo de acceso, aunque a eso hay que restar lo que tarden los decodificadores externos de memoria para mapear los periféricos.

Muy curioso esto de que lo que a priori parece una debilidad (latencia del 68000) puede llegar a convertirse en una ventaja, siempre me había parecido que la memoria y los buses de la MD iban demasiado rápido para lo lento que era externamente el Motorola, pensé que era un mal diseño que desaprovechaba el hardware, pero ahora entiendo que está perfectamente ideado para optimizar el rendimiento, gracias Ahora que lo explicas Stef, el creador del XGM driver que postea en SEGA-16, comentó en alguna ocasión que en su experiencia programando la latencia externa del Motorola no suponía ningún drama en Megadrive, imagino que se refería a lo que dices.

Relacionado con esto, y muy interesante también, lo que comentaste en la primera página:

Por ejemplo, una rutina VWF que se puede ver en cualquier juego de ROL necesita de muchos accesos a RAM para traer cada línea de píxeles de la letra; con el 68000 podrías traerte la línea de píxeles con mayor lentitud que el 65C816, pero una vez almacenada en el registro R0 del 68000, podrías desplazarla, hacer su sombra por arriba, por abajo y por la derecha y almacenar cada resultado en R1, R2 y R3. Luego almacenas el resultado en la salida de RAM, y la siguiente línea de píxeles que te traes ya tiene los resultados de la sombra de la línea superior en R2. Así te ahorras almacenar los 2 planos de píxeles en 2 ciclos como haría el 65C816, y para cada línea de píxeles, te ahorras traerte la sombra de la línea superior, por lo que en 68000 te podrías ahorrar 2 ciclos de acceso a RAM almacenando resultados intermedios en los registros disponibles, por lo que hace más ligero el algoritmo.

Viendo la latencia externa del M68000 podría considerarse que está menos preparado que el 65816 para ese tipo dede rutinas típicas de los RPG, pero atendiendo a otras particularidades del diseño del Motorola resulta que tiene hasta ventajas para ejecutar el algoritmo.

Al final esto no es tan Sota, Caballo, y Rey como demanda la mayoría de gente en este tipo de comparativas, buscando un resultado quirúrjico e inamovible sobre cual es el mejor absoluto en ésto y aquello, sino que existe un UNIVERSO de matices a tenor de como los use el programador, lo que busque plasmar, y de cómo sea el resto del diseño de la máquina. De hecho, en tu opinión, has sentenciado desde un primer momento que no los ves equivalentemente comparables.

Fascinante, sin más.

me mosquea porque yo tenía entendido que las ROMs en los cartuchos eran de 16 bits de bus de datos, lo cual implica 10MBytes/seg, no 5. Tampoco tengo muy claro qué son esos 5MHz, ya que normalmente se da en tiempo de acceso o en ciclos maestros del reloj (53.69 MHz en la Megadrive).

Yo tenía entendido exactamente lo mismo, y que en general la MD accede a las roms algo más rápido que SNES a las suyas siempre.

Sobre los datos de Segaretro yo llevo un tiempo que los cojo con muchas pinzas, ya que si bien hay mucha información «wikia» aprovechable, todo lo referente a MD huele a parcialismo turbio que echa patrás; mismamente hay una comparativa con SNES que a mi juicio está manipulada a más no poder por los que editan, y que encima titulan «Blast Proccesing» :

https://segaretro.org/Blast_processing

Por cierto, mira esto acerca del overclock:

http://www.sega-16.com/forum/archive/in ... -7138.html

El 68000 usado en la mega está especificado para 8MHz de frecuencia máxima... Meterle 10MHz es acortarle la vida a lo bestia.

LOL, ¿Me la estoy cargando xD? Tampoco lo uso mucho, sólo para curiosear de vez en cuando, o para partidas intensas al Gunstar Heroes.

El cualquier caso me haré con otra consola, y la del overclocking la dejaré de «batalla» hasta el día que pete xDD.

@Señor Ventura ¡Tú acaparador, largo! xDD. Fuera coñas me estoy leyendo con interés toda vuestra conversación, muy enriquecedora. Yo no pregunto por el 65816 porque ya lo haces tú

A @wwwendigo @Pek @Manveru Ainu ya les pillaré por banda cuando haya tiempo y ellos gusten, que se han quedado muchas cosas en el aire.

@magno
Cuando hice el /análisis de 32X estuve mirando el tema de CPUs porque imaginaba que subirle la freq al M68k sería perjudicial.
Pero el caso es que... mirando información de Motorola, en todas partes pone que cualquier 68000 está garantizado para funcionar hasta a 12MHz, así que esa sola no parece una razón para elegir los 7MHz, y sí todo lo que comentas sobre el uso de divisores de la freq maestra.

Muchas veces los fallos en los juegos al overclockear la consola son por el propio código del juego que no cuenta con ese exceso de velocidad. Puede ser por ejemplo que el código esté pensado para que el código haga algo sincronizado con una interrupción horizontal, pero al subir la velocidad el código se ejecuta antes de llegar al scanline concretado y ya pueden pasar cosas raras. Otro ejemplo son las fases de bonus de Sonic 2 que deben tener algún control respecto a la velocidad, y que cuando subes los mhz van a toda leche jeje

Luego sí, hay fallos de hardware un poco rarunos. El típico ejemplo es que la música suele ser lo primero que glitchea, seguramente por algún tema de sincronización 68k-z80 o algo así. Otro fallo que recuerdo es algo de la lectura del mando, en concreto en el Sonic overclockeado y mando de 6 botones, que si pulsas y mantienes el salto hace autofire (que no tiene normalmente) y encima hace saltos aleatorios, es decir lee tiempos de pulsacion aparentemente random.

Supongo que el tema velocidad y overclockeo como se puede estudiar mejor es teniendo delante el código fuente, y conociendo bien el hardware claro.

@Sexy MotherFucker Irremediablemente esto tenía que derivar, aunque sea fugazmente, al funcionamiento de estas cpu's bajo el entorno concreto de dos consolas (ya sabemos cuales).

Solo quería apuntar, que el denominado blast processing, no fué un mérito de la megadrive, sino un demérito de la snes. Es decir, que si no hubiesen montado una WRAM como la que emplearon, las cosas hubieran sido muy diferentes.

Recordemos a que denominaban "blast processing"... ni mas ni menos que a un ancho de banda superior.
Bien, pues bajo esa premisa, eso es lo que (para mi), hace tan valorable al 65816. Con LA MITAD de frecuencia, y LA MITAD de ancho de banda que el 68000, en ese contexto determinado, y separando lo que esas cpu's en concreto estaban preparadas para dar (ya que es lo que el hilo propone), la verdadera verdad es que el 65816 da unos 9KB por frame.

9KB vs 7KB, y con la mitad de frecuencia, y la mitad de bus.

Si, el 65816 es menos versatil, pero es tan superior en otros campos, que ya que hablais de las máquinas en las que fueron incorporados estos procesadores, teniendo cuenta el tipo de software que calzaban, la mejor opción no era el 68000, sino el 65816.

Eso si, con memorias a la altura que no limiten su dma, y, ¿por qué no decirlo?, con un poco mas de frencuencia. Un 65816 a los mismos 7mhz que megadrive, está preparada para alcanzar hasta 18KB por frame, lo cual es una pasada para hacer juegos artísticamente muy complejos.


Me apetecía soltar esta parrafada, ya que el hilo ha bajado un poco, y no interrumpo nada.

@Señor Ventura pues mira estaba abierto, voy a buscar a tiempo para retomar el debate ANTES de que acabe la semana, te respondo por aquí.

La gracia del motorola no es ser el más eficiente, ni el más rápido. El 68k daba facilidades, era un procesador que te llevaba de la mano. La cantidad de material escrito era importante, muchos programadores lo conocían y además satisfacía lo que buscaba SEGA para su nueva consola. La buena fama del ensamblador del 68k, y hablamos de ensamblador, es algo a valorar.

Por otro lado el 65C816 tiene su gracia precisamente en ser rápido y simple. Por tanto es normal que con menos frecuencia y menos ancho de banda haga lo más o menos lo mismo, es que está diseñado para eso, pero lo pagas con ser un chip más árido para programar.

@magno antes de darle mi opinión a Señor Ventura, me gustaría que un verdadero profesional aclarase un par de conceptos que yo por lo menos tengo pegados con alfileres, seré muy breve y directo al grano:

- ¿Hasta qué punto importa la CPU en SNES o MD a la hora de sacar a flote el máximo ancho de banda nominal por frame del DMA, que es de 7ypico kb en Megadrive, y 6ypico en SuperNintendo? Siempre había creído que esto tenía que ver más con los anchos de banda de las propias memorias, y todo lo relacionado con el sistema gráfico.

- ¿Influye el hecho de la resolución que emiten? Es decir; ¿si la SNES tuviese que dibujar a 320x224 en lugar de a 256 perdería ancho de banda? Ojo; 320x224 outpout literal, no 512 en los fondos y 256 en el campo de los sprites, y en cualquier caso ya sabemos que SNES no es compatible con ese ratio, es simplemente por teorizar y entender el concepto. En el caso de la MD al pasar al modo 256x224 disminuye, pero eso es porque SEGA la capó así a propósito para el modo retrocompatible con Master System II.

- Y en el caso de que sea la CPU la que dicte el rendimiento del ancho de banda; ¿hasta qué punto cara a generar ancho de banda le lastra al WDC el tener una memoria WRAM a menor frecuencia? Porque Ventura dice que simplemente de tener una ram a 3,58 mhz la SNES alcanzaría nada menos que un 128% más de ancho de banda que la propia Megadrive.

Gracias de antemano