En Amiga, ¿qué sucede cuando escribo en $DFC5A0 por error?
Estoy arreglando un juego (TV Sports Basketball) que intenta escribir datos de audio (usando el rango $DFF0A0
a $DFF0D0
) pero por alguna razón (mala programación), el índice es a veces (no siempre) falso
MOVEA.L #$00DFF0A0,A0 ;004e78: 207c00dff0a0 load custom address in A0
MOVE.W $0008(A5),D0 ;004e80: 302d0008 audio channel 0-3
LSL.W #4,D0 ;004e84: e948 shifting (mul by 16)
MOVE.L -$346E(A4),(A0,D0.W) ;004e86: 21accb920000 write to register
si D0
es mayor que 3, entonces la escritura (A0,D0.W)
está fuera de los límites. En mi caso, escribe a $DFC5A0
, porque después de cambiar D0
es $D500
. También depende de la ubicación de la memoria de la expansión de la memoria (usar solo la memoria del chip no activa el error).
Sé que el sistema de direccionamiento de Amiga tiene máscaras para registros personalizados y CIA, y tal vez realmente escriba en la dirección correcta (lo dudo con $D50
un valor base para el índice del canal...), pero si soluciono el problema por eliminando la escritura cuando el índice está fuera de rango, tal vez el sonido no funcione, mientras que funciona con esa dirección falsa.
Por ejemplo, si escribo algo en $DFC09A
él, en realidad tiene un efecto sobre $DFF09A
(INTENA, más fácil de comprobar con este registro en particular que tiene una contraparte de solo lectura), pero si escribo en $DFC59A
él, no tiene ningún efecto sobre INTENA.
No quiero dejar esa dirección falsa como está, porque viola el diseño de la memoria. ¿Existe una fórmula para enmascarar esta dirección y volver al $DFF0A0 - $DFF0D0
rango?
Respuestas
nota: estoy respondiendo mi propia pregunta después de más investigación y experimentación.
La $DFF000
base es la dirección base de registro de chip personalizada recomendada por Commodore .
Pero muchas otras direcciones base funcionan. Algunas líneas de dirección seleccionan la base de chip personalizada y otras se ignoran.
El área de dirección del chip personalizado es DF0000-DFFFFF
así que cualquier base $DFx000
funciona.
Esto se confirma haciendo algunas pruebas en el emulador WinUAE, que es muy fiel en esos aspectos, y que tiene la interesante capacidad de poder leer lo que está escrito en el registro usando su depurador interno.
Entonces, si escribo $12345678
, $DFC0A0
por ejemplo, $12345678
aparecerá $DFF0A0
cuando lea registros personalizados (usando el emulador): $DFC000
es tan bueno como $DFF000
una dirección base de chip personalizada, y algunos juegos (por ejemplo, Curse of Ra) usan direcciones base personalizadas alternativas (Curse of Ra usa $DFE000
), tal vez para confundir a los piratas informáticos, o simplemente para ser original.
Ahora, cuando escribo un valor de 32 bits $DFC5A0
(ejemplo de la vida real), la dirección se traduce en registros personalizados $1A0
y $1A2
cuáles son los registros de color 16 y 17 ( $5A0
está enmascarado $1A0
, solo hay $ 100 registros personalizados de 16 bits, cualquier bit superior se ignora ), por lo que en ese caso, el registro de audio no está escrito, sino los registros de color, por lo que realmente hay un error en la rutina de sonido.
Ahora, ¿por qué no tiene un efecto visual? Porque escribir en registros de color normalmente no tiene ningún efecto: la mayoría de las listas de cobre sobrescriben las de cada inicio del haz, cada 20 ms en PAL. Puede ser perceptible para el color de fondo (el fondo parpadeará brevemente), pero para los colores de primer plano sería apenas visible o incluso invisible.
Así que ahora solo tengo que decidir si no realizo ninguna acción en ese caso (como en el juego original) o si enmascaro el valor para seleccionar un canal de audio válido y ver si cambia el sonido, y tal vez corregir un error a largo plazo en el juego.