Hovercard del firmware CPC

Ciao a tutti!

Non so se sia qualcosa di veramente utile, ma per me è stato un bel progettinio divertente da realizzare.

Ho appena abilitato in tutto il forum uno strumento di riferimento del firmware all’interno dei post. Quando pubblichi del codice macchina o delle routine hardware, passando il cursore sopra un vettore del firmware, un riavvio del kernel, un registro CRTC ecc., ora apparirà una scheda che ne mostra input, output, registri alterati e un breve riepilogo di ciò che fa.

Funziona nel testo normale, nel codice in linea e nei blocchi con sintassi evidenziata.

Per farlo, ho convertito la Guida al Firmware di Bob Taylor e Thomas Defoe in formato json:
cpc-glossary.json (112.5 KB) e poi il motore di rendering del forum estrae i valori se riconosce una voce (da un elenco di 311) in un post che stai scrivendo.

Passa il cursore sopra i vettori in questi frammenti per vederlo in azione:

codice in linea:

; Wait for frame flyback to avoid screen snow
call &BD19 ; MC WAIT FLYBACK

; Set border ink to bright white
ld b, 26
ld c, b
call &BC38 ; SCR SET BORDER
ret

blocchi preformattati:

; Switch to 320x200 4-colour mode
ld a, 1
call &BC0E       ; SCR SET MODE

; Print ASCII character
ld a, 65         ; 'A'
call &BB5A       ; TXT OUTPUT
ret
; Query attached joystick directions and fire buttons
call &BB24       ; KM GET JOYSTICK
; H = Joystick 0, L = Joystick 1

Qualsiasi feedback sarà più che benvenuto — sentiti libero anche di criticarlo del tutto!

Oh, questa è una bella funzionalità!

Fammi provare…

CALL &BB18

CALL &BB18

CALL &BB18

Qualcuno si ricorda di CALL &BA0A? Quella che aggiungeva barre verticali a tutto lo schermo? Era un effetto indesiderato dovuto al salto nel mezzo di una routine?

Modifica: Devo dire che sono davvero impressionato dal fatto che funzioni anche quando è citato o all’interno di un blocco di codice!

Ci è voluto un po’ per risolverlo, ma sono contento di come funziona (la versione iniziale funzionava solo all’esterno dei blocchi di codice, perché è lì che funziona anche l’evidenziatura della sintassi).

Ho pensato di fare la stessa cosa anche per il BASIC, ma andrebbe in conflitto con il linguaggio naturale.

Questo è DAVVERO fantastico!

Molto meglio che dover andare a controllare cosa fa ciascun blocco di salto.

Ah, mi fa davvero piacere sentirlo. Non essendo uno sviluppatore, non avevo idea se sarebbe stato utile o solo un carino orpello — come ho detto, era solo un progetto divertente su cui lavorare sfruttando le funzionalità del forum :slight_smile:

Se hai qualche idea su come migliorarlo, fammi sapere!

Oh, fantastico. Lo adoro. Un’ottima idea!

Forse se all’interno di blocchi di codice?

Lo fa già, a meno che non intendiamo cose diverse?

10 PRINT "HELLO"
20 GOTO 10

I tag di chiave del linguaggio BASIC ricevono suggerimenti nei blocchi di codice, credo sia questo quello che si intende?

Ahhh intendevi per il BASIC, ok. Sì, si potrebbe fare.

Il mio primo ostacolo è: qual è il materiale di partenza? È stato abbastanza facile convertire la guida del firmware in un documento strutturato come puoi vedere nel post originale, ma cosa usiamo come base per il BASIC?

Edit: persino i blocchi di codice causerebbero problemi, perché anche i blocchi in assembly tendono a contenere parole del linguaggio naturale che sono anche parole chiave del BASIC.

Questo si potrebbe risolvere usando l’entità personalizzata quando le persone vogliono aggiungere listati in BASIC, tipo:

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

(nota che questo è un blocco di codice BASIC).

Tuttavia, richiederebbe che le persone si assicurino che il codice sia evidenziato correttamente come BASIC.

Ho creato i blocchi di codice BASIC quando mi sono occupato dell’evidenziazione automatica della sintassi e, in teoria, è automatica, ma non è molto testata — di sicuro non da me.

Fatto!

Sarebbe ottimo se facessi lo stesso sul wiki stesso. C’è almeno un’estensione da cui potresti prendere ispirazione - Extension:Lingo - MediaWiki.

Ci stavo pensando anch’io, in realtà, perché il meccanismo sottostante è davvero molto simile, al punto da poter riutilizzare il codice. Ma c’è abbastanza codice sulla wiki da giustificare una cosa del genere?

Da un rapido controllo, dice al Gate Array di passare alla modalità 2 senza informare il firmware.

È decisamente un hack. Salta proprio nel mezzo del codice, come dici tu.

Un’altra opzione, pulita in assembly e leggermente un hack da BASIC, è chiamare MC SET MODE che fa esattamente questo (chiamata a basso livello per impostare il Gate Array, ignorando il firmware di livello superiore). Confrontala con SCR SET MODE che imposta sia la modalità del firmware sia quella del Gate Array e corrisponde all’istruzione MODE del BASIC.

Questa routine si aspetta la modalità della macchina nel registro A. Il CALL del BASIC imposta nel registro A il numero di argomenti. Immagini già dove va a parare:

mode 1
call &bd1c,0,0 'MC SET MODE con due parametri, -> mode 2



Impostare una modalità del Gate Array più alta rispetto a quella del firmware può dividere i caratteri in barre, se si trovano in PEN 1 o PEN 2.

Impostare una modalità del Gate Array più bassa rispetto a quella del firmware può essere utile per creare sprite o tileset multicolor «dei poveri» in BASIC. Imposta mode 2 nel firmware con paper 0 : pen 1, e il Gate Array in mode 1 (o persino 0). Usa SYMBOL per definire i caratteri con i pattern pensati per il Gate Array. Il firmware disegna questi pattern credendo che siano monocromatici, mentre il Gate Array disegna i colori che intendi tu.
Un carattere occupa la larghezza di un carattere in mode 2, quindi 4 pixel in mode 1, 2 pixel in mode 0, e sempre un’altezza di 8.
Tileset e/o sprite senza scrivere una singola riga di assembly. :person_shrugging: