Sezione |
Indirizzi Base
Registri Interni
|
Capitolo 1 |
Il Processore e il Debugger |
DEBUG 7/22 [35 di 60] |
|
|
|
Aggiornato 24 settembre 2003 e 17 febbraio 2005 |
|
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:
|
|
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 |
|
Capitolo 1 | DEBUG 7/22 | |||||||
35 di 60 |
|
|
|
|
Home |
|
|||||||
|
Motore Ricerca |
|