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

* 29 abr 2018 18:00

Enlace permanente

- ¿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.

Las memorias tienen que ver, porque obliga al dma a adaptarse a la frecuencia nominal del componente con menos tasa.

En este caso, en snes la memoria ram obliga a que el dma funcione constantemente a 2,68mhz, que encima gracias a su latencia rebaja un poquito mas el resultado, dejándolo en 6,14kb.

El 68000 no necesita que su memoria sea tan rápida para sacarle el jugo porque su DMA funciona mucho mas lento.

- ¿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.

No, no influye la resolución en el ancho de banda disponible por frame.

Influye solo en el número de tiles que necesites transferir. La pantalla de megadrive necesita mas tiles para llenarse, y cuantos menos tiles necesites repetir, mas tiles diferentes necesitarás para llenarla, así que toca transferirlas, y eso agota el ancho de banda (pero es relativo, porque con solo un tile puedes hacer la mitad de un decorado a base de azul para el cielo, por ejemplo).

- 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.

Acusica

En realidad es un 117%.

Y si el 65816 funcionase a los mismos 7,67mhz que la megadrive, con su memoria ram a 7,67mhz, estaríamos hablando de un 251%, y eso con un bus de 8 bits. Si hubiese sido de 16 bits estaríamos hablando de un 502% en las mismas condiciones que una megadrive.

¿Como te has quedado, blast processing?

* 29 abr 2018 18:05

Enlace permanente

@Señor Ventura no te voy a contestar hasta que magno no confirme al 100% todo lo que has dicho, no te ofendas pero necesitamos el máximo de veracidad al respecto, pero en cualquier caso el ancho de banda es simplemente uno de los muchos aspectos por los que se puede elegir una CPU u otra para estos sistemas, y decir que SEGA se "equivocó" eligiendo el M68k, y que los procesadores estos sobran en consolas me parece una sobrada por tu parte increíble teniendo en cuenta la de veces que no has estado en lo cierto en lo referente a estas CPUs, por mucho que la estés argumentando.

Cuando magno responda, te doy mi opinión.

El 68000 no necesita que su memoria sea tan rápida para sacarle el juego porque su DMA funciona mucho mas lento.

¿Pero estás hablando del DMA de la MD o de la capacidad para operar externamente del Motorola? Porque el DMA de la consola no funciona a menor frecuencia que el de SNES.

* 29 abr 2018 18:15

Enlace permanente

@Señor Ventura no te voy a contestar hasta que magno no confirme al 100% todo lo que has dicho, no te ofendas pero necesitamos el máximo de veracidad al respecto, pero en cualquier caso el ancho de banda es simplemente uno de los muchos aspectos por los que se puede elegir una CPU u otra para estos sistemas, y decir que SEGA se "equivocó" eligiendo el M68k, y que los procesadores estos sobran en consolas me parece una sobrada por tu parte increíble teniendo en cuenta la de veces que no has estado en lo cierto en lo referente a estas CPUs, por mucho que la estés argumentando.

Cuando magno responda, te doy mi opinión.

https://www.youtube.com/watch?v=NlM3CKXJs5k



No creo que sea solo mi opinión, para estos softwares (sin entrar en entornos realmente complejos), como solían ser los juegos que calzaban estas máquinas, no hacían falta procesadores ultra complejos, y si, el 65816 a la misma frecuencia barrería por completo a un 68000 en la inmensa mayoría de las facetas (de un software estándar como aquellos).

La cuestión es que según se ha dicho por aquí la arquitectura del 68000 permitía evolucionar de forma que en programas complejos cundiera mas que procesadores mas simples a la misma frecuencia... pero, para un castlevania con 4 bichos moviéndose en pantalla, y un sistema de vídeo autónomo, el 65816 va por delante que un 68000 (entornos amigable de programación aparte).

¿Pero estás hablando del DMA de la MD o de la capacidad para operar externamente del Motorola? Porque el DMA de la consola no funciona a menor frecuencia que el de SNES.

A 7,67mhz, el DMA funciona a 1,92mhz (no llega, me sale 1,91 y pico), porque externamente es la frecuencia del micro.

Lo que pasa es que su bus es de 16 bits, así que doblas la tasa.

* 29 abr 2018 18:29

Enlace permanente

(entornos amigable de programación aparte).

Pero es que esto es un factor que no puedes apartar de la ecuación cara a que un fabricante lo considere un plus importante para implementar el micro en su consola de 1988, ya que sabe que tanto por C como por ensamblador los desarrolladores van a poder sacarle casi siempre un gran rendimiento a su producto con relativa facilidad, por eso cuando dices que SEGA "se equivocó" incluyéndolo no puedo pensar sino en lo fanboy que eres del 65816 y como te ciegas en cuanto ves el primer rayo de esperanza, además de en la de veces que te has equivocado tanto con este como con el Motorola, que ojo yo tampoco estoy libre de pecado ya que wwwendigo me ha corregido a mí unas cuantas flipadas también xDD. Lo que digo es que mientras a mí los errores me han hecho prudente, tú es que cada día te vienes más arriba por muchas veces que tropieces con la misma piedra xDDD. No niego la virtud que pueda tener lo del ancho de banda, simplemente digo que eso es UNO de tantos otros factores, que en máquinas como Neo Geo viene a importar casi una mierda porque no emplean DMA, y sin embargo calza un 68000, como otros cienes de placas, y eso teniendo los 65816 tirados de precio en comparación.

Y esta no es la contestación que te tengo guardada desde hace tiempo, simplemente es que me fascina tu osadía apasionada visto lo visto

A ver si vienen los "jefes" del asunto, y empezamos el debate.

P.D: Este hilo tiene mucho potencial, si lo llevamos bien será de los mejores en castellano.

A 7,67mhz, el DMA funciona a 1,92mhz (no llega, me sale 1,91 y pico), porque externamente es la frecuencia del micro.

Lo que pasa es que su bus es de 16 bits, así que doblas la tasa.

En esta reseña, que basa en documentación oficial según Manveru, dice que el bus de la consola rula a 3,58 Mhz al margen de a lo que rule el M68k:

https://josepjroca.wordpress.com/2015/0 ... ega-drive/

Edit: Pues ahora no lo pone, deber haberlo editado

En cualquier caso en Segaretro dicen que es más, pero claro, fíate tú de los fanboys que suelen editar por allí...

* 29 abr 2018 18:53

Enlace permanente

Pero es que esto es un factor que no puedes apartar de la ecuación cara a que un fabricante lo considere un plus importante para implementar el micro en su consola de 1988, ya que sabe que tanto por C como por ensamblador los desarrolladores van a poder sacarle casi siempre un gran rendimiento a su producto con relativa facilidad, por eso cuando dices que SEGA "se equivocó" incluyéndolo no puedo pensar sino en lo fanboy que eres del 65816 y como te ciegas en cuanto ves el primer rayo de esperanza, además de en la de veces que te has equivocado tanto con este como con el Motorola, que ojo yo tampoco estoy libre de pecado ya que wwwendigo me ha corregido a mí unas cuantas flipadas también xDD. Lo que digo es que mientras a mí los errores me han hecho prudente, tú es que cada día te vienes más arriba por muchas veces que tropieces con la misma piedra xDDD. No niego la virtud que pueda tener lo del ancho de banda, simplemente digo que eso es UNO de tantos otros factores, que en máquinas como Neo Geo viene a importar casi una mierda porque no emplean DMA, y sin embargo calza un 68000, como otros cienes de placas, y eso teniendo los 65816 tirados de precio en comparación.

Soy como el caballero negro de los monty pyton, ¡un rasguño nada mas! xD

Un 65816 a la misma frecuencia que un 68000 te lo barre del mapa en entornos de software simples, como lo era un juego estándar de la época de los 16 bits, y además te brindaría mas ancho de banda para mover mas gráficos.

A lo mejor sega basó su estrategia en la amigabilidad y familiaridad a la hora de programar, como estrategia para atraer desarrolladores, y en ese sentido obviamente no es una equivocación, porque es cierto que tiene sentido.

Lo que yo digo en mi opinión, es que yo prefiero un entorno de programación mas cabrón, pero que me permita conseguir mas resultados, y en ese sentido para mi sega se equivocó, porque con un 65816 a 7mhz tienes mas potencia de proceso y mas ancho de banda que con un 68000 a 7mhz. A lo mejor no para entornos super complejos, pero para el tipo de software estándar que usaban estas máquinas, de sobra.

En esta reseña, que basa en documentación oficial según Manveru, dice que el bus de la consola rula a 3,58 Mhz al margen de a lo que rule el M68k:

https://josepjroca.wordpress.com/2015/0 ... ega-drive/

A lo mejor me lo he saltado, pero no pone nada de eso.

Y dudo horrores que manveru haya dicho eso, porque si externamente el bus funciona a 1,92mhz forzado por la frecuencia externa del 68000, difícilmente el DMA se va a saltar eso, al menos así por las buenas.

* 29 abr 2018 19:08

Enlace permanente

@Señor Ventura no, no, Manveru directamente dijo que no tenía ni idea del asunto del bus xD. Lo que sí comentó es que le constaba que el tío del reportaje los basa en documentación oficial, pero ahora no aparece, y voto a Brios que yo lo vi expuesto las primeras veces que lo leí.

Lo que yo digo en mi opinión, es que yo prefiero un entorno de programación mas cabrón, pero que me permita conseguir mas resultados, y en ese sentido para mi sega se equivocó, porque con un 65816 a 7mhz tienes mas potencia de proceso y mas ancho de banda que con un 68000 a 7mhz. A lo mejor no para entornos super complejos, pero para el tipo de software estándar que usaban estas máquinas, de sobra.

Pero es que yo sigo sin estar de acuerdo en que con un 65816 obtengas un rendimiento mejor en todo, siendo el asunto del ancho de banda un factor sin duda a valorar, pero como te ha dicho muchas veces magno, y algunas menos wwwendigo, estás de más obsesionado con ese tema, ya que a partir de 6 kb se pueden hacer cosas muy molonas ya, y el hecho de que un 65816 pudiese ofrecer más ancho de banda potencial no me parece algo 100% concluyente cara a implementar ese micro SÍ o SÍ en una consola de 16 bits despreciando al otro, ya que hay muchos otros factores a valorar, y no estoy hablando sólo de los "friendly" que sea el Motorola -que también-. Entiendo tu punto, respeto tu gusto por el procesador, y yo estoy encantado de adquirir conocimientos sobre este que antes no tenía. Pero decir que el M68k "sobra" en una consola de 16 bits me parece una barrabasada.

En lo que yo creo que SEGA sí se equivocó fué en no clockear al Motorola con un pelín más de frecuencia, por ejemplo a 10 mhz como la CP-S salida ese mismo año y el Sharp-X68000 en 1987, ya que si no pudieron incluir hardware nativo de rotación/escalado por motivos del tamaño en la placa como dijeron en una entrevista, teniendo que cargar de por vida el M68k con esos asuntos por software, un poco más de velocidad le hubiese hecho ganar calidad jugable en términos de juegos poligonales, y visual en materia zooms/rotados por soft, etc.

Cuando magno me responda, tochopost incoming

29 abr 2018 19:58

1 valoración positiva

Enlace permanente

A ver, la cuestión que planteas es muy interesante, pero no es fácil de responder, ya que normalmente las limitaciones de un sistema tan complejo como las consolas suele venir por varios factores. Intentaré responderte, aunque parte de las respuestas ya las comenté en otros hilos:

- ¿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.

Por definición de lo que es un Direct Memory Access, la CPU no influye en ABSOLUTAMENTE nada en el DMA. De hecho, la gracia del DMA es que la CPU está parada mientras éste se ejecuta, ya que el bus entre la ROM y la RAM o la ROM y la VRAM estarían ocupados y habría colisión. Es decir, imagina que la CPU lanza un DMA y mientras éste envía datos desde ROM a VRAM, la CPU siguiente ejecutando la siguiente instrucción del programa, que está en ROM también. Sería necesario un arbitraje de bus , que es algo complejo y no existe en estas consolas.

Lo que pasa es que si la CPU tiene que "renderizar" una parte de la imagen, cuanto más rápida sea la CPU, antes tendrá preparado el siguiente frame, pero el DMA para enviar las tiles o el tilemap a VRAM siempre será igual de lento.
En el caso de SNES, el DMA se ejecuta a la frecuencia más baja posible de funcionamiento del bus A (el que conecta ROM/RAM con CPU, el bus B es el que conecta PPU con CPU), que es 2.58MHz, es decir, 8 ciclos de reloj maestro. Como ya te comenté en otro post, esto se debe a que el 65C816 tiene 1 ciclo de acceso externo (tanto de escritura como de lectura), así que como la memoria RAM y la memoria VRAM son bastante lentas en tiempo de acceso, ese ciclo de lectura/escritura de la CPU tiene que ser largo (es decir, frecuencia baja) para que le dé tiempo a la ROM o RAM a tener el dato listo en sus pines de salida.
Además de la frecuencia de reloj del DMA, está el tiempo que se le asigna a hacer dichas transferencias. En la SNES, para escribir en VRAM tienes que estar en el borrado vertical, que es el instante de tiempo en el que el haz de electrones del tubo de la TV está desconectado y retornando a la esquina superior izquierda de la pantalla para dibujar el siguiente campo de la imagen. Ese tiempo es de 25 líneas en PAL y 21 en NTSC, y esto viene definido por el estándar de video, no por la consola (aunque realmente para la consola el blanking vertical empieza un poco antes y termina un poco después, ya que sólo tiene 240 líneas activas). Así que en PAL harías el DMA a la misma frecuencia que en NTSC, pero tendrías más tiempo para enviar datos, por lo que el ancho de banda por frame es mayor.

- ¿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.

Es que si la SNES tuviera una resolución vertical diferente ya no sería SNES... Me explico con datos de NTSC (para PAL son igual, solo que el blanking vertical dura más):
* Para la SNES, la pantalla de tu televisor tiene 262 líneas en cada campo (par e impar), es decir, 524 líneas por frame (el estándar de NTSC dice que hay 525, 262 en el campo par y 263 en el impar).
* Para la SNES el campo par de tu TV es un frame, y el campo impar es el siguiente frame, es decir, que trabaja de forma entrelazada actualizando el contenido de la pantalla de la TV en cada campo, en vez de hacerlo en cada frame como lo haría si funcionara de forma progresiva.
* Cuando el contador vertical interno a la SNES marca 0, empieza la parte activa de la imagen; cuando llega a 240, empieza el blanking vertical que durará hasta la línea 261 (21 líneas de V-Blank, aunque esto es configurable a 224, pero para no liarlo más, lo dejamos así).
* El contador se resetea al final de la línea 261 y vuelve a 0, empezando el siguiente campo activo de la imagen.

Así que si quieres sacar una resolución vertical diferente, te tienes que ajustar a ese patrón de dibujado de las líneas, podrías sacar hasta 256x256, pero fíjate que entonces sólo tendrías 6 líneas de borrado vertical, lo cual es inviable.

Si lo que quieres es cambiar es la resolución horizontal, entonces habría que cambiar más cosas del funcionamiento de la SNES, pero el ancho de banda a VRAM (frecuencia del DMA y tiempo de V-Blank) no cambiarían.

- 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.

Si la WRAM, la VRAM y las ROM hubieran sido más rápidas, todo podría haber ido a más frecuencia, teniendo en cuenta que el límite fundamentalmente lo marca el ciclo de acceso de lectrua/escritura del 65C816 y el tiempo de acceso de la ROM y RAM (la más lenta de ambas).
Lo que dice @Señor Ventura es parcialmente cierto, porque si la RAM hubiera tenido un tiempo de acceso de menos de 100ns y todas las ROMs que se usaran en los cartuchos también, entonces no hubiera habido necesidad de un modo "Slow-ROM" a 2.68MHz y se hubiera podido usar el DMA a más frecuencia.
También cabe la posibilidad que lo que esté limitando la frecuencia máxima del DMA sea el propio controlador de DMA (que creo que va en el chip PPU-1), pero lo dudo.

* 29 abr 2018 20:10

Enlace permanente

@magno uff, necesito varias relecturas para digerir bien tu respuesta, muchísimas gracias por contestar tan rápido

Pero volviendo al ancho de banda nominal por frame de 6,14 kb que tanto le obsesiona a Señor Ventura xD, en ese sentido, ¿supone o no una ventaja el 65816 sobre el 68000? Dices que está parcialmente lo cierto en el tema de las frecuencias, ¿en qué parte "parcial" se equivoca? Lo digo para ir descartando ya ciertas cosas.

29 abr 2018 20:18

Enlace permanente

@magno uff, necesito varias relecturas para digerir bien tu respuesta, muchísimas gracias por contestar tan rápido

Pero volviendo al ancho de banda nominal por frame de 6,14 kb que tanto le obsesiona a Señor Ventura xD, en ese sentido, ¿supone o no una ventaja el 65816 sobre el 68000? Dices que está parcialmente lo cierto en el tema de las frecuencias, ¿en qué parte "parcial" se equivoca? Lo digo para ir descartando ya ciertas cosas.

El 65816 con la mitad de frecuencia, y la mitad de ancho de banda del bus, consigue pisarle los talones al 68000, saca tus propias conclusiones.

Es decir, con una cpu a 7,67mhz tendrías un bus a 7,67mhz, y potencialmente el DMA podría funcionar a esa frecuencia.

29 abr 2018 20:24

Enlace permanente

Pero volviendo al ancho de banda nominal por frame de 6,14 kb que tanto le obsesiona a Señor Ventura xD, en ese sentido, ¿supone o no una ventaja el 65816 sobre el 68000?

Claramente no lo es. Ya se lo comenté en otras ocasiones pero no me hizo demasiado caso... De todos los códigos que he analizado, nunca he visto un DMA usado al 100%, es decir, aprovechando esos 6.14Kb por frame. Lo que hacen la mayoría de los juegos es cargar en una zona de VRAM todas las tiles que necesitan para los background antes de empezar una escena, y luego lo que se actualiza en cada VBlank es el tilemap (que son 1024 bytes por background), la tabla OAM (544 bytes) y las tiles de los sprites (como mucho 128 sprites 4BPP, 4096 bytes en el caso extremo de todos los sprites 8x8). En el peor de los casos, en un VBlank enviarías 4*1024+544+4096, es decir, aproximadamente 8,5 kbytes. Y ningún juego usa 4BGs, ni pone 128 tiles en pantalla, ni actualiza los BGs en cada frame.
Además, los BGs se pueden actualizar de forma inteligente sin transferir todo el tilemap del tirón, sino solo las tiles que cambian gracias a la flexibilidad de la PPU. Si se programa adecuadamente, se necesitan enviar 32 bytes para una columna de tilemaps y 32 bytes para una fila de tilemaps, es decir, que un juego que requiera actualizar los BGs con mucha rapidez y muy a menudo necesitaría enviar 4*64 bytes = 128 bytes para hacer el scroll simultáneo de 4 BGs en el misom frame. Por ejemplo, un shoot'em-up que tenga 4 planos, necesitaría sólo enviar 128 bytes, y si pusiera 128 sprites en pantalla que se actualizaran en cada frame (cosa que no ocurre nunca), entonces necesitarías menos de 5Kbytes por frame para enviar toda esa información, considerando lo que dije al principio, que las tiles de los fondos se transfieren al principio de una escena y se quedan en VRAM inalteradas.

Dices que está parcialmente lo cierto en el tema de las frecuencias, ¿en qué parte "parcial" se equivoca? Lo digo para ir descartando ya ciertas cosas.

En que no depende solo del tiempo de acceso de la RAM, sino también de la ROM del cartucho.

29 abr 2018 20:36

Enlace permanente

Claramente no lo es. Ya se lo comenté en otras ocasiones pero no me hizo demasiado caso...

Un inciso, porque la pregunta que te ha hecho está mal planteada.

6,14kb no ofrecen ninguna ventaja frente a 7,22kb, ni yo he dicho nunca eso. A lo que el se refería es a mi comentario sobre un DMA en snes a 7,67mhz, y un DMA en megadrive a 7,67mhz.

Sigo leyendoos

* 29 abr 2018 20:41

Enlace permanente

Claramente no lo es. Ya se lo comenté en otras ocasiones pero no me hizo demasiado caso...

Un inciso, porque la pregunta que te ha hecho está mal planteada.

6,14kb no ofrecen ninguna ventaja frente a 7,22kb, ni yo he dicho nunca eso. A lo que el se refería es a mi comentario sobre un DMA en snes a 7,67mhz, y un DMA en megadrive a 7,67mhz.

Sigo leyendoos

Exacto, Señor Ventura dice que si el WDC a 3,58 Mhz logra 6,14kb por frame, clockeado a la misma frecuencia que un Motorola le rebasaría ampliamente en ese mismo campo concreto.

Mis dudas eran hasta qué punto importa la CPU a la hora de "ensanchar" ese margen.

De lo que dices magno, yo estoy entendiendo que no es un tema tan relevante como parece importarle tanto a Ventura, ya que según tú no conoces ningún sistema consolero que aproveche al 100% todo su margen por frame.

Es que me flipa que diga que los 68.000 sobran en las consolas, es para hacérselo mirar xDD

* 29 abr 2018 20:48

Enlace permanente

Exacto, Señor Ventura dice que si el WDC a 3,58 Mhz logra 6,14kb por frame, clockeado a la misma frecuencia que un Motorola le rebasaría ampliamente en ese mismo campo concreto.

Mis dudas eran hasta qué punto importa la CPU a la hora de "ensanchar" ese margen.

De lo que dices magno, yo estoy entendiendo que no es un tema tan relevante como parece importarle tanto a Ventura, ya que según tú no conoces ningún sistema consolero que aproveche al 100% todo su margen por frame.

Es que me flipa que diga que los 68.000 sobran en las consolas, es para hacérselo mirar xDD

La cpu no tiene que ver nada, pero es un indicativo de a que frecuencia funciona el bus.

P.D: Entre un 65816 a 7,67mhz y un 68000 a 7,67mhz, cualquiera te dirá que el primero es mas potente.

29 abr 2018 20:58

Enlace permanente

P.D: Entre un 65816 a 7,67mhz y un 68000 a 7,67mhz, cualquiera te dirá que el primero es mas potente.

Y por lo leído en este hilo y otros, hay otros factores a valorar en lo referente a incluirlos en una consola clásica incluso a la misma frecuencia. El 65816 es una máquina accediendo a memorias y ejecutando sus propias miniinstrucciones. El 68000 es más versátil, friendly, y permite al programador plantearse muchos algorritmos de diferente manera como para incluso mejorar al WDC en ciertos campos a base de flexibilidad.

Por eso quiero leer todo lo que tenga que decir un, literalmente, profesional como magno antes de darte mi opinión final.

Yo no estoy poniendo al 68.000 por delante que quede claro, simplemente reitero que en base a la de veces que has metido la gamba (como yo) me parece muy atrevido por tu parte que de repente ahora estés tan seguro de que SEGA se equivocó con el procesador, y que literalmente digas que sobra en una consola en comparación del 65816, cuando hay otros factores a valorar.

A mí ahora que los conozco más ambos me parecen geniales en su estilo. Pero decir que uno es mejor que otro para consolas me parece una ebriedad por tu parte xD

29 abr 2018 22:37

Enlace permanente

A todo esto, @Señor Ventura, el ancho de banda de la SNES es de 6,14 KBytes, no 6,14 kb (kilobits). Lo digo por si a alguien le extraña que habéis estado hablando de Kb y en mi último post yo hablo de kB y no le cuadran los datos.

En cuanto a los procesadores, el 68000 es más cómodo porque tiene muchos registros donde almacenar operaciones intermedias y asi evitar constantemente accesos externos de R/W, sobre todo si programas en ensamblador. El 65C816 te obliga a calentarte la cabeza al programar si quieres hacer rutinas rápidas aprovechando bien los registros y los modos de direccionamiento.

30 abr 2018 20:13

Enlace permanente

A todo esto, @Señor Ventura, el ancho de banda de la SNES es de 6,14 KBytes, no 6,14 kb (kilobits). Lo digo por si a alguien le extraña que habéis estado hablando de Kb y en mi último post yo hablo de kB y no le cuadran los datos.

Cierto, no se puede dejar llevar uno por esos dejes a la hora de hablar con propiedad, especialmente en estos temas, donde una errata así cambia un mundo.

30 abr 2018 20:33

Enlace permanente

@Señor Ventura mañana o así ("así" lo mismo es pasado xD) mi opinión.

Una última cosa:

La cpu no tiene que ver nada, pero es un indicativo de a que frecuencia funciona el bus.

Si la CPU no tiene que ver con el ancho de banda nominal por frame; ¿entonces por qué estás sacando pecho con el 65816 en ese aspecto?

* 30 abr 2018 20:46

Enlace permanente

@Señor Ventura mañana o así ("así" lo mismo es pasado xD) mi opinión.

Una última cosa:

La cpu no tiene que ver nada, pero es un indicativo de a que frecuencia funciona el bus.

Si la CPU no tiene que ver con el ancho de banda nominal por frame; ¿entonces por qué estás sacando pecho con el 65816 en ese aspecto?

Porque es fundamental que su frecuencia externa sea alta. Accede a memoria en un ciclo, así que trabaja externamente tan rápido como internamente, eso hace que el bus tenga esa misma frecuencia de trabajo, y por lo tanto que el DMA pueda trabajar potencialmente a esa velocidad.

Recordemos que el DMA se adapta al componente mas lento, así que para que un 68000 tenga un bus tan rápido, tendría que funcionar externamente a esa velocidad, y eso implicaría tener que funcionar internamente a 4 veces esa frecuencia. Vamos, que saldría carísimo xD

Es una incógnita (al menos para mi) a que frencuencia tope puede llegar a trabajar el DMA de snes, pero supongo que eso ya da igual xD

30 abr 2018 20:52

Enlace permanente

@Señor Ventura un ciclo de espera para trabajar externamente tengo entendido, imagino que es a lo que te refieres, pero sí, la virtud del 65816 es su agilidad accediendo a memorias y ejecutando sus propias instrucciones.

Como dijo magno al principio, se comporta más como un microcontrolador que como una CPU gobernanta.

Weno, cuando tenga energía nos damos de hostias un rato xDD

30 abr 2018 21:07

Enlace permanente

Weno, cuando tenga energía nos damos de hostias un rato xDD

Yo pium pium xD

(mensaje borrado)

09 may 2018 20:56  (mensaje borrado)

Enlace permanente