Tarjetas flotantes de firmware de CPC

¡Hola a todos!

No sé si esto será algo realmente útil, pero para mí ha sido un proyectito de lo más divertido.

Acabo de activar en todo el foro una herramienta de referencia de firmware para las publicaciones. Ahora, cuando publiques código máquina o rutinas de hardware, al pasar el cursor sobre un vector de firmware, reinicio de kernel, registro CRTC, etc., aparecerá una tarjeta flotante mostrando sus entradas, salidas, registros alterados y un breve resumen de lo que hace.

Funciona en texto normal, código en línea y bloques de sintaxis.

Para lograrlo, convertí la Guía de Firmware de Bob Taylor y Thomas Defoe a formato json:
cpc-glossary.json (112.5 KB) y luego el renderizador del foro extrae los valores si reconoce una entrada (de una lista de 311) en la publicación que estás escribiendo.

Pasa el cursor sobre los vectores en estos fragmentos para verlo en acción:

código en línea:

; Esperar al barrido vertical del marco para evitar nieve en pantalla
call &BD19 ; MC WAIT FLYBACK

; Establecer la tinta del borde a blanco brillante
ld b, 26
ld c, b
call &BC38 ; SCR SET BORDER
ret

bloques preformateados:

; Cambiar a modo 320x200 de 4 colores
ld a, 1
call &BC0E       ; SCR SET MODE

; Imprimir carácter ASCII
ld a, 65         ; 'A'
call &BB5A       ; TXT OUTPUT
ret
; Consultar direcciones del joystick conectado y botones de disparo
call &BB24       ; KM GET JOYSTICK
; H = Joystick 0, L = Joystick 1

Cualquier comentario será más que bienvenido. ¡Siéntanse libres de criticarlo sin piedad también!

¡Oh, esta es una función estupenda!

Déjame probar…

CALL &BB18

CALL &BB18

CALL &BB18

¿Alguien recuerda CALL &BA0A? ¿El que añadía barras verticales a toda la pantalla? ¿Fue un efecto no deseado de saltar en medio de una rutina?

Edición: ¡Me impresiona que funcione incluso cuando se cita o dentro de un bloque de código!

Tardé un poco en solucionarlo, pero estoy contento con cómo funciona (la versión inicial solo funcionaba fuera de los bloques de código porque ahí es donde también funciona el resaltado de sintaxis).

Pensé en hacer lo mismo para BASIC, pero chocaría con el lenguaje natural.

¡Esto está GENIAL!

Mucho mejor que tener que ir a buscar qué hace cada bloque de salto.

¡Ah, qué bueno escuchar eso! Como no soy desarrollador, no tenía idea de si esto iba a ser útil o solo una linda curiosidad. Como dije, fue simplemente algo divertido en lo que trabajar aprovechando las capacidades del foro :slight_smile:

Si tienes alguna idea para mejorarlo, ¡avísame!

¡Oh, es increíble! Me encanta. ¡Buena idea!

¿Quizás si está dentro de bloques de código?

Ya lo hace, ¿a menos que nos refiramos a cosas distintas?

10 PRINT "HELLO"
20 GOTO 10

¿Creo que se refiere a que las palabras clave de BASIC reciben sugerencias en los bloques de código?

Ahhh, te referías a BASIC, vale. Sí, eso se podría hacer.

Mi primer obstáculo es: ¿cuál es el material de origen? Fue bastante fácil convertir la guía del firmware en un documento estructurado como puedes ver en el post original, pero ¿qué usamos como entrada en lo que respecta a BASIC?

Edit: incluso los bloques de código causarían problemas, porque hasta los bloques de ensamblador suelen contener palabras en lenguaje natural que coinciden con palabras clave de BASIC.

Esto se podría resolver usando la entidad personalizada cuando la gente quiera añadir listados de BASIC, como:

10 MODE 1: CALL &BC0E
20 SOUND 1, 478, 50

(ten en cuenta que este es un bloque de código BASIC).

Sin embargo, requeriría que la gente se asegurara de que el código esté marcado correctamente como BASIC.

Hice los bloques de código BASIC cuando implementé el resaltado de sintaxis automático y, en teoría, es automático, pero no está muy probado —desde luego, no por mí.

¡Listo!

Estaría bien que hicieras lo mismo en el propio wiki. Hay al menos una extensión en la que podrías inspirarte: Extension:Lingo - MediaWiki.

De hecho, estaba pensando en eso yo mismo porque el mecanismo subyacente es muy similar, hasta el punto de reutilizar código. Pero, ¿hay suficiente código en la wiki como para justificarlo?

Por lo que he podido comprobar rápidamente, le indica al gate array que cambie al modo 2 sin avisar al firmware.

Es un truco (hack) en toda regla. Salta en medio del código, tal y como dices.

Otra opción, limpia en ensamblador y un poco chapucera desde BASIC, es llamar a MC SET MODE, que hace exactamente esto (una llamada a bajo nivel para configurar el gate array, ignorando el firmware de alto nivel). Compáralo con SCR SET MODE, que establece el modo del firmware y el modo del gate array, y que corresponde a la instrucción MODE de BASIC.

Esta rutina espera el modo de la máquina en el registro A. La instrucción CALL de BASIC guarda en A el número de argumentos. Ya ves por dónde van los tiros:

mode 1
call &bd1c,0,0 'MC SET MODE con dos parámetros, -> modo 2



Configurar un modo de gate array superior al modo del firmware puede dividir los caracteres en barras, si están en PEN 1 o PEN 2.

Configurar un modo de gate array inferior al del firmware puede ser útil para hacer sprites o tilesets multicolores de forma rudimentaria en BASIC. Configura el mode 2 en el firmware con paper 0 : pen 1, con el gate array en modo 1 (o incluso 0). Usa SYMBOL para definir caracteres con patrones pensados para el gate array. El firmware dibuja estos patrones pensando que son monocromáticos, pero el gate array dibuja los colores que tú quieres.
Un carácter ocupa el ancho de un carácter de modo 2, es decir, 4 píxeles en modo 1, 2 píxeles en modo 0, y siempre 8 de altura.
Tileset y/o sprites sin escribir una sola línea de ensamblador. :person_shrugging: