JavascriptProva

martedì 5 giugno 2012

Rudimenti di terminale Linux: spostare e copiare cartelle

Adesso che ho imparato a creare e distruggere cartelle vuote e piene, mi rimane spostare e copiare cartelle.

Creo una cartella:
antonello@ubuntu:~$ ls
Documenti         Immagini  Musica    Scaricati  Video
examples.desktop  Modelli   Pubblici  Scrivania
antonello@ubuntu:~$ mkdir MiaCartella
antonello@ubuntu:~$ ls
Documenti         Immagini     Modelli  Pubblici   Scrivania
examples.desktop  MiaCartella  Musica   Scaricati  Video
antonello@ubuntu:~$ cd MiaCartella
antonello@ubuntu:~/MiaCartella$ mkdir Uno
antonello@ubuntu:~/MiaCartella$ mkdir Due
antonello@ubuntu:~/MiaCartella$ ls
Due  Uno
antonello@ubuntu:~/MiaCartella$ cd Uno
antonello@ubuntu:~/MiaCartella/Uno$ mkdir CartellaDelCavolo
antonello@ubuntu:~/MiaCartella/Uno$ ls
CartellaDelCavolo
antonello@ubuntu:~/MiaCartella/Uno$ cd ..
antonello@ubuntu:~/MiaCartella$ cd ..
antonello@ubuntu:~$ 
Ecco: ho creato una cartella CartellaDelCavolo posta nella cartella Uno.
La voglio spostare nella cartella Due.
antonello@ubuntu:~$ mv MiaCartella/Uno/CartellaDelCavolo MiaCartella/Due/CartellaDelCavolo
antonello@ubuntu:~$ cd MiaCartella/Uno
antonello@ubuntu:~/MiaCartella/Uno$ cd ../Due
antonello@ubuntu:~/MiaCartella/Due$ ls
CartellaDelCavolo
antonello@ubuntu:~/MiaCartella/Due$ 
Fatto.
Adesso copio la cartella anche nella cartella Uno: Dopo vari impazzimenti ho capito che cp funzionerà per i files, ma non per le cartelle per le quali ci vuole il parametro -r.

Ecco l'errore:
antonello@ubuntu:~$ cp MiaCartella/Due/CartellaDelCavolo MiaCartella/Uno/CartellaDelCavolo
cp: omitting directory `MiaCartella/Due/CartellaDelCavolo'
antonello@ubuntu:~$ 


Ed ecco la correzione:
antonello@ubuntu:~$ cp -r MiaCartella/Due/CartellaDelCavolo MiaCartella/Uno/CartellaDelCavolo
antonello@ubuntu:~$ cd MiaCartella/Uno
antonello@ubuntu:~/MiaCartella/Uno$ ls
CartellaDelCavolo
antonello@ubuntu:~/MiaCartella/Uno$ cd ..
antonello@ubuntu:~/MiaCartella$ cd Due
antonello@ubuntu:~/MiaCartella/Due$ ls
CartellaDelCavolo
antonello@ubuntu:~/MiaCartella/Due$ 
Ecco che funziona: la cartella si trova in tutte e due le cartelle!

lunedì 4 giugno 2012

Rudimenti di terminale Linux

Parallelamente, riattacco Linux.
Ubuntu versione 12.04

Terminale:
io@ubuntu:~$ 
Su quale directory mi trovo?
Qual è il comando analogo al DIR del dos?
Non lo ricordo... vediamo.

Ecco, dovrebbe essere ls.
Ci provo.
io@ubuntu:~$ ls
Documenti         Immagini  Musica    Scaricati  Video 
examples.desktop  Modelli   Pubblici  Scrivania 
io@ubuntu:~$ 
Bene.
Ricordo che c'è un codice colore.
Qui mi vengono delle voci colorate in azzurro. Cosa saranno?
Dovrebbero essere delle directory, mentre quello scritto normalmente è un'altra cosa.
Vediamo se trovo materiale su questo codice colore...

Sì: eccolo: questo blu è il colore delle directory.
Ora, quindi, se queste sono cartelle, scendiamo più a fondo in una di queste.
Come si fa a cambiare cartella? Vediamo qual è il corrispettivo di CD.

Dovrebbe essere sempre cd.
Proviamo.
io@ubuntu:~$ cd documenti
bash: cd: documenti: No such file or directory
io@ubuntu:~$ cd Documenti
io@ubuntu:~/Documenti$
E infatti funziona, con l'unica avvertenza che Linux è case sensitive!

Adesso elenco il contenuto della sottocartella Documenti.
io@ubuntu:~/Documenti$ ls
io@ubuntu:~/Documenti$ 
E' vuota.
Vediamone un'altra:
io@ubuntu:~/Documenti$ cd..
cd..: command not found
io@ubuntu:~/Documenti$ cd ..
io@ubuntu:~$ cd Immagini
io@ubuntu:~/Immagini$ ls
io@ubuntu:~/Immagini$ cd ..
io@ubuntu:~$ cd Scrivania
io@ubuntu:~/Scrivania$ ls
gnome-terminal.desktop
io@ubuntu:~/Scrivania$ 
Ho combinato alcuni macelli.
Ma ho imparato alcune cose.
Per ritornare al livello superiore si digita quasi come in DOS cd .. ma senza slash, e con uno spazio prima dei puntini, altrimenti non funziona.
Sono sceso nella directory Scrivania e ottengo un file colorato in verde.
Che significa?

Ecco la risposta che ho trovato:
Green color - Executable or recognized data file
Dunque questo file, essendo il terminal, è un file eseguibile, e per questo è verde!

Ora dei comandi sulle cartelle... In effetti, per il DOS non è che li ricordi tutti... Potrebbe essere un'occasione per ripassarli anche per il DOS.

Una cartella si può creare, distruggere, spostare, copiare.
io@ubuntu:~$ mkdir Cavolata
io@ubuntu:~$ ls
Cavolata   examples.desktop  Modelli  Pubblici   Scrivania
Documenti  Immagini          Musica   Scaricati  Video
io@ubuntu:~$ rmdir Cavolata
io@ubuntu:~$ ls
Documenti         Immagini  Musica    Scaricati  Video
examples.desktop  Modelli   Pubblici  Scrivania
io@ubuntu:~$ 
Perfetto!

Però eliminare una cartella non vuota è diverso.
Metto un file di testo inventato sul momento in una cartella di nuova creazione, usando la finestra...

Ecco la situazione:
io@ubuntu:~$ ls
Cavolata   examples.desktop  Modelli  Pubblici   Scrivania
Documenti  Immagini          Musica   Scaricati  Video
io@ubuntu:~$ cd Cavolata
io@ubuntu:~/Cavolata$ ls
cavolicchio
io@ubuntu:~/Cavolata$ 
Ora torno al livello superiore e provo a rimuovere la cartella Cavolata con rmdir.
io@ubuntu:~/Cavolata$ cd ..
io@ubuntu:~$ rmdir Cavolata
rmdir: failed to remove `Cavolata': Directory not empty
io@ubuntu:~$ 
E ottengo un messaggio di errore proprio perchè la directory non è vuota.

Il comando è rm -rf.
Proviamo:
io@ubuntu:~$ rm -rf Cavolata
io@ubuntu:~$ ls
Documenti         Immagini  Musica    Scaricati  Video
examples.desktop  Modelli   Pubblici  Scrivania
io@ubuntu:~$ 
E funziona!

sabato 2 giugno 2012

Dissezione del file oggetto: il campo Locat del subrecord FIXUP del record FIXUPP

Dunque...

Vediamo cosa abbiamo ricavato finora.

I record SEGDEF definiscono le caratteristiche dei vari segmenti.
In pratica, definiscono:
  • L'allineamento;
  • Il rango (combine);
  • la lunghezza.

I record LEDATA, per quanto ricordo, contengono il "contenuto" vero e proprio dei segmenti.

La parte più difficile è il record FIXUPP.
Esso, a parte i primi tre bytes di rito, contiene un subrecord che, a quanto ho capito, può essere di due tipi: FIXUP o THREAD (non meglio da me conosciuti, prendiamoli per buoni).
Se si tratti di un subrecord FIXUP o THREAD, dipende dal primo byte di questo subrecord.
Vediamo sul pratico...

Il codice che identifica il record FIXUPP è il 9C.
00 B4 00 CD 16 B4 4C CD-21 F2 9C 0F 00 C8 03 54
01 C4 10 54 01 C4 15 50-02 07 00 DA 8A 06 00 C1


Eccolo isolato:
9C 0F 00 C8 03 54 01 C4 10 54 01 C4 15 50 02 07 00 DA


...e depurato dei tre bytes rituali iniziali e dell'ultimo (checksum):
C8 03 54 01 C4 10 54 01 C4 15 50 02 07 00

Ora, questa sequenza di bytes è fatta di un unico sottorecord, che può essere di tipo THREAD o di tipo FIXUP, e la differenza è specificata dal primo bit.
Mi sembra ovvio che, essendo il primo bytes C8, il primo bit è pari a 1, il che significa che si tratta di un sottorecord di tipo FIXUP.

Salto tutto il capitolo del documento relativo ai subrecord di tipo THREAD e vado a qualli di tipo FIXUP.

Il primo campo del subrecord FIXUP si chiama Locat, ed è lungo due bytes.
Eccolo isolato:
C8 03 54 01 C4 10 54 01 C4 15 50 02 07 00
  • Il primo bit del campo Locat è quello che identifica il record come di tipo FIXUP.
  • Il secondo bit del campo Locat distingue fra self-relative e segment-relative fizup. Non ricordo bene cosa significhi, ho una vaga idea...
  • I successivi 4 bit formano il sottocampo Location e specificano il tipo di aggiustamento che va fatto: credo si tratti di specificare se quello da aggiustare è l'offset o l'indirizzo di segmento o ambedue...
  • I restanti 10 bits formano il Segment Data Offset, ossia indicano la posizione dove effettuare il riaggiustamento nel record LEDATA precedente.

Che macello!!!.
Vediamo il campo Locat di questo subrecord di tipo FIXUP:
C8 03 = 1100-1000 0000-0011
Dividiamo i sottocampi:
1-1-0010-0000000011.
Il primo bit è 1, il che identifica questo sottorecord come un sottorecord di tipo FIXUP e non THREAD.
Il secondo bit è 1, il che significa che si tratta di un aggiustamento segment-relative.
Il campo successivo è Location, e indica il tipo di aggiustamento che va fatto, in questo caso il suo valore è 2, e significa che è un aggiustamento 16 bit-base.
Vediamolo con dispObj:
FIXUPP:  Type 9C, Offset 006A
         Segment-relative base location 003 (003),
           Frame & Target segment DATA
         Segment-relative word offset location 010 (010),
           Frame & Target segment DATA
         Segment-relative word offset location 015 (015),
           Frame & Target segment TEXT, offset 0007
    0000:9C 0F 00 C8 03 54 01 C4-10 54 01 C4 15 50 02 07 ­ ...╚.T.─.T.─.P..
    0010:00                                              ­ .
Ho beccato il primo di tre aggiustamenti.
"Segment-relative base location".

E abbiamo visto i primi tre sottocampi di Locat.
Adesso vediamo l'altro, che è 00000000011, ossia 3, e indica in quale offset del LEDATA precedente va fatto l'aggiustamento.
Corrisponde a quanto detto dal dispObj, ossia 003.
Andiamo a vedere il LEDATA:
0000:EB 07 BA 00 00 8E DA FA-FA B4 00 B0 03 CD 10 A1
0010:00 00 2E 8B 1E 00 00 B4-00 CD 16 B4 4C CD 21
Eccolo!

Ora mi esercito con gli altri, sempre sul campo Locat.
Riprendo il record, e lo separo nei vari sottorecords FIXUP:
C8 03 54 01 
C4 10 54 01 
C4 15 50 02 07 00
(l'ultimo sottorecord FIXUPP è più lungo, non so perchè, lo vedrò poi) Ecco i campi Locat.
1100-1000 0000-0003

1100-0100 0001-0000

1100-0100 0001-0101


Dividiamoli in sottocampi:
1 1 0010 0000000003

1 1 0001 0000010000

1 1 0001 0000010101
Traduzione: Nel primo campo Locat il sottorecord è FIXUP, la correzione è segment-relative, si tratta di una rilocazione dell'indirizzo di segmento (base location). La posizione nel LEDATA è 003.

Nel secondo campo Locat il sottorecord è FIXUP, la correzione è segment-relative, si tratta di una rilocazione di offset. La posizione nel LEDATA è 010.

Nel terzo campo Locat il sottorecord è FIXUP, la correzione è segment-relative, si tratta di una rilocazione di offset. La posizione nel LEDATA è 015.

Confrontiamo col responso di dispObj:
FIXUPP:  Type 9C, Offset 006A
         Segment-relative base location 003 (003),
           Frame & Target segment DATA
         Segment-relative word offset location 010 (010),
           Frame & Target segment DATA
         Segment-relative word offset location 015 (015),
           Frame & Target segment TEXT, offset 0007
Esatto!!!

mercoledì 30 maggio 2012

Dissezione del file oggetto: il record SEGDEF

Mi sono arenato.
Non ricordo più i concetti di classe e combine di un segmento.

Scrivo un sorgentino con le classi.
text SEGMENT "CODE"

inizio: JMP     Procedura

Var     DW 0FAFAH

Procedura PROC   
 MOV AH,00H
 MOV AL,03H
 INT 10H

        MOV     AX,[Var]
        MOV     BX,Var
        
        
        MOV AH,00H
        INT 16H

        MOV AH,4CH
        INT 21H

Procedura ENDP
text ENDS
END inizio
Ecco il record LNAMES del file oggetto:
 96 0C 00 00 04 54 45 58 54 04 43 4F 44 45 F6 
Ecco, ho ottenuto in sequenza il nome del segmento e il nome della classe, TEXT e CODE.

Avendo retrodatato il computer riesco a far funzionare anche il programma dispObj:
LNAMES:  Type 96, Offset 000C
            1: Name
            2: Name TEXT
            3: Name CODE
    0000:96 0C 00 00 04 54 45 58-54 04 43 4F 44 45       ­ .....TEXT.CODE
Quindi vado a SEGDEF:
SEGDEF:  Type 98, Offset 001B
         Reloc para-aligned, combine type none, length 001B
         Segment name TEXT, class CODE
    0000:98 07 00 60 1B 00 02 03-01                      ­ ...`.....
Dove l'allineamento al paragrafo è specificato dal primo sottocampo di tre bytes pari a 3, la combine "none" dal secondo sottocampo di tre bytes pari a zero.
Vengono quindi:
-la lunghezza del segmento pari a 001B (27) bytes;
-l'indice del nome del segmento pari a 02 (ossia TEXT)
-l'indice del nome della classe pari a 03 (ossia CODE).


Adesso mi sbizzarrisco a creare un sorgente con più segmenti:
data SEGMENT "DATI"
uno     dw 1234h
due     dw 3456h
data ENDS

text SEGMENT "CODE"

inizio: JMP     Procedura

Var     DW 0FAFAH

Procedura PROC   
 MOV AH,00H
 MOV AL,03H
 INT 10H

        MOV     AX,[Var]
        MOV     BX,Var
        
        
        MOV AH,00H
        INT 16H

        MOV AH,4CH
        INT 21H

Procedura ENDP
text ENDS
END inizio
Vediamo dispObj:
LNAMES:  Type 96, Offset 000C
            1: Name
            2: Name DATA
            3: Name TEXT
            4: Name CODE
            5: Name DATI
    0000:96 16 00 00 04 44 41 54-41 04 54 45 58 54 04 43 ­ .....DATA.TEXT.C
    0010:4F 44 45 04 44 41 54 49-                        ­ ODE.DATI
SEGDEF:  Type 98, Offset 0025
         Reloc para-aligned, combine type none, length 0004
         Segment name DATA, class DATI
    0000:98 07 00 60 04 00 02 05-01                      ­ ...`.....
SEGDEF:  Type 98, Offset 002F
         Reloc para-aligned, combine type none, length 001B
         Segment name TEXT, class CODE
    0000:98 07 00 60 1B 00 03 04-01                      ­ ...`.....
Ecco: vengono elencati in LNAMES tutti i nomi dei segmenti e delle classo, ed essendoci due segmenti, vengono creati due records SEGDEF.

Il primo è questo:
98 07 00 60 04 00 02 05-01
che si legge:
  • allineamento al paragrafo perchè il primo sottocampo di tre bytes è pari a 3
  • combine=none perchè il secondo sottocampo di tre bytes è pari a zero
  • lunghezza del segmento di 0004 bytes
  • indice del nome del segmento 02, corrispondente a DATA
  • indice della classe del segmento 05 corrispondente a DATI

Il secondo è questo:
98 07 00 60 1B 00 03 04-01
che si legge:
  • allineamento al paragrafo perchè il primo sottocampo di tre bytes è pari a 3
  • combine=none perchè il secondo sottocampo di tre bytes è pari a zero
  • lunghezza del segmento di 001B (27) bytes
  • indice del nome del segmento 03, corrispondente a TEXT
  • indice della classe del segmento 04, corrispondente a CODE.

Quindi, dopo un record LNAMES, che elenca i nomi e le classi dei segmenti, i records SEGDEF specificano per ogni segmento gli attributi (allineamento, combine), la lunghezza di ogni segmento e la corrispondenza con i nomi e le classi specificati in LNAMES.
In pratica, dopo essersi reso conto di tutti i nomi, l'assemblatore elenca i segmenti con nome, classe, lunghezza, allineamento e combine.

Faticosetto, l'argomento!

martedì 29 maggio 2012

Dissezione del file oggetto: record SEGDEF (98H), campo ATTRIBUTI, sottocampo ALLINEAMENTO

Il record SEGDEF (98H) è sicuramente quello che al primo studio di questa roba mi ha dato più grattacapi nel cercare di capirci qualcosa.

SEGDEF:98 07-00 60 1B 00 02 01 01 E2
Il macello sta nel fatto che c'è un campo formato da una serie di lunghezza variabile di bytes che esprimono gli attributi del segmento.
Nella fattispecie abbiamo un byte che vale 60.
Lo scrivo in binario:
01100000
Andiamo per ordine:
Il primo sottocampo è di tre bytes, e vale 011, ossia 3.
Questo è il campo dell'ALIGNMENT del segmento, che può avere i seguenti valori:
  • 0: segmento assoluto (non ricordo più cosa significa)
  • 1: segmento allineato al byte
  • 2: segmento allineato alla word
  • 3: segmento allineato al paragrafo
  • 4: segmento allineato alla pagina
  • 5: segmento allineato alla doubleword
Bene.
Acquisito questo, adesso mi metto a giocare creando segmenti variamente allineati e vedere come varia questo byte.
Anzi parto dall'intenzione di volere un certo valore di questo byte e vediamo se ci riesco variando il sorgente.


Adesso il sottocampo dovrà essere 1, quindi il byte sarà 20.
dati segment byte
dato1 dw 1234h
dato2 dw 5678h
dati ends

text segment
assume cs:text,ds:dati
inizio:
        mov     ah,00h
        mov     al,03h
        int     10h
        
        mov     ah,00h
        int     16h
        
        mov     ah,4ch
        int     21h
       
text ends
end inizio
 80 0A 00 08 6D 69 6F 32-2E 61 73 6D 88 96 0C 00
 00 04 54 45 58 54 04 44-41 54 49 EF 98 07 00 20
Bene!
Adesso il sottocampo dovrà essere 2, quindi il byte sarà 40.
dati segment word
dato1 dw 1234h
dato2 dw 5678h
dati ends

text segment
assume cs:text,ds:dati
inizio:
        mov     ah,00h
        mov     al,03h
        int     10h
        
        mov     ah,00h
        int     16h
        
        mov     ah,4ch
        int     21h
       
text ends
end inizio
80 0A 00 08 6D 69 6F 32-2E 61 73 6D 88 96 0C 00
00 04 54 45 58 54 04 44-41 54 49 EF 98 07 00 40
Ottimo.
Adesso specifichiamo l'allineamento al paragrafo così da trasformare il byte in 60.
Ho capito che l'allineamento di default dei segmenti è al paragrafo.
dati segment para
dato1 dw 1234h
dato2 dw 5678h
dati ends

text segment
assume cs:text,ds:dati
inizio:
        mov     ah,00h
        mov     al,03h
        int     10h
        
        mov     ah,00h
        int     16h
        
        mov     ah,4ch
        int     21h
       
text ends
end inizio
80 0A 00 08 6D 69 6F 32-2E 61 73 6D 88 96 0C 00
00 04 54 45 58 54 04 44-41 54 49 EF 98 07 00 60
Perfetto!
Adesso il sottocampo sarà 4, quindi il byte sarà 80.
dati segment page
dato1 dw 1234h
dato2 dw 5678h
dati ends

text segment
assume cs:text,ds:dati
inizio:
        mov     ah,00h
        mov     al,03h
        int     10h
        
        mov     ah,00h
        int     16h
        
        mov     ah,4ch
        int     21h
       
text ends
end inizio
80 0A 00 08 6D 69 6F 32-2E 61 73 6D 88 96 0C 00
00 04 54 45 58 54 04 44-41 54 49 EF 98 07 00 80
Benissimo!
Adesso il sottocampo sarà 5, quindi il byte sarà A0.
dati segment dword
dato1 dw 1234h
dato2 dw 5678h
dati ends

text segment
assume cs:text,ds:dati
inizio:
        mov     ah,00h
        mov     al,03h
        int     10h
        
        mov     ah,00h
        int     16h
        
        mov     ah,4ch
        int     21h
       
text ends
end inizio
80 0A 00 08 6D 69 6F 32-2E 61 73 6D 88 96 0C 00
00 04 54 45 58 54 04 44-41 54 49 EF 98 07 00 A0
Perfetto!!!

Dissezione del file oggetto: il record LNAMES (96H)

Riporto ancora qui il mio schema:
THEADR:80 09 00 07 6D 69 6F 2E-61 73 6D BC
LNAMES:96 07 00 00 04 54 45 58 54 1A
SEGDEF:98 07-00 60 1B 00 02 01 01 E2
LEDATA:A0 1F 00 01 00 00 EB 02 FA FA B4 00 B0 03 CD 10 2E A1 00 00 2E 8B 1E 00 00 B4 00 CD 16 B4 4C CD 21 F0
FIXUPP:9C 0D 00 C4 0C 50-01 02 00 C4 11 50 01 02 00 0C
MODEND:8A 06 00 C1 50 01-00 00 5E
Dopo i primi tre bytes "rituali", che esprimono il tipo di record e la sua lunghezza, prendiamo il corpo del record.
Esso è fatto di un byte che esprime la lunghezza del nome del segmento e un numero variabile di bytes, che ne esprimono il nome, ambedue questi campi ripetuti per il numero di segmenti che il programma comprende, con uno fisso iniziale di lunghezza zero.

Ne faccio un codice colore:
LNAMES:96 07 00 00 04 54 45 58 54 1A
C'è un primo byte, marcato in celeste, che esprime la lunghezza di una stringa di lunghezza zero, quindi un byte, marcato in celeste, che esprime la lunghezza della stringa contenente il nome dell'unico segmento, marcato in verde: TEXT. Adesso ho scritto rapidamente un sorgentino con due segmenti, e prendo il record LNAMES:
96 0C 00 00 04 44 41 54 49 04 54 45 58 54 EF
. Qui la sequenza lunghezza della stringa-stringa con il nome del segmento è ripetuta due volte: per il segmento DATI e per il segmento TEXT il cui nome appare nei bytes marcati in verde.
Il record LNAMES, espresso dal numero 96H, è un semplice elenco dei nomi dei segmenti di cui è composto il programma.

Dissezione del file oggetto formato OMF

Scaricare il PDF col formato dell'OMF, che se mi sbaglio a digitarlo sul motore di ricerca mi appare tutta la lista dei siti che parlano dell'Ordine dei Frati Minori (OFM)!!!
80H THEADR
Ecco il record:
80 09 00 07 6D 69 6F 2E-61 73 6D BC
Dunque, dunque... qual è la tredicesima lettera dell'alfabeto? La M. E già, ricordiamo anche la firma di Mark Zbikowski 4D: minuscola diventa 6D.

Ecco: la traduzione di questo record è:
  • 80H: questo è il record THEADR
  • 0900: questo record è lungo 9 bytes (escluso il byte che lo identifica e questi stessi due bytes che ne indicano la lunghezza)
  • 07: la stringa riportata in questo record è lunga 7 bytes
  • 6D 69 6F 2E 61 73 6D: "mio.asm"
  • BC: checksum (che devo ancora capire bene come viene calcolato...)

Veniamo a quello successivo.

Voglio stabilire un preciso codice di colore per identificare i campi del record. Ci provo...
C:\Arch-Lab\Lavoro>debug mio.obj
-d
17B1:0100  80 09 00 07 6D 69 6F 2E-61 73 6D BC 96 07 00 00   ....mio.asm.....
17B1:0110  04 54 45 58 54 1A 98 07-00 60 1B 00 02 01 01 E2   .TEXT....`......
17B1:0120  A0 1F 00 01 00 00 EB 02-FA FA B4 00 B0 03 CD 10   ................
17B1:0130  2E A1 00 00 2E 8B 1E 00-00 B4 00 CD 16 B4 4C CD   ..............L.
17B1:0140  21 F0 9C 0D 00 C4 0C 50-01 02 00 C4 11 50 01 02   !......P.....P..
17B1:0150  00 0C 8A 06 00 C1 50 01-00 00 5E 00 00 00 00 00   ......P...^.....
17B1:0160  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
17B1:0170  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
-
Ecco, con l'aiuto del documento PDF che ho scaricato, me li sono identificati tutti.
Ora li riporto singolarmente...
THEADR:80 09 00 07 6D 69 6F 2E-61 73 6D BC
LNAMES:96 07 00 00 04 54 45 58 54 1A
SEGDEF:98 07-00 60 1B 00 02 01 01 E2
LEDATA:A0 1F 00 01 00 00 EB 02 FA FA B4 00 B0 03 CD 10 2E A1 00 00 2E 8B 1E 00 00 B4 00 CD 16 B4 4C CD 21 F0
FIXUPP:9C 0D 00 C4 0C 50-01 02 00 C4 11 50 01 02 00 0C
MODEND:8A 06 00 C1 50 01-00 00 5E
Bene. Ora sarà più facile ragionarci!