Hilo técnico de consolas 2D

cirote3 escribió:

Snes escribió:@cirote3 si por hay ronda entre un 10% y un 17% ,pero si se mejora el rendimiento general del juego eliminado casi todas las ralentizaciones .

Diría más bien entre un 2% y un 17%

He leido que ese agua en concreto de Sonic 3 no funciona correctamente en la Genesis 3 ya que es muy sensible al timming y esa consola es un ASIC no muy bien hecho por lo que no tiene los timmings perfectos pero nunca he visto un vídeo del problema que se produce.

Tampoco entiendo muy bien cual es la diferencia entre las 2 aguas ¿Que ponen un delay para que coincida con el Hblank y asi no salen los dots? ¿Y como saben cuanto tiempo tarda la línea en dibujarse?

Un Saludo.

naxeras escribió:Tampoco entiendo muy bien cual es la diferencia entre las 2 aguas ¿Que ponen un delay para que coincida con el Hblank y asi no salen los dots? ¿Y como saben cuanto tiempo tarda la línea en dibujarse?

Entiendo que la diferencia es que en una se actualiza toda la paleta del agua en un HBlank de golpe y en la otra se actualiza poco a poco, en varios HBlanks. Los HBlanks siempre duran lo mismo, la línea siempre tarda lo mismo en dibujarse.

¿Podría alguien explicarme lo de slow rom y fast rom? Se refiere al tipo de memoria rom (acceso a los datos y tal) en la que la original era más lenta que la fast rom y por eso provoca caídas? Al menos algo así he entendido.

Lázaro escribió:¿Podría alguien explicarme lo de slow rom y fast rom? Se refiere al tipo de memoria rom (acceso a los datos y tal) en la que la original era más lenta que la fast rom y por eso provoca caídas? Al menos algo así he entendido.

En el modo slow, la ROM tiene un tiempo de acceso de 200ns y en el fast de 120ns. Así que sí, la ROM en modo slow es más lenta y por eso provoca más ralentizaciones. Viendo los vídeos la diferencia entre los dos modos es menor de lo que me esperaba, la verdad.

@cirote3 ¿Pero es algo que se puede programar o es el hardware que lleva?
Hay momentos en los que se nota, si, pero si no hay mucha cosa en pantalla tampoco se nota tanto.

Lázaro escribió:@cirote3 ¿Pero es algo que se puede programar o es el hardware que lleva?
Hay momentos en los que se nota, si, pero si no hay mucha cosa en pantalla tampoco se nota tanto.

Los cartuchos que no soportaban modo fast eran más baratos. Si el cartucho soporta el modo fast, hay que activarlo con instrucciones dentro del juego.

@cirote3 Y si se comercializaban con soporte de modo fast, ¿por qué no lo activaban de serie? ¿Se sabía de antes todo esto?

Los cartuchos slow también provocan que la snes se configure para trabajar a una velocidad menor. El reloj de la CPU de quedaba en 2,68 mhz en lugar de los 3,58 MHz del modo fast.
Producir cartuchos con slow ROMs era mass barato y las empresas solían optar por ese camino de ahorrar dinero.

sgonzalez escribió:Los cartuchos slow también provocan que la snes se configure para trabajar a una velocidad menor. El reloj de la CPU de quedaba en 2,68 mhz en lugar de los 3,58 MHz del modo fast.
Producir cartuchos con slow ROMs era mass barato y las empresas solían optar por ese camino de ahorrar dinero.

Realmente era porque Nintendo es la que les vendia los cartuchos a las empresas a un precio de todo menos barato jajajajaja, menudas regalias les pedía por su cuasi monopolio de marca, eso si merecia la pena porque al final vendían mas con Nintendo que con la competencia.

Lázaro escribió:@cirote3 Y si se comercializaban con soporte de modo fast, ¿por qué no lo activaban de serie?

La SNES siempre arranca por defecto en modo slow, es el programador quien tiene que activar el modo fast cuando arranca el juego si sabe o cree que el cartucho lo va a soportar.

Lázaro escribió:¿Se sabía de antes todo esto?

Claro que se sabía, ¿por qué no se iba a saber?

cirote3 escribió:

Lázaro escribió:¿Se sabía de antes todo esto?

Claro que se sabía, ¿por qué no se iba a saber?

bueno ,se sabia ...
lo del fast rom es relativamente nuevo ,anda que no se ha escrito nada en este foro acerca de las ralentizaciones del castlevania 4 .
que si la consola no da para mas ,que las ralentizaciones eran por la cpu ect ,todo eso hace dos dias como quien dice .

como este juego otros que se arreglaron con el cambio a fast rom

Lázaro escribió:¿Podría alguien explicarme lo de slow rom y fast rom? Se refiere al tipo de memoria rom (acceso a los datos y tal) en la que la original era más lenta que la fast rom y por eso provoca caídas? Al menos algo así he entendido.

De hecho esto es buen momento para desmitificar ciertos funcionamientos de Fast/Slow-ROM.

Tal y como te indican Fast-Rom es un cartucho que permite a la CPU leer la ROM a 3,58 MHz en lugar de 2,68 MHz, en los bancos altos del mapa de memoria.

¿Es un mejora del 33%? ¿O es una mejora del 25%?
- Se dice que es una mejora del 33% porque el aumento de 2,68 MHz a 3,58 MHz es del 33,5%
- En cambio si calculamos la pérdida de eficiencia de entre 3,58MHz a 2,68 MHz es del 25,14%

La gente suele utilizar el número más grande. No es equívoco pero "suena mejor" pudiendo parecer que el rendimiento real y la diferencia de rendimiento es más exagerada de lo que realmente es... ¿Pero es realmente un aumento de rendimiento tan bestia? (hablando de ese 33%)

El acceso de CPU a ROM funciona a 3,58MHz con Fast-ROM pero esto no cambia el tiempo de acceso al resto de componentes sigue siendo el mismo: CPU a RAM/WRAM 2,68MHz, CPU a SRAM 2,68MHz, DMA a VRAM 2,68MHz, CPU a joypad 1,79MHz...

Además hay que tener en cuenta que tampoco evita los propios cuellos de botella del propio sistema, como cuando durante una transferencia DMA, la CPU se pausa mientras el controlador DMA toma el control del bus, lo que significa que Fast-ROM tampoco acelera ese proceso, o cuando para comunicarse con el SPC700, la CPU tiene que esperar a que este responda por los puertos, y el ritmo de esa transferencia lo marca el propio SPC700, no la velocidad de lectura de la ROM.

Con lo que aquí entraríamos en Ley de Amdahl la que describe que el rendimiento de un sistema está limitado por aquellas partes que no se puede cambiar. Te pongo un ejemplo simple:

Imagina que te lleva 1 hora escribir e imprimir un documento: dedicas 40 minutos a escribirlo y la impresora tarda 20 minutos en imprimirlo.

Ahora, decides comprar una impresora de última generación que imprime el mismo documento en 5 minutos. ¿Cuánto tardas ahora en tener el documento físico en tus manos? 45 minutos. Aunque hayas mejorado la impresora, sigues escribiendo a un ritmo que te lleva 40 minutos terminar el texto. En este caso, tú eres quien no ha mejorado, lo que hace que esos 40 minutos sean inevitables.

La mejora entre la impresora antigua y la nueva es del 75 % (de 20 minutos a 5 minutos), pero la mejora total para la tarea completa es solo del 25 % (de 1 hora a 45 minutos).

Luego ¿Cómo se compara esto con lo que hemos visto con Fast/Slow-ROM?
A pesar de que el acceso a ROM aumente ese 33%, a nivel general y dependiendo de las exigencias de acceso a ROM que requiera un juego u otro, la mejora variará según el escenario, pero a nivel general, un máximo de mejora de rendimiento de alrededor del 15% es lo que se logra con Fast-ROM.

Es por ello que aunque hay una mejora notable, juegos en Fast-ROM que antes no lo eran llegan a presentar aún ralentizaciones (Contra III, Thunder Spirits,SCIV...) por eso hackers como Vitor Vilela son más conservadores al declarar "casi todo".


Como dice @cirote3 la SNES arranca en modo SLOW, pero aunque vea el flag marcado de FAST-ROM, hay que verificar que también se esté accediendo a la zona de la memoria rápida de la ROM:

Hay que mirar que el código se esté ejecutando entre los bancos $80 y $FF (los Bancos 83D... se encuentran en esa zona):


Luego existen muchos juegos de SNES a Slow-ROM que funcionan perfectamente a 60FPS (como el nombreado F-Zero) donde poner Fast-ROM no tendría demasiado sentido ya ya mantiene una estabilidad perfecta. Gracias a que la PPU se encarga de lo más pesado (el modo 7), la CPU tiene que encargarse de las posiciones relativas de un máximo de 4 naves en pantalla respecto al jugador, el HUD, marcadores... El coste para la CPU en esta parte es pequeño; lo que sí consume es tiempo de bus por el HDMA.

A partir de aquí podríamos teorizar en F-Zero funcionase con Fast-ROM cuántos elementos más podríamos añadirle o no pero la realidad es que no existe de momento tal ROM para realizar comprobaciones y cómo se viese afectado el rendimiento según el número y la razón de esos elementos.

En el apartado de las ralentizaciones fue Nintendo la que realmente metió lo pata dando le a las empresas (capcom etc) la oportunidad de escoger entre fast rom y lowrom . Si Nintendo solo hubiera dado a las empresas la confirmación de fastrom la SNES hubiera tenido ralentizaciones en sus juegos? Te aseguro que sí pero no hubiera sido tan crítico como lo que tú vimos en la época, pero este problema de las ralentizaciones no era exclusivamente de la snes la MD, Neo Geo todas las 16 bit lo presentaban en mayor o menor medida que otras pero todas los tenían, la snes en este apartado era la que más sufría por la política de Nintendo. En cuanto a F zero por ejemplo la snes no necesita el fastrom para mover esas cuatro naves como antes dicho , pero una MD tiene que reducir distancia de dibujado ir a 30 FPS reducir resolución y la CPU a full para mover esas cuatro naves, eso es por diferencia de arquitectura entre ambas consolas pero aquí la snes sale ganando . Quizás si la snes no hubiera tenido la configuración de slowrom en los cartuchos hubiera estado más parejas con su competencia directa la MD.
Editó

Traducción:
Optimicé los códigos de *Thunder Spirits* para SNES!

Fue mi mayor desafío hasta la fecha, ya que el juego está pésimamente optimizado (es una brutalidad).
kandowontu había realizado una conversión a FastROM y, aun así, el juego sufría de un *lag* tremendo.
¡Ahora va mucho más fluido

Los cartuchos hubieran sido más caros todavía. ¿Hubieran vendido más para compensar el sobreprecio?
Seguramente no.

Creo que los cartuchos de la Mega Drive más rápidos eran igual de lentos que los más lentos de la SNES (200ns de latencia). Nunca he entendido por qué a Nintendo se le critica tanto el tema de la velocidad de los cartuchos y Sega tiene carta blanca

En ese tema yo no estoy muy puesto, seguro que @M68K sabe más

@M68K ¡Muchísimas gracias por la explicación! Vaya currada jaja
Más o menos me imaginaba que sería algo de eso pero en temas técnicos soy un pez de cuidao.

cirote3 escribió:Creo que los cartuchos de la Mega Drive más rápidos eran igual de lentos que los más lentos de la SNES (200ns de latencia). Nunca he entendido por qué a Nintendo se le critica tanto el tema de la velocidad de los cartuchos y Sega tiene carta blanca

En ese tema yo no estoy muy puesto, seguro que @M68K sabe más

Realmente que una ROM tenga 200ns no significa directamente que ambas CPUs puedan completar una lectura en 200ns, sino que la memoria necesita ese tiempo para preparar los datos válidos.

Luego cada CPU funciona a diferentes frecuencias con sus tiempo por ciclo (esto dependiente de los MHz), el número de ciclos por instrucción y la cantidad de datos transferibles cada vez (bus de 16bits vs bus de 8bits)

Lo que pasa es que era más determinante o más bien afecta más al rendimiento el tiempo de acceso a ROM de SNES que el de MD. Slow-ROM/Fast-ROM está directamente ligada al tiempo de los ciclos del 5A22 y, por tanto, puede afectar directamente a cuánto tarda la CPU en ejecutar código que depende de accesos a ROM.

Lázaro escribió:@M68K ¡Muchísimas gracias por la explicación! Vaya currada jaja
Más o menos me imaginaba que sería algo de eso pero en temas técnicos soy un pez de cuidao.

Nada hombre, si algo no te queda claro avisa que a base de símiles podemos llegar muy lejos.

M68K escribió:

cirote3 escribió:Creo que los cartuchos de la Mega Drive más rápidos eran igual de lentos que los más lentos de la SNES (200ns de latencia). Nunca he entendido por qué a Nintendo se le critica tanto el tema de la velocidad de los cartuchos y Sega tiene carta blanca

En ese tema yo no estoy muy puesto, seguro que @M68K sabe más

Realmente que una ROM tenga 200ns no significa directamente que ambas CPUs puedan completar una lectura en 200ns, sino que la memoria necesita ese tiempo para preparar los datos válidos.

Luego cada CPU funciona a diferentes frecuencias con sus tiempo por ciclo (esto dependiente de los MHz), el número de ciclos por instrucción y la cantidad de datos transferibles cada vez (bus de 16bits vs bus de 8bits)

Lo que pasa es que era más determinante o más bien afecta más al rendimiento el tiempo de acceso a ROM de SNES que el de MD. Slow-ROM/Fast-ROM está directamente ligada al tiempo de los ciclos del 5A22 y, por tanto, puede afectar directamente a cuánto tarda la CPU en ejecutar código que depende de accesos a ROM.

Todo eso lo tenía más o menos claro, lo que no tengo claro es si en los juegos comerciales de la Mega Drive se configuraba el tiempo de lectura con una latencia similar a la del modo FastROM de la SNES. Por lo que he leído, la latencia mínima que se usó era 200ns, la misma que los cartuchos SlowROM de la SNES, y había juegos comerciales con mayor latencia. Por eso no entiendo que se le eche tanto en cara la velocidad de los cartuchos a Nintendo y a Sega no. Supongo que los cartuchos de Mega Drive permitían transmitir más datos por segundo a costa de tener mayor latencia.

cirote3 escribió:Todo eso lo tenía más o menos claro, lo que no tengo claro es si en los juegos comerciales de la Mega Drive se configuraba el tiempo de lectura con una latencia similar a la del modo FastROM de la SNES. Por lo que he leído, la latencia mínima que se usó era 200ns, la misma que los cartuchos SlowROM de la SNES, y había juegos comerciales con mayor latencia. Por eso no entiendo que se le eche tanto en cara la velocidad de los cartuchos a Nintendo y a Sega no. Supongo que los cartuchos de Mega Drive permitían transmitir más datos por segundo a costa de tener mayor latencia.

Además de la mayor transferencia que comentas, en MD podías tener tranquilamente una ROM de 250ns o incluso 300ns de latencia que no iba a cambiar la frecuencia de reloj ni la velocidad de la CPU (Tiene un margen de hasta 520ns: 130ns por ciclo con, como mínimo 4 ciclos y luego puede transferir hasta 16 bits "en un viaje"), mientras que en SNES aumenta/reduce el número de ciclos necesarios para acceder a esa lectura de 6 a 8 ciclos del reloj maestro (funcionando a 3,58MHz o a 2,68MHz en acceso) limitando transferencias a un bus de 8bits.

La recriminación entonces creo que viene del hecho de "capar" su propia CPU para abaratar costes a cambio de rendimiento. Y que es notorio cuando pasan un juego con slowdowns constantes a Fast-ROM y se eliminan la mayoría o reducen esos tiempos. Por eso la gente se queja de ello o llama más la atención.

Ya sabes, se va a recriminar a cada sistema el punto débil del mismo: "Ojalá MD tuviera más colores, ojalá la CPU de SNES fuese más rápida, deberían haberle puesto a Dreamcast que pueda leer DvDs, Saturn es difícil de programar.." etc etc

Que maravilla poder leer mensajes TAN trabajados e interesantes