|
 |
Il Processore e il Debugger |
DEBUG 7/22
[35 di 60] |
|
 |
|
Aggiornato
24 settembre 2003 e 17 febbraio 2005 |
 |
|
Comando D - Analizza il contenuto della memoria [seconda
parte] |
|
 | La potenza di DUMP sta
nella sua capacità di ficcare il naso nella memoria..., in
tutta la memoria! |
| Specificando l'indirizzo desiderato
ci viene offerta la possibilità di verificare
concetti e idee maturate in altri ambiti di studio; per esempio possiamo vedere se la
Ram del Video è effettivamente costituita da bytes alternati di carattere (ascii)
e di colore (attributo); basta specificare, dopo il comando
D, l'indirizzo di quell'area,
B800:0000: |
 |
Se fai click sull'icona a
sinistra si apre l'Ambiente Assembly
e puoi
provare DEBUG
on-line.
Scegli
il pulsante di opzione "Aprire il file" o "Esegui
l'applicazione"
e conferma
con
OK.
NB: alcuni gestori di protezione (per esempio SP2 di WinXP) non ti consentono questa operazione:
in questo caso scrivi c:\arch-lab\bin\sys\assembler.pif direttamente nel campo indirizzo del Browser |
 |
| Straordinario:
l'indagine ci dice che
le prime 128 locazioni contengono 64 coppie consecutive
di bytes 20H/07H.. Ma che
significa? |
| Intanto ciascuna coppia è una banale
sequenza di bytes, ma il loro significato,
nell'ambito nel quale sono stati trovati, non è banale! Nella
Ram Video il primo è il carattere
effettivamente presente sul monitor (e, poichè ha valore
20H si tratta di uno spazio, come
risulta dalla
caratteri
Ascii standard), mentre il secondo
è il codice associato al suo colore (poichè è 07H
si tratta di bianco su nero, come risulta dal
byte d'attributo di colore presentato in
in questa pagina). |
| Dunque quella strana sequenza di bytes, mostrata con fredda
determinazione dal debugger, rappresenta i primi 64 caratteri posti sul
monitor, a cominciare dal primo, nell'angolo in alto a sinistra..
praticamente 64 spazi invisibili (perchè
anche se colorati di bianco su nero sempre
spazi sono...) |
| In effetti, se tenti di verificare direttamente questo evento è difficile che la
schermata sia uguale a quella che ti ho proposto qui sopra.. Il
debug è un fedele servitore e codifica quello
che trova sul monitor in quel momento.. la codifica proposta nello schema
precedente è relativa ad uno schermo completamente vuoto... |
| Per fare un passo avanti proviamo ad
eliminare il prompt colorato, a
pulire lo schermo e a
lanciare Debug; i comandi da dare sono, in
sequenza:
prompt $p$g , CLS
e debug, tutti confermati con
invio. |
| Ecco cosa vedremo dopo aver dato anche il comando
-d b800:0000: |
| Che è successo? Debug
ha codificato quello che ha trovato: ogni carattere presente sul monitor,
a
gruppi di 64 alla volta; poichè la prima riga del monitor è vuota (cioè i
primi 80 caratteri sono tutti spazi) per cominciare a notare qualcosa bisogna
dare un altro comando
-d... Solo
nel secondo elenco si comincia a capire il meccanismo. |
| Le prime coppie diverse da 20H/07H
sono proprio visibili a partire dal 161° bytes (quello
all'indirizzo B800:00A0): infatti:
 | i primi 160 bytes sono 80
bytes
20H
e 80
bytes
07H;
e rappresentano gli 80 spazi della prima riga vuota del monitor. |
| i successivi bytes sono per metà al valore
07H perchè il colore della frase
presente sul monitor è, appunto, bianco su nero (=07H)... |
| ... mentre l'altra metà sono i bytes 43H, 3AH, 5CH, 41H, 52H, 43H, 48H, 2DH, ...,
appunto la traduzione esadecimale dei caratteri che compongono le frasi a
video, C:\ARCH-LAB\LAVORO>DEBUG |
|
| Del resto il buon Debug
cerca di aiutarci a capire inserendo a destra la traduzione Ascii dei bytes
trovati, indicando tra un carattere e l'altro un puntino, non riuscendo ad
associare al colore
07H altro simbolo;
cosicché la frase trovata e ricostruita è proprio quella
attualmente a video:
C:\ARCH-LAB\LAVORO>DEBUG |
©
2001-2010 - Studio Tecnico
ing. Giorgio OBER
Tutti i diritti sono riservati
|
