[SUPER NINTENDO] Hilo oficial.

@Señor Ventura el tipo de memoria que usa? o por como tiene el bus? hace poco se estaba hablando que el problema de super era que no alcanzaba a actualizar la vram y por eso se recurria a usar franjas negras, o reducir sprites, tambien animaciones. pero no se como han hecho con otros juegos, sin usar chips de apoyo lograron meter sprites grandes, por ahi un juego de rol se entiende porque va todo pausado.

Yo en la época siempre pensé que era la mas potente de las 16bits y tenia sentido ya que salió al menos 2 años mas tarde que su competencia directa.

Tenia toda la prensa comprada cacareando las capaciades tecnicas, que tenia los sprites mas grandes, que la tira de sprites en pantalla a años luz de la competencia, que si el modo 7 que hacia scaling y rotaciones de sprites, los colores de pantalla, luego el sonido alucinante, el superFX y la resolución mucho mas grande de la competencia.

Con los años me he dado cuenta que practicamente todo eran trolas o medias verdades, aún así la consola tiene muchas fortalezas y la disfruté en su día aunque aún más después de los años gracias a traducciones de sus fantasticos RPG, pero cuando he probado toda la competencia en profundidad (PCE y MD) pues me di cuenta que no era ni muchisimo menos lo que nos vendieron en cuanto a hardware.

Para mi pertenece a la mejor generación de consolas dónde es necesario tener todas porque todas aportan algo, si SNES hubiera sido la bestia parda que tendria que haber sido por llevar 2 años de retraso se hubiera comido a la competencia tanto que casi se hubieran quedado en anecdota asi que casi mejor que no haya sido así y tengamos la variedad y calidad que tenemos.

Un Saludo.

cristus escribió:@Señor Ventura el tipo de memoria que usa? o por como tiene el bus?

La wram obliga al resto del pipeline a adaptarse a su frecuencia cuando es usada específicamente.

Posiblemente el dma funcione realmente a 2,68mhz de forma establecida, pero hace años leí que se especulaba que este (es decir, el bus), tenía el ancho de banda que tenía por culpa de tener que adaptarse a la frecuencia que impone la wram, pero es tan fácil como ver a que velocidad transfiere a una sram a 3,58mhz desde el cartucho, y se habría descubierto el pastel.

Editado: parece que se afirma que el dma si funciona a 3,58mhz pudiendo alcanzar casi 9KB por frame, pero que la frecuencia de la wram la mantiene a 2,68mhz, alcanzando sus poco mas de 6KB por frame. Habrá que indagar un poco mas.

cristus escribió:hace poco se estaba hablando que el problema de super era que no alcanzaba a actualizar la vram

Eso dependerá de lo ambicioso que se sea, porque eso no va a ser así en cualquier caso. Con snes se cometían muchos fallos... se underclockeaba la cpu, se utilizaba la página cero para simular comportamientos de otras cpus, se usaba la cpu para descomprimir datos de la rom porque no pocas veces los samples que usaba el spc700 obligaba a necesitar roms mas grandes (y la solución era, como digo, comprimir en lugar de otorgar roms mas amplias)... todo esto lo juntas, y obtienes como resultado una cpu trabajando mas tiempo del que debe.

Cpu y dma comparten bus, y si la cpu está activa demasiado tiempo, le deja menos tiempo al dma. Ahí tienes un motivo real de por qué se necesitaban emplear bandas negras. También influye la propia potencia del procesador, pero no es correcto decir que era un mal procesador, porque si que proporciona una potencia aceptable, el problema es que era potente, pero sin margen para hacerle esas perrerías sin costarle un handicap.


Ahora, cuando hablamos de accesos a la vram, hay que distinguir entre sprites y planos.

La snes tiene la particularidad, por como almacena los tiles en memoria, de manejar diferentes tamaños según su profundidad de color. Como digo, esto afecta a los planos únicamente.

Ya existió un intenso debate sobre la imposibilidad posibilidad de enviar tiles de 3BPP ahorrando un 25% de tiempo de transferencia con respecto a 4BPP, y además puede enviar tiles de 2BPP necesitando solo el 50% del ancho de banda.

En definitiva, el problema de no alcanzar a actualizar la vram dependerá mucho de lo que hagas, de como lo hagas, y de cuanto quieras actualizar, porque SI tiene un ancho de banda generoso.

cristus escribió:y por eso se recurria a usar franjas negras, o reducir sprites, tambien animaciones. pero no se como han hecho con otros juegos, sin usar chips de apoyo lograron meter sprites grandes, por ahi un juego de rol se entiende porque va todo pausado.

Este ejemplo si desactiva algunas scanlines, pero se puede mejorar el resultado. Si usas planos a 2 o 3BPP, el rendimiento con las animaciones aumenta.

@Señor Ventura gracias por la explicación,
el chip de super ya estaba pensado para ahorrar memoria, porque son canales adpcm, pero esas descompresiones las hacia el cpu entonces? hay muchos juegos que para cambiar de sample para la música, se para el juego completo.
me decis que el acceso a memoria por frame es de 6kb, pero para trener una referencia, en otras maquinas de que valores hablamos? por ejemplo pc engine, megadrive, neo geo....

cristus escribió:@Señor Ventura gracias por la explicación,
el chip de super ya estaba pensado para ahorrar memoria, porque son canales adpcm, pero esas descompresiones las hacia el cpu entonces? hay muchos juegos que para cambiar de sample para la música, se para el juego completo.
me decis que el acceso a memoria por frame es de 6kb, pero para trener una referencia, en otras maquinas de que valores hablamos? por ejemplo pc engine, megadrive, neo geo....

Las descompresiones de los samples de audio las realiza el spc700, a lo que me refería es que de por si el audio cuesta una buena parte de la rom, así que los graficos podían comprimirse para no conceder roms mas grandes, y estas si las descomprime la cpu principal, la cual es una tarea adicional que retrasa el momento de dejar libre el bus para el dma, quedándole menos tiempo para transferir.

6,32KB es el pico máximo que nunca vas a aprovechar en situaciones de juego normal (6,14KB realmente debido a una condición de la wram para alimentar las celdas que contienen la información, ya que integran "micro condensadores" que necesitan renovar su carga, parando durante 40 ciclos a mitad de cada scanline, y obligando a todo el sistema a detenerse, también al dma), a menos que planifiques otro tipo de comportamiento, como ir a los 30 fps, cpu externa, bandas negras, etc.

El dma a 3,58mhz da una tasa de 8,89KB/frame, pero por culpa de la wram está limitado a funcionar a 2,68mhz, o directamente lo planificaron para que funcione así. Según leo hay formas de conseguir que transfiera a 3,58mhz, pero se me hace raro que pueda ser posible.

Se que hay áreas de la wram cuyo acceso de lectura/escritura permiten a la cpu a funcionar a 3,58mhz, sin underclockeos, y bien pensado, supongo que esto no podría suceder si la unidad dma (encapsulada junto al 65816 en el 5A22), no estuviese funcionando también a 3,58mhz... en cuyo caso una sram rápida desde el cartucho solucionaría todos los problemas puenteando la wram, pero no he leído documentación al respecto, así que es algo que asemejo mas a una teoría que a una forma de funcionar comprobada.


Prefiero no hablar de otras máquinas en el hilo de la snes, pero puedes preguntar en otros hilos.

@Señor Ventura el chip SA-1 y super fx tienen una muy pequeña ram, pero mas rápida, eso permite mejorar la tasa del dma?

cristus escribió:@Señor Ventura el chip SA-1 y super fx tienen una muy pequeña ram, pero mas rápida, eso permite mejorar la tasa del dma?

En teoría es a eso a lo que se refiere, pero no es necesario un procesador de apoyo.

Recientemente se ha modificado el another world/out of this world para que trabaje sobre el frame buffer en una sram a 3,58mhz desde el cartucho, en lugar de desde la wram utilizando pequeñas áreas a esa frecuencia. Sin procesador de apoyo.

El resultado son 30fps constantes manteniendo la resolución, y no me extrañaría que aún quede margen para mas.

Lo que me fascina es la snes pal, que presumiblemente alcanzaría en esas condiciones los *casi* 21KB por frame. Una burrada. Habria que ver que pasa con esto.

@Señor Ventura

Recientemente se ha modificado el another world/out of this world para que trabaje sobre el frame buffer en una sram a 3,58mhz

Memoria extra en el cartucho = dopping. Leve, pero no deja de ser un upgrade.

No obstante es interesante ver trabajar a la SNES con memorias sincronizadas con su Pipeline.

@SexyMotherFucker Independientemente de eso, el punto es que ese hubiera sido el rendimiento del another world de la snes si la wram hubiera funcionado a una frecuencia sincronizada con la cpu.

Se le puede preguntar al autor del hack si está empleando el dma a 2,68mhz, porque a 3,58mhz implica transferir antes para dejar aún mas tiempo de cpu para procesar (y a 3,58mhz, no a 2,68mhz), estamos hablando de que solo el problema de la wram está bloqueando un rendimiento muy, muy significativo.

El techo del rendimiento de ese another world podría estar incluso mas arriba, lo que podría implicar quedarte en esos 30fps y subir un poco mas la resolución, o bajar a 20 y mejorar mas claramente la definición.

Supuestamente el dma está underclockeado a 2,68mhz, pero puede funcionar a 3,58mhz. Recordemos que el 65816 y el dma forman parte de un mismo encapsulado (5A22), y personalmente (y sin ninguna información mediante que lo corrobore), digo que me parece extraño que ambas no puedan ir a 3,58mhz al unísono.

Si la cpu funciona a 3,58mhz cuando la memoria funciona a 3,58mhz (o a un múltiplo de 3,58mhz), o cuando accede a ciertas regiones de la propia wram (que si permite sincronizar a 3,58mhz, desconozco la razón exacta, pero si que la propia wram funciona a 3,58mhz en esas situaciones), entonces es de esperar que pase lo mismo con el dma.


DMA -> wram -> ram de vídeo -> 2,68mhz/6,32KB/frame (6,14KB tras reajustes de hardware).

¿DMA -> sram -> ram de video 3,58mhz/8,89KB/frame? (no he calculado en cuanto se queda tras esos reajustes).



Volviendo al another world, desbloquea poder trabajar a 3,58mhz durante todo el bloque de procesos (y no solo durante el breve espacio que proporciona la wram a esos 3,58mhz, pero igual el programa está llamando al DMA funcionando a 3,58mhz, pero no se está aprovechando porque el autor del hack no ha tocado eso para su hack.

Es decir, mejora lo que mejora automáticamente tras imponer esa nueva situación física del hardware, pero el software no lo usa en específico.


Podrá considerarse ilegítimo, pero es el rendimiento que pudo haber sido de no ser por la típica nintendada.

@Señor Ventura

Supuestamente el dma está underclockeado a 2,68mhz,

Si eso es cierto, entonces el ancho de banda de SNES siempre está constreñido aunque use Fastrom. ¿No?

Luego las cifras que llevas AÑOS soltando en el foro deberías retractarlas, y cuando hables de los "Kbs" de diferencia con otras máquinas respecto al DMA poner la cifra equivalente @2'68 MHz

Menos ancho de banda, sus limitaciones en el vblank, clock máximo de CPU de sólo 3'58 MHz, roms lentas... SNES es la reina de las bandas negras por un buen motivo.

¿1990 existían rams disponibles @3'58 MHz?

@SexyMotherFucker El ancho de banda siempre estará constreñido aunque use fast rom, pero supuestamente no si usa una sram a 3,58mhz (que es lo que tenía que haber sido la wram).

Las cifras que llevo años diciendo son ciertas, 6,14KB es el ancho de banda de una snes ntsc de stock. Una snes pal con una sram a 3,58mhz desde el cartucho debería rozar los 21KB por frame, lo cual es bastante monstruoso para un sistema de vídeo como ese. Le estás dando la gasolina que necesita para brillar como debe.

El equivalente a la tasa de transferencia de un lector de CDs a 8X.


Por lo demás, las perradas que le hacían, como emular el comportamiento de otras cpus, o underclockear el pipeline con slow roms, ya no es culpa de la snes, y no es el funcionamiento normal de la máquina. Las bandas negras son gratis, les encantaba lo gratis cuando querían reducir costes.


Y hablando del funcionamiento normal de la máquina... se dejaron tanto por explorar...

@Señor Ventura Juraría que tú siempre has dado 1 cifra diferente dependiendo si era fast o slow Rom, pero bueno.

Por lo demás el what If que te estás montando de la "gasolina" necesaria es similar al de; y si la MD hubiese venido con sus 128kb de vram originales y por consiguiente con doble bus de vídeo...

O; y si la Ps2 hubiese tenido 8MB de EDRAM en lugar de 4.

O la GC 48 MB de 1Tram como la placa Triforce en lugar de los 24 originales.

O la Xbox 128 en lugar de 64.

Etc. Etc.

Interesantes, pero bastante irrelevantes para la mayoría.

SexyMotherFucker escribió:Juraría que tú siempre has dado 1 cifra diferente dependiendo si era fast o slow Rom, pero bueno.

He dado dos cifras:
-6,32KB/ frame, que es el ancho de banda real.
-6,14KB/frame, que es el ancho de banda resultante de una compensación, lo comenté unos posts atrás.

Y luego tenemos la cifra teórica de 8,89KB/frame si transfieres un Byte cada 6 ciclos en lugar de cada 8 ciclos, que es lo que supuestamente te permite el DMA al funcionar a 3,58mhz desplazando la work ram al cartucho usando igualmente una frecuencia de 3,58mhz.

Todo esto en ntsc, en pal los anchos de banda son tremendamente brutos.

NO ENTIENDO por qué hay que luchar contra las significativas restricciones de los formatos ntsc, cuando las PAL estarían desbloqueando un rendimiento brutal, y a 30fps ya ni te digo.

Reivindico el formato pal como base para el benchmarking, que también son super nintendos, digo yo.

La excepción es la nes, que en pal sale perdiendo porque no se sirve de ningún ancho de banda.

SexyMotherFucker escribió:Por lo demás el what If que te estás montando de la "gasolina" necesaria es similar al de; y si la MD hubiese venido con sus 128kb de vram originales y por consiguiente con doble bus de vídeo...

Con la diferencia de que en el caso de la snes el upgrade es real sin recurrir a modificar la consola. Añades una sram a 3,58mhz en el cartucho, y si la suposición es correcta, es que le cambia la cara al rendimiento (parece que está documentado y todo el rollo, pero yo no lo he comprobado personalmente).


P.D: Sobre tu post anterior, aunque 6,14KB te resulte pobre, hay que recordar que las tiles de 2BPP solo pesan 16 Bytes, y comprimir a 3BPP solo le cuestan 24 Bytes al ancho de banda (32 en vram porque se realiza sobre una base de 4BPP).

Puede ocurrir, según configuración, que con ese poco ancho de banda le cunda mas, aunque ya digo que la snes en realidad si puede tener a su disposición aún mas ancho de banda del conocido.

@Señor Ventura Con las NTSC tienes 60fps completos.

Con las PAL más ancho de banda y tiempo de CPU, pero a 50.

Cada una tiene lo suyo.

El problema es que pasar de 6 a 9 kb en el DMA no lo va a notar NADIE salvo los que nos entretenemos contamos píxeles. Y cuando tú, todo emocionado, vayas corriendo a explicárselo al 99% del planeta en plan; "¿Veis gente? ¡Ganas 3 scanlines aquí! ". Esa gente va a reaccionar así:



Pato el primero.

Una SNES con una Wram @3'58 MHz hubiese sido totalmente irrelevante a nivel comercial. A ojos del gran público no hubiese marcado ninguna diferencia salvo en casos muy concretos.

En cambio una SNES sin roms lentas sí hubiese sido relevante porque se habría mejorado el rendimiento de muchos juegos criticados por ello.

@SexyMotherFucker Pues así a bote pronto, una snes pal con una sram desde el cartucho (si es que la teoría de la sram a 3,58mhz es cierta), podría reproducir full motion vídeo a 512x224 y 4BPP a unos 16 frames por segundo. Parece que la cosa andaría mas sobre los 19KB/s que algo por debajo de los 21KB/s. Yo no me reiría mucho de la snes pal por sus 50fps, precisamente porque esos 10fps, si adaptas la velocidad del juego, si que no lo vas a notar, pero la enorme diferencia de rendimiento, SI.


El resto díselo a rebecca heinemann, que estuvo luchando la de dios porque le pusieron en chino terminar el port del another world de snes.

Léete esto:
https://fabiensanglard.net/another_world_polygons_SNES/


Tener casi 9KB de ancho de banda por frame implica que, mientras que antes transferir 6KB de tiles durante el vblank causaba dejar sin tiempo a la cpu para que procese sus cosas, ahora puedes transferir esos 6KB, y aún disponer de un 30% de tiempo para que la cpu haga lo que tenga que hacer, que a 3,58mhz con una fast rom, es MUCHO.

Para que te hagas una idea de cuanto si que se nota.


edit: El port original del another world, y el hack, efectivamente refleja un cambio significativo en el rendimiento, pero además hay que recordar que cambia el rendimiento porque cambian las condiciones, no porque el propio código las esté aprovechando. La diferencia debería incluso mas grande aún.

@Señor Ventura Dopaje para SNES es que ya hubo a espuertas en los 90: ram extra en los cartuchos, chip FX, etc. Por lo que esta memoria @3'58 MHz dentro del cartucho poco aporta más allá de satisfacer curiosidad científica, ya que las bondades que pueda aportar también las podría ejecutar perfectamente un chip SA-1 anexo... Y eso ya lo vimos, no en juegos como Another World, pero sí de otra manera en los Kirby que lo usan con rendimiento inmaculado. Lo que vendría siendo una SNES funcionando sin sus cuellos de botella.

En esta consola a nivel de hardware extra el Gran aporte fue el MSU1, el cual podría considerarse el "CD-rom" Digital de la consola.

Con este percal, si yo fuese fan de SNES estaría más interesado en ver desarrollado el potencial completo del sistema por sí misma:

- Roms de 96-100 megabits.
- SIEMPRE fast roms.
- Exploración de los límites en los modos hi-res de la consola sin "niñeras" (Chips de apoyo). O de las supuestas aplicaciones de los multiplicadores ociosos.
- Desarrollos desde 0 para consolas PAL.

Ahí ya hay un ecosistema interesante y casi insólito por explorar. Recurrir a meter más "chatarra" extra en los cartuchos me resulta anacrónico en el caso de SNES.

@Sexy MotherFucker añado que a mi me gustaría que desarrollando juegos nuevo usando SA1 y SFX2 originales para ver si se puede rascar todavía más de ellos, del SFX2 casi seguro que sí, es imposible que con solo un par de juegos se haya exprimido al máximo.

@Sexy MotherFucker eso está muy bien pero no creo que ningún equipo se meta a desarrollar en serio para SNES, es complicado. Recuerdo hace meses que leyendo acabé en un subreddit sobre aficionados que querían programar para SNES. Aquello parecía casi un grupo de terapia para traumas.
Para sacar algo en SNES debes controlar el hw a la perfección y programar en ensamblador para una CPU sobre la que apenas hay documentación alguna. Imagina que había aficionados que llevaban semanas para lograr que algo se mueva en ella. No es como otros sistemas (NES, GB o MD) que se pueden programar en C y con un compilador sencillo y bien trabajado por una CPU muy conocida y documentada. Para SNES es un infierno comparado con ellas. Si quieres ver algo deberás reunir un grupo de enfermos de SNES dispuestos a consumir meses de aprendizaje y posiblemente desarrollar ellos mismos herramientas que no existen aún para programar en la consola, y luego está que todo ese trabajo lleve detrás un incentivo que les merezca la pena.

Un saludo

@Falkiño los 6502 y 65816 están muy bien documentados; no tanto como los M68k, pero si quieres aprender puedes. Otra cosa es que al ser más rudimentarios que el modelo de procesador "Moderno" que representaron los Motorola eche para detrás a mucha gente.

Lo verdaderamente chungo del desarrollo en SNES, entiendo yo, es la propia arquitectura de la consola: ram segmentada, limitaciones con el vblank, etc. Y la poca información del resto del hardware (PPUs). Hay que lidiar con muchos obstáculos. Ahora bien; también abre la puerta a oportunidades únicas: matemática del color, HDMA, escalados por hardware, etc.

@Sexy MotherFucker claro, a ver una SNES con conocimientos actuales de optimización y ROMs mayores puede dejarnos con el culo torcido. Pero es como dices, la arquitectura en sí es difícil y está poco documentada. En ese subreddit había desarrolladores entusiastas de homebrew retro y desaconsejaban programar en SNES por todo lo comentado, decían que era mejor centrarse en NES, GB o MD, daba muchos menos dolores de cabeza. No es de extrañar que debido a ello muchas empresas que hacen cosas para máquinas antiguas se centren en los microordenadores y las tres consolas citadas (a veces con ports para Neo Geo y GBA y poco más) y cuando sacan algo en SNES es porque meten una Raspi o lo que sea en el cartucho.

Hasta que algún loco no se meta a descubrir toda esa info de SNES y sepa crear un kit y unas instrucciones claras open source para la comunidad no se va a poder explorar esa consola con conocimientos modernos. Es triste, pero es así.

Un saludo

No se hace en snes cosas por limitaciones que tanto gusta indicar a los menos fanáticos del sistema, no se hace por complejidad (poca documentación y nulas herramientas que faciliten la tarea), tiempo y coste si pretendes sacarlo en físico.

O´Neill escribió:No se hace en snes cosas por limitaciones que tanto gusta indicar a los menos fanáticos del sistema, no se hace por complejidad (poca documentación y nulas herramientas que faciliten la tarea), tiempo y coste si pretendes sacarlo en físico.

Claro es que si fuese por limitaciones no se sacaban cosas para Game Boy o NES. También si fuera por potencia no tendría sentido que el emulador de Dreamcast fuese durante años mejor que el de Saturn o que el de GameCube fuera mejor al de N64. No se trata de la potencia del sistema sino del sistema en sí, cómo sea de complejo entenderlo y más si como es el caso, que las herramientas que haya sean nulas y la documentación disponible genérica y escasa.

SNES en ese sentido es un melón por abrir, pero ahí entra el incentivo que pueda tener un grupo para abrirlo ¿merece la pena el esfuerzo? Si lo merece sería en cualquier caso por incentivos económicos, si te planteas "descubrir SNES" en ese sentido vas a querer un retorno por esa inversión de dinero y tiempo; pero si analizas el mercado tiene más sentido invertir menos dinero y menos tiempo y lanzar algo para otras máquinas más sencillas. Está bien ser nintenfermo, pero no gilipollas.

Un saludo!

@SexyMotherFucker no estoy de acuerdo. A un programador que sabe lo que hace no le asusta nada, la diferencia entre la scene de snes, y el resto de scenes, es que en snes cada uno hace la guerra por su lado, no hay una librería de conocimientos como para que pueda surgir un sdk que reuna todos los "descubrimientos". Ese es el problema, y no otro: la filosofía.

Por lo demás, se trata de un hardware externo que te enseña cual hubiera sido el rendimiento de una snes si esa infame wram hubiera tenido la frecuencia que tenía que tener, eso se lo hacen a cualquier otro hardware y efectivamente su DMA no nota cambios, pero la snes SI. Esa es la gracia, que con una sram ves a la verdadera snes tal cual es.

Para mi es tan ilegítimo como legítimo, en este caso, es una excepción.


Queda mucho por explorar, el hdma todavía hoy tiene que explorarse bien... y te llevas tus chascos. Tenía muchas ganas de multiplexar tiles de un plano en modo 7 para zooms perpendiculares, pero no hay registros que permitan vram to vram copy fuera del v-blank, y la tabla de atributos queda escrita físicamente sobre el silicio (hardwired), por lo que no se puede manipular. El único puntero ya está siendo usado por el line buffer, por lo que todas las esperanzas se centran en el hdma, pero no hay registro que lo soporte. Mi idea se centraba en un triple buffering de tiles ya instalados en vram, por lo que te ahorras trasferir 64 Bytes por tile para un ancho total de 32 por línea (8 canales x 4 Bytes, como máximo un tile adicional cada dos scanlines). Copiar de vram a vram literalmente seria como pedirle a un escritor que transcriba un texto que está en la habitación de al lado sin levantarse a mirar.

Sinceramente, me ha debastado enterarme de eso, tenía mis planes, ahora que voy a poder centrarme en aprender... pero hay mas oportunidades, siempre se abren ventanas cuando se cierran puertas: 8,89KB por frame, nuevo record de su generación

@Falkiño no sé en que quedó, pero hace unos años estaban los brasileños dandole cera a un SDK para SNES, claro que no es chasquear los dedos y tenerlo ya listo y pulido. El de MD fueron como 10 o 15 años para llegar al nivel de refinamiento actual no? Pues eso.

Pero no creo que SNES sea más compleja que sacar algo 2D potable que cualquier maquina 3D, incluída PS1 que es la "fácil", pero tenemos Saturn y N64 sacando locuras homebrew 3D y creo que son más complejas de domar y controlar ya sólo por el salto de diseño al 3D. En SNES falta gente y tiempo creo yo, que con todo ya hay homebrew interesante para ella, mejor o peor: Xenocrisis, New Super Mario Land, Super Boss Gaiden, etc.

Por lo que he leído a gente que desarrolla para la consola, la dificultad no está tanto en el desconocimiento de sus características o en la ausencia de documentación, sino el las peculiaridades que impone la máquina (más allá de los conocimientos que de por sí tenga el programador), de hecho, al tipo que hizo el "Mega Man 4 Episodio Rojo", y que a su vez, también programa para Snes (ahora está haciendo un plataformas de acción del estilo que tiene buena pinta), le leí decir que es al contrario, decía de forma sencilla para que se entendiera, que programar juegos para Snes es como "activar casillas" y que el sistema se encargue de hacer, mientras que por ejemplo, en MD, era un proceso más artesanal cuya limitación dependía más del ingenio y conocimiento, y creo que por lo que se puede ver a dai de hoy, diría que no va desencaminado.

Chavales, que han sacado un Sonic, los ports de NES, el hack que está haciendo un chaval del Super Mario World que tiene una pintaza tremenda, el juego de naves ese con fondos en modo 7, el run & gun que a nivel jugable es loquísimo lo que pasa que el arte visual es bastante meh...

Cualquiera diría que no se hace nada... yo creo que lo que hay es un poco de envidia viendo lo que se hace en otros sistemas

Para mí el mayor problema de largo es que no haya un buen compilador de C para la SNES. Documentación hay a punta pala, y el tema de la emulación para devs está mucho mejor en la SNES que en la MD gracias al Mesen. Pero sin un compilador a la altura, la SNES siempre va ir por detrás de las "competidoras" (MD, NG y GBA).

No es que no salgan cosas para la snes, es que la escena no está unificada.

Y particularidades tienen todas las máquinas. Si que es cierto que snes es rígida, pero también es flexible precisamente con sus funciones propias, el hdma por ejemplo resulta ser bastante "analógico", tanto que aún queda tela por cortar...

El problema es querer que la super nintendo sea otra máquina, eso nunca va a pasar. Ahora, también es cierto que durante su etapa comercial tampoco la dejaron ser ella misma, ni dejaban de underclockearla, ni empleaban siquiera todos sus modos gráficos... por no tener no tuvo ni lector de cd.

@Señor Ventura @cirote3
Lo del compilador es un problema, pero es que es la máquina más llena de putadas que he visto en los 8-16 bits. O sea, si estoy en este modo, esto tiene esta profundidad de color, en este otro esta otra. Si uso fastrom, los bancos son de 64kb, si uso slowrom son de 128kb. El mapper interno funciona de diferentes maneras dependiendo de varios factores...El sonido lo tienes que microprogramar para el chip de Sony en su ensamblador....

Tienes que acordarte de 200 cosas solo para no volverte loco debugando.

@kusfo79 Pienso igual, el compilador es un problema. Pero creo que el verdadero problema es la comunidad de dev de SNES, cada uno va a su bola y no se centraliza nada, incluso algunos se callan cosas que encuentran, y así no se puede avanzar.
Aunque pensándolo bien, también hay otro problema por el que creo que la dev de SNES no es igual que en MD, y es el miedo a que Nintendo llame a tu puerta

kusfo79 escribió:@Señor Ventura @cirote3
Lo del compilador es un problema, pero es que es la máquina más llena de putadas que he visto en los 8-16 bits. O sea, si estoy en este modo, esto tiene esta profundidad de color, en este otro esta otra. Si uso fastrom, los bancos son de 64kb, si uso slowrom son de 128kb. El mapper interno funciona de diferentes maneras dependiendo de varios factores...El sonido lo tienes que microprogramar para el chip de Sony en su ensamblador....

Tienes que acordarte de 200 cosas solo para no volverte loco debugando.

O automatizarlo con un sdk y olvidarte del tema. Point & click, que es lo que ya sabemos que le falta.

De todos modos yo no consideraría eso una putada, todas las máquinas imponen condiciones, lo que pasa es que la snes tiene muchas funciones, y así es normal que consideres que se vuelve rígida. Estas máquinas son todas fixed, y si vas a sota caballo y rey, no vas a notar nada, pero si puedes usar toda una gama de funciones, vas a notar mas que cuesta que interactúen entre ellas.

Vamos, que bendito problema.


También puedes dividir la pantalla en secciones, y usar diferentes modos y funciones en cada una de ellas. Luego está lo estupenda que es para paralelizar junto con 8 canales dma programables, que también se menciona muy poco las cosas que tiene que te solucionan la vida.

Precisamente si algo le achaco yo a la snes, no es lo que tu dices, sino la wram a 2,68mhz, o el hecho de que solo tiene un puntero. Eso si que hace daño.

Señor Ventura escribió:

kusfo79 escribió:@Señor Ventura @cirote3
Lo del compilador es un problema, pero es que es la máquina más llena de putadas que he visto en los 8-16 bits. O sea, si estoy en este modo, esto tiene esta profundidad de color, en este otro esta otra. Si uso fastrom, los bancos son de 64kb, si uso slowrom son de 128kb. El mapper interno funciona de diferentes maneras dependiendo de varios factores...El sonido lo tienes que microprogramar para el chip de Sony en su ensamblador....

Tienes que acordarte de 200 cosas solo para no volverte loco debugando.

O automatizarlo con un sdk y olvidarte del tema. Point & click, que es lo que ya sabemos que le falta.

De todos modos yo no consideraría eso una putada, todas las máquinas imponen condiciones, lo que pasa es que la snes tiene muchas funciones, y así es normal que consideres que se vuelve rígida. Estas máquinas son todas fixed, y si vas a sota caballo y rey, no vas a notar nada, pero si puedes usar toda una gama de funciones, vas a notar mas que cuesta que interactúen entre ellas.

Vamos, que bendito problema.


También puedes dividir la pantalla en secciones, y usar diferentes modos y funciones en cada una de ellas. Luego está lo estupenda que es para paralelizar junto con 8 canales dma programables, que también se menciona muy poco las cosas que tiene que te solucionan la vida.

Precisamente si algo le achaco yo a la snes, no es lo que tu dices, sino la wram a 2,68mhz, o el hecho de que solo tiene un puntero. Eso si que hace daño.

Precisamente, que tenga tantas cosas que dependen de tantos settings (a veces como digo sin sentido, como lo de la fast rom y slow rom), es lo que hace que un SDK sea complicado de hacer.

kusfo79 escribió:@Señor Ventura @cirote3
Lo del compilador es un problema, pero es que es la máquina más llena de putadas que he visto en los 8-16 bits. O sea, si estoy en este modo, esto tiene esta profundidad de color, en este otro esta otra. Si uso fastrom, los bancos son de 64kb, si uso slowrom son de 128kb. El mapper interno funciona de diferentes maneras dependiendo de varios factores...El sonido lo tienes que microprogramar para el chip de Sony en su ensamblador....

Tienes que acordarte de 200 cosas solo para no volverte loco debugando.

El tener que picar todo en ensamblador o utilizar compiladores lentos y con bugs como el que utiliza PVSnesLib es mucho peor que las restricciones que impone la PPU o la memoria (nadie tiene por qué usar slow rom para hacer homebrew).

CristianCG escribió:@kusfo79 Pienso igual, el compilador es un problema. Pero creo que el verdadero problema es la comunidad de dev de SNES, cada uno va a su bola y no se centraliza nada, incluso algunos se callan cosas que encuentran, y así no se puede avanzar.
Aunque pensándolo bien, también hay otro problema por el que creo que la dev de SNES no es igual que en MD, y es el miedo a que Nintendo llame a tu puerta

Si en la comunidad de SNES cada uno va a su bola es porque casi todos los juegos "potentes" están hechos en ensamblador, reutilizando pocas librerías del resto.

A nintendo se la sopla lo que hagas para consolas de hace 30 años, si no utilizas su IP (IANAL ).

Por cierto, la SNESDEV 2025 Jam está ahora mismo en fase de votación, hay 18 entradas: https://itch.io/jam/snesdev-2025/entries

kusfo79 escribió:Precisamente, que tenga tantas cosas que dependen de tantos settings (a veces como digo sin sentido, como lo de la fast rom y slow rom), es lo que hace que un SDK sea complicado de hacer.

Intrincada si es, pero no se si ese sería el motivo para no empezar si hubiese disposición.

La gente es un poquito hermética en la escena de snes. Si que se comparte información si preguntas, pero si te fijas, no hay demasiado movimiento.

O´Neill escribió:No se hace en snes cosas por limitaciones que tanto gusta indicar a los menos fanáticos del sistema, no se hace por complejidad (poca documentación y nulas herramientas que faciliten la tarea), tiempo y coste si pretendes sacarlo en físico.

Cada vez que alguno del clan MD empieza a dar la turra con la limitación de CPU de la SNES (algo que hasta los propios fans de la consola reconocemos, ya ves tú) me acuerdo de esto:

cirote3 escribió:El tener que picar todo en ensamblador o utilizar compiladores lentos y con bugs como el que utiliza PVSnesLib es mucho peor que las restricciones que impone la PPU o la memoria (nadie tiene por qué usar slow rom para hacer homebrew).

Yo prové el PVSNESlib hace como 10 años, y los problemas que recuerdo eran más del sdk que no del compilador (que es un fork del TCC, y yo había usado para programar cosas en MS-DOS). Pero bueno, en esa época también había gente usando el WDC C (que era el que se había usado en los 90 para programar el Secret of Evermore), yo no lo usé.

Ahora hace unos años el vbcc añadió soporte optimizado para SNES, no sé si puede adaptarse el sdk de PVSNESlib para usarlo allí, pero en otras plataformas es un compilador con buena fama.

Yo creo que la situación es parecida a la de PC Engine. Tienes compiladores disponibles, pero el sdk es malo (Hugo C en el caso de PC Engine).

kusfo79 escribió:

cirote3 escribió:El tener que picar todo en ensamblador o utilizar compiladores lentos y con bugs como el que utiliza PVSnesLib es mucho peor que las restricciones que impone la PPU o la memoria (nadie tiene por qué usar slow rom para hacer homebrew).

Yo prové el PVSNESlib hace como 10 años, y los problemas que recuerdo eran más del sdk que no del compilador (que es un fork del TCC, y yo había usado para programar cosas en MS-DOS). Pero bueno, en esa época también había gente usando el WDC C (que era el que se había usado en los 90 para programar el Secret of Evermore), yo no lo usé.

Ahora hace unos años el vbcc añadió soporte optimizado para SNES, no sé si puede adaptarse el sdk de PVSNESlib para usarlo allí, pero en otras plataformas es un compilador con buena fama.

Yo creo que la situación es parecida a la de PC Engine. Tienes compiladores disponibles, pero el sdk es malo (Hugo C en el caso de PC Engine).

Igual lo que falta es un buen combo de SDK + compilador, porque por lo que parece PVSnesLib no ha sido suficiente.

cirote3 escribió:

kusfo79 escribió:

cirote3 escribió:El tener que picar todo en ensamblador o utilizar compiladores lentos y con bugs como el que utiliza PVSnesLib es mucho peor que las restricciones que impone la PPU o la memoria (nadie tiene por qué usar slow rom para hacer homebrew).

Yo prové el PVSNESlib hace como 10 años, y los problemas que recuerdo eran más del sdk que no del compilador (que es un fork del TCC, y yo había usado para programar cosas en MS-DOS). Pero bueno, en esa época también había gente usando el WDC C (que era el que se había usado en los 90 para programar el Secret of Evermore), yo no lo usé.

Ahora hace unos años el vbcc añadió soporte optimizado para SNES, no sé si puede adaptarse el sdk de PVSNESlib para usarlo allí, pero en otras plataformas es un compilador con buena fama.

Yo creo que la situación es parecida a la de PC Engine. Tienes compiladores disponibles, pero el sdk es malo (Hugo C en el caso de PC Engine).

Igual lo que falta es un buen combo de SDK + compilador, porque por lo que parece PVSnesLib no ha sido suficiente.

Por cierto, una cosa que se me ha olvidado comentar antes. Comentabas que lo del slowrom - fastrom no debería importar a un homebrewer, pero de hecho és importante y no puedes abstraerte. Si usas fastrom, los bancos son más pequeños y tienes que manejar mejor cuando mapear los diferentes recursos.

kusfo79 escribió:

cirote3 escribió:

kusfo79 escribió:Yo prové el PVSNESlib hace como 10 años, y los problemas que recuerdo eran más del sdk que no del compilador (que es un fork del TCC, y yo había usado para programar cosas en MS-DOS). Pero bueno, en esa época también había gente usando el WDC C (que era el que se había usado en los 90 para programar el Secret of Evermore), yo no lo usé.

Ahora hace unos años el vbcc añadió soporte optimizado para SNES, no sé si puede adaptarse el sdk de PVSNESlib para usarlo allí, pero en otras plataformas es un compilador con buena fama.

Yo creo que la situación es parecida a la de PC Engine. Tienes compiladores disponibles, pero el sdk es malo (Hugo C en el caso de PC Engine).

Igual lo que falta es un buen combo de SDK + compilador, porque por lo que parece PVSnesLib no ha sido suficiente.

Por cierto, una cosa que se me ha olvidado comentar antes. Comentabas que lo del slowrom - fastrom no debería importar a un homebrewer, pero de hecho és importante y no puedes abstraerte. Si usas fastrom, los bancos son más pequeños y tienes que manejar mejor cuando mapear los diferentes recursos.

Lo sé, me refería a que hoy en día nadie te va a obligar a usar SlowROM porque los cartuchos que soportan FastROM salen demasiado caros

kusfo79 escribió:

cirote3 escribió:El tener que picar todo en ensamblador o utilizar compiladores lentos y con bugs como el que utiliza PVSnesLib es mucho peor que las restricciones que impone la PPU o la memoria (nadie tiene por qué usar slow rom para hacer homebrew).

Yo prové el PVSNESlib hace como 10 años, y los problemas que recuerdo eran más del sdk que no del compilador (que es un fork del TCC, y yo había usado para programar cosas en MS-DOS). Pero bueno, en esa época también había gente usando el WDC C (que era el que se había usado en los 90 para programar el Secret of Evermore), yo no lo usé.

Ahora hace unos años el vbcc añadió soporte optimizado para SNES, no sé si puede adaptarse el sdk de PVSNESlib para usarlo allí, pero en otras plataformas es un compilador con buena fama.

Yo creo que la situación es parecida a la de PC Engine. Tienes compiladores disponibles, pero el sdk es malo (Hugo C en el caso de PC Engine).

¿De dónde has sacado esa información sobre Secret of Evermore y el compilador WDC C?

No encuentro nada de información

@Diskover

Lo de que Secret of Evermore fue hecho en C se "sabe" (en realidad es una suposición, pero bastante probable) es por que hay restos del código C en la ROM, como se puede ver aquí: https://tcrf.net/Secret_of_Evermore#Plain_Text_in_ROM

Esto pasaba porque muchas veces las ROMs se padeaban con datos aleatorios, que en ocasiones eran los contenidos de la RAM en ese momento. Como el juego se programó probablemente en máquina MSDOS con un editor como Brief, casi seguro es que el código es del juego.

Sobre qué compilador se usó para este juego concreto, solo tenemos referencias que Zardoz y su derivado WDC eran los que se habían usado en la época en los foros de nesdev:
https://forums.nesdev.org/viewtopic.php?t=10336

kusfo79 escribió:@Diskover

Lo de que Secret of Evermore fue hecho en C se "sabe" (en realidad es una suposición, pero bastante probable) es por que hay restos del código C en la ROM, como se puede ver aquí: https://tcrf.net/Secret_of_Evermore#Plain_Text_in_ROM

Ese código contiene coma flotante, ¿cómo va a usarse eso en un juego de SNES? Que un juego tenga código fuente en texto plano no significa que ese código se haya utilizado en el juego tal cual.

cirote3 escribió:

kusfo79 escribió:@Diskover

Lo de que Secret of Evermore fue hecho en C se "sabe" (en realidad es una suposición, pero bastante probable) es por que hay restos del código C en la ROM, como se puede ver aquí: https://tcrf.net/Secret_of_Evermore#Plain_Text_in_ROM

Ese código contiene coma flotante, ¿cómo va a usarse eso en un juego de SNES? Que un juego tenga código fuente en texto plano no significa que ese código se haya utilizado en el juego tal cual.

No entiendo muy bien tu duda. Hay multitud de juegos de SNES que usan coma flotante, igual que juegos de Mega, Nes o Master System. Obviamente, no hay multiplicación y división hardware para coma flotante de fábrica, así que toca programarlas a mano.

Sobre lo del código fuente, hay muchos juegos donde pasa lo mismo, y sí, normalmente, el código es del juego que estaban programando en ese momento. Parece que es porque para hacer padding hacían un memcopy basto que se llevaba contenido de la RAM un poco random.

Otros juegos con lo mismo (mira Demolition man, por ejemplo):
https://tcrf.net/Aerobiz_Supersonic_(SNES)
https://tcrf.net/Andro_Dunos_(Neo_Geo)
https://tcrf.net/Castelian_(NES)#Source_Code
https://tcrf.net/Daffy_Duck:_The_Marvin_Missions_(SNES)
https://tcrf.net/Demolition_Man_(SNES)

kusfo79 escribió:

cirote3 escribió:

kusfo79 escribió:@Diskover

Lo de que Secret of Evermore fue hecho en C se "sabe" (en realidad es una suposición, pero bastante probable) es por que hay restos del código C en la ROM, como se puede ver aquí: https://tcrf.net/Secret_of_Evermore#Plain_Text_in_ROM

Ese código contiene coma flotante, ¿cómo va a usarse eso en un juego de SNES? Que un juego tenga código fuente en texto plano no significa que ese código se haya utilizado en el juego tal cual.

No entiendo muy bien tu duda. Hay multitud de juegos de SNES que usan coma flotante, igual que juegos de Mega, Nes o Master System. Obviamente, no hay multiplicación y división hardware para coma flotante de fábrica, así que toca programarlas a mano.

¿Sabes ejemplos de juegos comerciales que usen coma flotante en las consolas que dices, en especial en la NES y la Master System? Incluso en consolas más potentes con CPUs de 32bit como la PSX, la Saturn o la GBA usar coma flotante es un despilfarro, lo normal es usar coma fija.

kusfo79 escribió:Otros juegos con lo mismo (mira Demolition man, por ejemplo):
https://tcrf.net/Demolition_Man_(SNES)

El código comentado utiliza coma fija, no flotante...

Como no sea para algo que no sea el juego en si...

@cirote3
Bueno, dos que tenía en mente en realidad son trampa: Mario Kart y Pilotwings, pero hacen las operaciones con el DSP-1. En Mega los casos típicos son juegos poligonales o raycasters (Bloodshot, F-15 Strike Eagle, Corporation...). En Master otro caso similar, el F-16. Es cierto que en juegos 2d no creo que nunca fueran necesarios.

Sobre el caso concreto del Secret of Evermore, solo se me ocurriría que lo usasen para las partes del mapa con Modo 7, pero el código va de pendientes, tipo más bien plataformas, así que no sé... Otra cosa es que nos esté engañando las apariencias, y todos los números con decimales que vemos son en realidad coma fija, y que el compilador trata las constantes con decimales por defecto como fixed point.

Señor Ventura escribió:Como no sea para algo que no sea el juego en si...

El código parece ser algo relacionado con pendientes, o sea no tiene pinta de que sea parte de alguna tool o algo. Y en una máquina monoproceso MSDOS de la época, lo más lógico es que sea algo del juego mismo, no otra cosa que el programador tuviese abierta en ese momento.

kusfo79 escribió:@cirote3
Bueno, dos que tenía en mente en realidad son trampa: Mario Kart y Pilotwings, pero hacen las operaciones con el DSP-1. En Mega los casos típicos son juegos poligonales o raycasters (Bloodshot, F-15 Strike Eagle, Corporation...). En Master otro caso similar, el F-16.

¿Pero tienes alguna prueba de que los juegos que mencionas funcionan con coma flotante y no con coma fija? El DSP-1 trabaja con coma fija, no con flotante.

@kusfo79 copiaselo a chat gpt, a ver que te dice.


Edit: me pone que la única explicación es que el propio compilador teaduce a enteros, pero lo que me pregunto es como discrimina, ¿tiene que haber alguna mini base de datos por ahí para determinarlo?, una especie de regla que, o consulta caso a caso, o aplica por defecto.

cirote3 escribió:

kusfo79 escribió:@cirote3
Bueno, dos que tenía en mente en realidad son trampa: Mario Kart y Pilotwings, pero hacen las operaciones con el DSP-1. En Mega los casos típicos son juegos poligonales o raycasters (Bloodshot, F-15 Strike Eagle, Corporation...). En Master otro caso similar, el F-16.

¿Pero tienes alguna prueba de que los juegos que mencionas funcionan con coma flotante y no con coma fija? El DSP-1 trabaja con coma fija, no con flotante.

No, la verdad estoy puesto en dissasemblies ni Rom Hacks, solo cosas que se han comentado en SpritesMinds, Nesdev o similares. También hay muchos casos en que puede ser que la gente se confunda entre coma fija o coma flotante, así que no puedo meter la mano en el fuego.