[SUPER NINTENDO] Hilo oficial. en Retro y descatalogado

serratix 12 jul 2010 14:23

Mi Gran Noche

848 mensajes
desde mar 2010
en Madrid, Villa y Zanja

El Super Shadow of the Beast tenía pinta de ser un juegazo. Hay un lavado de cara en el tratamiento del color respecto a la version MD y ordenador. La banda sonora parece bastante remezclada, le da un toque más de acción; las versiones anteriores eran más "oscuras" y tenían una atmósfera más siniestra
http://www.youtube.com/watch?v=4Xv3t2nCaIs

Ralph 12 jul 2010 14:57

MegaAdicto!!!

14.020 mensajes
desde feb 2006

Volver a la página principal.

GUÍA DE ASM
Capítulo 4: Programación ASM de Rutinas Simples

Introducción

Siguiendo con el curso, nos toca ver la programación de ASM de rutinas simples con registros: sumas, restas, multiplicación y división de registros. Algo más practico que la guía anterior.

Registros del CPU

Ya hemos hablado de los MD (modos de Direccionamiento) pero ahora necesitamos trabajar directamente con los registros internos del CPU, así que los conoceremos más. Como se dijo en el Capítulo 1 los registros internos del 65816 son:

-A:

-X:

-Y:

-D:

-S:

-PBR:

-DBR:

-PC:

-P:

Recuerda que los registros son zonas de memoria dentro del procesador donde se puede almacenar información, de forma que el acceso a esta información sería inmediato.

Ya has visto algunas instrucciones básicas con los registros A, X y Y. Pero aun no hemos visto sumas de registros distintos o multiplicaciones de ellos.

Repasemos los registros básicos A,X e Y y luego veremos los complejos.

A, X e Y

A - Registro Acumulador

El acumulador se usa para cálculo y almacenamiento general. En otras palabras, puede almacenar cualquier valor y luego se le pueden realizar operaciones matemáticas.

Por ejemplo, si queremos guardar el dato 20 hex dentro del acumulador, entonces se debe hacer:
LDA #$20 (LDA = Load Accumulator o Cargar Acumulador con algún valor)

El acumulador puede estar en modo de 8-bits o 16-bit. Si esta en 8 bit, solo puede contener valores de 00 a FF (decimal 00 a 256) y en 16 bit valores de 0000 a FFFF (decimal 0 a 65535).
Para saber si el acumulador esta en 8 o en 16 bit hay que chequear el bit n° 5 o "m", del registro flag P (Capítulo 1). Si el bit 5 esta seteado (es decir m = 1) el acumulador esta en 8 bit y si el bit 5 esta re-seteado (m = 0) el acumulador está en 16 bit.

A todo esto, recuerda las diferencias entre #$ y $, por ejemplo LDA #$20 y LDA $20

-El primero modo carga A con el valor 20 hex. Quedando A = 20.
-El segundo modo carga A un dato de la dirección 20 hex.

Si en un log de snes9x trace tenemos:
$00/8359 8A TXA A:1800 X:0017 Y:0000 D:0000 DB:7E

Podemos ver en azul el valor que tuvo A justo ANTES de ejecutarse la instrucción TXA, este es 1800h.

X, Y - Registros Índice

Los registros X e Y están asociados al acumulador. También pueden guardar valores adentro y luego realizar operaciones matemáticas. Sin embargo, estos se usan para una algo especial.
Estos registros son usados generalmente para indexar localizaciones de memoria.
Los registros X e Y también pueden ser de 8 o 16 bits dependiendo del Flag X del registro P. Si X = 1 entonces estos registros están en modo de 8 bit. Y si X=0 están en 16 bits.

Si en un Log de snes9x trace tenemos:
$00/8359 8A TXA A:1800 X:0017 Y:0000 D:0000 DB:7E

Podemos ver en azul el valor que tuvo X e Y al momento de ejecutarse la instrucción TXA, este es X=0017h y Y=0000h.

D - Registro de Pagina Directa (Direct Page Register)

Hay que aclarar que existe un Modo de Direccionamiento llamado Direct Page o DP (Pagina Directa) y un Registro llamado Direct Page.
El primer banco de la memoria que va de 00:0000 a 00:FFFF es conocido como página cero (los primeros 64 Kbytes de memoria). El segundo banco 01:0000 a 01-FFFF página uno, y así sucesivamente. Este registro actúa solo dentro de este rango de la página 0 y ayuda a ahorrar espacio en las instrucciones cuando uses DIRECCIONES QUE SEAN DE 1 BYTE como LDA $01, STA $AB ya que el Banco no se escribe, se asume como Banco 0.

(FALTA IMAGEN)

Ejemplo:
$81:1234 LDA $11 ;D:0000 (en los LOGs le llaman D a la Direc Page, no confundir con el Flag "Decimal")

¿cargas en A lo que está en $81:0011? ¿Cargas en A lo que está en $81:1211?. NO. Cargas en A lo que está en $00:0011.
Siempre que hagas una instrucción donde uses una dirección de 1 BYTE y donde no indiques el BANCO, estarás usando el registro DP que te da el banco y la dirección base, luego tu dirección se SUMA a está DP para obtener la dirección Final. Así DP +$11 = $0000 + $11 = $00: 0011.

Ejemplo de Log del juego "Return of the Jedi" de Snes:
$81/BF45 85 3D STA $3D [$00:003D] A:0002 X:00F0 Y:0004 D:0000 DB:80 S:1FF6
Podemos ver DP=0000, entonces entre [ ] se ve la dirección final a donde de accederá, es decir DP + $3D = $0000 + $3D = $00:0003D. Nota que el Banco 00 te lo da el DP y no el registro Data Bank (DB, en rojo) que es que normalmente te indica el banco a direccionar.

Ejemplo de NO uso del Direct Page:
$81/BF2B AD 23 07 LDA $0723 [$80:0723] A:85BD X:00F0 Y:0004 D:0000 DB:80 S:1FF6
Se ve que como se usa una dirección de 16 bits, no usamos el Direct Page, sino el Banco Actual que se encuentra en el Registro DB=80. Aunque estés parado en $81/FB2B, el banco NO es $81, sino lo que indica el registro DB. Finalmente la dirección final de donde se saca el dato es $80:0723

S - Registro de Pila (Stack Register/ Stack Pointer)

La pila o stack es un área de memoria RAM que existe en todos los sistemas y que sirve para almacenar datos de los registros de la CPU que no deben perderse durante la ejecución de una rutina determinada. Es un registro de 16 bits que contiene la dirección de la siguiente posición de memoria libre dentro del área de la PILA.

Como se explicó en el capitulo 3, en la pila los elementos se almacenan siguiendo un orden tipo LIFO: Last In First Out, el último dato en entrar es el primero en salir. El SP (satck pointer o puntero de Pila) apunta siempre a la última dirección libre de la PILA.

En el caso del SNES la memoria RAM va desde $0000 hasta $FFFF. El SP se inicializa habitualmente al valor $FFFF:

Cada vez que ponemos (PUSH) agregamos un valor en el stack, el puntero del stack subirá bajando de índice, pero el stack (como espacio) disminuye.
Al contrario, si sacamos (POP) valores del stack, el stack se incrementa desde el punto de vista de espacio, pero el puntero se decrementa ya que baja.

Ejemplo:
Haremos que se ingrese un valor al Stack y luego se saque al acumulador.
Supongamos que el puntero del stack esta en $2FFF, entonces si:

PEA $1000 (PEA = Push Effective Address o Agregar Dirección Efectiva)
Con esta instrucción agregamos la posición $1000 al stack, el puntero del stack ahora estará en $2FFD (al inicio estaba $2FFF) ya que $1000 ocupa 2 bytes.

PLA $1000 (PLA = Pop to Accumulator o Sacar al Acumulador -> se asume en 16-bits)
Reservará el acumulador con $1000 y el puntero del stack se devuelve a $2FFF.

PC - Contador de Programa (Program counter)

Este registro mantiene la Dirección de la actual instrucción que se ejecuta. Se usa junto con PBR, así PBR:PC forma la dirección física real de la siguiente instrucción a ejecutar, es decir que se tiene el Banco y la Dirección actual. Por ejemplo $12:3456, PBR

Por ejemplo en un extracto de un log de snes9x trace tenemos:

Imagen

Aquí se muestra en azul el valor actual del PC cuando ejecuto la instrucción ASL A.

PBR - Registro del Banco de programa (Program Bank Register)

Este registro mantiene el código actual del banco que esta corriendo. Especifica los límites altos del bloque de 64Kb. También especifica los 8 bits más altos de la dirección efectiva. Puede ser referido con los 8 bit superiores de los 24 del Program Counter. Se usa solo con SALTOS.

Ejemplo:
PBR: $80 -> Decimos que la instrucción siguiente opera en el Banco 80.
JMP $1C00 -> Salta a la posición 1C00 del banco 80 -> $80:1C00
Seria lo mismo hacer:
JMP $801C00 -> especificamos el banco en la dirección efectiva mediante los 8 bits mas altos ($801C00 es de 24 bits y de los bits 15 al 23 son los mayores, tenemos en este caso el byte 80).

Si en un log de snes9x trace tenemos:
$0C/8359 8A 20 JMP 20 A:1800 X:0017 Y:0000 D:0000 DB:7E

El registro PBR se visualiza en el PC, en los 8 bits mas altos, en este caso PBR=0C.

DBR - Registro de Banco de Datos (Data Bank Register)

Parecido al registro PBR. Especifica el banco pero al momento de hacer una carga o un guardado en memoria que sea de 16 bits (LDA, STA, transferencias).

Ejemplo:

LDA $123456;
DBR: $12, es el banco de la dirección efectiva.

Ejemplo2:
DBR: $12 -> seteamos el DBR en $12
LDA $8000; Carga el acumulador con el valor que esta en la dirección 8000, pero del banco $12. -> $12:8000.

Tabla Rápida de Opcodes Principales

Imagen

Operaciones básicas

Haremos operaciones básicas utilizando solo el registro A.

1. “Sumar a A el valor 4 y dejar el resultado en A” => A=A+4

CLC ; dejamos el carry en 0
ADC #$4 ;se le suma a A el operando, en este caso 4. Esto hace por dentro según la tabla de arriba: A=A+Operando+carry y como dejamos el carry en 0 queda A= A+4+0=> A= A+4.

2. “Restar a A el valor 5 y dejar el resultado en A” => A=A-5

SEC ; dejamos el carry en 1
SBC #$5 ; restamos el operando 5. SBC hace esto según la tabla de arriba A=A-operando+carry-1.
Carry lo dejamos en 1 para que: A=A-5+1-1=> A= A-5

3. “Multiplicar el contenido de A por 2 y guardar el resultado en A” => A=A*2

CLC ; ¿seguro va CLC?
ASL A ; ¡error! Aquí NO VA CLC según la tabla, la solución seria solo ASL ya que ASL A hace A=A*2.

4. “Dividir A por 4 y guardar el resultado en A” => A=A/4

Como no existe una instrucción directa para hacer la división por 4, pero si hay una para hacer una división por 2 (LSR), entonces se hará dos veces una división por 2:

LSR A ; hace A=A/2
LSR A ; hace A=(A/2)/2 =>A=A/4

Operaciones No Tan Básicas

Estas operación utilizan los registros X, Y, A y S (Registro Pila).

1. “Multiplicar lo que esta en el registro Y por 4 y el resultado dejarlo en el registro A” => A =4*Y

Primero multiplicar Y por 2, entonces hacemos:
ASL Y
¡error! No se puede usar ASL con X o Y (esto sale en la tabla de arriba, captan?)
Entonces hacemos:

TYA ;pasamos el contenido de Y a A.
ASL ;A multiplicado por 2, dejando el contenido en A (eso dice la tabla)
ASL ;A multiplicado por 2, si ya estaba multiplicado por 2, entonces queda 4*A

2. Y=X-A

Necesitamos restar X con A, pero no se puede usar la instrucción SBC con X, solo con A, pero A tiene un valor que no se puede perder ya que es necesario para restárselo a X. ¿Qué se puede hacer? Utilizar uno de los registros explicados arriba, me refiero a la Pila o Stack. La pila nos sirve para guardar valores de un registro momentáneamente.

Entonces:

PHA ;el contenido de A pasa al stack (se copia al stack)
TXA ;A = X, es decir, pasemos lo de X hacia A
SEC
SBC $01,S ;restamos lo que tiene A (lo de X) con lo del stack (esta A en el tope de arriba del stack,
recuerda que se acumulan hacia arriba), por eso el S es de Stack. Finalmente el contenido
pasa a A. Lo del 01 es la pocición de arriba hacia abajo, como es el Tope, es la primera.
TAY ; Pasamos lo de A hacia Y
PLA ; lo que esta en el stack pasa a A, es para dejar vació el stack.

3. X=A+5+Y

CLC
ADC #$5
ADC Y
TAX
¿esta correcto? No. Ya que no se puede usar ADC Y, entonces usaremos el Stack...

CLC
ADC #$5
PHA ;pasamos A a la pila
TYA ;pasamos lo de Y hacia A
CLC
ADC $01,S ;sumamos lo del stack con A
TAX ;pasamos lo de A hacia X
PLA ;dejamos la pila como estaba, pasando el valor que tiene almacena en el tope, a A.

4. Y=STACK*2-Y+3

En este ejemplo no se opera con A, por lo tanto lo podemos usar para cualquier paso de datos, entre los otros registros Y y Stack.

TYA ;pasamos lo de Y a A
PHA ;pasamos el contenido de A a la pila
TSC ;asignamos a A lo que vale el stack
ASL A ;multiplicamos x 2
SEC ;carry=0
SBC $01,S ;restamos lo que esta en el stack a A
CLC ;carry=1
ADC #$3 ;sumamos 3h a A
TAY ;pasamos lo de A a Y
PLA ;pasamos lo del stack a A

5. STACK=X/2-8

TXA ;pasamos lo de X hacia A
LSR A ;A=A/2
SEC
SBC #$8
TCS ;pasamos lo A hacia el stack

6. A=(X+2)/4

TXA
CLC
ADC #$2
LSR A
LSR A

7. X=2*A+2*Y

ASL A ;hacemos primero 2*A
PHA ;pasamos el contenido de A a la pila
TYA ;pasamos Y a A
ASL A ;A=A*2
CLC ;falta…
ADC $01,S ;sumamos lo que hay en A con lo que esta en el tope de la pila
TAX ;el resultado queda en X
PLA

8. Y=(Y-5)*8-X/2

TXA ;primero hagamos el X/2
LSR :A=A/2
PHA ;el resultado de A/2 lo tiramos a la pila
TYA ;sigamos ahora con (Y-5)
SEC
SBC #$5
ASL A ;multiplicamos A*2, 3 veces
ASL A
ASL A ;Hasta ahora todo guardado en A
SEC
SBC $01,S ;restamos lo que esta en A( (Y-5)*8 ) menos lo de la pila (x/2)
TAY ;el resultado queda en Y

9. X = A * 2:

ASL A
TAX

10. A = X + Y

TYA
PHA ; en la pila esta Y
TXA
CLC
ADC $01,S ;sumamos lo que esta en A(X) y lo de la pila (Y) y queda en A
PLA

11. X = A + Y

TAX
TYA
PHA
TXA
CLC
ADC $01,S
TXA
PLA

12. X = Y + 2

TYA
CLC
ADC #$2
TAX

13. A = 20 + 30

LDA #$20
CLC
ADC #$30

Operaciones con Direcciones

1. “Guardar en la dirección 1234 el resultado de X+2” => $1234 = X + 2

TXA
CLC
ADC #$2
STA $1234

2. $FF0D = (X + 3) + (A / 2)

LSR A
PHA
TXA
CLC
ADC #$3
CLC
ADC $01,S
STA $FF0D

3. X = #$2BC + Y + A

CLC ;primero hacemos #$2BC+A
ADC #$2BC
PHA ;guardo en le stack el valor la suma TYA
CLC
ADC $01,S
TAX

Preguntas y Respuestas

1. PILA = ($1234,Y) + 10 decimal

LDA ($1234,Y)
CLC
ADC #$0A ; 10 dec = 0A hex
PHA

2. Simular un CICLO FOR y la condición IF-ELSE.
A partir de la dirección de memoria $1234 (RAM) sumar 1 a A hasta que sea igual a 0x08 entonces salte a $AB

$7E:1234: INC ; en los bancos $7E o $7F está la memoria RAM, usamos 7E
$7E:1235: CMP #$08 ; ¿A = 0x08? Si es así, Flag Z=1 (ver Capítulo 2 para regla de Branches)
$7E:1237: BEQ $AB
$7E:1239: BRA $1234

3. Si en un Log se tiene:
$80/D34F F0 0B BEQ $0B [$D35C] A:1900 X:0000 Y:006F D:1928 DB:86
$80/D35C C2 21 REP #$21 A:1900 X:0000 Y:006F D:1928 DB:86

P: ¿Se usa o No el Direct Page? ¿Se usa el registro Data Bank?

R: No se usa el DP, aunque el operando $0B sea una dirección de 1 byte, en los SALTOS como BEQ, BCC, etc.. no se usa el DP, sino que se salta a la dirección actual + operando + largo operando = $80D34F + $0B + 2 bytes = $80D35C.
El DB=86 en este caso no se usa, ya que el salto especifica solo el dirección y no el banco, por lo tanto se asume el banco actual 80.

Fuente: http://darkn.romhackhispano.org

Volver a la página principal.

Eteream 18 jul 2010 23:39

ElTerrorDeLasNenas

548 mensajes
desde ago 2005

Ralph escribió:
Eteream escribió:

Soy consciente de que no hay ahora mismo un término medio que ayude a comprender a los "novatos" a entender que está pasando (quizás cuando domine todo esto pueda hacerlo yo mismo, sin tener que adueñarme del trabajo de los demás), pero para los que comprenden bien ensamblador, les vendrá bien la documentación sobre la SNES, que es lo que les falta para saber programar para esta maquina. No es que no sepa organizarme, es que simplemente he empezado por donde he podido... de hecho, sigo un poco perdido, no soy ningún experto.

...de todos modos, se agradece el detalle de la crítica, porque sin esto, uno nunca sabe si mejora, o empeora. Lo de los conceptos basicos y "machacados", era en un principio la prioridad, pero como digo, es que he empezado por donde he podido. Esto va para largo, así que ya llegará el día en que todo esté muy bien ordenado y explicado.

No, no es cuestión de orden. Es que hay cosas que no tienen sentido.

Ralph escribió:Cada vez que ponemos (PUSH) agregamos un valor en el stack, el puntero del stack subirá bajando de índice, pero el stack (como espacio) disminuye.

El espacio de stack es el que es, no dismuniye. Disminuye el espacio vacio disponible.
Push = apilar, en jerga: hacer push

Ralph escribió:Al contrario, si sacamos (POP) valores del stack, el stack se incrementa desde el punto de vista de espacio, pero el puntero se decrementa ya que baja.

Lo mismo. Y el puntero se incrementa ya que ´sube´.
Pop = desapilar, en jerga: hacer pop

Hay bastantes errores parecidos, no se si seran de traducción. Por eso digo que valdria la pena ir más despacio comprendiendo las cosas.

Ralph 19 jul 2010 00:31

MegaAdicto!!!

14.020 mensajes
desde feb 2006

Yo diría que si es cuestión de orden... mi deseo hubiera sido empezar mas despacio, pero la desinformación es total, y no me ha quedado mas remedio que aprender a montar en bicicleta en un cohete.

...voy como puedo, vaya. Consigo empaparme de algunas cosas, y de otras no. He encontrado algunos PDF's bastante interesantes, pero ahora mismo me estoy qeudando sin tiempo.

magno 19 jul 2010 06:21

MegaAdicto!!!

2.232 mensajes
desde ene 2005

Página web de magno

Eteream escribió:
Ralph escribió:Cada vez que ponemos (PUSH) agregamos un valor en el stack, el puntero del stack subirá bajando de índice, pero el stack (como espacio) disminuye.

El espacio de stack es el que es, no dismuniye. Disminuye el espacio vacio disponible.
Push = apilar, en jerga: hacer push

Eteream escribió:
Ralph escribió:Al contrario, si sacamos (POP) valores del stack, el stack se incrementa desde el punto de vista de espacio, pero el puntero se decrementa ya que baja.

Lo mismo. Y el puntero se incrementa ya que ´sube´.
Pop = desapilar, en jerga: hacer pop

Pues yo creo que lo has interpretado mal, porque eso que explicas es lo que yo entiendo leyendo esas líneas: el stack se incrementa desde el punto de vista de espacio, es decir, que incrementa el espacio libre, y lo que se quiere remarcar es que el puntero de pila se decrementa, es decir, que la operación va "al revés" del dibujo mental que te podrías hacer.
En sí el espacio reservado a la pila ni aumenta ni disminuye, es el que es, pero es que ahí no se dice lo contrario.

Estos errores de interpretación pueden ser muy comunes según quién lo lea; yo pensaba que te referías a errores de bulto de verdad, cosas que son incorrectas, pero este tipo de cosas no creo que sean dignas de ser remarcadas porque yo sí he entendido lo que ponía.

Yo pensaba que aquí ibas a decir lo que realmente está mal, y es que el puntero de pila se DECREMENTA cuando se hace PUSH (al puntero de pila se le resta 1 ó 2 según el tipo de acceso a memoria de 8 ó 16 bits) y se INCREMENTA cuando se hace POP.

Ralph 19 jul 2010 14:09

MegaAdicto!!!

14.020 mensajes
desde feb 2006

Voy a salirme del tema un momento, pero me interesa preguntar unas cosillas:

-Esta es la lista de juegos que no funcionan en el SNES Power pak [Link!]. Al principio de la lista podemos ver que aparece el comanche, cuando se supone que no pasó del E3 de 1995, ¿Es que existe la rom, o algún prototipo? o_O

-¿Se sabe cuanto puede ocupar descomprimido el Street fighter 2 Alpha, teniendo en cuenta que se trata de un cartucho de 32 megas?. ¿Existen datos, o documentación sobre el chip S-DD1?.

-El Rock'n Roll racing ocupa 8 Mbits, pero la versión Megadrive también ocupa la misma catidad a pesar de que tan solo las voces usan el canal PCM (pero por lo visto solo a 7000hz), ¿a que se debe esto?, ¿El sonido en formato PCM admite compresiones tan bestias cuando se almacenan en el cartucho?.

ChepoXX 19 jul 2010 14:29

MegaAdicto!!!

4.052 mensajes
desde ago 2003

-Esta es la lista de juegos que no funcionan en el SNES Power pak [Link!]. Al principio de la lista podemos ver que aparece el comanche, cuando se supone que no pasó del E3 de 1995, ¿Es que existe la rom, o algún prototipo? o_O

tengo entendido que que hay una versión beta o demo pero no del juego en si sino del motor en un espacio abierto, hay unos videos en youtube

¿Se sabe cuanto puede ocupar descomprimido el Street fighter 2 Alpha, teniendo en cuenta que se trata de un cartucho de 32 megas?. ¿Existen datos, o documentación sobre el chip S-DD1?.

descomprimido creo que no se puede jugar descomprimido a diferencia del star ocean, ya que si es descomprimido no funciona en el power pack........ por otro lado cuando no estaba emulado se utilizaban unos parches en la rom con unos complementos.

socram8888 19 jul 2010 14:31

lol socram pole

2.591 mensajes
desde may 2007

socram8888 está baneado por "incumplimiento términos y condiciones de uso"

El canal PCM en ese juego está controlado por el Z80, que tiene 8 veces menos RAM (8kB vs 64kB) que el SPC700 de la SNES, así que probablemente será por problemas de espacio

Pero a mi me parece vaguería, porque teniendo el 68000 acceso directo a los registros del YM2612, ya me dirás porqué no se encargó la CPU principal del sonido...

ChepoXX 19 jul 2010 16:20

MegaAdicto!!!

4.052 mensajes
desde ago 2003

no estaba emulado se utilizaban unos parches en la rom con unos complementos.

mmm ahor que lo pienso eran como desempaquetados y pesaba el rom mas packs como 6 megas de pc no de consola jjee no se si lo tenga por ahí todavía.

Ralph 19 jul 2010 16:31

MegaAdicto!!!

14.020 mensajes
desde feb 2006

ChepoXX escribió:tengo entendido que que hay una versión beta o demo pero no del juego en si sino del motor en un espacio abierto, hay unos videos en youtube

Teniendo en cuenta las pegas con que se encontraron para terminar el juego, la verdad, ya me esperaba que fuese solo el motor del juego, y poco mas, en el que pilotar por el escenario, y punto. Lo que ocurre es que de ese juego solo conocía la existencia de un video en el E3 de 1995, y ya empezaba a pensar que era el unico dato qeu existía al respecto.

...encontrarlo será un imposible, imagino.

ChepoXX escribió:descomprimido creo que no se puede jugar descomprimido a diferencia del star ocean, ya que si es descomprimido no funciona en el power pack........ por otro lado cuando no estaba emulado se utilizaban unos parches en la rom con unos complementos.

En realidad solo lo pregunto por curiosidad, no para usarlo con el power pak. Quizás no se sepa nada al respecto, ¿no?.

socram8888 escribió:El canal PCM en ese juego está controlado por el Z80, que tiene 8 veces menos RAM (8kB vs 64kB) que el SPC700 de la SNES, así que probablemente será por problemas de espacio

Pero a mi me parece vaguería, porque teniendo el 68000 acceso directo a los registros del YM2612, ya me dirás porqué no se encargó la CPU principal del sonido...

La cuestión es, ¿como es posible que en SNES ocupe el mismo tamaño de cartucho?, ¿realmente se almacenan en el cartucho tan comprimidas?.

...y otra cosilla. En megadrive, de estar controlado por el 68000, ¿en que cambiaría el resultado si las voces del canal PCM están a 7000hz?(como dijiste en el otro hilo), ¿quizás el Z80 tiene limitaciones en ese sentido?(no admitiendo frecuencias altas). La memoria de audio es exactamente la misma tanto si la controla uno como si la controla otro, ¿no?.

...¿sería posible tecnicamente que Z80 y 68000 controlen el sonido sin estorbarse?. El 68000 se encarga del canal PCM, y el Z80 de los 9 canales restantes (melodías y SFX... el canal PCM para las voces para el 68000).

ChepoXX escribió:mmm ahor que lo pienso eran como desempaquetados y pesaba el rom mas packs como 6 megas de pc no de consola jjee no se si lo tenga por ahí todavía.

Osea, que realmente no llega a los 48 megas, ¿no?, porque parte de la rom tiene los datos comprimidos que ya están descomprimidos en el resto del pack. ¿Realmente es así?, ¿se puede demostrar?.

Elelegido 19 jul 2010 17:43

RIP

11.111 mensajes
desde abr 2004
en paz descanse

Genial el último aporte.

magno 19 jul 2010 19:42

MegaAdicto!!!

2.232 mensajes
desde ene 2005

Página web de magno

Para el S-DD1 hay una documentación muy buena hecha por mi amigo Andreas Naive, una fiera de los algoritmos y de la ingeniería inversa que vive aquí en Madrid pero que no he tenido la oportunidad de conocer. La documentación que aportó la tengo por ahí, incluso imprimida en papel porque es realmente buena.

Los ratios de compresión que puede alcanzar el chip son muy buenos, y se estiman que están en torno a 2:1; así, el Star Ocean con el parche para que se pueda jugar sin el chip ocupa 96 megas (tiene 48 de ROM), y el SF2A estaría en torno a los 64 megas.
Sí que es posible aplicar el mismo principio que para SO con el SF2A: consiste en trazar en el código ensamblador TODAS las escrituras al registro $4800, comprobar a qué direcciones se refiere como origen comprimido y destino de RAM descomprimido, y entonces hacer una llamada a una rutina que te crees que simplemente copie el correspondiente chunk de datos ya descomprimidos al destino correcto. Es un curro de la hostia, pero se podría hacer...

ChepoXX 19 jul 2010 19:45

MegaAdicto!!!

4.052 mensajes
desde ago 2003

Osea, que realmente no llega a los 48 megas, ¿no?, porque parte de la rom tiene los datos comprimidos que ya están descomprimidos en el resto del pack. ¿Realmente es así?, ¿se puede demostrar?.

Si quieres te paso la rom para que la estudies, eso si no estoy seguro de ternerla ya la tuve un tiempo por tenerla y lusgo me baje larom normal sin parches cuando el snesX9 emuló el chip de compresión

Ralph 19 jul 2010 20:12

MegaAdicto!!!

14.020 mensajes
desde feb 2006

magno escribió:Para el S-DD1 hay una documentación muy buena hecha por mi amigo Andreas Naive, una fiera de los algoritmos y de la ingeniería inversa que vive aquí en Madrid pero que no he tenido la oportunidad de conocer. La documentación que aportó la tengo por ahí, incluso imprimida en papel porque es realmente buena.

Para hacerme una idea, ¿es muy extensa? (nº de paginas).

magno escribió:Los ratios de compresión que puede alcanzar el chip son muy buenos, y se estiman que están en torno a 2:1; así, el Star Ocean con el parche para que se pueda jugar sin el chip ocupa 96 megas (tiene 48 de ROM), y el SF2A estaría en torno a los 64 megas.

Esto ya supera todas mis espectativas. ¿No solo hablamos de un ratio de 2:1, sino de que el chip también puede realizar tareas de compresión de datos?.

magno escribió:Sí que es posible aplicar el mismo principio que para SO con el SF2A: consiste en trazar en el código ensamblador TODAS las escrituras al registro $4800, comprobar a qué direcciones se refiere como origen comprimido y destino de RAM descomprimido, y entonces hacer una llamada a una rutina que te crees que simplemente copie el correspondiente chunk de datos ya descomprimidos al destino correcto. Es un curro de la hostia, pero se podría hacer...

Digo yo, que el grupo de ingenieros que creasen el S-DD1, dejarían un poco a huevo, no la documentación, sino la manera de poder adaptar una rutina al codigo para trasladar los datos en grupos a la dirección correcta. Algo así como una plantilla.

Me parece interesante, sobre todo, que aunque son posibles cartuchos de 98Mbits, son posibles cartuchos incluso mayores (aunque ya tendrían mas limitaciones a partir de esos 98 megas... se que tengo la información en el hilo, voy a buscarlo), pero que con el chip este se podrían alcanzar cantidadaes asombrosas de información. Facilmente cartuchos de 150 y 200 megas [babas]

...sueño con un port decente del art of fighting, aunque se pueden hacer tantas cosas...

Chepoxx escribió:Si quieres te paso la rom para que la estudies, eso si no estoy seguro de ternerla ya la tuve un tiempo por tenerla y lusgo me baje larom normal sin parches cuando el snesX9 emuló el chip de compresión

No, no te preocupes, si la cuestión no es conseguir la rom

EDIT: Una pregunta sobre el Power pak de SNES. Los juegos que soporta, ¿son solo la versión PAL de estos, si usas el cartucho en una consola PAL sin modificar?

FFantasy6 20 jul 2010 10:42

MegaAdicto!!!

30.512 mensajes
desde dic 2003

Esto es interesante.

Una rom para testear las SNES'es

http://www.digitpress.com/forum/showthread.php?t=146537

Ralph 20 jul 2010 13:38

MegaAdicto!!!

14.020 mensajes
desde feb 2006

Volver a la página principal.

JUEGOS CANCELADOS T-Z

· Taloon's Mystery Dungeon
· Targa
· Tarzan
· Thunder in Paradise
· Time Killer(s)
· Tinhead
· Tom and Jerry 2
· Toxic Crusaders
· Turbo Toons
· Tweety and Sylvester
· Ultrabots: Sanction Earth
· Undercover Cops
· Universal Soldier
· Warrior of Rome III
· Wile E's Revenge (Road Runner 2)
· Wrestlerage
· Zoo Ball

Taloon's Mystery Dungeon

Little is known about this prototype of Taloon's Mystery Dungeon. According to hydr0x, this prototype came from a German age ratings organization. It would have been a port of Torneco no Daibouken, a spinoff of Dragon Quest 4, featuring the pudgy merchant, Taloon. It's unique semi-action rpg elements may have made it considered for the European market, much like Terranigma was.

Targa

Targa went unreleased in Europe and North America. It is a hybrid between an R-type-style shooter and a Contra-style action game. It went on to be released in Japan as Rendering Ranger R2. In this article, we will have a look at this rare gem, complete with some notes from developer Manfred Trenz. Thanks goes out to Fire-WSP, who provided the screenshots, and Manfred Trenz for answering my questions.

Rendering Ranger R2 is a title that bears some significance in the Super NES/ Super Famicom collecting scene. It happens to be one of the most rare games ever released for the system, with a total production run of a few thousand copies at most. Copies show up every now and then on eBay, and fetch well over $100 US each. This game also happens to be developed by Manfred Trenz, who created the excellent Turrican series.

The game starts off with a Contra style action sequence. There is no story, the player merely moves forward and start shooting. You start off with a choice of a rapid fire spread gun or a focused laser gun. These can be upgraded with power ups. Later in the game, rebound and multi-directional pulse guns become available. The controls allows you to easily aim and shoot the enemies that appear above and below.

The level design in the action sequences is straightforward. In the first level, the main issue is avoiding pits. In subsequent action levels, there is a bit more exploration, but there are no brain teasing puzzles. Enemies swarm you and show no mercy, so it is best to turn on the auto-fire option so you can focus on aiming. If you die, the weapon system only downgrades the currently selected weapon, so the best strategy is to switch to the weakest weapon in your arsenal if you are on the verge of death.

In the third stage, you are treated to an R-Type style shooter. These sequences really show off the amazing pre-rendered graphics (think Donkey Kong Country) as well as the smooth frame rate that is not seen in many Super NES games. The ship uses the same weapons as in the action sequences, and the same strategy to keep the weapons applies. The only unique power ups in the shooting levels are these pods that increase the amount of shots your ship shoots. You can collect up to two of them, and they are positioned above and below the ship (see the picture on the left).

At times, the entire screen fills up with your shots, which can just barely keep up with the screen fulls of enemies. At times, there is upwards of 20 enemies coming after you at a time. It is quite awe-inspiring to see, even when compared to modern consoles. It really shows that the snes could handle a lot of sprites and not have slowdown.

Rendering Ranger is well known due to its boss battles. The bosses are huge, sometimes encompassing an area larger than the screen! The first few levels have one boss at the end, but further into the game it almost gets to the point where you only fight bosses. Each boss has a particular weak point, and it takes a lot of shooting to kill them off.

If there is one weakness to this game, it is the extreme difficulty. Even with passwords, only expert players will reach the end of the game. I played on the easiest difficulty level with the maximum amount of lives, and I could barely pass the first level. The biggest problem is that it takes a lot of hits to kill off even the weakest enemies. If you lose your weapon power ups by dying, then you can almost kiss your chances of beating a boss goodbye. To remedy this issue so that I could make this article, I created two Pro Action Replay codes:

7E051507 - Infinite lives

7E06BC05 - Infinite health

The sound in the game is what you would expect from a futuristic action game. The pounding snes-rock/techno suit this game, though throughout most of the game, all you will hear is the constant shooting of your weapon. The enemies don't make any noise except when you destroy them. There are appropriate buzzing noises for things like lasers.

I had the opportunity to ask Manfred Trenz, the designer of Targa/ Rendering Ranger some questions:

Snes Central: Why was Targa released in Japan and not in other regions?
Manfred Trenz: Softgold, which was the publisher at this time, said nobody was really interested in this game except Virgin Japan. To be honest, I never believed this.
SC: Why was the Targa renamed Rendering Ranger R2 in Japan?
MT: The first version of Targa used old school hand drawn graphics. Since Donkey Kong came out on the SNES using rendered graphics, one (person) at Softgold came to the conclusion that this is a must for Targa too. This is where this name comes from. Simply while using rendered graphics.
Rendering Ranger -> RR -> R2
I still have a version with the original graphic set.
SC: Slowdown hampered many Super NES games, such as Gradius III. How did you manage to overcome this in Rendering Ranger?
MT: Very very tricky assembly programming.
SC: What differences are there between Targa and Rendering Ranger?
MT: The entire graphics as well as some design changes.
SC: How long did it take to develop Targa?
MT: Almost 3 years
SC: Why did you make Targa have both space shooting and platform action sequences, instead of focusing on one or the other? Why did you decide to develop Targa instead of Super Turrican 3?
MT: At the first place Targa was intended to be a space shooting game. But Softgold was not't sure if this is enough to make big sales and decided to bring in the successful jump'n'shoot Turrican elements. This is why Targa became a mixture of both.

To finish off, here is a series of comparison shots of Rendering Ranger and Targa. The space shooter levels appear to be identical in both versions.

More Screenshots:

Tarzan

Tarzan is an unreleased game in development by Gametek.

Tarzan was mentioned to be in development by Gametek in the June 1993 issue of Nintendo Power. Clayton Kauzlaric, a developer of the game (and the source of the image, see bibliography for link) says that the game was within months of completion. He says that it was canceled due to the fact that you kill off endangered species, and the fact the game wasn't that fun.

Bibliography:

· Nintendo Power, Pak Watch, Publication date: June 1993, Volume: 49, Pages: 113
· Blog by developer Clayton Kauzlaric regarding this game. (link)

Thunder in Paradise

Thunder in Paradise was an unreleased game based on the TV series featuring Hulk Hogan. It was in development by Software Toolworks. Scans courtesy of KingMike.

Thunder In Paradise was a short lived action series featuring Hulk Hogan. The premise of the show was two ex-Navy Seals (one played by Hogan) travelling around the world in their hi-tech boat fighting crime. As one might expect, the series only lasted one season. In addition to this unreleased SNES game, there was also an unrelated interactive FMV game released on the CD-i.

The Super NES game was previewed in the October 1994 issue of EGM. The screenshots show there were going to be at least three gameplay modes: shooting from the boat, side scrolling action, and overhead action. The graphics do not look too bad, but the side scrolling level looks more incomplete than the boat and overhead levels. The show was cancelled in late 1994, ending any chance this game had for release.

Scans

Bibliography:

· Electronic Gaming Monthly, Preview, Publication date: October 1994, Volume: 63, Pages: 116
· Wikipedia entry on the Thunder in Paradise series (link)
· Information on the CD-i game on Moby Games (link)

Time Killer(s)

Time Killer was shown at the 1993 Summer CES by T*HQ. I have a feeling this could have been a working title for the 1994 game Time Trax (which was published by subsidary Malibu Games). Time Killers was a violent fighting game, which eventually got published in 1996 on the Genesis, but a SNES version was never released.

Bibliography:

· Nintendo Power, Pak Watch - Summer CES, Publication date: August 1993, Volume: 51, Pages: 113

Tinhead

Tinhead was an unreleased game, intended for a 1994 release. It was cancelled after developer MicroProse ran out of money. A completed ROM image of the game exists, and it was released commercially in the US on the Genesis.

Tinhead was one of the many action platform games planned for release on 16-bit systems. The game was in production at the UK development studio, MicroProse. Unlike Boo!, a game in development at about the same time as Tinhead, this game was completed. It was in development for the SNES, Genesis and Amiga. The Genesis version was released in the US by Accolade and Spectrum Holobyte, though remained unreleased on the SNES for unknown reasons. According to game producer Stuart Whyte, the Amiga version was in development but never finished (Stuart Whyte is the current executive producer at Lionhead studios, responsible for the Fable series). The game was never released by MicroProse due to the game maker running out of money. A working title for this game was Waldo.

ROM Image

A ROM image of the unreleased SNES version of Tinhead exists, though its source is unknown. If I were to guess, this game was leaked out onto USENET during the 90s. Another possibility is that the ROM image came directly from Stuart Whyte's website, though considering the .smc extension, I would bet against that. Also, the ROM image is PAL, so if you try playing this in a flash cart on an NTSC SNES (which is all the rage now a days), the game will run too fast. Aside from the extra speed, I did not notice any glitches when I played it on my NTSC SNES. Believe me when I say this will hamper any efforts to pass this game. The game itself appears to be finished.

The Game

Tinhead was complete, but I have to rank this as a second rate platformer, among the Zools, Bubsys and Aero The Acrobats of the 16-bit platforming realm (though Aero the Acrobat 2 is freaking awesome). With the glut of platformers out there, surely this game would have been buried among them. Perhaps the competition on the Genesis was less, making it justifiable for release on that platform. Whatever the reason it was not released on the SNES, we may never know.

The story behind Tinhead is some intergalactic goblin, known as Grim Squidge, has stolen all of the stars in the galaxy by sucking them up in his vacuum cart and scattering them elsewhere. Tinhead, the protector who guards the edge of the galaxy gets a distress signal and goes to rescue the stars. Not exactly an inspiring story, but then again, what platformer from the early 90s had one?

The game is a platformer, with a strong shooter aspect to it. The game has more in common with Super Mario than Contra, though. There are four levels in the game, each broken up into three "sectors", and further split up into two sub-sectors. This means each level has six parts. After each sector, you get a password to save your progress. At the end of each level, there is an end boss. This game is a collect-o-thon, though the main things to look for are batteries (which increase Tinhead's health) and tin balls (which increase the amount of shots you can fire simultaneously). One annoying aspect is that the orange capsules that contain the powerups must be touched before the powerup can be collected. In tight spots, this can require making a tricky jump twice if you need the powerup.

Tinhead is a cute looking platformer with nice (if simple) graphics. There isn't a lot of variety in the levels, with only five or six enemy types per stage. The level graphics are basic, sort of reminiscent of the original Sonic the Hedgehog. The graphics are very colourful and smooth, and would have appealed to the demographics of those who played video games at the time. There is nothing that makes it stand out from other 16-bit platformers, though.

I really liked the music in this game, but after listening to the same tune for six straight stages, it gets old. In particular, I liked the music from the second level, which starts off nice and cheery, then gets manic. Having more variety would help the game go by easier, as deaths and level restarts are rampant. The sound effects are generic blips and bloops.

As for gameplay, the controls work well. It suffers from what I refer to as "Mega Man Collection Gamecube Syndrome", where the jump button is mapped to the "Y" button rather than the "B" button like virtually every other platform game released on the SNES. Luckily, the designers have four different button configurations, so you are not stuck with the default scheme. There are three different shot types: fully horizontal, shot upwards at a 45 degree angle, and lobbed to bounce around on the ground. Each shot type is mapped to its own button. If you use control style "3", the horizontal shot is mapped to the Y button, which is likely optimal for most gamers. The game limits the amount of shots you can fire simultaneously until you gather powerups to increase your capacity, which can lead to slow progress. Jumping is done without difficulty, though if you hit a ceiling while jumping, you lose all your momentum. Realistic, maybe, but it is downright frustrating in parts.

Lessons In Platform Game Level Design

The part of the game that makes it sub-par is not the simplistic graphics or repetitive music: the level design is very poor. A lot of the problems likely would be resolved if the view wasn't so narrow. At any rate, here are eight rules of designing platform games.

Rule 1: When making a platform game, never put in a spot where you have to make a jump that is pretty much impossible to achieve without getting hit. The example above shows a point in the first part of the third sector in level one where you have to get through this gap that has spikes above and below you. Jump too high, and you get a spikes to the head, and you will most likely miss the platform as your momentum gets killed. Jump too low, and you miss the platform and get hit by the spikes from below. It is lose-lose all around unless you get very lucky (after probably 20 attempts, I still couldn't do it).

Rule 2: When making a platform game, never force the player to go back to the start of the level unnecessarily. In level one, there are various chutes that transport you to different parts of the stage. However, there is little indication to suggest whether or not the chutes will progress you through the level or send you backwards. In one stage, I was about halfway through, and went through one of these chutes, and I was sent to start of the stage. I would have been just as well off to have perished!

Rule 3: On a similar note, when making a platform game with very large levels, it is always a good idea to have midpoint saves so that when you die, you don't have to restart from the beginning of the level! The stages in this game are incredibly long, which is not a bad thing on its own, but if you are near the end of the level and you die, you have to start over again. I found myself dying a lot, so this made the game much more frustrating than it would have otherwise been. There really isn't any excuse for it, considering that the concept of the midway save point has been around since Super Mario Bros. for the NES (and the levels in that game are much shorter than the ones in this game).

Rule 4: Variety is the spice of life, so they say, and there isn't much of it in this game. The graphics in all six stages for the levels do not change. The simple graphics are fine, but after seeing the same scenery and listening to the same level music for six stages, it gets pretty old. When designing a platform game, change things up every couple of levels or so!

Rule 5: When making a platform game, do not place a powerup directly over a bunch of spikes that you can't avoid because you fall straight down after getting the powerup. I never was able to get the powerup above without getting hit.

Rule 6: When making a platform game where you have things like fans that blow you to great heights, there are a couple of rules. Number 1: If there are spikes to avoid, make sure they are visible before jumping on the fan! In the example above, there are three fans, with two that are directly underneath spikes of death that you cannot see at fan level. Number 2: Ensure that the fan blows you to where you need to go. The screen above shows me in a position where I am completely stuck. The fan doesn't blow me up to the platform I need to get to, nor is there any way to go down. This is essentially forces you to hit restart. Mind you, it is a pretty uncommon occurrence to be in this position, but it happened to me more than once in this spot. Terrible, but perhaps an indication that this game was not 100% finished.

Rule 7: You know, I love slopes. I thought that the slopes in Super Mario Bros. 3 were a real treat and made for some interesting levels. Tinhead uses slopes, but makes them so that they seem like they are covered in some sort of low viscosity fluid. You slide down these hills rapidly, and for whatever reason, you walk up them just as fast. This makes fighting enemies on slopes, or at the bottom of slopes nearly impossible without taking damage. When designing a platform game, don't make the character slide down slopes too fast!

Rule 8: The last point I would like to make on level design is what I call "the unseen threat". In Super Mario World, you could press L and R to scroll the screen to the left or right to get a view of what was ahead, though it was not entirely necessary as you could always see threats as they came. In Tinhead, you can also do this, but you soon find that it becomes a necessity to constantly hold down the scroll button. The level graphics are nice and large in this game, but the zoomed-in view serves as a handicap when it comes to the actual gameplay. If you play this game, you will run into many points where you make a jump to a new platform, and immediately run into an enemy that takes more than one hit to kill, giving you no recourse but to take a hit. Sure, there are tons of health powerups in this game, but the real problem is that you lose one of your simultaneous shots every time you get hit. This makes it a slow affair to tackle parts of the level not yet explored. Not only that, but there are many points where you must make a leap of faith, and when falling not know what is below (often there are spikes and enemies!). When designing a platform game, make sure that the player can see enemies and other dangers before making a leap!

Comparison with the Genesis version

The Genesis version of Tinhead is pretty much exactly the same as the Super NES version. Some of the powerup graphics are different (for example the star you need to collect before you can complete a level). The sound in the Genesis is inferior to the SNES version. In particular, the sound effects and music sound tinny compared to the SNES version. The controls are much different than the SNES version due to the lower amount of buttons on a standard Genesis controller. There are no buttons for manual scrolling of the screen. Also, there is only one button for shooting: to switch between the different types of shots you have to press the A button. The game also plays fast, almost as if they didn't bother to optimize it for a NTSC console. Due to the wider resolution of the Genesis, there are somewhat fewer problems with "the unseen threat". As you can see from the screenshot comparison, the problems with level layout still exist. Which version of this game you play is a matter of preference, I suppose.

Developer's goodies

On Stuart Whyte's webpage on Tinhead, there is a zip file full of raw graphics used during the development of the game. I converted these graphics from Amiga bitmap to PNG for your viewing pleasure (see the screenshots section). The graphics appear to come from both the SNES and Genesis versions of the game. I can't comment on the amount of unused tiles for the game, but as you can see from the image on the right, there are instances of graphical changes during the development of the game. There are many images that are identical, but have different pallets. There also are several images showing different models for the Tinhead character itself.

Another interesting developer bit is this document on sound design. This particular document is for the Mega Drive version of the game (I would assume the game was in development for the Mega Drive/Genesis before porting to the SNES). It is interesting because it gives insight on how music and sound effects were planned for the game. Things of interest include the fact that this game was designed for the PAL version first, with compensation to make sure the sound effects do not go too far out of sync in the NTSC conversion. As an example of how the sound was designed, here is a description of the first level music:

The Level One music should be a fast paced, cheerful tune, in a similar style to the main theme music (hardcore rave meets Kylie Minogue) but with a different tune and without the cartoon sound effects. Emphasis should be placed on conveying a sense of urgency, and there should perhaps be echoes of 'chase scene' music. The piece of music should be two minutes long, and should loop.

Codes

There are several codes for the game. All are taken off Stuart Whyte's page.

Level 1-2 - LAMBDA
Level 1-3 - SARTRE
Level 2-1 - QUANTA
Level 2-2 - MESONS
Level 2-3 - TENSOR
Level 3-1 - LEPTON
Level 3-2 - GORGON
Level 3-3 - BOSONS
Level 4-1 - BARYON
Level 4-2 - GIBSON
Level 4-3 - NEUMAN
BALROG - password to send you to the final boss, I assume
CAMELS - The only thing I could see affected by this code is that it sets your shots to max, and that your shots don't decrease when you get hit.

Summary

Tinhead, whether on the released Genesis version or the unreleased Super NES version, is a sub-par platform game. I found it to be very frustrating, and I never even bothered attempting to get past the second level. In fact, at times I wished I was playing Batman: Revenge of the Joker! The graphics and sounds in this game are nice, but the poor level design and zoomed in playing field drove me nuts. With the plethora of platform games available on the Super NES, this game would have been lost in the shuffle to far superior games in the genre. The game's brutal difficulty makes this one a hardcore-only affair. It is really no wonder no publisher bothered to pick this game up for the SNES.

Scans
(Click in the image to enalrge)

Bibliography:

· Review of the Genesis version of Tinhead on Sega 16 (link)
· Page on Tinhead by producer Stuart Whyte (link)

Tom and Jerry 2

Tom & Jerry 2 was being developed by Hi Tech, and published by Allan. It appears different that the Genesis game, Frantic Antics. One can only speculate as to why it was canceled. It probably found the same fate as other Hi Tech games like Bobby's world, in which the market was too saturated for platformers based on cartoons.

Scans
(Click in the image to enlarge)

Preview from Nintendo Fun Vision (issue 16)

Toxic Crusaders

Toxic Crusaders was an unreleased game in development by Bandai. There is a mention that it was in development in the September 1991 issue of Nintendo Power. There was apparently an article for it in the 39th issue of EGM (see the link to Unseen 64). It appears to be a side-scrolling platform action game.

From unseen64.net:

Toxic Crusaders is an animated series based on the Toxic Avenger films. It features Toxie, the lead character of the films leading a trio of misfit superheroes who combat pollution. Video games based on Toxic Crusaders were also produced by Bandai and Sega, which were released on the Nintendo Entertainment System, Game Boy, and Sega Genesis.[Info from Wikipedia]

A Super Nintendo version was in development by Bandai, but it was never released in the end. It looked different from the Genesis version, that was developed by Sega. Some screens of the SNES version can be seen in the issue 39 of EGM.

Images:

Bibliography:

· Nintendo Power, Pak Watch - Gossip Galore (mention of development), Publication date: September 1992, Volume: 40, Pages: 113
· Info on Unseen 64 (link)

Turbo Toons

Turbo Toons is an overhead racing game that is somewhat similar to Off Road. It features many of Hanna Barbara's second class cartoon characters, like Yogi Bear. The game was released in Europe. The game was perhaps finished for US release, as it is listed by the ESRB.

Tweety and Sylvester

Tweety and Sylvester was an unreleased game based on the popular Warner Bros characters by TecMagik.

Tweety and Sylvester was an unreleased game by TecMagik that was apparently completely unrelated to the unreleased game by Sunsoft called Sylvester and Tweety that was in development around the same time. The graphics do look different. I can only guess as to why there would be two Sylvester and Tweety games in development by different companies at the same time. Since the Sunsoft one was in development for much longer, I guess this version was not released due to this conflict. Or maybe it is because TecMagik went out of the 16-bit business (they only released three SNES games)?

Bibliography:

· Nintendo Power, Pak Watch Update, Publication date: December 1993, Volume: 55, Pages: 112

Ultrabots: Sanction Earth

Thanks to Maik Wiechmann for some of the info on this page.

This game was in development by NovaLogic, and was going to be published by Data East. The game was supposed to have a first person view from inside the mech, and the gameplay was supposed to be a simulation. There was a preview of the game at the 1992 Winter CES, and Nintendo Power said it looked "promising". The April 1992 issue of Nintendo Power had a further preview, which stated that the game was supposed to run at 16 FPS, and have the ability to control six battle robots. They mentioned it was supposed to be released in summer of that year. Ultrabots (or Xenobots in Europe) was released as a DOS game in 1995 by Electronic Arts.

Bibliography:

· Nintendo Power, Pak Watch - Super Rumors, Publication date: September 1991, Volume: 28, Pages: 97
· Nintendo Power, Pak Watch (mention of development), Publication date: February 1992, Volume: 33, Pages: 111
· Nintendo Power, Pak Watch - CES Special, Publication date: March 1992, Volume: 34, Pages: 112-113
· Nintendo Power, Pak Watch, Publication date: April 1992, Volume: 35, Pages: 109
· Nintendo Power, Poster, Publication date: June 1993, Volume: 37, Pages: -
· Nintendo Power, Summer CES Special, Publication date: August 1992, Volume: 39, Pages: 58-61
· Ultrabots at Moby Games (link)

Undercover Cops

Undercover Cops was released in Japan, but the serial code, SNS-AUCJ-JPN does not match this game. Odd. Anyways, the game is a typical snes-era brawler.

Serial Code: SNS-UV-USA

Universal Soldier

Universal Soldier was in development by a company called Carolco and was to be published by Accolade. The game was actually a sequel to the Manfred Trentz game, Turrican, but the character sprite was changed so that it could be rebranded as a movie tie-in. A rom of what appears to be the complete version of this game exists. The enemies and gameplay closely match Turrican, as to be expected. It is unknown why this game was canceled. Genesis and Game Boy versions of this game were released, and Turrican 2 was released on various computer platforms. Nintendo Power commented in the October 1992 issue that it was similar to Contra, but complained about the poor controls.

From unseen64.net:

Turrican was released in 1989 for the Commodore 64 and 1990 for the Amiga and Atari ST. It was Programmed by Rainbow Arts and Factor 5. Then Accolade made a port to the Sega Genesis, GameBoy, and Turbo Graphix 16. The Accolade Ports were a huge disaster. However, Accolade wanted to do the same thing with Turrican 2, which is known to be the best Turrican game and in general one of the best games ever made. They screwed up a classic and they wanted to screw up another.

However, the members of Accolade wanted to make their new port into a game based off of Universal Soldier to make more money. Universal Soldier was released for the Sega Genesis and Game Boy and was given horrible reviews. It’s a shame they took such a great game and turned it into a mess. There was going to be a Super Nintendo version but Nintendo didn’t license it despite the message on the title screen.

The Super Nintendo version was even worse than all of Accolade’s previous ports! The controls are messed up, the music sounds good at first but it becomes a mess. For example, one of the best songs in Turrican 2 is “The Wall” but in the SNES Universal Soldier version you can’t even hear the song because the beat is too loud. The Sound effects are annoying, the graphics are obviously ripped from Turrican, and the collision detection is beyond terrible.

If it was released, it would probably be called one of the worst games ever made. If you want to try this disaster a ROM of it was leaked on the internet.

Youtube links:
http://www.youtube.com/watch?v=nKX6m_xo ... r_embedded
http://www.youtube.com/watch?v=mWh-vuBw ... r_embedded
http://www.youtube.com/watch?v=D7bGrTgJ ... r_embedded

Bibliography:

· Nintendo Power, Summer CES Special, Publication date: August 1992, Volume: 39, Pages: 58-61
· Nintendo Power, Pak Watch, Publication date: October 1992, Volume: 41, Pages: 111
· Nintendo Power, Pak Watch (mentions that Accolade was going to release Turrican as Universal Soldier), Publication date: April 1993, Volume: 47, Pages: 109
· Wikipedia info on the Turrican series (link)

Warrior of Rome III

Warrior of Rome III was being developed for both the Genesis and the Snes, but was cancelled for both. The prequels were released on the Genesis. It was likely going to be a strategy game. It was going to be published by short lived Extreme, and was shown at the 1993 Summer CES.

Serial Code: SNS-35-USA

Bibliography:

· Nintendo Power, Pak Watch - Summer CES, Publication date: August 1993, Volume: 51, Pages: 112

Wile E's Revenge (Road Runner 2)

Wile E's Revenge was the sequel to Road Runner's Death Valley Rally. In this game, you took the role of Wile E Coyote, and chased the Road Runner through various locations in the United States. According to Rene Boutin, the producer of the game at Sunsoft of America, the game was about half done before being canceled.

Road Runner's Death Valley Rally was an awkward platform game. The logical step for the sequel would be to have you control Wile E. Coyote as he pursued the Road Runner. The development duties went to Software Creations, who created games like Plok and Blaster Master 2 for the Genesis. The game is sort of a 2.5D game, where Wile E Coyote can move up and down to take different paths.

A rom exists of an early version of the game, though it appears to be in more primitive form. For instance the splash logo:

Later beta (Courtesy of Rene Boutin)

Earlier beta version

As you can see, the rom version has a 90 degree rotation of the logo. The first level seems pretty much complete. To complete the level, you chase after the Road Runner and break open various boxes. There are various traps that are straight from the cartoon, such as the infamous rubber band trick. Unfortunately, the game crashes after the first level in the rom.

The graphics are simple, though it is pretty faithful to the style of the cartoons. In the rom, the sound effects were pretty standard fare, and the music was extremely muted. The play control was down pat, though. I'm sure if this game were finished, it would have been one of the better licenced platform games in the snes era.

Rene Boutin, producer of this game gives a synopsis of development and overview of the game:

The high level concept of the game was that the player got to be "the bad guy" (Coyote) for once. You'd speed through a level collecting parts to a contraption, and meanwhile being antagonized by the Road Runner. Then the next level, you'd have your contraption built and you'd be using it.

Now Warner Bros would NEVER allow Coyote to actually catch RR, so in the game every time you got within a few pixels of RR, he takes off. I think once players would catch on to the futility of trying to chase RR, they'd probably ignore him altogether. And this was one of the big flaws in the overall design of the game (Which I readily admit to having had a big responsibility in}.

The other angle to the gameplay was for a game with lots of fast running along really long levels. A kind of fervent fast racing type of gameplay with SOME elements of platformers. But that just wasn't panning out by this stage in the project. Something was seriously lacking. In hindsight we could have had a sort of meter that the player would have to keep full by staying real close to the Road Runner as much as possible, while hunting for the parts to his contraption. But instead, the best we could come up with at the time was good old "collecting stuff" (bleah!). Trying to co-design a game with a team that was half-way across the globe didn't help either. Ideally a designer needs to be working hand in hand with a programmer. Ah what a decade+ of wisdom and game experience can do, huh?

Last info I want to share with you is the reasons for the cancellation. Although I've conveyed here that the game lacked depth by that point, the big event was Sunsoft's closure for bankruptcy.

Images:

Wrestlerage

Before Battletoads, there was Wrestlerage; on the SNES, at least. This 1991 side-viewed grapple-fest aimed to capitalise on the success of the two NES wrestling titles previously produced by Rare, but also to break away from the restrictive ring-based play of the licensed games by taking the action out into the streets / parks / fairgrounds / building sites / anywhere else with a bit of free space.

Starring a cast of eight fictitious brawlers ranging from Mr. Mangler through to the Silver Bullet, Wrestlerage was set to transpose the best elements of the popular wrestling game onto a Double Dragon-style scrolling urban background, each of the fighting arenas around three screens in length. The traditional attacks of such games (both unarmed and weapons-based) would be joined by dropkicks, pins, grapples and unique attacks such as carrying your opponents bodily around the screen and even, if the mood took you, bouncing their heads off various pieces of background scenery. A mode of play was even planned where all the contenders jumped into one big on-screen free-for-all rather than slugging it out head-to-head.

But these ambitions were to remain unrealised when, at around 60% complete, the lack of a licence or an already successful version which the marketers could use as a core selling point finally sealed Wrestlerage’s fate. In a tricky period for the console market, with punters becoming more cautious than ever about how their money was spent, the sad fact was that none of the potential distributors were willing to take on board the risk of an original game. And so the way was left clear for the Battletoads conversions instead to become RARE’s first SNES outings… [Source: rareware.com]

Zoo Ball

Zoo Ball is an unreleased game planned for release in the US by American Technos. The game was going to be a localization of Dolucky no Kusayakiu. Thanks to KingMike for the scans.

Zoo Ball is an unreleased baseball game featuring animal characters as players. The game was going to be published by American Technos, though the Japanese game was released by Imagineer and Zoom (as Dolucky no Kusayakiu). Why American Technos decided to localize this is unknown, though maybe they figured it would appeal to younger players. The screenshots found in the April 1994 issue of EGM clearly shows the Japanese version of this game. They described the animation of the game as "cute" and the sound as "funny".

Images

As you can see from the pictures above, the screenshots from the EGM preview probably came from the final version of the Japanese game. There appears to be a lot of shilling for Coca-Cola in this game. One would assume that it would have been very cheap to localize this with their logo plastered everywhere in the game. Perhaps that was another reason for its demise?

Scans
(Click in the image to enlarge)

Bibliography:

· Electronic Gaming Monthly, Preview, Publication date: April 1994, Volume: 57, Pages: 136

Fuente: SNEScentral & Google

Volver a la página principal.

ChepoXX 20 jul 2010 21:36

MegaAdicto!!!

4.052 mensajes
desde ago 2003

De esta lista no me llama ninguno, talvez el willie revenge por la buena pinta pero nada mas.

Ralph 20 jul 2010 21:55

MegaAdicto!!!

14.020 mensajes
desde feb 2006

Yo le daría una oportunidad al toxic crusaders... podría resultar una especie de splatterhouse cutre, pero molaría mil de todos modos.

...y obviamente al targa, que no es otro que el rendering ranger, pero en versión beta.

FFantasy6 escribió:Esto es interesante.

Una rom para testear las SNES'es

http://www.digitpress.com/forum/showthread.php?t=146537

No acabo de verle la utilidad.

ryo hazuki 20 jul 2010 21:56

¡Tuturuuu!

Validador C/V

44.279 mensajes
desde abr 2008
en El psy kongroo

PSN ID: Fran2-0

Al Undercover cops jugue mucho en recreativa y aunque era lo mismo de siempre, me molaba lo salvaje que eran las llaves y los golpes especiales

Una pena que el juego original sea taaaaaaaan caro..........

FFantasy6 20 jul 2010 22:01

MegaAdicto!!!

30.512 mensajes
desde dic 2003

Ralph escribió:No acabo de verle la utilidad.

Yo si, y necesitaria algo parecido para una megadrive, para saber que le falla, sino la tiro.

Ralph 20 jul 2010 22:16

MegaAdicto!!!

14.020 mensajes
desde feb 2006

Hombre, está claro que es para diagnosticar cosillas. Pero muchas veces, a causa de tonterías la maquina no enciende, y entonces te da igual.

No se, como no me veo muy a menudo reparando maquinas, pues no se hasta que punto haría falta algo así, y en que casos.

...vamos, hablar por hablar, de toda la vida

FFantasy6 20 jul 2010 22:18

MegaAdicto!!!

30.512 mensajes
desde dic 2003

Si, eso tambien, que si falla el video por ejemplo no sirve de nada xD a no ser que pite xDDDDDD

socram8888 20 jul 2010 22:31

lol socram pole

2.591 mensajes
desde may 2007

socram8888 está baneado por "incumplimiento términos y condiciones de uso"

Ralph escribió:...

Si, podrían trabajar ambos a la vez

No sé si de forma nativa, pero sí usando cualquiera de estos dos métodos:
- El 68000 le pide el bus (pone el Z80 en HALT, es decir, para su funcionamiento) al Z80 y entonces escribe el valor del PCM, y luego le devuelve el control.
- El Z80 reserva por ejemplo 1KB para PCM. Entonces el 68000 transmite un bloque de 1KB de PCM a la RAM del Z80 y le escribe un valor en la RAM para indicarle que tiene que reproducir esos datos. Cuando acabe el Z80, escribe otro valor en su RAM, que el 68000 leerá, y en ese momento escribirá el siguiente bloque de audio PCM.

No sé si ambos pueden operar a la vez, pero estas dos alternativas son bastante buena idea para sobrepasar el límite de los 8kB de su RAM

Yo creo que lo de los 7000 Hz es más bien para ahorrar espacio en la RAM del Z80, ya que un PCM a 7000 Hz ocupa menos que uno a 22050 Hz, por ejemplo

Ralph 20 jul 2010 22:41

MegaAdicto!!!

14.020 mensajes
desde feb 2006

socram8888 escribió:Si, podrían trabajar ambos a la vez

No sé si de forma nativa, pero sí usando cualquiera de estos dos métodos:
- El 68000 le pide el bus (pone el Z80 en HALT, es decir, para su funcionamiento) al Z80 y entonces escribe el valor del PCM, y luego le devuelve el control.
- El Z80 reserva por ejemplo 1KB para PCM. Entonces el 68000 transmite un bloque de 1KB de PCM a la RAM del Z80 y le escribe un valor en la RAM para indicarle que tiene que reproducir esos datos. Cuando acabe el Z80, escribe otro valor en su RAM, que el 68000 leerá, y en ese momento escribirá el siguiente bloque de audio PCM.

No sé si ambos pueden operar a la vez, pero estas dos alternativas son bastante buena idea para sobrepasar el límite de los 8kB de su RAM

Podría ser que sobre el papel se acelerara algo el trabajo, pero no veo la posibilidad de que trabajen a la vez.

El otro día escuché la melodía de un juego en el que la percusión usaba el canal PCM, y no veas el cambio que pega la musica con una buena percursión... eso si, me dió por buscar el video del juego in game, y tal como esperaba, los SFX y las voces tenían ese tipico efecto granulado.

¿Que es lo que hace que el resto de canales sean tan poco propicios para los sonidos digitalizados?.

socram8888 escribió:Yo creo que lo de los 7000 Hz es más bien para ahorrar espacio en la RAM del Z80, ya que un PCM a 7000 Hz ocupa menos que uno a 22050 Hz, por ejemplo

Pero sobre todo, ocupa menos memoria en el cartucho, y en total, son 8Mbits, igual que en SNES. Es lo que me choca.

socram8888 20 jul 2010 23:35

lol socram pole

2.591 mensajes
desde may 2007

socram8888 está baneado por "incumplimiento términos y condiciones de uso"

Hombre, es que poner tres palabras a 7000Hz o a 22050 no creo que tenga mucha repercusión en el tamaño final [+risas]

Ralph 21 jul 2010 01:57

MegaAdicto!!!

14.020 mensajes
desde feb 2006

socram8888 escribió:Hombre, es que poner tres palabras a 7000Hz o a 22050 no creo que tenga mucha repercusión en el tamaño final

No me has entendido, en megadrive usan el canal PCM, como tu dices, para 4 palabras mal contadas (y encima a 700h0z), mientras que el resto usa los canales normales, usando un sonido que no ocupa tanto. En SNES, las voces, efectos, y musicas, usan canales PCM, y por lo que se ve, a todo trapo.

...¿Por qué ambos cartuchos pesan lo mismo?.

magno 21 jul 2010 06:51

MegaAdicto!!!

2.232 mensajes
desde ene 2005

Página web de magno

Ralph escribió:
socram8888 escribió:Hombre, es que poner tres palabras a 7000Hz o a 22050 no creo que tenga mucha repercusión en el tamaño final

No me has entendido, en megadrive usan el canal PCM, como tu dices, para 4 palabras mal contadas (y encima a 700h0z), mientras que el resto usa los canales normales, usando un sonido que no ocupa tanto. En SNES, las voces, efectos, y musicas, usan canales PCM, y por lo que se ve, a todo trapo.

...¿Por qué ambos cartuchos pesan lo mismo?.

Estaba siguiendo esta conversación sobre el audio de MEgadrive con cierta incredulidad porque no sabía realmente de qué iba el tema, PERO LO ACABO DE PILLAR

¡Resulta que vuestra duda es por qué ocupan ambos lo mismo cuando uno usa el sintetizador y otro PCM!
Pues ocupan lo mismo porque SNES usa BRR (Bit Rate Reduction), que al descomprimir da muestras PCM; no es un sintetizador MIDI lo que tiene, sino canales con el audio a tutiplén, pero que se almacena comprimido en el cartucho; estos datos comprimidos se transfieren al chip de sonido que se encarga de descomprimir y aplicar efectos, ecos, volumen y demás a las muestras PCM descomprimidas.

Aquí tenéis la información:

http://wiki.superfamicom.org/snes/show/Bit+Rate+Reduction+%28BRR%29

Ralph 21 jul 2010 12:36

MegaAdicto!!!

14.020 mensajes
desde feb 2006

Ya decía yo. Es la única conclusión lógica, pero no imaginaba que pudiesen almacenarse tan comprimidas. Gracias por la info magno

#277671# 21 jul 2010 12:56

1988, Super Nintendo entra en escena

Imagen

Mas informacion AQUI

Ralph 21 jul 2010 13:12

MegaAdicto!!!

14.020 mensajes
desde feb 2006

Volver a la página principal.

GUÍA DE ASM
Capítulo 5: Programación en ASM (mostrar un texto por pantalla)

Ley Nº 1 de la programación en ASM:

“Las Tiles o Fuentes a mostrar por Pantalla se deben meter en ROM o RAM y luego pasarla a la VRAM, ya que así y solo así se podrá ver en pantalla. No hay otra forma.” Magno.

Introducción:

Nuevo V1.1:
Compilando el fuente en el fabuloso X86.
Más términos como Tile y sprite.
Aclaraciones y cambios que hay que hacerle al fuente para que se compile con X86 y el fuente sea ejecutable en el ZSNES.
El fuente .asm completo para X86.

Después de mucho tiempo, por fin he entendido como mostrar algo por pantalla, usando puro ASM, lo que muchos esperaban…¡por fin todo explicado!
Lo que pretendo es mostrar el mensaje “hola mundo”, clásico en el mundo de la programación, por la pantalla, que responda al Joystick, y todo esto verlo en el emulador.

Esto nos servirá para entender como se hace un juego en ASM, y servirá para entender mucho mejor los famosos LOG del Trace del SNES9X. Es el documento con más contenido de programación ASM que he hecho hasta ahora.

¡Quizás este es el documente MAS esperado por los verdaderos Rom-hackers de la SNES!

¿Que se espera?

Simplemente hacer una ROM sencilla que muestra un texto por pantalla y que responda al Joypad de manera que al presionar START se baya oscureciendo la pantalla.

Esta es la ROM que ustedes harán, claro que con texto que quieran (:

Antes que Todo

Para realizar a programar en ASM de la SNES, hay que tener en cuenta varias cosas (muchas cosas están ya explicadas con detalle en los capítulos anteriores, así que iré rápido):

La SNES corre sobre un procesador 65816, similar al 6502 (procesador donde corre la NES) pero con nuevas instrucciones disponibles.
El 65816 es un procesador de 16 bits, pero también de 8 bits. Soporta direccionamiento de 24 bits. A diferencia con el direccionamiento de 16 bits, ahora puedes agregar el byte de BANCO. Puedes hacer en 24 bits, por ejemplo una instrucción LDA $C01234, donde el banco es C0.
La memoria total esta dividida en BLOQUES de 32K cada uno.
NO se puede escribir en la ROM, solo en la RAM. Es decir no se puede hacer un:
LDA $20 luego hacer STA $C01234 ya que estamos escribiendo en la ROM (el Banco C0 es de la ROM). En cambio SI se puede hacer un LDA $20 y luego STA $7E0154 ya que escribimos en la RAM.
Las direcciones de la ROM varían según una HiRom o LoROM. La RAM es la misma para ambos.

HiROM -> RAM: 7E-7F: 0000-FFFF
Aquí hay 64K en cada banco (7E y 7F) lo que suma 128K de RAM, el tamaño total de memoria RAM de la SNES.

ROM: C0-FF: 0000-FFFF
En la ROM las Direcciones son de 0000-FFFF para CADA banco.

LoROM -> RAM: 7E-7F: 0000-FFFF
Aquí hay 64K en cada banco (7E y 7F) lo que suma 128K de RAM.

ROM: 80-FF: 8000-FFFF
En la ROM las Direcciones son de 8000-FFFF para CADA banco.

La CPU tiene registros internos: A, X, Y, D, S, PBR, DBR, PC y P. Todos se usan de alguna forma al momento de programar. A, X e Y son los que mas se usan directamente.

El Registro P - Registro de Banderas (Flag Register)

n: Negative
v: Overflow (desbordamiento)
m: Memory/Accumulator Select (acumulador)
x: Index Register select (registros X e Y)
d: Decimal
i: Interrupt
z: Zero
c: Carry (acarreo)
e: Emulation (0 = Modo Nativo)

Un REP #$30 deja X,Y, A en modo de 16 bit ya que 30 hex = 110000, deja en 0 (R[reset]EP) el Bit 4 de X (indices X e Y ) y bit 5 M (acumulador).
Un SEP #$30 deja X,Y, A en modo de 8 bit ya que 30 hex = 110000, deja en 1 (S[set]EP) el Bit 4 de X (indices X e Y ) y bit 5 M (acumulador).

Términos usados

Puerto: es una dirección de memoria en la que al escribir en ella, no escribes dentro de un chip, sino que estas escribiendo en otro dispositivo. Así las direcciones $2116 y $2117 son puertos ya que no escribimos directamente a los chips de RAM si no que en el controlador de video de la SNES.
PPU: Picture processing unit (unidad de imagen de procesamiento). Esta el la cosa que la toma datos gráficos de la SNES y las tira a una imagen en la pantalla de TV. En detalle: La PPU es un hardware interno a la SNES que viene en un chip diferente a la CPU y que se encarga de controlar el video y la salida a formato NTSC o PAL. Esta PPU es un procesador que funciona de forma independiente y automática según los valores que contengan sus registros y es el que genera la famosa interrupción NMI cuando se inicia el tiempo de VBlank.
VBlank o Blanking: Es el tiempo que tarda el haz de electrones de la TV en retornar desde la última línea de pantalla, abajo a la derecha, hasta la primera, arriba a la izquierda, para dibujar otro frame. El tiempo exactamente es de 65 microsegundos en el sistema europeo PAL y otro tiempo diferente en NTSC y en este tiempo se debe copiar lo que está en los planos a VRAM.
Registros: Puertos de Memoria-mapeados de Input/Output usados para enviar datos y comandos a PPU.
OAM : El Plano/tabla de Sprites se copia aquí y se mantiene información de ellos. OAM significa "Object Attribute Memory", es decir “Atributos de los Objetos en Memoria”.
CG: Color palette data (Datos de la paleta de Colores), o datos de la memoria que la almacena. Hay 256 paletas que contiene los niveles color en un valor de 16-bit.
SC: Screen (Pantalla). Usualmente nos referimos a Tile Map (o simplemente MAP) para un BG, el cual esta guardado en VRAM. Una pantalla esta formada por 32x32 tiles.
BG: Background (Fondo). Hay 4 BGs, o Planos o "layers", para cada Tile. Esos BGs pueden ser deslizados (scrolled), y en especial tipo de BG, en "Mode 7", puede ser ESCALADO y ROTADO en una sorprendente vista 3-D. A veces el termino "plano" es usado como BG pero con indice menor (BG1=Plane 0, BG2=Plane 1, GB3=Plano2, BG4=Plano 3).
Tile: Objetos gráficos que forman una pantalla (tile map). Un tile esta formado por 4 Planos de 8x8 pixels y estos planos por bits (1bpp=1 bit por píxel, 2bpp=bit por píxel, 2bpp, u 8bpp). La cantidad de colores posibles del tile lo da la cantidad de bits del bitplane que forma un plano, así 4 colores = 2 bitplanes, 16 colores = 4 bitplanes, 256 colores = 8 bitplanes, 256 colores = modo 7 (caso especial que lo veremos mas adelante). Varios Tiles forman un sprite.
Sprite: Objeto grafico que le podemos dar movimiento. Esta formada por tiles. La tabla de sprites se carga en OAM.
DMA: Conjunto de Registros que permiten copiar datos a VRAM extremadamente rápido sin usar mucho el procesador.

De la Fuente al Objeto

Vamos a realizar un Código Fuente, que será Compilado por un Compilador o Traductor para generar un OBJETO de salida, que es en este caso, un ROM que es EJECUTABLE para un emulador de SNES.

Herramientas de programación

Para programar: Un editor de Texto cualquiera, recomiendo EditPad Lite (Tip: con Shift + F11 se ven el numero de línea). A todo esto ¿alguien conoce un editor ASM con colores y todo lo demás que sirva para ASM 65816??? Si alguien sabe, que me mande un correo please, si no tendré que hacer yo mismo un editor

.

Para Compilar y Crear un SMC: Aquí hay una variedad mayor:
X86: usado por Magno, yo lo estoy aprendiendo a usar. Muy bueno y completo, quizás el mejor.
SNESASM de ThE INqUISITIoN of BLW (ojo que hay otro que se llama SNESASM Cross Assembler 1.05, pero NO me refiero a este). Muy sencillo de usar, pero incompleto en algunas aspectos. Este use para hacer la rom que trabajaremos en este capitulo. Es para compilar programas sencillos. No se esperen una maravilla de compilador, esta hecho a base de comandos en lenguaje C.

Para compilar fácilmente con SNESASM: Crear un acceso directo del SNESASM y en las propiedades, al final le agregas: [fuente] [archivo.smc] por ejemplo:

…..\SNESASM.EXE demo1.asm demo1.smc

Así como se ve en la imagen:

En la pestaña “Memoria” ponle todo Automático. Ahora edita el archivo fuente (en este caso demo1.asm) y ejecuta el acceso directo, así generaras el .smc mas rápidamente (.

Para compilar fácilmente con X86. Tenemos que aprender desde ya a compilar con este gran compilador ya que es el que usaremos de aquí en adelante. Crear un acceso directo del x86 y en las propiedades, al final le agregas: –s(ese) –l(ele) [fuente.asm] por ejemplo:

…..\X816.exe -s -l DEMO1.ASM

El –S es para que cree el ejecutable .SMC y el –L para que cree un archivo .LST con los códigos hex de cada opcode y la lista de errores posibles del fuente. Esto es muy útil al momento de depurar tu programa.

Etapas de Desarrollo del Programa

Al programar la frase “Hola mundo” no es llegar y ponerse a escribir código print “hola mundo” como en C. Para nada, aquí es mas largo, casi 100 líneas de código. Pero tranquilos ya que lo entenderemos de a poco.
Para hacer un buen programa hay que aplicar Ingeniería, y para esto cumplimos una serie de etapas para cumplir un objetivo final. Las etapas básicas para escribir cualquier programa de ASM que hagas, son:

1. Declaración de Directivas de Ensamblador

Algunos copiladores exigen que tu código ASM de SNES tiene un código inicial que configura (no inicializa) los registros, índices, compilador etc., antes del programa principal. Ese conjunto de instrucciones en ingles le llaman Directivas de Ensamblador (Assembler Directives).

X86 y otros compiladores tienen estas directivas Opcionales, que van comienzo del código asm. En general si usas X86 van siempre. En el ASMSNES que yo uso, NO necesariamente deben estar.

El conjunto de Directivas es variado, dependiendo del compilador. El compilador X86 en el readme.txt entrega una larga lista, he aquí todos:

.EQU
.ORG
.DCB o .DB
.DCD or .DD
.DCL or .DL
.DCW or .DW
.DSB
.DSD
.DSL
.DSW
.PAD
.INCSRC (.SRC)
.INCBIN (.BIN)
.BASE
.MEM
.INDEX
.DETECT
.DASM
.OPTIMIZE (.OPT)
.HROM
.LROM
.HIROM
.SMC
.LIST
.SYMBOL
.PARENTHESIS (.PAR)
.ECHO
.COMMENT
.INTERRUPTS (.INT)
.CARTRIDGE (.CART)
.IF
.ELSE
.ENDIF
.IFDEF
.IFNDEF
.MACRO
.MODULE (.MOD)
.LOCALSYMBOLCHAR (.LOCCHAR)
.ASCTABLE
.ASC
.TABLE (.TAB)

No explicare todos, solo los más importantes (quizás en futuras versiones explicare uno a uno), estos son:

.ORG
Lo que hace es definir la dirección de inicio donde se empezara a escribir el código que le persigue. Recuerda que esto va al principio del código del juego. Pero existen 2 tipos de ROMs: Hi-roms y Lo-roms, ambos tienen sus direcciones específicas donde se puede empezar a escribir código. Lo-rom desde banco 80 dirección 8000 (dirección 808000) y las Hi-rom desde banco C0 dirección 0000 (dirección C00000).

Se usa así si el código que se hace es para una Lo-Rom :
.org $808000

Y para una Hi-Rom :
.org $C00000

.HIROM
Seteamaos el modo de la ROM, por defecto está en modo de Low ROM. Esta directiva es parecida a .HROM o .LROM. Usando ON o OFF en el operando se deja en modo de Hi ROM o Lo ROM. Si no va este modo, X86 envía un mensaje al compilarlo, ya que es necesario ponerlo.

Ejemplos:
.hirom ; reporta el status de la high ROM
.hirom on ; usa modo high ROM
.hirom off ; usa modo low ROM

.MEM
Define el ancho de bits del acumulador de 8 o 16 bits (por defecto es 16 bit). X86 envía un mensaje si no se define un .mem 8 o .mem 16.

Ejemplos:
.mem ; reporta el ancho de bits de A
.mem 8 ; setea A a 8 bit
.mem 16 ; setea A a 16 bit

.INDEX
Define el ancho de bits del Registro Indice X o Y a 8 o 16 bits (por defecto es 16 bit). X86 envía un mensaje si no se define un .index 8 o .index 16.

Ejemplos:
.index ; reporta el ancho de bit X/Y
.index 8 ; setea X/Y a 8 bit
.index 16 ; setea X/Y to 16 bit

.DETECT
Detecta el ancho de bits (por defecto esta en off), con esto X86 detecta si hay un cambio de ancho de Bits al realizar una instrucción REP/SEP (cambia de ancho de bits de acumulador o índices) y automáticamente X86 cambia el ancho de bits del acumulador

Ejemplos:
.detect ; reporta si detect esta on o off
.detect on ; activa autodetection
.detect off ; disactiva autodetection

.EQU
Puede ser .EQU o simplemente EQU o un signo igual =. Asigna un valor a un símbolo (como el la instrucción Define de C++).

Ejemplo:
space equ 32
letter_a = 65
LDA $space ;es lo mismo que LDA $32.

.OPTIMIZE (.OPT)
Activa o desactiva la optimización de dirección (por defecto esta en off).
X816 es capaz de detectar si una dirección está en un mismo Banco que la dirección actual. Si es así la dirección si es de 24-bit pasa a ser de 16-bit, esto eliminas las referencias de 24 bits cuando solo hablamos de direcciones de 16 bits y estamos en el mismo banco. X816 genera errores cuando hay una referencia a una dirección de 24 y el modo de direccionamiento es de 16 bits, pero el código resultante solo toma para la operación los 16 bits menores y no los 24 bits completos.

Ejemplos:
.optimize ; reporta el estatus de optimize
.optimize on ; activa optimize
.optimize off ; desactiva optimize

Código Ejemplo Directiva de Compilación

Al crear un fuente para X86 debes poner al comienzo de tu archivo esto (no se si para otro es igual, ASMSNES no lo requiere):

.org $808000
.hirom off
.mem 16
.index 16
.detect on
.optimize off

Es fácil ahora interpretar lo que queremos hacer: una Lo-rom, con acumulador de 16 bits, índices de 16 bits, que detecte cambios de anchos de bits y que no optimice las direcciones.
Insisto que si haces fuente para SNESASM esto NO es obligatorio.

2. Declaración de Constantes

Esta declaración es muy simple, y se hace mediante la palabra reservada EQU que la tienen casi todos los compiladores, también funciona como directiva. Podemos definir constantes que usaremos en el programa reiteradamente, por ejemplo ciertas direcciones de la RAM a que se accesará mas de una vez, etc. No es obligatorio definir constantes, es solo para tu facilidad.

El uso es:
CONTANTE equ <num o hex>

Código Ejemplo Declaración de Constantes

Ejemplo sacado del archivo WWF_v50.asm de Magno, donde él pone a disposición un código que muestra algo en pantalla con las fuentes extraídas y modificada del juego Chrono Trigger. Esta en su página, sección Documentos (http://www.nekein.com/magno).

font equ $0A ;en general se ocupa esta dirección
charset equ $81E4
INI_X equ 32 ; es la posición de la pantalla
; en píxeles donde queremos que empiece el texto
INI_Y equ 64 ; es preferible que estos valores decimales
; sean múltiplos de 8

POS_X equ $4D
POS_Y equ $4A
FUENTE equ $44
NUM_TILES equ $7E807E
….
….

3. Instrucciones de Partida

Se inicializan ahora los registros básicos como el Carry y el de Interrupción, y se deja activado el Modo Nativo de la SNES, sin emulación de la 6502. SIEMPRE son el mismo conjunto de instrucciones, donde sea que lo quieras compilar tu fuente, si en X86 o en SNESASM.

En general aquí se hacen 3 pasos:

Activar interrupciones.

START SEI ; SEI: Set Interrupt Flag. El Label o Etiqueta “start” indica que comienza el código, puede ser “inicio” o “comienzo”, etc. SEI deja en 1 el flag de interrupción, es decir, que vamos a permitir que se produzcan interrupciones durante la ejecución. En general siempre se usa “Start y sei” en la misma línea.

El Data Bank Register (DB) debe partir igual al Program Bank Register (PB).

PHK ; PHK: Push Program Bank Register. El banco actual del
Program Bank se guarda en la Pila, de manera de pasarlo al Data Bank.

PLB ; PLB: Pull Data Bank Register. Sacamos el valor de la pila y la pasamos al Data Bank.

Cuando la SNES se inicia, en el registro PB se carga el byte del banco donde se están leyendo las instrucciones (esto es “interno” no hay código), pero el DB queda vacío, por lo que se llena con el valor de PB. En estas 2 líneas hacemos que el registro DB (Data bank) valga lo mismo que el PB (Program bank)

Dejar en 0 el bit de Emulación para actuar en modo de Nativo de 16 bit.

CLC ;limpiamos el Bit de CARRY (Carry=0)
XCE ;Dejamos Modo nativo de 16 BIT (No hay emulación del 6502). XCE lo que hace es poner a '0' el bit de emulación, que por defecto siempre está a '1', si no se pone a '1' el 65C816 se comportaría exactamente igual que el 6500 de la NES; para poner ese bit al valor que queramos siempre se ha de hacer a través del bit de Carry C.

4. Inicialización de los registros

Esta es una parte vital para todo el desarrollo del programa. Hablamos de registros de video, dma, Joystick, interrupción, que ahora se deben inicializar. Esto te ayudará a entender mejor cuando suceden rutinas complicadas que se repiten en todos los juegos, como “inicializar VRAM para mostrar gráficos”, “meter el texto en RAM”, etc.
Antes, una explicación de la grafica de la Snes y términos usados de aquí en adelante.

4.1 Gráfica de la SNES

Una pantalla de SNES (en 1 frame) esta formada por 4 capas fijas llamadas BG o Planos, que no tienen porque estar activas las 4 a la vez. También esta formada por una Capa de Sprites, en la que los gráficos de allí dentro se mueven según unas tablas. Toda esta información se mete en la VRAM.

Cada capa de estas es independiente entre sí, por tanto, esto que explico ahora vale para cada una de las capas fijas por igual (que nombrar desde BG1 a BG4). Si solo quieres activar las capas BG2 y BG3, deberás escribir en VRAM para cada una de ellas un Mapa de Tiles.

Cada capa BG ocupa toda la pantalla y esta formada por una rejilla 32x32 de Tiles 8x8 (es decir, cada celdilla es una tile 8x8 píxeles) es decir, que tenemos una resolución de 256x256 píxeles.

Por tanto, lo lógico es pensar que hay que decirle a la SNES que tile 8x8 tiene que dibujar en cada celdilla. Para ello está el mapa de tiles, que tiene 2 bytes para indicar en que posición de la VRAM esta la tile que hay que sacar en esa celda. Como hay 32 celdas en cada una de las 32 filas, tenemos
-> 32 * 32 * 2 = 2kbytes de información para cada BG (recuerda que hay 4 BG's). Así que de VRAM necesitas un mínimo de 8 Kbytes para meter la información de las BG. El resto, 56Kbytes (así hacer los 64 Kbytes totales) es para que metas las tiles en sí de los gráficos que forman cada una de las BGs, así como de la capa de sprites.
Como ves, esto es espacio de sobra para meter gráficos. Además, estos gráficos se copian en VRAM SOLO y UNICAMENTE cuando se produce el Blanking del TV (ver Definiciones de sección “Términos Usados” para saber que es Blanking).

Esto es completamente lógico y lo hacen todas las consolas, puesto que mientras que el haz de electrones de la TV esta dibujando un frame en pantalla, éste no puede variar y por tanto no se puede producir ningún movimiento en la pantalla.

A parte está la Capa de Sprites. La SNES sólo puede mover 128 sprites a la vez, y la tabla de cada sprite es de 220 bytes, así que haces la multiplicación y ya tienes cuanto ocupa esta tabla completa. La capa de Sprites NO SE COPIA EN VRAM, SINO EN OAM, que es otro trozo de memoria que queda a parte de RAM y VRAM, que también se accede en modo puerto como la VRAM. Esta es más complicada de entender, así que la veremos quizás mas adelante.

La SNES utiliza uno de los 8 Modos Gráficos para mostrar algo en pantalla (del 0 al 7, ¿han escuchados del Mode 7 del Mario World 2 ?). El modo 0 es el mas sencillo ya que muestra 4 colores por tile, y se pueden usar los 4 planos. El Mode 7 es el más complejo, pero puedes hacer efectos en 3D.
El modo 1 es el más fácil y es el mas se usa para enseñar programación asm.

MODO Numero de BGs Máximos colores/Tile Paletas BitPlanes Colores 0 4 4 8 4 bpp 32 1 3 16/16/4 8 4 bpp 128
Como se ve, ya con modo 1 tenemos 128 colores. En Modo 1 tenemos el BG 1 y 2 con 16 colores y el BG 3 con 4 colores.

4.2 Como se fabrica un Tile y se muestra en Pantalla

Al programar podemos hacer un tile a base de códigos Hex, esos códigos representan en Binario una figura o fuente (una letra o símbolo).

Así tenemos por ejemplo 2 caracteres Char1 y Char2:
Char1 = $00, $00, $00, $00, $00, $00, $00, $00 -> 8 hex
Char2 = $00, $3C, $4E, $5E, $5E, $40, $3C, $00 -> 8 hex

No se ven pero si los pasas por un programa que yo hice SNES_FONT_MAKER V1.0 podrás ver que fuentes son.

En ASM quedaría:
Char1 dcb $00, $00, $00, $00, $00, $00, $00, $00
Char2 dcb $00, $3C, $4E, $5E, $5E, $40, $3C, $00

Y si pasamos a Binario (%) y escribimos hacia abajo cada uno, nos quedaría la versión que se ve en pantalla:

% 00000000 = $00
% 00000000 = $00
% 00000000 = $00
% 00000000 = $00 Este es Char1 (de 8 x 8 pixels)
% 00000000 = $00
% 00000000 = $00
% 00000000 = $00
% 00000000 = $00

% 00000000 = $00
% 00111100 = $3C
% 01001110 = $4E
% 01011110 = $5E Este es Char2 (es un carácter e) =
% 01011110 = $5E $00,$3C,$4E,$5E,$5E,$40,$3C,$00
% 01000000 = $40
% 00111100 = $3C
% 00000000 = $00

Esto ve se con mi programa SNES_FONT_MAKER V1.0 que hice:

Ahora bien como saber que color tienen los pixels que forman el carácter e.

4.3 Los Colores [ registros $2121 y $2122 ]

Los colores de los pixels se ven gracias a los BipPlanes, la SNES usa 4 bpp (bit plane font), es decir Fuente en Planos de 4 Bit.

0 0 0 0 = Color #0
bitplane 0 bitplane 1 bitplane 2 bitplane 3

0 1 1 0 = Color #6
bitplane 0 bitplane 1 bitplane 2 bitplane 3

Ahora Tabla completa de Modos:

MODO Numero de BGs Máximos colores/Tile Paletas BitPlanes Colores 0 4 4 8 4 bpp 32 1 3 16/16/4 8 4 bpp 128 2 ? ?? ? 4 bpp ?? 3 2 256 y 16 1 y 8 4 bpp 256 y 32 4 2 256 y 4 1 y 8 4 bpp 256 y 32 5 ? ?? ? 4 bpp ?? 6 ? 16 8 4 bpp 128 7 ? 256 1 4 bpp 256
El color de fondo que se ve en pantalla es algo mas complicado. Los colores de la SNES son 15 bit; 5 bits para azul, 5 para verde, y 5 para rojo. El orden aquí no es como VB u otro (clásico RGB), sino que es BGR (es invertido!!)

El formato es:

?aaaaavv vvv rrrrr = 16 bits
a : azul
v : verde
r : rojo
? : no se usa

Ejemplo se uso:
0111 1100 0000 0000 = #$7C00 Azul brillante
0000 0000 0001 1111 = #$001F Rojo brillante
0111 1100 0001 1111 = #$7C1F Púrpura
0000 0000 0000 0000 = #$0000 Negro
0111 1111 1111 1111 = #$7FFF Blanco

La implementación en ASM se ve detalladamente en la Inicialización de la VRAM.

4.4 La VRAM [ registros $2116, $2117, $2118, $2119, $2139, $213A ]

Si queremos mostrar una fuente por pantalla la única forma es pasando las fuentes de ROM/RAM a VRAM, ya que así y solo así se podrá ver en pantalla. Esto se hace mediante un “pasadizo”, los registros $2118 y $2119.
Recuerda los Bancos de los registros son $00 al $3F o $80 al $BF, ya que aquí estás escribiendo en lo que se llama PPU (Picture Processing Unit).

Estos registros son de la VRAM, al usarlos (escribir, leer) estas no escribiendo o leyendo en la Memoria principal, sino lo haces en la VRAM. Por eso a este tipo de registros (al igual que los otros 5 listados arriba) se les conoce por Registros de Hardware y precisamente a los de la VRAM se les llama Video Port Address.

La Super Nes tiene su propia RAM para video, por eso le llamamos VRAM. Es requerido para escribir datos gráficos (muy pocas veces se lee), y puede ser accesado por ciertos registros establecidos. Me refiero a la Video RAM (VRAM), que es un bloque de 64K de memoria esta dentro del controlador de video y donde las se guardan las Tiles y los Tile Map (La pantalla final que se ve).

En la VRAM usualmente se escribe en ella y no lee.

Registros $2116, $2117: VRAM Address (2 bytes en total)

Al escribir en $2116 le estamos pasando un dato a un dispositivo a parte que está dentro de la SNES pero fuera de la CPU principal (es como el puerto serie del ordenador, que cada vez que quisieras enviar un dato por él, tuvieras que escribir en una dirección de memoria concreta, esto es lo mismo). En este caso, al escribir en $2116 en cualquiera de los bancos $00 al $3F o $80 al $BF, estás escribiendo en lo que se llama PPU (Picture Processing Unit, ver terminología).

El registro $2116 indica a la PPU donde comenzamos a escribir o leer.
Si quieres decirle a la SNES que escribiras/leeras de la VRAM en la posición $4000 de esta. Deberás escribir en una dirección de memoria normal del mapa de la SNES que es $2116 y $2117, entonces al escribir cada byte de la dirección destino en VRAM debes poner en estos registros $2116= #$00 y $2117= #$40. O simplemente puedes hacer $2116 = #40000. Con esto se pone apuntando a su memoria RAM interna de la VRAM a la posición $4000, ya que se leerá o escribirá.

Ejemplo:
LDX #$2000
STX $2116

Registros $2118, $2119: VRAM Data Write (2 bytes en total)

Ahora si queremos “meter” algo en la VRAM, es decir escribir, debes meter los valores que quieras en las posiciones del $2118 y $2119. Este es el “pasadizo” de datos de la RAM a VRAM.
Si quieres meter AABB en VRAM hay que hacer $2118=$AA y $2119=$BB. Tu ya sabes, con LDA $AA, luego STA $2118, después LDA $BB, STA $2119. Este registro es incrementado automáticamente según el bit 7 del registro $2115.

Registros $2139, $213A: VRAM Data Read (2 bytes en total)

Si queremos leer de la VRAM, consultamos los registros $2139 y $213A. Este registro es incrementado automáticamente según el bit 7 del registro $2115.

4.5 Los Registros de Video

Todos los registros Externos a la CPU tienen una dirección fija en la MEMORIA, ya que así esta memoria actúa como puente entre el hardware y el código. En Memoria tenemos dirección para saber si la pantalla esta con Brillo o no, si estamos leyendo un joytick o no, etc. Y podemos setear estos registros para que por ejemplo NO se lea el joystick al empezar el juego, o esconda ciertos planos gráficos en algunos instantes del juego, etc.
Existe un lista muy completa en un archivo txt, llamado all_register.txt en mi pagina, esta escrito por un tal Yoshi que ha hecho muchos documentos Técnicos de la SNES. Aquí solo listare y explicare los fundamentales que se requieren saber. Explicaré lo que pueda ya que aún no domino el tema de los registros muy bien

En el campo Tamaño de la siguiente Tabla se muestran:
?: No se que estadísticas tiene este registro
2: El largo es de 2 byte (1 palabra o word)
d: Es requerido un Doble-byte para escribir en este registro. Es de 16 bit pero se llena con 2 STA seguidos.
w: En el Registro es posible Grabar
r: En el Registro es posible Leer

Tamaño/ Grabable Dirección Nombre(s) y Explicación de Registro (no todos)
Si el mismo Registro tiene varios nombres, se separan por / W
$2100 Screen Display
x000bbbb x: 0 = Screen on
1 = Screen off.
bbbb: Brillo o Brightness ($0-$F).

Ejemplo: si hacemos:
LDA $8F
STA $2100
estamos haciendo que este registro se carge con 8F h = 10001111 bin => x =1 y bb.=1111, es decir lo seteamos con; Screen OFF y con Brillo de 1111 bin = F hex => Full Brightness, es decir Brillo de pantalla al Máximo. ¿Fácil no? W $2101 OAM size /Tamaño de OAM (Plano de Strites se copia en OAM)
sssnnbbb s: 000 = 8x8 or 16x16.
001 = 8x8 or 32x32.
010 = 8x8 or 64x64.
011 = 16x16 or 32x32.
100 = 16x16 or 64x64.
101 = 32x32 or 64x64.
n: Name selection (upper 4k word addr).
b: Base selection (8k word seg. addr). W 2 $2102 / $2103 OAM address /Dirección de Sprite memory OAM /Registros de Sprite
aaaaaaaa r000000m a: dirección OAM.
r: Rotación prioridad de OAM.
m: Bit menos significativo. W $2104 OAM data
dddddddd d: byte a escribir en VRAM W $2105 Screen mode
abcdefff a: BG4 tile size (0=8x8, 1=16x16).
b: BG3 tile size (0=8x8, 1=16x16).
c: BG2 tile size (0=8x8, 1=16x16).
d: BG1 tile size (0=8x8, 1=16x16).
e: Highest priority for BG3 in MODE 1.
f: MODE definition. W $2106 Screen pixelation / Pixelación de Pantalla
xxxxabcd x: Pixel size (0=Smallest, $F=Largest).
a: Affect BG4.
b: Affect BG3.
c: Affect BG2.
d: Affect BG1. W $2107 BG1 VRAM location / Ubicación de BG1 (Plano0) en la VRAM
xxxx xxab x: Base address
ab: SC size
Ejemplo:
lda #$10
sta $2107 ; 10 hex = 0001 0000 => X = 000100 y AB = 00, X al revez sería 001000 = 1000. El mapa de gráficos BG1 estará en $1000 de VRAM.
....

....
......... ver documento de Yoshi ….. W $210B BG1 & BG2 Ubicación de Tiles en VRAM
aaaabbbb a: dirección de BG2 (plano 1).
b: dirección de BG1(plano 0).
Ejemplo:
lda #$01
sta $210B ;Seteamos BG1para tiles en VRAM en la dirección $1000.
Sip, se lee al revés. LDA #$01 = 0000 0001 => a = 0000 y b = 0001 => al revés es 1000. W $210C BG3 & BG4 Ubicación de Tiles en VRAM
aaaabbbb a: dirección de BG4 (plano 3).
b: dirección de BG3(plano 2). W D (16 bits de largo, se llena con 2 STA) $210D BG1 horizontal scroll / Plane 0 scroll x
mmmmmaaa aaaaaaaa a: Horizontal offset.
m: Only set with MODE 7.

Ejemplo:

LDA #$00
STA $210D ; llenamos Plane 0 scroll x (las aaaaaaaa)
STA $210D ; llenamos Plane 0 scroll x (llenamos aaa ) W D $210E BG1 vertical scroll / Plane 0 scroll y
mmmmmaaa aaaaaaaa a: Horizontal offset.
mayor menor m: Only set with MODE 7.
Ejemplo:
LDA #$00
STA $210E ; llenamos Plane 0 scroll Y (las aaaaaaaa)
STA $210E ; llenamos Plane 0 scroll Y (llenamos aaa )
....
....
......... ver documento de Yoshi …..
W $2115 Video port control / Control del Puerto de video / VRAM Adress Increment Register
i000abcd i: 0 = Se incrementa después de escribir en $2118
o leer de $2139.
1 = Se incrementa al escribir en $2119
o leer de $213A.
ab: Full graphic (ver tabla de abajo).
cd: SC increment (ver tabla de abajo).
abcd
0100 Increment by 8 for 32 times (2-bit formation).
1000 Increment by 8 for 64 times (4-bit formation).
1100 Increment by 8 for 128 times (8-bit formation).
0000 Address increments 1x1.
0001 Address increments 32x32.
0010 Address increments 64x64.
0011 Address increments 128x128.
Ej:
LDA #$80 ; 80 hex = 1000 0000 bin
STA $2115 ; Controlamos el Puerto de video diciendo que incrementaremos 1x1 cada vez que se escriba en $2118 o lea en $2139. W 2 $2116 / $2117 Video port address / VRAM Address
aaaaaaaa aaaaaaaa a: direccion para accesar a la VRAM

Ejemplo: Si quieres escribir en la posición de VRAM $4000 el valor $AABB, hago $2116=$00 y $2117=$40. (primero el byte MENOR luego el MAYOR) W 2 $2118 / $2119 Video port data
dddddddd dddddddd d: data to write to VRAM
$2119 $2118
Se incrementa según el Bit 7 el registro $2115.
Si el Bit 7 (aparece i en esta tabla, mas arriba) es:
0 y se Escribe solo en $2118, por lo que los 8-bits menores son escritos, entonces la dirección es incrementada.
0 y se Escribe $2119 y luego en $2118, entonces la dirección se incrementa.
1 y se Escribe solo en $2119, por lo que los 8-bits mayores son escritos, entonces la dirección es incrementada.
1 y se Escribe $2118 y luego en $2119, entonces la dirección se incrementa.

Ejemplo: Si quieres escribir en la posición de VRAM $4000 el valor $AABB, es decir hago $2118=$AA y $2119=$BB.
W $211A MODE7 settings
ab0000yx ab: (see table below).
y: Vertical screen flip (1=flip).
x: Horizontal screen flip (1=flip).
Si ab es:
00: Se repite la pantalla si se sale del área de pantalla.
10: Carácter 0x00 se repite se sale del área de pantalla.
11: Salir de la pantalla pone la pantalla a 1 color. W $211B COS (COSINE) rotate angle / X Expansion
Aquí va el Angulo que quieres rotar
....
....
......... ver documento de Yoshi …..
W $2121 Colour # (or pallete) selection / Registro Numero de Color
xxxxxxxx x: Dirección (color #). WD (se llenan con varios STA, del menor byte al mayor) $2122 Colour data
?aaaaavv vvvrrrrr a: Valor del color azul.
v: Valor del color verde.
r: Valor del color rojo.

Este registro es de 15 bits: 5 bit para azul, 5 para verde y 5 para rojo.
....
....
......... ver documento de Yoshi …..

W

$4200 Counter enable / Registro de Joypad
a0yx000b a: interrupción NMI/VBlank
y: Contador Vertical.
x: contador Horizontal.
b: Activa Lectura de Joypad.

Ejemplo: si hacemos al comienzo del código de un programa:
lda #$01 ; 01 hex = 00000001 bin
sta $4200 ; Activamos Lectura de JOYPAD
....
....
......... ver documento de Yoshi …..
R $4210 NMI
x000vvvv x: Disable/enable NMI.
v: Version # ($5A22 (???)) RW $4211 Video IRQ
i0000000 i: 0 = IRQ is not enabled.
1 = IRQ is enabled. RW $4212 Status register
xy00000a x: 0 = Not in VBlank state.
1 = In VBlank state.
y: 0 = Not in HBlank state.
1 = In HBlank state.
a: 0 = Joypad not ready.
1 = Joypad ready.
....
....
......... ver documento de Yoshi …..
R $4218 Joypad #1 status / Registro de Estado Botones joypad #1
abcd0000 a: A button (1=pressed).
b: X button (1=pressed).
c: Top-Left (1=pressed). [L Button]
d: Top-Rght (1=pressed). [R button] R $4219 Joypad #1 status / Registro de Estado Botones joypad #1
abcdefgh a: B button (1=pressed).
b: Y button (1=pressed).
c: Select (1=pressed).
d: Start (1=pressed).
e: Up (1=pressed).
f: Down (1=pressed).
g: Left (1=pressed).
h: Right (1=pressed).

....
....
......... ver documento de Yoshi …..

4.6 ¿Que registros específicos Inicializar?

Diré cual son los registros que se deben inicializar y su implementación en ASM.

Inicializar el Direct Page.
REP 30 ; X,Y en 16 bits
LDA #$0000 ; cargamos A con el VALOR 0x0000 (0000 hex)
TCD ; lo de A pasa al DP, es decir que la DP lo dejamos con valor 0.

Guardar las Fuentes en la RAM.
Esto se DEBE hacer aquí, por obligación y no en otra. Aquí se cargan TODAS las fuentes posibles a dibujar y deben estar en el orden que se muestra en Charset, es un orden establecido por el compilador.
Las fuentes de color azul son las que se usaron en la creación de la ROM y representan la letra en cuestión, en cambio, las de color roja hay que hacerlas si quieres usarlas (por eso están con el valor $00 que es símbolo de nulo o vació, es decir que si muestras un @ se verá solo en fondo ya que la letra será transparente) con el programa SNES_FONT_MAKER V1.0 que hice yo mismo.

LDA #CHARSET
STA $0A

CHARSET
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'@'
DC.B $00,$3C,$66,$7E,$66,$66,$66,$00 ;'A'
DC.B $00,$7C,$66,$7C,$66,$66,$7C,$00 ;'B'
DC.B $00,$3C,$66,$60,$60,$66,$3C,$00 ;'C'
DC.B $00,$78,$6C,$66,$66,$6C,$78,$00 ;'D'
DC.B $00,$7E,$60,$78,$60,$60,$7E,$00 ;'E'
DC.B $00,$7E,$60,$78,$60,$60,$60,$00 ;'F'
DC.B $00,$3C,$66,$60,$6E,$66,$3C,$00 ;'G'
DC.B $00,$66,$66,$7E,$66,$66,$66,$00 ;'H'
DC.B $00,$3C,$18,$18,$18,$18,$3C,$00 ;'I'
DC.B $00,$1E,$0C,$0C,$0C,$6C,$38,$00 ;'J'
DC.B $00,$6C,$78,$70,$78,$6C,$66,$00 ;'K'
DC.B $00,$60,$60,$60,$60,$60,$7E,$00 ;'L'
DC.B $00,$63,$77,$7F,$6B,$63,$63,$00 ;'M'
DC.B $00,$66,$76,$7E,$7E,$6E,$66,$00 ;'N'
DC.B $00,$3C,$66,$66,$66,$66,$3C,$00 ;'O'
DC.B $00,$7C,$66,$66,$7C,$60,$60,$00 ;'P'
DC.B $00,$3C,$66,$66,$66,$3C,$0E,$00 ;'Q'
DC.B $00,$7C,$66,$66,$7C,$6C,$66,$00 ;'R'
DC.B $00,$3E,$60,$3C,$06,$66,$3C,$00 ;'S'
DC.B $00,$7E,$18,$18,$18,$18,$18,$00 ;'T'
DC.B $00,$66,$66,$66,$66,$66,$3C,$00 ;'U'
DC.B $00,$66,$66,$66,$66,$3C,$18,$00 ;'V'
DC.B $00,$63,$63,$6B,$7F,$77,$63,$00 ;'W'
DC.B $00,$66,$3C,$18,$3C,$66,$66,$00 ;'X'
DC.B $00,$66,$66,$3C,$18,$18,$18,$00 ;'Y'
DC.B $00,$7E,$0C,$18,$30,$60,$7E,$00 ;'Z'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'['
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'\'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;']'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'^'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'_'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;' ' espacio
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'!'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'"'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'#'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'$'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'%'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'&'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'''
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'('
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;')'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'*'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'+'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;','
DC.B $F0,$E0,$E0,$C0,$C0,$E0,$F0,$00 ;'-'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'.'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'/'
DC.B $00,$3C,$66,$6E,$76,$66,$3C,$00 ;'0'
DC.B $00,$18,$38,$18,$18,$18,$7E,$00 ;'1'
DC.B $00,$7C,$06,$0C,$30,$60,$7E,$00 ;'2'
DC.B $00,$7E,$06,$1C,$06,$66,$3C,$00 ;'3'
DC.B $00,$0E,$1E,$36,$7F,$06,$06,$00 ;'4'
DC.B $00,$7E,$60,$7C,$06,$66,$3C,$00 ;'5'
DC.B $00,$3E,$60,$7C,$66,$66,$3C,$00 ;'6'
DC.B $00,$7E,$06,$0C,$0C,$0C,$0C,$00 ;'7'
DC.B $00,$3C,$66,$3C,$66,$66,$3C,$00 ;'8'
DC.B $00,$3C,$66,$3E,$06,$66,$3C,$00 ;'9'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;':'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;';'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'<'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'='
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'>'
DC.B $00,$00,$00,$00,$00,$00,$00,$00 ;'?'

Ahora tenemos disponibles TODOS los caracteres para ocuparlos después (son 64 caracteres).

NOTA: si compilas con X86 el comando es .DBC así:

.DCB $00,$00,$00,$00,$00,$00,$00,$00 ;'<'

Lo que se hace aquí es cargar en A el offset (el byte bajo) de la dirección de memoria donde empiezan los caracteres y la guarda en $7E:000A. En $7E:000B se guarda el byte alto y en $7E:000C el byte del banco, que SÓLO hace falta si se direcciona (en la parte del programa principal) esa zona de memoria donde están las letras de la forma LDA [$0A],Y, y no hace falta el byte de banco si se direcciona así LDX ($0A). Luego veremos que se hace de la forma LDX ($0A). Como ves, pasamos las fuentes a RAM (solo decía STA $0A y si no se indica banco entonces se pasa al banco 7E de la RAM).

Setear el registro Screen display, dirección en la memoria: $2100
LDA $8F
STA $2100
Estamos haciendo que este registro se cargue con 8F hex = 10001111 bin y recuerda el formato: x000bbbb en la tabla de registros. Entonces aquí tenemos x =1 y bb.=1111, es decir lo seteamos con Screen OFF y con Brillo de 1111 bin = F hex => Full Brightness, es decir Brillo de pantalla al Máximo.

Setear el registro OAM size, $2101
LDA #$00
STA $2101

Setear el registros de Sprite, $2102, $2103
LDA #$00
STA $2102
STA $2103 ;no es necesario hacer otra vez LDA #$00

Setear el registro Screen Mode, $2105
LDA #$00
STA $2105

Setear el registro Screen pixelation, $2106
LDA #$00
STA $2106

Setear el registro Ubicación de BG1 (Plano 0) en VRAM, $2107
LDA #$00
STA $2107

Setear el registro Ubicación de BG2 (Plano 1) en VRAM, $2108
LDA #$00
STA $2108

Setear el registro Ubicación de BG3 (Plano 2) en VRAM, $2109
LDA #$00
STA $2109

Setear el registro Ubicación de BG4 (Plano 3) en VRAM, $210A
LDA #$00
STA $210A

Setear el registro Ubicación de tiles en BG1 y BG2 (Plano 0 + 1) en VRAM, $210B
LDA #$00
STA $210B

Setear el registro Ubicación de tiles en BG3 y BG4 (Plano 2 + 3) en VRAM, $210C
LDA #$00
STA $210C

Setear el registro BG1 horizontal scroll (Plano 0, Scroll X), $210D
LDA #$00
STA $210D ;es de 16 bits de largo, primero cargamos de ceros la parte chica
STA $210D ;luego la mayor, OJO que no se puede hacer LDA #$0000 y luego STA, ya que se debe llenar en “tiradas” de 8 bits.

Setear el registro BG1 vertical scroll (Plano 0, Scroll Y), $210E
LDA #$00
STA $210E
STA $210E

Setear el registro BG2 horizontal scroll (Plano 1, Scroll Y), $210F
LDA #$00
STA $210F
STA $210F

Setear el registro BG2 vertical scroll (Plano 1, Scroll Y), $2110
LDA #$00
STA $2110
STA $2110

Setear el registro BG3 horizontal scroll (Plano 2, Scroll Y), $2111
LDA #$00
STA $2111
STA $2111

Setear el registro BG3 vertical scroll (Plano 2, Scroll Y), $2112
LDA #$00
STA $2112
STA $2112

Setear el registro BG4 horizontal scroll (Plano 3, Scroll Y), $2113
LDA #$00
STA $2113
STA $2113

Setear el registro BG4 vertical scroll (Plano 3, Scroll Y), $2114
LDA #$00
STA $2114
STA $2114

Setear el registro VRAM address increment, $2115
LDA #$80 ; 80 hex = 1000 0000 bin -> ver formato en tabla de registros.
STA $2115 ; La inicialización al Controlamos el Puerto de video diciendo que incrementaremos 1x1 cada vez que se escriba en $2118 o lea en $2139.

Setear el registro VRAM Address, $2116, $2117
LDA #$00
STA $2116 ; Zona baja de la dirección de VRAM
STA $2117 ; Zona alta

Setear el registro MODE7 settings, $211A
LDA #$00
STA $211A

Setear el registro MODE7 matrix parametros A,B,C,D, $211B,$211C,$211D,$211E.
LDA #$01 ; Parámetro A: Coseno parte X (ver libros de Matemática, dentro de sección Trigonometría para que sepan que es Seno, Coseno, etc…)
STA $211B ; Registro de COS (COSENO) rotación de ángulo en Modo 7.
LDA #$00
STA $211B ; necesita que se guarde un 0000 0000 0000 0001 dentro del registro ya que por Regla Matemática Coseno de 1 es 0 (COS (1) =0)

LDA #$00 ; Parámetro B: SENO parte X
STA $211C
STA $211C

LDA #$00 ; Parámetro C: SENO parte Y
STA $211D
STA $211D

LDA #$01 ; Parámetro D: COSENO parte Y
STA $211E
LDA #$00
STA $211E

Setear el registro MODE7 Posición Centrada X e Y, $211F, $2120
LDA #$00
STA $211F
STA $211F
STA $2120
STA $2120

Setear el registro Numero de Color, $2121
LDA #$00
STA $2121

Setear el registro Window mask setting BG1 y BG2, $2123
LDA #$00
STA $2123

Setear el registro Window mask setting BG3 y BG4, $2124
LDA #$00
STA $2124

Setear el registro Window mask setting Objeto y Color, $2125
LDA #$00
STA $2125

Setear el registro Window 1 Posición Izquierda, $2126
LDA #$00
STA $2126

Setear el registro Window 1 Posición Derecha, $2127
LDA #$00
STA $2127

Setear el registro Window 2 Posición Izquierda, $2128
LDA #$00
STA $2128

Setear el registro Window 2 Posición Derecha, $2129
LDA #$00
STA $2129

Setear el registro Logica de Window de BG1, BG2, BG3, BG4, $212A
LDA #$00
STA $212A

Setear el registro Logica de Mask Objeto Windows y color Window, $212B
LDA #$00
STA $212B

Setear el registro Main screen designation, $212C
LDA #$01
STA $212C ; el formato es 000abcde donde e: 1 o 0; y maneja el GB1 activado/desactivado. En este caso es BG1 activado.

Setear el registro Sub-screen designation, $212D
LDA #$00
STA $212D

Setear el registro Window mask main screen designation, $212E
LDA #$00
STA $212E

Setear el registro Window mask sub screen designation, $212F
LDA #$00
STA $212F

Setear el registro Fixed color addition or screen addition, $2130
LDA #$30 ; 30 hex = 0011 0000 bin le damos Fixed Color a Sub Screen y activamos
STA $212F ; suma y resta para fixed color.

Setear el registro Addition/subtraction for screens, BGs, & OBJs, $2131
LDA #$00
STA $2131

Setear el registro Fixed colour data para addition/subtraction, $2132
LDA #$E0 ; E0 hex = 11100000 bin
STA $2132 ; esto quiere decir que se permite un cambio de color Azul, Verde o Rojo.
; ver tabla de registros completa de Yoshi para mas detalles.

Setear el registro Screen mode/video select, $2133
LDA #$00
STA $2133

Setear el registro Counter enable / Enable V-blan, Interrupt, JoyPad, $4200
LDA #$00
STA $4200

Setear el registro Programmable I/O port (out-port), $4201
LDA #$FF ; FF hex = 11111111 bin
STA $2131 ; es decir que se activa el puerto de I/O (Joypad, pantalla) para se programado.

Setear el registro Multiplicand 'A', $4202
Este registro permite entregar el primer factor (A) de una multiplicación A*B=C donde A:8 bit, B.8 bit y C: 16bit.
LDA #$00
STA $4202 ;si quieres multiplicar A * B, entonces A debe estar en
$4202 y B en $4203, el resultado se puede leer de $4216/$4217 (el resultado es de 16 bits).

Setear el registro Multiplier 'B', $4203
Este registro permite entregar el segundo factor (B) de una multiplicación A*B=C.
LDA #$00
STA $4203

Setear el registro Dividend ‘C’, $4204
Este registro permite entregar el dividendo (C) de una división C*D=E, donde C: 16 bit, D: bit y E: 16 bit.

LDA #$00
STA $4204 ;si quieres dividir X/Y, X debe estar en $4204/$4205, e Y en
;$4206, el resultado puede ser leído desde $2114 y el resto
LDA #$00 ;se lee de $4216/4217.
STA $4205

Setear el registro Divisor 'D', $4205, $4206
LDA #$00
STA $4206

Setear el registro Horizontal Count Timer / Video horizontal IRQ, $4207
LDA #$00
STA $4207

Setear el registro Horizontal Count Timer MSB (bit mas significante) / Video horizontal IRQ MSB, $4208
LDA #$00
STA $4208

Setear el registro Vertical Count Timer / Video vertical IRQ, $4209
LDA #$00
STA $4209

Setear el registro Vertical Count Timer MSB (bit mas significante) / Video vertical IRQ MSB, $420A
LDA #$00
STA $420A

Setear el registro DMA Enable (bits 0-7), $420B
LDA #$00
STA $420B

Setear el registro Horizontal DMA (HDMA) Enable (bits 0-7), $420C
LDA #$00
STA $420C

Setear el registro Access cycle designation / Cycle speed (rom tipo slow/fast), $420D
LDA #$00
STA $420D

5. Inicialización de la VRAM

La VRAM se inicializa gracias a los Registros $2105, $2107, $210B, $212C, $2121, $2122.

Aquí tenemos los siguientes pasos:

Ubicación del Mapa de Gráficos BG1 (también conocido como Screen map data) en VRAM. Recuerda que se usa la dirección de memoria $2107 para indicarle a la SNES la dirección.

REP #$30 ; X,Y,A EN MODO 16 BITS
; 30 hex = 110000 = bit 5( y 6 en 1,
SEP #$20 ; ACUMULADOR EN MODO 8 BITS

LDA #$10
STA $2107 ;EL MAPA DE GRÁFICOS BG1 ESTARÁ EN $1000 DE VRAM. RECUERDA QUE SE LEE AL REVÉS => 10 HEX = 00010000 BIN Y SEGÚN EL FORMATO (VER LISTA DE REGISTROS DE ARRIBA) X = 000100 AL REVÉS SERIA 001000 = 1000.

Ubicación de Tiles en el Mapa de Gráficos BG1 en VRAM. Recuerda que se usa la dirección de memoria $210B para indicarle a la SNES la dirección.

lda #$02
sta $210B ; Las tiles del Plano 0 estarán en dirección $2000 de VRAM, recuerda que se lee al revés, el formato es aaaa bbbb y 02 hex = 0000 0002 bin => b = 0002 al revés 2000.

Setear el registro Screen Mode, usar dirección $2105.

LDA #$00
STA $2105 ; Ya esta seteado, pero se hace igual otra vez. Al estar en 0000 0000 todos los Tiles de los 4 BG se setean en modo 8x8 (ver documento de yoshi para mas detalles).

Setear registro Main screen designation con el registro $212C.

LDA #$01
STA $212C ; Ya esta seteado. El formato es 000abcde donde e: 1 o 0; y maneja el GB1 activado o desactivado. En este caso es BG1 activado. (ver documento de yoshi para mas detalles).

Inicialización de Colores con el registro $2121 y $2122.

Los colores de Fondo y Tiles se manejan a través del registro $2121 y $2122.

$2121 debe estar en 0 siempre.
$2122 maneja el color de las fuentes y fondo

Se inserta con LDA y luego con STA. Como es registro es de 16 bits (15 se ocupan) se inserta primero los 8 byte MENORES y luego los 7 MAYORES restantes. Así si queremos poner el color AZUL Brillante ponemos primero el #$00 y luego el #$7C.

Primero dejaremos el registro $2121 (Registro Número de Selección de Color) en 0.
LDA #$00
STA $2121

Ahora veamos el color del Fondo, así que si hacemos un:
LDA #$FF
STA $2122
LDA #$FF
STA $2122

Aquí estamos dejando el fondo de color Blanco. Si hubiésemos puesto en ves de #$FF y #$FF, los valores $00 y $00 nos da un fondo Negro. Y si hacemos #$00 y #$7C nos da Azul Brillante.

Luego si queremos mostrar las Fuentes Rojas de nuestro texto que luego pondremos (mas abajo explico este siguiente paso):

LDA #$1F
STA $2122
LDA #$00
STA $2122

Así deberíamos mostrar el texto que queremos con ASM.

Activar lectura de JoyPad

LDA #$01
STA $4200 ; El formato es a0yx000b y si b = 1
; => Se activa Lectura de Joypad.

6. Programa principal

El programa principal es la parte que más interviene el programador de asm, ya que toda la lógica de la ROM. Para este ejemplo lo dividiré en sucesiones con letras a,b,etc...

Pasar las Fuentes de RAM a VRAM

Ya tenemos todo el set de fuentes en RAM, ahora hay que pasarlas a VRAM para que se vean en pantalla.
Para esto se utilizan los registros $2116, $2117, $2118 y $2119.
Aquí hay que copiar de la RAM a la VRAM todas las fonts almacenadas alli.

Pasos:
Asignar la Dirección de VRAM utilizando el registro $2116, $2117 donde copiaremos la lista de fuentes posibles a utilizar.

LDX #$2000 ; usaremos la dirección $2000 de VRAM por lo que cargamos X con el VALOR 0x2000
STX $2116 ; #$2000 es de 16 bits por lo que se guarda #$00 en $2116 y automáticamente en $2117 el #$20, formando #$2000.
LDY #$0000
COPYCHAR LDA ($0A),Y

Cargamos en A el Offset que guardamos en $0A (sección Registros de Videos, punto 2), que es donde empieza la lista de fuentes. El (offset), Y es que sacamos el contenido que hay en $0A + Y (direccionamiento indexado Y, ¿recuerdas?), e Y lo inicializamos en 0 así sacamos primero lo que hay en $0A + 0 = $0A, luego podemos hacer un incremento Y para sacar lo que hay en $0A + 1 = $0B, y así sacando lo que hay dentro de cada dirección a partir de $0A (no es infinito, luego verás que hay un tope). Por eso a $0A se le conoce como “puntero” ya que es parecido a los punteros del lenguaje C.

Almacenar cada fuente por medio de registros $2118 y $2119.

Las Direcciones $2118 y $2119 son el “pasadizo” que une la RAM con VRAM, así podemos pasar datos a través de ellos. Si almacenas en $2118 o $2119 estas almacenando en VRAM.

STA $2118

guardamos en VRAM lo que esta guardado en A, es decir el offset de donde comienzan las fuentes, parte el offset de la letra @.

STZ $2119

Siempre cero en este registro para no hacer volteo H/V (esto lo dice Magno, lo consultare..¿?).
Por cada byte leído desde RAM se copia ese mismo byte en VRAM (STA $2118) más un byte a cero (STZ $2119), es decir que en VRAM tenemos el doble de bytes que en RAM para las mismas fuentes.

Hacer ciclo (también conocido como “bucle”) que copie todas las fuentes

INY ; incremento Y
CPY #$0200 ; comparo si Y = 200
BNE COPYCHAR ; si es NO es así, salta al Label COPYCHAR , es decir sigue copiando las demás fuentes. Copiamos 200 bytes (0x200) de RAM y pasan a ser 400 Bytes en VRAM y cada fuente ocupa 8 bytes de memoria, es decir que en VRAM sacamos 0x200/0x8 = 0x40 = 64 decimal. Es decir que en 200 bytes tenemos 64 fuentes (es decir todo el pack de caracteres) copiadas a VRAM. En VRAM se guarda después de cada fuente un espacio de 8 bytes con valor 0, por eso ocupamos 400 bytes.

NOTA: cuando tienes un CPX/CPY y luego un BNE, entonces Salta si no es igual la comparación, pero si tienes un AND y luego un BNE Salta si es igual la comparación. Ojo que se invierten.

Pasar la Pantalla ASCII a VRAM usando registros $2116, $2117, $2118 y $2119.
Si no pones esta parte, entonces solo se verá el fondo de color y ninguna letra. En esta parte debemos guardar la pantalla en VRAM, para eso debemos definirla, así que al final del código pon esto (Si te fijas bien, el texto esta en ASCII puro):

TEXTPAN
DC.B " "
DC.B " "
DC.B " "
DC.B " "
DC.B " "
DC.B " DARK-N "
DC.B " "
DC.B " "
DC.B " "
DC.B " "
DC.B " "
DC.B " PRESENTA "
DC.B " "
DC.B " ESTE SIMPLE "
DC.B " CODIGO "
DC.B " "
DC.B " HOLA "
DC.B " "
DC.B " MUNDO "
DC.B " "
DC.B " "
DC.B " PRESIONA BOTON START "
DC.B " "
DC.B " "
DC.B " "
DC.B " 2004 "
DC.B " "
DC.B " "
DC.B " "
DC.B " "

Luego seguimos con el código:

LDX #$1000 ; Asignamos una nueva dirección de VRAM
STX $2116 ; esta vez la $1000, se hace como siempre por
; el registro $2116
LDX #$0000 ; x = valor 0000
TEXTINFO LDA TEXTPAN,X ; Obtenemos la datos que conforman la
; pantalla que esta en ASCII
AND #$3F ; 3F = 63 dec = 0-63 = 64 caracteres

STA $2118 ; como siempre por este pasadizo tiramos
STZ $2119 ; datos a la VRAM.
; dejamos en cero el registro $2119
; (NO H/V FLIPPING)
INX
CPX #$0400 ; Trasferimos la pantalla completa
; $20*$20=$0400 (1024 BYTES)
; comparo si X = 400
BNE TEXTINFO ; si es NO es así, salta al Label TEXTINFO, es decir sigue copiando las demás datos de la pantalla.

NOTA: Los Labels (como TEXTINFO) debe in pegados a la izquierda de la pantalla.

Leer Joypad y botones con registro $4210 y $4219.

LDA #$0F
STA $2100 ; screen enabled, brillo al máximo
CLI ; CLEAR INTERRUPT BIT (lo dejamos en 0)
RUNAROUND LDA $4210 ; chequeamos el VERTICAL BLANK
AND #$80 ; 80 hex = 10000000 bin
BEQ RUNAROUND ; si son iguales entonces aun no se ejecutó
; el VBlanck, entonces salta de nuevo atrás.
; solo se ejecutara si pasa un refresco de
; pantalla.

Ahora para leer el Joypad, así que les muestro un ejemplo. Preguntaremos si esta presionado el Botón Start, si es así, que baya a una subrutina llamada RESET.
LDA $4219 ; se carga los que hay aquí, pongamos que A sale cargado
; el valor 1000 0000 , el botón B presionado
AND #$10 ; compara 10 hex = 0001 0000 bin con lo de A
; 10000000
; and 00010000 no son iguales
BNE RESET ; salta SI SON IGUALES (el AND funciona al revés que el CPX/CPY)
; por lo que no ejecuta y sigue lo que sigue debajo de BNE.

Siguiendo con nuestro programa:

JOYPAD LDA $4212 ; registro de dispositivo Joypad
AND #$01 ; se esta leyendo el Joypad, si esta activado
; $4212 = xxxxxxx1 y si no $4212 = xxxxxxx0
BNE JOYPAD ; si no esta activado que vuelva e intente de
; nuevo, si esta activo que siga.
LDA $4219 ; Leemos registro de botones
AND #$10 ; 10 hex = 00010000 bin = boton start
BNE RESET ; Presionado "START"? salte a RESET
JMP RUNAROUND ; sino que vuelva en un loop.

Oscurecer la Pantalla
Ahora la pantalla se oscurecerá poco a poco. A cada refresco de pantalla de bajara la luz.

RESET SEP #$30 ; X,Y,A en modo de 16 bit
LDY #$0F ; Y = F hex
LUS1 LDX #$06 ; X = 6 hex => es el tiempo que demora en un brillo
; antes de cambiar a otro, se le quita 1 a cada vuelta.
DEY ; y = y – 1 = E
STY $2100 ; $2100 = E => $2100 brillo de pantalla, 0F es máximo
; y 0E un poco menos, hasta llegar a 00, oscuro.

WAIT LDA $4210 ;
AND #$80
BEQ WAIT ; que pase un refresco de pantalla y luego siga.
; tendrá que ir a Wait en Loop hasta que suceda.

DEX ; X = X – 1 (primero valdrá 5, luego 4, luego 3,…0)
CPX #$00 ; X = 0?
BNE WAIT ; si no equivale (x=0) que vuelva a WAIT. Esto es
; para hacer tiempo en cada brillo.
CPY #$00 ; X = 0? (Y parte con F, luego E, ...0)
BNE LUS1 ; si no es así que vuelva a LUS1. Cuando se espero lo
; suficiente que se baya a LUS1

REP #$10 ; 10 hex = 10000 bin = bit 5 (X) índices en modo 16 bit
LDX #$0FFF ; cargamos un valor de 16 bits en X: 0FFF
DARK LDA $4210 ;
AND #$80
BEQ DARK ; esperamos un refresco y seguimos

DEX ; X = X – 1 (partió con 0FFF, luego 0FFE,....,0000)
CPX #$0000 ; X = 0000?
BNE DARK ; si no es así que baya a DARK y haga otro refresco.

Dejar el Program Bank vacío

SEP #$30 ; X, Y, A en modo de 8 bits
LDA #$00 ; A = 00
PHA ; Metemos #$00 al STACK
PLB ; Sacamos #$00 del stack y lo metemos en el Banco
; de Programa ($00: ZZZZ)
JMP.l START ; salto largo a $008000

7. Programa Completo.

7.1 Fuente .asm para ensamblador SNESASM

NOTA: No recomiendo usar este fuente ya que corre solo con SNESASM y este compilador es muy básico.

font equ $0A

START sei
phk
plb

clc
xce

;==========================================================================
; INITIALIZACION DE REGISTROS
;==========================================================================
;
rep #$30
lda #$0000
tcd
lda #charset
sta font
SEP #$30 ; X,Y,A are 8 bit numbers
LDA #$8F ; screen off, full brightness
STA $2100 ; brightness + screen enable register
LDA #$00 ;
STA $2101 ; Sprite register (size + address in VRAM)
LDA #$00
STA $2102 ; Sprite registers (address of sprite memory [OAM])
STA $2103 ; "" ""
LDA #$00 ; Mode 0
STA $2105 ; Graphic mode register
LDA #$00 ; no planes, no mosaic
STA $2106 ; Mosaic register
LDA #$00 ;
STA $2107 ; Plane 0 map VRAM location
LDA #$00
STA $2108 ; Plane 1 map VRAM location
LDA #$00
STA $2109 ; Plane 2 map VRAM location
LDA #$00
STA $210A ; Plane 3 map VRAM location
LDA #$00
STA $210B ; Plane 0+1 Tile data location
LDA #$00
STA $210C ; Plane 2+3 Tile data location
LDA #$00
STA $210D ; Plane 0 scroll x (first 8 bits)
STA $210D ; Plane 0 scroll x (last 3 bits) #$0 - #$07ff
STA $210E ; Plane 0 scroll y (first 8 bits)
STA $210E ; Plane 0 scroll y (last 3 bits) #$0 - #$07ff
STA $210F ; Plane 1 scroll x (first 8 bits)
STA $210F ; Plane 1 scroll x (last 3 bits) #$0 - #$07ff
STA $2110 ; Plane 1 scroll y (first 8 bits)
STA $2110 ; Plane 1 scroll y (last 3 bits) #$0 - #$07ff
STA $2111 ; Plane 2 scroll x (first 8 bits)
STA $2111 ; Plane 2 scroll x (last 3 bits) #$0 - #$07ff
STA $2112 ; Plane 2 scroll y (first 8 bits)
STA $2112 ; Plane 2 scroll y (last 3 bits) #$0 - #$07ff
STA $2113 ; Plane 3 scroll x (first 8 bits)
STA $2113 ; Plane 3 scroll x (last 3 bits) #$0 - #$07ff
STA $2114 ; Plane 3 scroll y (first 8 bits)
STA $2114 ; Plane 3 scroll y (last 3 bits) #$0 - #$07ff
LDA #$80 ; increase VRAM address after writing to $2119
STA $2115 ; VRAM address increment register
LDA #$00
STA $2116 ; VRAM address low
STA $2117 ; VRAM address high
STA $211A ; Initial Mode 7 setting register
STA $211B ; Mode 7 matrix parameter A register (low)
LDA #$01
STA $211B ; Mode 7 matrix parameter A register (high)
LDA #$00
STA $211C ; Mode 7 matrix parameter B register (low)
STA $211C ; Mode 7 matrix parameter B register (high)
STA $211D ; Mode 7 matrix parameter C register (low)
STA $211D ; Mode 7 matrix parameter C register (high)
STA $211E ; Mode 7 matrix parameter D register (low)
LDA #$01
STA $211E ; Mode 7 matrix parameter D register (high)
LDA #$00
STA $211F ; Mode 7 center position X register (low)
STA $211F ; Mode 7 center position X register (high)
STA $2120 ; Mode 7 center position Y register (low)
STA $2120 ; Mode 7 center position Y register (high)
STA $2121 ; Color number register ($0-ff)
STA $2123 ; BG1 & BG2 Window mask setting register
STA $2124 ; BG3 & BG4 Window mask setting register
STA $2125 ; OBJ & Color Window mask setting register
STA $2126 ; Window 1 left position register
STA $2127 ; Window 2 left position register
STA $2128 ; Window 3 left position register
STA $2129 ; Window 4 left position register
STA $212A ; BG1, BG2, BG3, BG4 Window Logic register
STA $212B ; OBJ, Color Window Logic Register (or,and,xor,xnor)
LDA #$01
STA $212C ; Main Screen designation (planes, sprites enable)
LDA #$00
STA $212D ; Sub Screen designation
LDA #$00
STA $212E ; Window mask for Main Screen
STA $212F ; Window mask for Sub Screen
LDA #$30
STA $2130 ; Color addition & screen addition init setting
LDA #$00
STA $2131 ; Add/Sub sub designation for screen, sprite, color
LDA #$E0
STA $2132 ; color data for addition/subtraction
LDA #$00
STA $2133 ; Screen setting (interlace x,y/enable SFX data)
LDA #$00
STA $4200 ; Enable V-blank, interrupt, Joypad register
LDA #$FF
STA $4201 ; Programmable I/O port
LDA #$00
STA $4202 ; Multiplicand A
STA $4203 ; Multiplier B
STA $4204 ; Multiplier C
STA $4205 ; Multiplicand C
STA $4206 ; Divisor B
STA $4207 ; Horizontal Count Timer
STA $4208 ; Horizontal Count Timer MSB (most significant bit)
STA $4209 ; Vertical Count Timer
STA $420A ; Vertical Count Timer MSB
STA $420B ; General DMA enable (bits 0-7)
STA $420C ; Horizontal DMA (HDMA) enable (bits 0-7)
STA $420D ; Access cycle designation (slow/fast rom)
;===========================================================================
; I. DE VRAM
;===========================================================================
rep #$30
sep #$20
lda #$10
sta $2107
lda #$02
sta $210b
lda #$00
sta $2105
lda #$01
sta $212c

lda #$00
sta $2121

lda #$FF ; fondo blanco
sta $2122 ;
lda #$FF ;
sta $2122 ;
lda #$1F ; letras rojas
sta $2122 ;
lda #$00
sta $2122 ;
lda #$01
sta $4200 ; ENABLE JOYPAD READ (bit one)
;==========================================================================
; MOVIENDO GRAFICAS A VRAM
;==========================================================================
ldx #$2000 ;fuentes de ram a VRAM
stx $2116
ldy #$0000
copychar lda (font),y
sta $2118
stz $2119
iny
cpy #$0200
bne copychar

ldx #$1000 ;texto en ASCII a VRAM
stx $2116
ldx #$0000
textinfo lda TEXTPAN,x
and #$3f

sta $2118
stz $2119
inx
cpx #$0400

bne textinfo

lda #$0f
sta $2100
cli
runaround lda $4210
and #$80
beq runaround

joypad lda $4212 ; lectura de joypad
and #$01
bne joypad
lda $4219 ; lectura de boton start
and #$10
bne reset
jmp runaround

reset sep #$30 ; oscurecimiento
ldy #$0f
lus1 ldx #$06
dey
sty $2100
wait lda $4210
and #$80
beq wait
dex
cpx #$00
bne wait
cpy #$00
bne lus1
rep #$10
ldx #$0fff
dark lda $4210
and #$80
beq dark
dex
cpx #$0000
bne dark
sep #$30
lda #$00
pha
plb

jmp.l START ;salto largo a $008000
;============================================================================
; FUENTES
;============================================================================
charset
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ;'@'
dc.b $00,$3C,$66,$7E,$66,$66,$66,$00 ;'A'
dc.b $00,$7C,$66,$7C,$66,$66,$7C,$00 ;'B'
dc.b $00,$3C,$66,$60,$60,$66,$3C,$00 ;'C'
dc.b $00,$78,$6C,$66,$66,$6C,$78,$00 ;'D'
dc.b $00,$7E,$60,$78,$60,$60,$7E,$00 ;'E'
dc.b $00,$7E,$60,$78,$60,$60,$60,$00 ;'F'
dc.b $00,$3C,$66,$60,$6E,$66,$3C,$00 ;'G'
dc.b $00,$66,$66,$7E,$66,$66,$66,$00 ;'H'
dc.b $00,$3C,$18,$18,$18,$18,$3C,$00 ;'I'
dc.b $00,$1E,$0C,$0C,$0C,$6C,$38,$00 ;'J'
dc.b $00,$6C,$78,$70,$78,$6C,$66,$00 ;'K'
dc.b $00,$60,$60,$60,$60,$60,$7E,$00 ;'L'
dc.b $00,$63,$77,$7F,$6B,$63,$63,$00 ;'M'
dc.b $00,$66,$76,$7E,$7E,$6E,$66,$00 ;'N'
dc.b $00,$3C,$66,$66,$66,$66,$3C,$00 ;'O'
dc.b $00,$7C,$66,$66,$7C,$60,$60,$00 ;'P'
dc.b $00,$3C,$66,$66,$66,$3C,$0E,$00 ;'Q'
dc.b $00,$7C,$66,$66,$7C,$6C,$66,$00 ;'R'
dc.b $00,$3E,$60,$3C,$06,$66,$3C,$00 ;'S'
dc.b $00,$7E,$18,$18,$18,$18,$18,$00 ;'T'
dc.b $00,$66,$66,$66,$66,$66,$3C,$00 ;'U'
dc.b $00,$66,$66,$66,$66,$3C,$18,$00 ;'V'
dc.b $00,$63,$63,$6B,$7F,$77,$63,$00 ;'W'
dc.b $00,$66,$3C,$18,$3C,$66,$66,$00 ;'X'
dc.b $00,$66,$66,$3C,$18,$18,$18,$00 ;'Y'
dc.b $00,$7E,$0C,$18,$30,$60,$7E,$00 ;'Z'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '['
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '\'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; ']'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '^'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '_'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ;' ' espacio
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '!'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '"'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '#'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '$'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '%'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '&'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '''
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '('
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; ')'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '*'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '+'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; ','
dc.b $00,$00,$00,$3c,$3C,$00,$00,$00 ;'-'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '.'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '/'
dc.b $00,$3C,$66,$6E,$76,$66,$3C,$00 ;'0'
dc.b $00,$18,$38,$18,$18,$18,$7E,$00 ;'1'
dc.b $00,$7C,$06,$0C,$30,$60,$7E,$00 ;'2'
dc.b $00,$7E,$06,$1C,$06,$66,$3C,$00 ;'3'
dc.b $00,$0E,$1E,$36,$7F,$06,$06,$00 ;'4'
dc.b $00,$7E,$60,$7C,$06,$66,$3C,$00 ;'5'
dc.b $00,$3E,$60,$7C,$66,$66,$3C,$00 ;'6'
dc.b $00,$7E,$06,$0C,$0C,$0C,$0C,$00 ;'7'
dc.b $00,$3C,$66,$3C,$66,$66,$3C,$00 ;'8'
dc.b $00,$3C,$66,$3E,$06,$66,$3C,$00 ;'9'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; ':'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; ';'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '<'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '='
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '>'
dc.b $00,$00,$00,$00,$00,$00,$00,$00 ; '?'

;============================================================================
; PANTALLA EN ASCII
;============================================================================

; 12345678901234567890123456789012 => 32
TEXTPAN
dc.b " "
dc.b " "
dc.b " "
dc.b " "
dc.b " "
dc.b " DARK-N "
dc.b " "
dc.b " "
dc.b " "
dc.b " "
dc.b " "
dc.b " PRESENTA "
dc.b " "
dc.b " ESTE SIMPLE "
dc.b " CODIGO "
dc.b " "
dc.b " HOLA "
dc.b " "
dc.b " MUNDO "
dc.b " "
dc.B " "
dc.b " PRESIONA BOTON START "
dc.b " "
dc.b " "
dc.b " "
dc.b " 2004 "
dc.b " "
dc.b " "
dc.b " "
dc.b " "

7.2 Fuente .asm para ensamblador X86

NOTA: Recomendado desde aquí en adelante el uso de compilador x86. Es el más completo y más profesional que hay.

.org $808000
.hirom off
.mem 16
.index 16
.detect on
.optimize off

font equ $0A

START sei
phk
plb

clc
xce

;==========================================================================
; INITIALIZACION DE REGISTROS
;==========================================================================
;
rep #$30
lda #$0000
tcd
lda #charset
sta font
SEP #$30 ; X,Y,A are 8 bit numbers
LDA #$8F ; screen off, full brightness
STA $2100 ; brightness + screen enable register
LDA #$00 ;
STA $2101 ; Sprite register (size + address in VRAM)
LDA #$00
STA $2102 ; Sprite registers (address of sprite memory [OAM])
STA $2103 ; "" ""
LDA #$00 ; Mode 0
STA $2105 ; Graphic mode register
LDA #$00 ; no planes, no mosaic
STA $2106 ; Mosaic register
LDA #$00 ;
STA $2107 ; Plane 0 map VRAM location
LDA #$00
STA $2108 ; Plane 1 map VRAM location
LDA #$00
STA $2109 ; Plane 2 map VRAM location
LDA #$00
STA $210A ; Plane 3 map VRAM location
LDA #$00
STA $210B ; Plane 0+1 Tile data location
LDA #$00
STA $210C ; Plane 2+3 Tile data location
LDA #$00
STA $210D ; Plane 0 scroll x (first 8 bits)
STA $210D ; Plane 0 scroll x (last 3 bits) #$0 - #$07ff
STA $210E ; Plane 0 scroll y (first 8 bits)
STA $210E ; Plane 0 scroll y (last 3 bits) #$0 - #$07ff
STA $210F ; Plane 1 scroll x (first 8 bits)
STA $210F ; Plane 1 scroll x (last 3 bits) #$0 - #$07ff
STA $2110 ; Plane 1 scroll y (first 8 bits)
STA $2110 ; Plane 1 scroll y (last 3 bits) #$0 - #$07ff
STA $2111 ; Plane 2 scroll x (first 8 bits)
STA $2111 ; Plane 2 scroll x (last 3 bits) #$0 - #$07ff
STA $2112 ; Plane 2 scroll y (first 8 bits)
STA $2112 ; Plane 2 scroll y (last 3 bits) #$0 - #$07ff
STA $2113 ; Plane 3 scroll x (first 8 bits)
STA $2113 ; Plane 3 scroll x (last 3 bits) #$0 - #$07ff
STA $2114 ; Plane 3 scroll y (first 8 bits)
STA $2114 ; Plane 3 scroll y (last 3 bits) #$0 - #$07ff
LDA #$80 ; increase VRAM address after writing to $2119
STA $2115 ; VRAM address increment register
LDA #$00
STA $2116 ; VRAM address low
STA $2117 ; VRAM address high
STA $211A ; Initial Mode 7 setting register
STA $211B ; Mode 7 matrix parameter A register (low)
LDA #$01
STA $211B ; Mode 7 matrix parameter A register (high)
LDA #$00
STA $211C ; Mode 7 matrix parameter B register (low)
STA $211C ; Mode 7 matrix parameter B register (high)
STA $211D ; Mode 7 matrix parameter C register (low)
STA $211D ; Mode 7 matrix parameter C register (high)
STA $211E ; Mode 7 matrix parameter D register (low)
LDA #$01
STA $211E ; Mode 7 matrix parameter D register (high)
LDA #$00
STA $211F ; Mode 7 center position X register (low)
STA $211F ; Mode 7 center position X register (high)
STA $2120 ; Mode 7 center position Y register (low)
STA $2120 ; Mode 7 center position Y register (high)
STA $2121 ; Color number register ($0-ff)
STA $2123 ; BG1 & BG2 Window mask setting register
STA $2124 ; BG3 & BG4 Window mask setting register
STA $2125 ; OBJ & Color Window mask setting register
STA $2126 ; Window 1 left position register
STA $2127 ; Window 2 left position register
STA $2128 ; Window 3 left position register
STA $2129 ; Window 4 left position register
STA $212A ; BG1, BG2, BG3, BG4 Window Logic register
STA $212B ; OBJ, Color Window Logic Register (or,and,xor,xnor)
LDA #$01
STA $212C ; Main Screen designation (planes, sprites enable)
LDA #$00
STA $212D ; Sub Screen designation
LDA #$00
STA $212E ; Window mask for Main Screen
STA $212F ; Window mask for Sub Screen
LDA #$30
STA $2130 ; Color addition & screen addition init setting
LDA #$00
STA $2131 ; Add/Sub sub designation for screen, sprite, color
LDA #$E0
STA $2132 ; color data for addition/subtraction
LDA #$00
STA $2133 ; Screen setting (interlace x,y/enable SFX data)
LDA #$00
STA $4200 ; Enable V-blank, interrupt, Joypad register
LDA #$FF
STA $4201 ; Programmable I/O port
LDA #$00
STA $4202 ; Multiplicand A
STA $4203 ; Multiplier B
STA $4204 ; Multiplier C
STA $4205 ; Multiplicand C
STA $4206 ; Divisor B
STA $4207 ; Horizontal Count Timer
STA $4208 ; Horizontal Count Timer MSB (most significant bit)
STA $4209 ; Vertical Count Timer
STA $420A ; Vertical Count Timer MSB
STA $420B ; General DMA enable (bits 0-7)
STA $420C ; Horizontal DMA (HDMA) enable (bits 0-7)
STA $420D ; Access cycle designation (slow/fast rom)
;===========================================================================
; I. DE VRAM
;===========================================================================
rep #$30
sep #$20
lda #$10
sta $2107
lda #$02
sta $210b
lda #$00
sta $2105
lda #$01
sta $212c

lda #$00
sta $2121

lda #$FF ; fondo blanco
sta $2122 ;
lda #$FF ;
sta $2122 ;
lda #$1F ; letras rojas
sta $2122 ;
lda #$00
sta $2122 ;
lda #$01
sta $4200 ; ENABLE JOYPAD READ (bit one)
;==========================================================================
; MOVIENDO GRAFICAS A VRAM
;==========================================================================
ldx #$2000 ;fuentes de ram a VRAM
stx $2116
ldy #$0000
copychar lda (font),y
sta $2118
stz $2119
iny
cpy #$0200
bne copychar

ldx #$1000 ;texto en ASCII a VRAM
stx $2116
ldx #$0000
textinfo lda TEXTPAN,x
and #$3f

sta $2118
stz $2119
inx
cpx #$0400

bne textinfo

lda #$0f
sta $2100
cli
runaround lda $4210
and #$80
beq runaround

joypad lda $4212 ; lectura de joypad
and #$01
bne joypad
lda $4219 ; lectura de boton start
and #$10
bne reset
jmp runaround

reset sep #$30 ; oscurecimiento
ldy #$0f
lus1 ldx #$06
dey
sty $2100
wait lda $4210
and #$80
beq wait
dex
cpx #$00
bne wait
cpy #$00
bne lus1
rep #$10
ldx #$0fff
dark lda $4210
and #$80
beq dark
dex
cpx #$0000
bne dark
sep #$30
lda #$00
pha
plb

jmp.l START ;salto largo a $008000

;============================================================================
; FUENTES
;============================================================================
charset
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ;'@'
.dcb $00,$3C,$66,$7E,$66,$66,$66,$00 ;'A'
.dcb $00,$7C,$66,$7C,$66,$66,$7C,$00 ;'B'
.dcb $00,$3C,$66,$60,$60,$66,$3C,$00 ;'C'
.dcb $00,$78,$6C,$66,$66,$6C,$78,$00 ;'D'
.dcb $00,$7E,$60,$78,$60,$60,$7E,$00 ;'E'
.dcb $00,$7E,$60,$78,$60,$60,$60,$00 ;'F'
.dcb $00,$3C,$66,$60,$6E,$66,$3C,$00 ;'G'
.dcb $00,$66,$66,$7E,$66,$66,$66,$00 ;'H'
.dcb $00,$3C,$18,$18,$18,$18,$3C,$00 ;'I'
.dcb $00,$1E,$0C,$0C,$0C,$6C,$38,$00 ;'J'
.dcb $00,$6C,$78,$70,$78,$6C,$66,$00 ;'K'
.dcb $00,$60,$60,$60,$60,$60,$7E,$00 ;'L'
.dcb $00,$63,$77,$7F,$6B,$63,$63,$00 ;'M'
.dcb $00,$66,$76,$7E,$7E,$6E,$66,$00 ;'N'
.dcb $00,$3C,$66,$66,$66,$66,$3C,$00 ;'O'
.dcb $00,$7C,$66,$66,$7C,$60,$60,$00 ;'P'
.dcb $00,$3C,$66,$66,$66,$3C,$0E,$00 ;'Q'
.dcb $00,$7C,$66,$66,$7C,$6C,$66,$00 ;'R'
.dcb $00,$3E,$60,$3C,$06,$66,$3C,$00 ;'S'
.dcb $00,$7E,$18,$18,$18,$18,$18,$00 ;'T'
.dcb $00,$66,$66,$66,$66,$66,$3C,$00 ;'U'
.dcb $00,$66,$66,$66,$66,$3C,$18,$00 ;'V'
.dcb $00,$63,$63,$6B,$7F,$77,$63,$00 ;'W'
.dcb $00,$66,$3C,$18,$3C,$66,$66,$00 ;'X'
.dcb $00,$66,$66,$3C,$18,$18,$18,$00 ;'Y'
.dcb $00,$7E,$0C,$18,$30,$60,$7E,$00 ;'Z'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '['
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '\'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; ']'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '^'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '_'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ;' ' espacio
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '!'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '"'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '#'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '$'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '%'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '&'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '''
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '('
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; ')'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '*'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '+'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; ','
.dcb $00,$00,$00,$3c,$3C,$00,$00,$00 ;'-'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '.'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '/'
.dcb $00,$3C,$66,$6E,$76,$66,$3C,$00 ;'0'
.dcb $00,$18,$38,$18,$18,$18,$7E,$00 ;'1'
.dcb $00,$7C,$06,$0C,$30,$60,$7E,$00 ;'2'
.dcb $00,$7E,$06,$1C,$06,$66,$3C,$00 ;'3'
.dcb $00,$0E,$1E,$36,$7F,$06,$06,$00 ;'4'
.dcb $00,$7E,$60,$7C,$06,$66,$3C,$00 ;'5'
.dcb $00,$3E,$60,$7C,$66,$66,$3C,$00 ;'6'
.dcb $00,$7E,$06,$0C,$0C,$0C,$0C,$00 ;'7'
.dcb $00,$3C,$66,$3C,$66,$66,$3C,$00 ;'8'
.dcb $00,$3C,$66,$3E,$06,$66,$3C,$00 ;'9'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; ':'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; ';'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '<'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '='
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '>'
.dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '?'

;============================================================================
; PANTALLA EN ASCII
;============================================================================

; 12345678901234567890123456789012 => 32
TEXTPAN
.dcb " "
.dcb " "
.dcb " "
.dcb " "
.dcb " "
.dcb " DARK-N "
.dcb " "
.dcb " "
.dcb " "
.dcb " "
.dcb " "
.dcb " PRESENTA "
.dcb " "
.dcb " ESTE SIMPLE "
.dcb " CODIGO "
.dcb " "
.dcb " HOLA MUNDO "
.dcb " "
.dcb " - CODIGO PARA X86 - "
.dcb " "
.dcb " "
.dcb " PRESIONA BOTON START "
.dcb " "
.dcb " "
.dcb " "
.dcb " 2004 "
.dcb " "
.dcb " "
.dcb " "
.dcb " "

Desde aquí en adelante empiezan los Registros Hardware, que tiene una dirección de memoria fija asignada. Los Bancos son 00-3F y $80-$BF y las direcciones 2000-5FFF.

7 6 5 4 3 2 1 0 => 8 bits => 1 byte
____________________
E
| n | v | m | x | d | i | z | c |
-------------------------------

Volver a la página principal.

John Torrijas 22 jul 2010 03:01

P*tas y barcos

791 mensajes
desde abr 2009

Gamertag: autenticafabada

ZIDEVS escribió:1988, Super Nintendo entra en escena

Que interesante...

Había muchas diferencias entre ese prototipo de Super nintendo y lo que finalmente vimos? A nivel técnico, digo.

Las malas lenguas decían que los de Nintendo empezaron a trabajar en su consola tras el lanzamiento en Japón de Mega drive...pero la fecha del reportaje (noviembre de 1988, un mes después del lanzamiento de la Mega) y las capturas de pilotwings me llevan a pensar que llevaban trabajando en ella bastante más tiempo.

Había algún cacharro por 1988 que permitiese rotar sprites?

Ralph 22 jul 2010 03:25

MegaAdicto!!!

14.020 mensajes
desde feb 2006

John Torrijas escribió:Había muchas diferencias entre ese prototipo de Super nintendo y lo que finalmente vimos? A nivel técnico, digo.

Como la noche y el día. Lo comento en el articulo sobre el chip super FX, en la sección "hardware". Echale un vistazo, porque te vas a sorprender seguro

John Torrijas escribió:Las malas lenguas decían que los de Nintendo empezaron a trabajar en su consola tras el lanzamiento en Japón de Mega drive...pero la fecha del reportaje (noviembre de 1988, un mes después del lanzamiento de la Mega) y las capturas de pilotwings me llevan a pensar que llevaban trabajando en ella bastante más tiempo.

Probablemente ya estaban pensando en la sucesora de la NES antes de 1988, pero si, en nintendo se durmieron en los laureles, y la salida de la megadrive les hizo cometer un par de errores importantes. Las prisas nunca son buenas.

John Torrijas escribió:Había algún cacharro por 1988 que permitiese rotar sprites?

Puede que algún ordenador de la epoca, pero consolas, ninguna. AES permitía escalar sprites, pero no rotarlos... creo que hasta la llegada del chip SFX (super mario world 2), ninguna consola rotó nunca un solo sprite (en SNES se trataba siempre de fondos tratados con modo 7).

John Torrijas 22 jul 2010 03:54

P*tas y barcos

791 mensajes
desde abr 2009

Gamertag: autenticafabada

Ralph escribió:Como la noche y el día. Lo comento en el articulo sobre el chip super FX, en la sección "hardware". Echale un vistazo, porque te vas a sorprender seguro

Vaya, vaya...un 68000 y un FX "de serie"...

Un S-DD1 integrado ya habría sido el no va más: juegos más baratos, el doble de grandes, cartuchos con casi 100 megabytes...

Ralph escribió:Puede que algún ordenador de la epoca, pero consolas, ninguna. AES permitía escalar sprites, pero no rotarlos... creo que hasta la llegada del chip SFX (super mario world 2), ninguna consola rotó nunca un solo sprite (en SNES se trataba siempre de fondos tratados con modo 7).

El bichejo ese, cuando te lo cargas...no se acerca a la pantalla dando vueltas? no es un sprite?

magno 22 jul 2010 06:19

MegaAdicto!!!

2.232 mensajes
desde ene 2005

Página web de magno

John Torrijas escribió:

El bichejo ese, cuando te lo cargas...no se acerca a la pantalla dando vueltas? no es un sprite?

Es un sprite mientras está en ese tamaño y te lo tienes que cargar... cuando ya lo has hecho, se convierte en un BG con modo 7 y se rota...

socram8888 22 jul 2010 09:47

lol socram pole

2.591 mensajes
desde may 2007

socram8888 está baneado por "incumplimiento términos y condiciones de uso"

John Torrijas escribió:
Ralph escribió:Como la noche y el día. Lo comento en el articulo sobre el chip super FX, en la sección "hardware". Echale un vistazo, porque te vas a sorprender seguro

Vaya, vaya...un 68000 y un FX "de serie"...

Un S-DD1 integrado ya habría sido el no va más: juegos más baratos, el doble de grandes, cartuchos con casi 100 megabytes... [...]

Yo creo que eso hubiera encarecido la consola (ya que en el momento del lanzamiento de las SFC, ya que imagino que esa tecnología aún no estaba del todo implementada) y habría retrasado mucho el lanzamiento de la consola, cosa que Ninty no quería a fin de que Sega no tomara el control de los 16-bits

sgonzalez 22 jul 2010 09:58

MegaAdicto!!!

2.125 mensajes
y 3 fotos
desde ene 2004
en Pucela city

Página web de sgonzalez

socram8888 escribió:
John Torrijas escribió:
Ralph escribió:Como la noche y el día. Lo comento en el articulo sobre el chip super FX, en la sección "hardware". Echale un vistazo, porque te vas a sorprender seguro

Vaya, vaya...un 68000 y un FX "de serie"...

Un S-DD1 integrado ya habría sido el no va más: juegos más baratos, el doble de grandes, cartuchos con casi 100 megabytes... [...]

Yo creo que eso hubiera encarecido la consola (ya que en el momento del lanzamiento de las SFC, ya que imagino que esa tecnología aún no estaba del todo implementada) y habría retrasado mucho el lanzamiento de la consola, cosa que Ninty no quería a fin de que Sega no tomara el control de los 16-bits

Qué manía le habéis cogido a la cpu de la SNES. La Turbografx/Pc-Engine tiene una CPU menos potente que la de MD/SNES y nadie dice nada.
Pienso que Nintendo intentaría hacer la mejor elección calidad/precio para la época. Si hubieran puesto un 68000 a lo mejor el coste de fabricar la consola hubiera sido muy superior.

Ralph 22 jul 2010 13:14 *

MegaAdicto!!!

14.020 mensajes
desde feb 2006

Editado 2 veces. Última: 22/07/2010 - 14:08:34 por Ralph.

Tengo una pregunta:

Si cuando usas un fondo como un objeto, el fondo se queda en negro, ¿por qué no se puede usar otro fondo, y hay que dibujarlo con sprites?(si se quiere, sino, se queda negro)... ¿no permite la SNES 4 fondos por hardware? (uno sería el fondo, al cual se le puede aplicar modo 7... otro sería el propio escenario, osea, el suelo... otro sería, por decirlo de alguna manera, el "HUD"... ¿que queda?, ¿no podría este ser usado también como fondo, mientras que el otro plano se está usando como si fuera un objeto?).

(EDIT: es una pregunta un poco impertinente, porque de aplicar otro fondo para que haga de fondo, no podría quedarse estatico. De hecho, hay un juego que usa dos planos generados por modo 7, uno arriba, y otro abajo, y su comportamiento es identico, como un espejo.)

John Torrijas escribió:Un S-DD1 integrado ya habría sido el no va más: juegos más baratos, el doble de grandes, cartuchos con casi 100 megabytes...

SNES puede direccionar hasta 117.5 megas, aunque digamos que no todos los "bloques" son tratados igual, ni viajan a la misma velocidad por el bus.

...sea como sea, cartuchos de 98 megas si son posibles, y se les puede aplicar el chip S-DD1 perfectamente. Si, juegos de hasta 196 megas

... la verdad es que fueron bastante cobardes con la capacidad de los contenidos.

Star ocean lleva un cartucho de 48 megas, y un S-DD1. Creo que es el cartucho con mayor contenido de todo el catalogo (Street fighter alpha 2 le debe rondar los 64 megas en total: 32 megas + S-DD1).

John Torrijas escribió:Es un sprite mientras está en ese tamaño y te lo tienes que cargar... cuando ya lo has hecho, se convierte en un BG con modo 7 y se rota...

Ya lo ha explicado magno. Todos los objetos y fondos se pueden sustituir, de la misma forma que en una animación se sustituye el frame anterior, por el frame posterior... solo qeu en este caso, en vez de sustituir un sprite por otro, se sustituye un sprite por un fondo (para poderle aplicar las rutinas graficas del modo 7).

No me acuerdo realmente, pero es segurísimo que la plataforma que se mueve mientras dura el combate, deja de hacerlo y se pone "recta" cuando este termina (cambia de ser el fondo al que se le puede aplicar el modo 7, a ser un fondo normal).

En el AoF 1 y 2 de SNES, todo es subceptible de ser tratado con scaling (fondos y sprites). Al fondo se le aplican las rutinas de escalado por hardware, usando modo 7, mientras que los sprites (personajes, magias, etc) son escalados por software.

socram8888 escribió:Yo creo que eso hubiera encarecido la consola (ya que en el momento del lanzamiento de las SFC, ya que imagino que esa tecnología aún no estaba del todo implementada) y habría retrasado mucho el lanzamiento de la consola, cosa que Ninty no quería a fin de que Sega no tomara el control de los 16-bits

Si mal no recuerdo, la SNES llegó valiendo 26.990 pesetas... la megadrive en su día llegó valiendo 39.990.

Creeme, la intención no fué abaratar precios, porque calculo que no se pasaría tres pueblos con el PVP. Se la recortó por que se agotaron todos los plazos de sobra... al menos se andaron listos, y abortaron el 68000 a tiempo(sino tendrían que haber retrasado la maquina incluso para incluir el 65816), pero con el SFX lo tuvieron mas crudo, y creo que aguantaron mas tiempo sin lanzar la consola precisamente por el (para al final no incluirlo, que desperdicio).

sgonzalez escribió:Qué manía le habéis cogido a la cpu de la SNES. La Turbografx/Pc-Engine tiene una CPU menos potente que la de MD/SNES y nadie dice nada.

Si, pero tenía un chip de video de 16 bits. En definitiva, a la SNES la salvó el chipset de video que tenía... en realidad creo que pocos se hacen a la idea de lo que hubiera supuesto acompañar al sistema de video de SNES con un 68000 a 10 Mhz.

sgonzalez escribió:Pienso que Nintendo intentaría hacer la mejor elección calidad/precio para la época. Si hubieran puesto un 68000 a lo mejor el coste de fabricar la consola hubiera sido muy superior.

Y aún así, hubiera estado dentro de los margenes. Diría que incluso nos clavaron con el precio cuando la lanzaron.

YuushaDai 22 jul 2010 13:45

MegaAdicto!!!

1.319 mensajes
desde feb 2007

Ralph escribió:Star ocean lleva un cartucho de 48 megas, y un S-DD1. Creo que es el cartucho con mayor contenido de todo el catalogo (Street fighter alpha 2 le debe rondar los 64 megas en total: 32 megas + S-DD1).

O el Star Ocean o el Tengai Makyou creo que era un cartucho de 40 megas pero llevaba el chip SPC7110 de Epson y no se ya, pero creo que el ratio de compresion era mayor.

No sé si es correcto esto, pero un grupo de traducción sacó un descompresor de graficos para jugarlo en el zsnes hace tiempo, que aplicado a la rom, sacaba archivos.bin, y en total, el juego pasaba a ocupar descomprimido unos 23 Megabytes esto es en bits 184 megas. Es posible que el Tengai Makyou ocupara esta cifra?

Ralph 22 jul 2010 13:58

MegaAdicto!!!

14.020 mensajes
desde feb 2006

YuushaDai escribió:
Ralph escribió:Star ocean lleva un cartucho de 48 megas, y un S-DD1. Creo que es el cartucho con mayor contenido de todo el catalogo (Street fighter alpha 2 le debe rondar los 64 megas en total: 32 megas + S-DD1).

O el Star Ocean o el Tengai Makyou creo que era un cartucho de 40 megas pero llevaba el chip SPC7110 de Epson y no se ya, pero creo que el ratio de compresion era mayor.

No sé si es correcto esto, pero un grupo de traducción sacó un descompresor de graficos para jugarlo en el zsnes hace tiempo, que aplicado a la rom, sacaba archivos.bin, y en total, el juego pasaba a ocupar descomprimido unos 23 Megabytes esto es en bits 184 megas. Es posible que el Tengai Makyou ocupara esta cifra?

Cierto, el kabuki klash... tengo entendido que son 72 Mbits de contenido en total. Se estima que el star ocean ronda los 96 Mbits de contenido total gracias a la compresión.

...184 megas es una barbaridad, ¿existía por aquel entonces la tecnología para aplicar tales ratios de comrpesión?. No lo pongo en duda, pero que con un cartucho de 90 megas nos vamos casi a los 400, me parece una burrada.

magno 22 jul 2010 14:33

MegaAdicto!!!

2.232 mensajes
desde ene 2005

Página web de magno

Ralph escribió:Tengo una pregunta:

Si cuando usas un fondo como un objeto, el fondo se queda en negro, ¿por qué no se puede usar otro fondo, y hay que dibujarlo con sprites?(si se quiere, sino, se queda negro)... ¿no permite la SNES 4 fondos por hardware? (uno sería el fondo, al cual se le puede aplicar modo 7... otro sería el propio escenario, osea, el suelo... otro sería, por decirlo de alguna manera, el "HUD"... ¿que queda?, ¿no podría este ser usado también como fondo, mientras que el otro plano se está usando como si fuera un objeto?).

No he entendido a qué te refieres, ¿quizá a los fondos animados? Porque un fondo no es un objeto (es decir, no es un sprite). Si no se dibuja un fondo es porque se ha desactivado expresamente, y por tanto no está ni a negro ni a ningún color. Y si está activo no puede estar "sin nada", puesto que siempre habrá algo de contenido en la memoria VRAM.

En cuanto al tamaño máximo que puede direccionar de ROM en un cartucho la SNES es de 90 megas y pico, creo que ya lo comenté por ahí (no sé si en este foro, que llevo un lío), y eso es usando el modo 25 extendido como mapeo.
Fíjate que la SNES tiene un bus de direcciones de 24 bits, es decir, 16 megabytes = 128 megabits, pero la mitad de las páginas son LoROM, es decir, que sólo se puede acceder a ellas a la mitad 64 Mbit + 64Mbits/2 = 96 megabits. Ahora quítale los dos bloques de RAM, más el espacio de registros y la zona shadow de memoria RAM y te salen casi 93 más o menos; la cifra exacta os la puedo dar si me acuerdo de mirarlo esta tarde.

En cuanto al SPC7110 creo que no consigue un ratio tan salvaje de compresión como para sacar de 40 megabits los 184... ratio de más de 4:1 me parece una burrada, peor me has despertado la curiosidad sobre este chip, así que miraré qué hace... Pero los 96 megabits del SO con lo más grande que se conoce. También se decía que MArio RPG ocupaba 128 megabits descomprimido, puesto que el SA-1 ayudaba a descomprimir, pero no tengo muy claro que eso sea cierto.

Y el por qué no se sacaron esos chips antes, pues no lo tengo claro, pero hay un detalle que me hizo pensar: el S-DD1 usa una especie de descompresión aritmética, que estuvo hasta 1995 más o menos patentada y con royalties, y creo que hubo algún tipo de lío con eso (como lo hay ahora con el códec de video H.264). Resulta que justo cuando por esa época aparecieron chips que implementaban la decodificación aritmética, por lo que a lo mejor tuvo influencia... Seguro que los costes también afectaron. Lo de ponerlo directamente en la consola tiene otros impedimentos como espacio y gestión del bus, que ya es compleja como para añadir otro elemento más que accede a él...

Ralph 22 jul 2010 15:42

MegaAdicto!!!

14.020 mensajes
desde feb 2006

magno escribió:
Ralph escribió:Tengo una pregunta:

Si cuando usas un fondo como un objeto, el fondo se queda en negro, ¿por qué no se puede usar otro fondo, y hay que dibujarlo con sprites?(si se quiere, sino, se queda negro)... ¿no permite la SNES 4 fondos por hardware? (uno sería el fondo, al cual se le puede aplicar modo 7... otro sería el propio escenario, osea, el suelo... otro sería, por decirlo de alguna manera, el "HUD"... ¿que queda?, ¿no podría este ser usado también como fondo, mientras que el otro plano se está usando como si fuera un objeto?).

No he entendido a qué te refieres, ¿quizá a los fondos animados? Porque un fondo no es un objeto (es decir, no es un sprite). Si no se dibuja un fondo es porque se ha desactivado expresamente, y por tanto no está ni a negro ni a ningún color. Y si está activo no puede estar "sin nada", puesto que siempre habrá algo de contenido en la memoria VRAM.

Es sencillo. En el Super probotector, en la parte de la primera pantalla en la que un avión se acerca desde el fondo, y bombardea la zona, vemos como habilmente se ha sustituido el fondo, por otro mas simple... este, está formado por sprites.

Imagen

Aquí el video:
http://www.youtube.com/watch?v=ZfCHuftlwlE

...vemos como el fondo está dibujado, y después de atravesar algunos edificios, el fondo ya no está, hay otro mas simple, que es cuando aparece el avión.

Mi pregunta es, ¿mientras se usa el fondo para dibujar el avión, se puede usar otro fondo para dibujarlo, en vez de usar sprites?. Usando sprites para dinujar el fondo, queda mas simple... y digo yo, si se consiguen varios planos de scroll en muchos juegos, ¿no podría ser posible colocar un fondo mientras que aparece el avión?... o lo mas probable es que el fondo elegido se comporte igual que el avión, y haga un zoom junto con el.

magno 22 jul 2010 17:31 *

MegaAdicto!!!

2.232 mensajes
desde ene 2005

Página web de magno

Editado 1 vez. Última: 24/07/2010 - 18:23:04 por magno.

Ralph escribió:Mi pregunta es, ¿mientras se usa el fondo para dibujar el avión, se puede usar otro fondo para dibujarlo, en vez de usar sprites?. Usando sprites para dinujar el fondo, queda mas simple... y digo yo, si se consiguen varios planos de scroll en muchos juegos, ¿no podría ser posible colocar un fondo mientras que aparece el avión?... o lo mas probable es que el fondo elegido se comporte igual que el avión, y haga un zoom junto con el.

Creo que tienes un lío armao de cuidao

Como decía en mi otro post, fondo no es igual a sprite, son cosas opuestas diametralmente: el fondo son tiles que cubren la pantalla formando un mosaico, es plano totalmente; el sprite más básico es una tile 8x8 que tiene unas propiedades determinadas y que se puede situar en cualquier punto de la pantalla. El plano se ha de construir poniendo una tile tras otra ocupando todo los huecos (lo que se llama "BG map"), mientras que el sprite es como un "objeto de programación": tiene unas propiedades como tamaño, posición, giro y tile que se dibuja en esa posición (es decir, un struct de C). Entonces, la frase:

Ralph escribió:Usando sprites para dinujar el fondo, queda mas simple...

deja de tener sentido, puesto que para dibujar el fondo se usan tiles en un BG, no sprites; un fondo (BG) no puede estar formado por sprites. De todas formas, si se pudiera hacer lo que dices, gastarías el máximo número de sprites que puede tener en pantalla a la vez la SNES.
En la escena que dices, sólo las bombas, las chispas de fuego que salen cuando caen y los personajes son sprites; el resto de cosas son BGs (el avión en concreto es BG0).
Y de hecho, sí se pueden poner más cosas en los fondos a parte del avión, mientras tengas capas para llenar sí. Lo que pasa es que ahí entra la pericia del programador, ya que en ese caso concreto del Probotector, el fuego que aparece en el suelo es una capa entera y ya existe antes de que aparezca el avión; podrían haber usado esa capa para poner un fondo, y luego transferir la capa completa con el fuego cuando ya ha pasado el avión, pero no lo han hecho así porque no se habrán querido comer la cabeza más de la cuenta.
Por cierto, que he visto el video y he jugado ese trozo del Probotector y no veo en ninguno de los casos que el fondo se sustituya por otro más sencillo... está el fondo que los programadores han creído que tenía que estar, pero no creo que sea más sencillo porque tuviera que pasar el avión en concreto.

Y en cuanto a la otra cuestión del tamaño máximo de los cartuchos de SNES, aquí tenéis el mapa de memoria:
Imagen

Si hacemos cuentas tenemos:
* Bancos $FF - $C0 -> 64 bancos x 64 kbytes/banco = 4 Megabytes = 32 Megabits (zona HiROM)
* Bancos $BF - $80 -> sólo se usa de ellos la parte alta y es la zona "shadow ROM" de la parte alta de los bancos $FF a $C0, es decir, que es exactamente la misma zona del chip de ROM del cartucho a la que estaríamos accediendo, por lo que esta zona no cuenta para el total
* Bancos $7F y $7E -> Es la memoria RAM, que no cuenta tampoco para el total.
* Bancos $7D - $40 -> 62 bancos x 64 Kbytes/banco = 3.875 Megabytes = 31 Megabits (zona HiROM)
* Bancos $3F y $3E -> son 2 bancos a los que sólo se puede acceder a la parte alta, así que esto suma unos despreciables 64 Kbytes
* Bancos $3D - $00 -> sólo se usa de ellos la parte alta y es la zona "shadow ROM" de la parte alta de los bancos $7D a $40, es decir, que es exactamente la misma zona del chip de ROM del cartucho a la que estaríamos accediendo, por lo que esta zona no cuenta para el total

Así que los cálculos dan un maravilloso total de................ ¿¿¿63 MEGABIT(más esos miserables 64 Kytes)???
Pues sí, así es, éste es el tamaño máximo que Nintendo fijó para sus PCBs, de modo que no vendió ninguna que permitiera más capacidad porque el decodificador de direcciones implementado en el MAD-1 y MAD-2 no permitía direccionar más memoria; él era el responsable de esa "Shadow ROM" de la que hablaba. Pero si ahora cogéis esas mismas dos zonas y pensáis que sí se pueden direccionar desde la SNES, tenemos que añadir al total de 63 megabits que habíamos calculado:
* Bancos $BF - $80 -> 64 bancos de 32 Kbytes/banco = 2 Megabytes = 16 Megabits (zona LoROM)
* Bancos $3F - $00 -> 64 bancos de 32 Kbytes/banco = 2 Megabytes = 16 Megabits (zona LoROM)

Por tanto, si no usáramos un mapper de los que da Nintendo y nos hacemos una PCB casera nosotros mismos con el decodificador de direcciones, tenemos un total de ¡¡¡95 MEGABIT!!!

No sé si ha sido mucha tralla de post, pero espero que haya quedado claro

Ralph 24 jul 2010 17:23

MegaAdicto!!!

14.020 mensajes
desde feb 2006

He estado un poco liado, y me he reiterado un poco en las respuestas porque no he podido "parir" este post de una sola vez, aviso de ante mano, porque me da miedo hasta revisarlo [tomaaa]

...a lo mejor es mucha tralla, así que puedes tomartelo con calma, e ir respondiendo poco a poco en varios posts, según lo vayas viendo.

magno escribió:Si hacemos cuentas tenemos:
* Bancos $FF - $C0 -> 64 bancos x 64 kbytes/banco = 4 Megabytes = 32 Megabits (zona HiROM)

magno escribió:* Bancos $BF - $80 -> sólo se usa de ellos la parte alta y es la zona "shadow ROM" de la parte alta de los bancos $FF a $C0, es decir, que es exactamente la misma zona del chip de ROM del cartucho a la que estaríamos accediendo, por lo que esta zona no cuenta para el total

No queda muy claro la explicación. Según esto: "sólo se usa de ellos la parte alta y es la zona "shadow ROM" de la parte alta de los bancos $FF a $C0", estás señalando esta area:

Imagen

...Como no has usado las coordenadas verticales, resulta dificil saber que estás pensando exactamente.

La explicación: " es exactamente la misma zona del chip de ROM del cartucho a la que estaríamos accediendo, por lo que esta zona no cuenta para el total", tiene TODO el sentido, pero estás señalando a esta zona (cuando obviamente, la misma zona de chip de ROM del cartucho comprende al rango FF - 80 y FFFF - 0000):

Imagen

...sin embargo, estás haciendo mención a los bancos &BF - $80, que según lo veo, son estos:

Imagen

magno escribió:* Bancos $7F y $7E -> Es la memoria RAM, que no cuenta tampoco para el total.

magno escribió:* Bancos $7D - $40 -> 62 bancos x 64 Kbytes/banco = 3.875 Megabytes = 31 Megabits (zona HiROM)

magno escribió:* Bancos $3F y $3E -> son 2 bancos a los que sólo se puede acceder a la parte alta, así que esto suma unos despreciables 64 Kbytes

magno escribió:* Bancos $3D - $00 -> sólo se usa de ellos la parte alta y es la zona "shadow ROM" de la parte alta de los bancos $7D a $00, es decir, que es exactamente la misma zona del chip de ROM del cartucho a la que estaríamos accediendo, por lo que esta zona no cuenta para el total

Otra vez vuelvo a perderme. Los bancos $3D - $00, en teoría son estos:

Imagen

Y con esta sentencia me lo aclara: "sólo se usa de ellos la parte alta y es la zona "shadow ROM"... pero entonces dices lo siguiente: "de la parte alta de los bancos $7D a $00", lo cual, me cambia los esquemas:

Imagen

Después dices: "es decir, que es exactamente la misma zona del chip de ROM del cartucho a la que estaríamos accediendo, por lo que esta zona no cuenta para el total", con lo cual pienso: ¿eso de la misma zona del chip de rom, se refiere realmente a esto?:

Imagen

...si es así, en el ejemplo de antes, "la misma zon del chip de ROM del cartucho", es esto:

Imagen

y no esto (como ya he dicho antes):

Imagen

magno escribió:Así que los cálculos dan un maravilloso total de................ ¿¿¿63 MEGABIT(más esos miserables 64 Kytes)???

magno escribió:Pues sí, así es, éste es el tamaño máximo que Nintendo fijó para sus PCBs, de modo que no vendió ninguna que permitiera más capacidad porque el decodificador de direcciones implementado en el MAD-1 y MAD-2 no permitía direccionar más memoria

A ver si entiendo esto bien. MAD 1 y MAD 2 se encargan de gestionar el direccionamiento de memoria... para cartucho qeu superen los 16 Mbits, estamos hablando de usar los dos decodificadores, cada uno de un lado del mapa de memoria.

...hasta aquí bien (creo), y según estoy leyendo, DE MOMENTO, no es posible que direccionen mas de 63 Mbits + 64 Kbytes, pero mas abajo hablas de las dos partes del mapa de memoria que todavía no hemos tocado, y según estoy entendiendo, no es que no pueda direccionar mas, sino que nintendo no ha vendido esas PCB's a nadie (supongo que ya serían demaisado caras).

magno escribió:él era el responsable de esa "Shadow ROM" de la que hablaba. Pero si ahora cogéis esas mismas dos zonas y pensáis que sí se pueden direccionar desde la SNES, tenemos que añadir al total de 63 megabits que habíamos calculado:

En otras palabras, MAD-1 y MAD-2, si pueden direccionar TODO esto (cada uno su lado correspondiente):

Imagen

magno escribió:* Bancos $BF - $80 -> 64 bancos de 32 Kbytes/banco = 2 Megabytes = 16 Megabits (zona LoROM)
* Bancos $3F - $00 -> 64 bancos de 32 Kbytes/banco = 2 Megabytes = 16 Megabits (zona LoROM)

magno escribió:Por tanto, si no usáramos un mapper de los que da Nintendo y nos hacemos una PCB casera nosotros mismos con el decodificador de direcciones, tenemos un total de ¡¡¡95 MEGABIT!!!

Entendido, pero ahora viene el carrusel de preguntas(XD):

1º "Super nintendo podía direccionar hasta 128 Mbits, aunque solo 117.75 estaban realmente disponibles. Un mapeado normal limpio podría facilmente direccionar hasta 95Mbits de datos en la ROM (48 Mbits en modo FastROM)"

-¿Donde están en el mapa de memoria los 128 Mbits? (respuesta obvia, lo se, no están... pero, ¿donde están?).
-¿Por qué solo están disponibles 117.5 de esos 128? (lo he leido en algún lado, pero ya no encuentro el dato).

...para el dato:
Fast ROM = 120ns
LowROM = 200ns

...¿entonces son 48Mbits en Fast ROM, y 47 en Low ROM?. ¿Como se reparte la zona a 120ns y la zona a 200ns en el mapa de memoria?.

2º ¿Que consecuencias tiene usar Fast ROM o Low ROM?... es decir, ¿solo es lento su acceso?, o implica algo mas.

3º ¿Dos velocidades de acceso a datos (Fast ROM y Low ROM) era necesario por algún motivo?, o son una consecuencia... ¿de que son una consecuencia? (¿que se gana para tener que tirar con una lacra tan importante?).

4º ¿Donde están implementados en el hardware los decodificadores MAD-1 y MAD-2?.

5º Me referiré solo a un lado del mapa para no extenderme, cogiendo la rango $BF - 2000/$BF - 0000 y $BE - 2000/$BE - 0000... es un rango de datos que realmente no se puede usar, ¿no?, actua como la RAM del cartucho (no de sistema, ojo). Realmente los 95 Mbits de maxima no son usables al 100%.

6º ¿Que es esto?, ¿para que está reservado?:

Imagen

Sobre el modo-7 y los fondos, etc:

magno escribió:Como decía en mi otro post, fondo no es igual a sprite, son cosas opuestas diametralmente: el fondo son tiles que cubren la pantalla formando un mosaico, es plano totalmente

Hombre, esto está claro, creo que no me entendiste. Usar un fondo como un objeto/enemigo/campo de juego, tiene la consecuencia de dejar el fondo vacío, y en algunos juegos se dibujan sprites en el fondo para que esto no ocurra.

Fondo no es igual a sprite, pero sin embargo, puedo ordenarle que se quede en un determinado sitio... simplemente haciendo de fondo, aunque queden muchos huecos, y de un resultado muy simple (depende de los recursos que uno esté dispuesto a gastar).

magno escribió:el sprite más básico es una tile 8x8 que tiene unas propiedades determinadas y que se puede situar en cualquier punto de la pantalla

Ok, nada me impide ordenarle que se quede estatico en el fondo, o que acompañe al scroll, para que parezca un fondo, ¿no?.

magno escribió:El plano se ha de construir poniendo una tile tras otra ocupando todo los huecos (lo que se llama "BG map"), mientras que el sprite es como un "objeto de programación": tiene unas propiedades como tamaño, posición, giro y tile que se dibuja en esa posición (es decir, un struct de C).

Y el susodicho plano, puede usar las rutinas del modo 7, para escalar y rotar... pero nos queda un fondo negro (que no un "BG map" negro), un hueco enorme, que como ya he dicho, puede rellenarse estrategicamente con algunos sprites para que hagan de fondo.
Mi duda en todo caso fué, que si quiero usar un BG map con modo 7 para hacer de el un enemigo:

Imagen

...vemos que ya no hay fondo, el que hay tiene que desaparecer, así que si quiero rellenar el hueco resultante, ¿puedo usar de alguna manera otro "BG map" para que haga de fondo si queda espacio en memoria para dibujar mas tiles?, ¿sería técnicamente posible sabiendo que usando el modo 7, todo lo que no rote con el fondo, debe ser un sprite?, o tengo que conformarme con usar sprites para simular ventanales, y cosas así (en este caso, el fondo que había a base de tiles antes de desaparecer, debería parecerse al que vas a crear con sprites).

A parte de esta duda, me surgen otra. Sobre las propiedades de los sprites, ¿que función le otorga a un sprite la propiedad de "giro"?.

magno escribió:deja de tener sentido, puesto que para dibujar el fondo se usan tiles en un BG, no sprites; un fondo (BG) no puede estar formado por sprites. De todas formas, si se pudiera hacer lo que dices, gastarías el máximo número de sprites que puede tener en pantalla a la vez la SNES.

Usar sprites para sibujar un fondo es una perdida de tiempo, pero cuando usas un fondo para otras tareas que la de ser usado como fondo, te queda un hueco enorme.

...de todos modos, aprovecho para comentar que el maximo numero de sprites total, da para una superficie total de varias pantallas, lo que si es cierto, es que hay un limite por scanline (32 sprites), mas que suficiente, pero que ademas limita a esos 32 sprites a no estar formados por mas de 256 pixels (todo el ancho de su resolución... o al menos de la mas común). Por si fuera poco, ocupar todo un scanline originaría un fallo, y borraría parte del mismo.
En otras palabras, si el fondo del super soccer son sprites, ¿por qué no observamos ese bug?. Se me ocurre que reduciendo la resolución, evitamos dibujar 256 pixels por scan... aunque quizás también podría ser posible (aunque improbable) parchear el bug desde el propio programa del juego, y así evitar el fallo, ¿no?.

Imagen

Tenemos el terreno de juego, que es un BG map usando modo 7, con lo que en el fondo nos quedaría un hueco enorme... teniendo en cuenta lo expuesto, ¿tu que piensas?, ¿el fondo son sprites, u otro fondo adicional con tiles "sobrantes"? (veo que hay algo de compresión... osea, repetición de un patrón para conformar la grada. Esto da pistas, pero no doy credito de que pueda ser un fondo con sus tiles).

La norma dice que todo lo que no rote con el fondo, debe ser un sprite. Me surje una duda: Un fondo que usa las rutinas del modo 7, pero no rota en ningún momento (solo escalar para simular zoom, como en el super soccer), ¿significa que si no rota, y solo es escalado, se puede añadir otro fondo?. Esto es importante tenerlo en cuenta.

magno escribió:En la escena que dices, sólo las bombas, las chispas de fuego que salen cuando caen y los personajes son sprites; el resto de cosas son BGs (el avión en concreto es BG0).
Y de hecho, sí se pueden poner más cosas en los fondos a parte del avión, mientras tengas capas para llenar sí. Lo que pasa es que ahí entra la pericia del programador, ya que en ese caso concreto del Probotector, el fuego que aparece en el suelo es una capa entera y ya existe antes de que aparezca el avión; podrían haber usado esa capa para poner un fondo, y luego transferir la capa completa con el fuego cuando ya ha pasado el avión, pero no lo han hecho así porque no se habrán querido comer la cabeza más de la cuenta.

El fondo del avión, es escalado, y rota ligeramente... yo diría que el fondo que se usa para el fuego no se pudo usar para dibujar el fondo de la ciudad, porque aparece el avión y no pueden coincidir. De haber sido posible que coincidieran, bastaba con usar el fondo del avión en cuanto desapareciera después de tirar las bombas, para sacar el fondo del fuego (que en realidad es el mismo fondo con el qeu se ha usado para el avión, con las rutinas de modo 7).

...y entonces lo habríamos tenido todo. Un fondo sin tanto "hueco", la escena del avión, el fuego... todo.

Pero no, no es posible porque el modo 7 tiene la limitación que tiene.

magno escribió:Por cierto, que he visto el video y he jugado ese trozo del Probotector y no veo en ninguno de los casos que el fondo se sustituya por otro más sencillo... está el fondo que los programadores han creído que tenía que estar, pero no creo que sea más sencillo porque tuviera que pasar el avión en concreto.

En la escena del avión, en el fondo predomina el negro (es un hueco importante), y quedan unos pequeños edificios medio derruidos (que para mi, están formados por sprites, porque permanecen cuando aparece el avión, no puede ser un fondo, lo dice la norma). Antes de esa escena, el fondo de la ciudad es mas detallado... no por nada, imagino.

magno 24 jul 2010 18:33

MegaAdicto!!!

2.232 mensajes
desde ene 2005

Página web de magno

Me acaba de dar un SOPONCIOOOOOOOO!!! Estoy en coma y todavía no he llegado a la mitad del post

DDD

A ver, te contesto rápido a lo de la memoria:

* Efectivamente, el área shadow $3D a $00 es la copia del area $7D a $40. Era una errata que ya he arreglado.
* Y lo de la memoria shadow consiste que que en la zona $3D a $00, a la que sólo puedes acceder a la parte alta, estás leyendo los mismos datos que si leyeras la parte alta de cada banco entre $7D a $40. Es decir, accedes a la misma parte del chip poniendo $3D:8100 que $7D:8100, PERO NO SI PONES $3D:6100 (que sería, por ejemplo SRAM) y $7D:6100 (que sí sería una dirección de ROM).

Y esto es así porque el MAD hace que, cuando se genera la dirección $3D:6100 desde la SNES, no se active el /CE de los chips de ROM y sí el de la SRAM. Si no pusieras el MAD, y te montas tu propio decodificador de direcciones con lógica discreta, podrías acceder a todo el mapa de ROM, puesto la SNES genera el /ROMSEL pero nadie por medio evitaría que esa señal llegara a /CE de los chips de ROM.

El resto de cosas del post, que aún no sé si están relacionadas con este mismo tema, te las responderé en 1 semana, que tengo un vuelo que sale en unas horas y no me da tiempo a todo!!

HASTA LA VUELTA!!! (ME VOY DE VACAAAAAAAAAAAAAAAAAAAAAAAAS!!!)

sgonzalez 24 jul 2010 20:18

MegaAdicto!!!

2.125 mensajes
y 3 fotos
desde ene 2004
en Pucela city

Página web de sgonzalez

Ralph escribió:
magno escribió:
Ralph escribió:Tengo una pregunta:

...

Es sencillo. En el Super probotector, en la parte de la primera pantalla en la que un avión se acerca desde el fondo, y bombardea la zona, vemos como habilmente se ha sustituido el fondo, por otro mas simple... este, está formado por sprites.

Aquí el video:
http://www.youtube.com/watch?v=ZfCHuftlwlE

...vemos como el fondo está dibujado, y después de atravesar algunos edificios, el fondo ya no está, hay otro mas simple, que es cuando aparece el avión.

Mi pregunta es, ¿mientras se usa el fondo para dibujar el avión, se puede usar otro fondo para dibujarlo, en vez de usar sprites?. Usando sprites para dinujar el fondo, queda mas simple... y digo yo, si se consiguen varios planos de scroll en muchos juegos, ¿no podría ser posible colocar un fondo mientras que aparece el avión?... o lo mas probable es que el fondo elegido se comporte igual que el avión, y haga un zoom junto con el.

Nop, acabo de hacer la prueba con el emulador y los fondos no son sprites, son planos BG1 y BG2... Con lo cuál la teoría de que sólo puede haber un plano con fondo negro cuando hay zoom o rotaciones queda un poco coja.
Parece que hay juegos en los que ocurre el tema del fondo negro... y otros en los que hay más planos además del de zoom/rotación (super probotector o TMNT in Time per ejemplo)

Ralph 24 jul 2010 21:45

MegaAdicto!!!

14.020 mensajes
desde feb 2006

Pero obviamente aquí está pasando algo.

Imagen

El plano de los edificios derruidos no puede ocupar toda la superficie, porque si no, no dejarían todo ese huecazo, que no corresponde con el escenario ni aunque fuese la noche mas cerrada de la historia (que hace solo unos segundos era un día gris y lleno de nubes).

...parece que el plano de los edificios tiene sus propias limitaciones.

sgonzales escribió:la teoría de que sólo puede haber un plano con fondo negro cuando hay zoom o rotaciones queda un poco coja.

La realidad es que esa, es una limitación que existe, pero ojo, eso no significa que no puedan haber maneras de evitar el cumplimiento de la norma.

¿Que dice el emulador?. En el momento de la escena del avión, ¿cuantos planos está manejando la maquina?.

EDIT:

magno escribió:El resto de cosas del post, que aún no sé si están relacionadas con este mismo tema, te las responderé en 1 semana, que tengo un vuelo que sale en unas horas y no me da tiempo a todo!!

HASTA LA VUELTA!!! (ME VOY DE VACAAAAAAAAAAAAAAAAAAAAAAAAS!!!)

ok, pasalo bien... recupera fuerzas, y vuelve con ganas de escribir [sonrisa]

ryumarquez 25 jul 2010 19:22

Habitual

68 mensajes
desde ene 2009

Q gratos recuerdos vivi con Axeley........ fue el segundo juego de snes que tuve por alla en el año 1993.... la primera vez q lo jugue me dije dentro de mi q estaba jugando con un arcade o (Recreativa).
Los graficos eran unas pasadas y ni hablar de la musica y sus efectos de sonido...... tan solo escuchar la musica de la scena 2 es como para ponerse los pelos de punta para despues llegar y pelear con ese jefazo repleto de una calidad grafica para el deleite de nuestros ojos......!
No estoy de acuerdo para nada con el analisis hecho en este foro.... no se xq desmerita el apartado del audio, en mi mas humilde opinion considero este apartado es uno de los mejores para algun juego hecho para esta consola.... se le puede criticar q a veces la dificultad es excesivamente elevada...., he jugado otros juegos similares pero ninguno como AXELEY...............!

Only16bits 25 jul 2010 20:20

MegaAdicto!!!

2.019 mensajes
desde sep 2009

Este hilo tiene muchisima información interesante pero sobretodo para gente que le va esto de la programación, para el resto nos va más la práctica que es hablar de los juegos jeje

Ralph 25 jul 2010 20:32

MegaAdicto!!!

14.020 mensajes
desde feb 2006

ryumarquez escribió:No estoy de acuerdo para nada con el analisis hecho en este foro.... no se xq desmerita el apartado del audio, en mi mas humilde opinion considero este apartado es uno de los mejores para algun juego hecho para esta consola....

Las melodías podrán gustar mas o menos, pero es innegable que la factura técnica está muy por debajo de los títulos que mejor explotan el sistema de audio en SNES. De hecho, incluso sin compararlo con otros juegos, el sonido es el aspecto mas flojo todo del juego... creo que explico bastante bien que es lo que desmerece del aspecto sonoro, y que es lo que no.

A mi también me encanta la melodía de la segunda fase, pero tampoco hay ninguna otra a su altura. Entre unas cosas y otras, siendo justos, el aspecto sonoro es lo peor del juego... lo mejor que tiene, es que tiene personalidad, es muy caracteristico, y eso está bien, pero no es suficiente. Lo que no puede ser, es que por nostalgia o por hacer la vista gorda, todos los juegos lo tengan todo muy bien, y eso no es así.

Cuando yo hago un analisis, soy muy estricto, y NO MIENTO. No voy a regalarle los ojos a nadie para que lea lo que quiere leer sobre su juego preferido, mas bien al contrario, le voy a contar lo que tiene, y lo que no tiene. La intención es que sea ameno y sincero, los forofismos no me interesan.

...tampoco me baso en las típicas puntuaciones de que si no es un +90, no es bueno.

YuPiKaIe 25 jul 2010 21:30

yippi ka yei

6.246 mensajes
desde may 2006
en Barcelona

Página web de YuPiKaIe Facebook de YuPiKaIe Twitter de YuPiKaIe

Only16bits escribió:Este hilo tiene muchisima información interesante pero sobretodo para gente que le va esto de la programación, para el resto nos va más la práctica que es hablar de los juegos jeje

+1, el hilo es total y absolutamente impresionante, tiene un trabajo increíble por parte de ralph, un curro extraordinario, de los más completos en clásicas, con información a raudales

pero, la gracia de este tipo de hilos es el análisis de juegos, el descubrir catálogo, joyas desconocidad, aportar opiniones sobre juegos, etc

y este hilo no tiene esta tendencia, tiene una tendencia mucho más técnica, densa, de mucha información, que a mi personalmente aunque intendo empaparme de ella podría estarme horas leyendo datos técnicos del hilo, y por desgracia o mas bien dicho por desconocimiento técnico, prácticamente me quedaría absolutamente igual xd

Yo apoyo la idea de reforzar el tema de análisis, veo descompensado los pocos análisis que hay escritos en las 50 páginas de hilo...