| 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 | 
 |