Inizio

Prima - Prec - Contenuti - Prossima - Ultima

English - Deutsch - Español

Appendice E: Formati File dell'Emulatore

Questa sezione descrive tutti i formati file comuni nel campo di emulazione del commodore 64. Ciò è rivolto al programmatore interessato, il quale potrebbe desiderare imparare i funzionamenti interni dell'emulatore. Se siete soltanto interessati al vostro gioco favorito C64, allora non dovete preoccuparvi per questi particolari.

Power64 usa icone differenti per la varia disposizione del file. Poiché Power64 permette l'uso GZ/zip o files compressi LHA, molte delle icone vengono in tre sottotipi. Un'icona un normale per i files non compressi, un'icona con un nastro giallo per indicare compressione di GZ e un'icona con un nastro rosso per compressione ZIP. I files compressi LHA non trasportano un'icona un speciale che indica il tipo del file. Poiché sono così rari, un'icona semplice del documento LHA è usata per tutti i tipi di files compressi LHA.

E.1 Formato Programma *.P00

Il *.P00 è una formato flessibile del file, che può sostenere tutti i tipi comuni di files C64. Poichè ha una costante magica in testa al file inoltre permette tutti'emulatore di assicurarsi che nessun file non valido è usato. Ciò gli rende il formato suggerito del file per i singoli files.

typedef struct
 {
  Byte P00Magic[8];    /* $00 - $07 */
  Byte OrigFName[17];  /* $08 - $18 */
  Byte RecordSize;     /* $19 */
  Byte Dati[n];        /* $1A - ... */
 } P00File;

`P00Magic`	- Costante Magica 'C64File' = {$43, $36, $34, $46, $69, $6C, $65, $00}
`OrigFName`	- Nome del file Originale C64 (CBM Charset)
`RecordSize`	- Registra dimensione per files RELativi
`Dati`	- I dati attuali

Questo formato file era il primo usato da Wolfgang Lorenz in PC64. Nota che l'estensione *.P00 non è fissa. Piuttosto la 'P' sta per 'PRG' e può divenire un 'S' per 'SEQ', o 'R' per 'REL'. Inoltre lo '00' può essere usato per contare '01','02','03'... per risolvere conflitti di nome causato da un troncamento a 16 caratteri di un file C64 a un nome 8+3 MS-DOS . Naturalmente questo non è rilevante su un Macintosh, è solo un consiglio, se ti dovrebbe mai accadere per eseguire un file *.P01.

E.2 Formato Programma *.C64

Il formato *.C64 è il formato esatto che il C64 originale usa per immagazzinare programmi sia su disco o nastro.

typedef struct
 {
  Byte LoadAddrLow, LoadAddrHigh; /* $00 - $01 */
  Byte PrgData[n];                /* $02 - ... */
 } C64File;

`LoadAddr`	- L'indirizzo in RAM alla quale il programma avrà immagazzinato quando ha caricato con dispositivo secondario numero 1.
`PrgData`	- Il programma attuale.

Quesformattare file era introdotto al mondo degli emulatori da Miha Peternel in C64S. Come si può vedere dalla descrizione sopra questo è piuttosto un semplice formato. E' tuttora sconsigliato perché non fornisce emulatore la conoscenza di distinguere files validi e non per il loro uso.

E.3 Formato Disco Immagine Floppy *.X64

Il formato *.X64 è flessibile per immagine disco che supporta un vasto campo di dischi floppy. Nota così, che l'implementazione di *.X64 in Power64 può solo gestire dischi 1541.

typedef struct
 {
  Byte X64Magic[4];   /* $00 - $03 */
  Byte Version[2];    /* $04 - $05 */
  Byte DiskType;      /* $06 */
  Byte TrackCnt;      /* $07 */
  Byte SecondSide;    /* $08 */
  Byte ErrorFlag;     /* $09 */
  Byte Reserved[22];  /* $0A - $1F */
  Byte DiskInfo[31];  /* $20 - $3E */
  Byte ConstZero;     /* $3F */
  Byte DiskImage[683 * 256];
 } X64File;

`X64Magic`	- Costante magica 'C'1541/64 = `{$43, $15, $41, $64}`
`Versione`	- Versione C1541 2.6 = `{$02, $06}`
`DiskType`	- Floppy disco tipo: 1541 = `{$01}` Altri valori definiti: (non utile per Power64) `0..1540, 1..1541, 2..1542, 3..1551, 4..1570, 5..1571, 6..1572, 8..1581, 16..2031&4031, 17..2040&3040, 18..2041 24..4040, 32..8050, 33..8060, 34..8061, 48..SFD 1001, 49..8250, 50..8280`
`TrackCnt`	- Numero di Tracce sul Disco (Side 0) = {35}
`SecondSide`	- E' un Disco a Doppio Lato (0..No, 1..Si) = {$00}
`ErrorFlag`	- Flag per Errore (significato preciso non chiaro) (inutilizzato)
`Reserved`	- Deve essere $00
`DiskInfo`	- Descriztione dell' Immagine Disco (in ASCII o ISO Latin/1)
`ConstZero`	- Deve essere $00
`DiskImage`	- Settori disco 683 di ogni 256 bytes.

Per più informazioni su DiskImage vedi anche: *.D64.

Il *.X64 formato disco immagine era originariamente creato da Teemu Rantanen per l'uso in X64.
Come *.X64 usa un ben definito header dell' emulatore e fa si che solo validi files sono usati. Questo è un chiaro vantaggio oltre il formato *.D64 (sfortunatamente più diffuso).

E.4 Formato Disco Immagine Floppy *.D64

Il formato *.D64 è una copia 1 a 1 di tutti settori come essi appaiono su un disco floppy. Su un formato disco C1541 (e quindi anche in un *.D64 file) ogni settore consiste di 256 Byte. Per essere capace di trattare settori in cattivo stato il formato *.D64 offre opzionalmente una funzionalità addizionale di errore byte per settore. Un disco che è stato formattato usando lo standard C1541 con il comando NEW avrà 35 tracce contenente un totale di 683 settori. Con l'uso di speciale software è possibile formattare e scrivere su dischi con 40 tracce. Mentre le tracce extra rientrano nelle specifiche originali tali dischi sono leggibili con molti lettori C1541 (Nota: La lettura non richiede speciale software.).

Al momento ci sono 4 differenti tipi di formati *.D64:

683 Settori (= 35 Tracce) senza info errore
(Dimensione Totale: 174848 Byte = 170.75 KByte)
683 Settori (= 35 Tracce) senza info errore
(Dimensione Totale: 175531 Byte = 171.42 KByte)
768 Settori (= 40 Tracce) senza info errore
(Dimensione Totale: 196608 Byte = 192 KByte)
768 Settori (= 40 Tracce) senza info errore
(Dimensione Totale: 197376 Byte = 192.75 KByte)

Nota che le tracce al di fuori dei margini del disco contengono più settori di quelli al centro del disco (Zone Bit Recording). Il numero di settori su ogni traccia è:
Tracce 1..17 - 21 Settori
Tracce 18..24 - 19 Settori
Tracce 25..30 - 18 Settori
Tracce 31..35 - 17 Settori
Tracce 36..40 - 17 Settori (non standard!)

La mappa di allocazione blocco (BAM) è immagazzinata su traccia 18 - settore 0; la directory inizia a traccia 18 - settore 1.

Per immagazzinamento in un immagine *.D64 i settori sono sistemati nel seguente modo:

  Track  1 - Sector  0: Offset   0 * 256
  Track  1 - Sector  1: Offset   1 * 256
                .....
  Track  1 - Sector 20: Offset  20 * 256
  Track  2 - Sector  0: Offset  21 * 256
  Track  2 - Sector  1: Offset  22 * 256
                .....
  Track  2 - Sector 20: Offset  41 * 256
  Track  3 - Sector  0: Offset  42 * 256
                .....
  Track 18 - Sector  0: Offset 357 * 256
  Track 18 - Sector  1: Offset 358 * 256
                .....
  Track 35 - Sector  0: Offset 666 * 256
  Track 35 - Sector  1: Offset 667 * 256
                .....
  Track 35 - Sector 16: Offset 682 * 256

Nota che le tracce sono contate partendo con traccia 1, mentre i numeri settore iniziano con 0.

typedef struct
 {
  Byte DiskImage[SektorCnt][256];
  Byte ErrorInfo[SektorCnt]; /* Optional */
 } D64File;

`DiskImage`	- 256 Bytes per Settore
`ErrorInfo`	- 1 Byte per Settore

Nota che l'informazione di errore per tutti i settori è concentrata alla fine del file. Non c'è interleaving di disco immagine dati e errore informazione per settore di base.
Il significato dell' ErrorInfo è dato nella seguente tavola:

    Codice  Error  Type   1541 errore descrizione
    ----  -----  ----   ------------------------------
     01    00    N/A    Nessun errore, Settore ok.
     02    20    Read   Blocco Header non trovato
     03    21    Seek   Nessuna sync carattere
     04    22    Read   Blocco Dati non presente
     05    23    Read   Errore Checksum in Blocco Dati
     06    24    Write  Verifica Scrittura (su formato)
     07    25    Write  Errore in Verifica Scrittura
     08    26    Write  Protezione Scrittura accesa
     09    27    Seek   Errore Checksum in Blocco header
     0A    28    Write  Errore Scrittura Write
     0B    29    Seek   Non combacia l'ID disco
     0F    74    Read   Disco Non Pronto (nessun dispositivo 1)

E.5 Formato Disco ZipCode (1!, 2!, etc.)

Questo è una compressa versione di un file D64 che è frequentemente trovato sui siti C64 che già sono stati in giro per lungo tempo (e hanno servito i proprietari del C64 prima che l'emulazione divenisse comune). Un singolo D64 è diviso in 4 (35 tracce) o 5 (40 tracce) segmenti. Ogni parte è poi impacchettata usando il semplice metodo di compressione Execute Length Encoding.

Il primario motivo per l'esistenza di quesformattare file è che ogni segmento di tale ZipCode è meno di 44 KByte in dimensione, e può quindi facilmente essere gestito da un reale C64 e il suo lettore 1541 (dopo trasmissione via modem da un BBS). Inoltre l'impacchettamento e lo spacchettamento sono molto veloci su un C64.

Computers moderni, come un Power Macintosh, che sono usati per eseguire emulatori C64 non hanno problema nel gestire files da 171KByte in dimensione (come i D64), così non beneficiano della divisione dn un 1 'largo' file in parecchi più piccoli. Infatti, a causa delle larghe unità di allocazione di un moderno disco fisso e CD-ROM, lo spazio sprecato degli ultimi 4 blocchi semiriempiti dei 4 files è eccede lo spazio dalla compressione. Inoltre formati compressione moderni come Zip, GZ, LHA o SIT offrono migliore compressione che il RLE usato nel ZipCode.

Mentre ZipCode non è la migliore scelta di un formato file per un emulatore è ancora un buon formato su un reale C64 e molti siti offrono i loro files in ZipCode per supportare i fedeli al C64 che continuano ad usare il vero hardware.

Nota che ci sono anche 2 altri Zip formati per il C64, che non sono supportata di Power64. Usano il nome dei prefissi 1!!, 2!!, 3!!… e A!, B!, C!… rispettivamente. Sono descritti nella cllezione di Peter Schepers l'autore di 64COPY (schepers@dcs1.uwaterloo.ca), ma non ho mai visto files in quel formato sul web.

I contenuti del disco floppy è diviso su 4 o 5 segmenti in relazione alla seguente tavola:

   FileName  Traccia Range  Block Count
   --------  -----------  -----------
   1!xxxxxx     1 - 8     168 Sectors
   2!xxxxxx     9 - 16    168 Sectors
   3!xxxxxx    17 - 25    172 Sectors
   4!xxxxxx    26 - 35    175 Sectors
   5!xxxxxx    36 - 40     85 Sectors (solo per immagini disco da 40 tracce)

Tutti i segmenti hanno una simile struttura basata su settori di disco compresso. Nota che il primo header dei segmenti è differente dal resto.

typedef struct
 {
  Byte LoadAddr[2];     /* Konst. $03FE = { 0xFE, 0x03}; */
  Byte FloppyID[2];
  ZipSektor Image[168];
 } ZipSegment_1!;

typedef struct
 {
  Byte LoadAddr[2];     /* Konst. $0400 = { 0x00, 0x04}; */
  ZipSektor Image[...];
 } ZipSegment_n!;       /* n = {2, 3, 4, 5} */

La compressione prende posto su un settore per base settore. Per ogni settore c'è la seguente struttura:

typedef struct
 {
  Byte Track;     /* Track Number and Compression Mode */
  Byte Sector;    /* Sector Number */
  union {
    { Byte NoCompression[256]; } Mode00;
    { Byte SingleByte; } Mode01;
    { Byte Length;
      Byte RepeatChar;
      Byte RLEData[Length]; } Mode10;
   } Dati;
 } ZipSector;

`Track`	- Da il numero di traccia del settore compresso in Bit 5 to Bit 0. Bits 7&6 danno la modalità di compressione.
`Sector`	- Da il numero di settore del settore compresso.
`Data`	- Il significato di `Data` dipende sulla modalità di compressione.

Modalità di compressione:

00 - Nessuna compressione; Il settore è immagazzinato in pieno. I 256 Bytes di Dati danno i contenuti dei settori .

01 - L'intero settore è riempito con un singolo Byte. Un singolo Byte di Dati sarà ripetuto 256 volte per riempire il settore.

10 - Esegui Length Encoded Sector - Length da il numero di Bytes di compresso RLEData. RepeatChar è un Byte che non appare nel settore originale e che è ora usato come un marcatore per pezzi di dati codificati runlength. RLEData, differente da RepeatChar è solo piano, dati decompressi, che possono essere direttamente copiato. Dopo RepeatChar viene rilevato, il next Byte di RLEData dalla lunghezza di esecuzione e un terzo Byte denota il Byte di essere ripetuto.

11 -Non usato

I settori di un traccia NON sono immagazzinati in uno stile lineare (1, 2, 3, 4…). Per fare l'impacchettamento e lo spacchettamento molto più veloce su un reale 1541 interleaving è usato. La corretta sequenza di settori dipende sul numero di settori in un traccia e può essere visto sotto.

Traccia  1-17: 0 11 1 12 2 13 3 14 4 15 5 16 6 17 7 18 8 19 9 20 10
Traccia 18-24: 0 10 1 11 2 12 3 13 4 14 5 15 6 16 7 17 8 18 9
Traccia 25-30: 0  9 1 10 2 11 3 12 4 13 5 14 6 15 7 16 8 17
Traccia 31-40: 0  9 1 10 2 11 3 12 4 13 5 14 6 15 7 16 8

Esempio per il primo dei pochi settori del primo segmento (1!*):

$0000: 0xFE, 0x03,       /* Load Addr. Const $03FE */
$0002: 0x36, 0x34,       /* Floppy ID */
$0004: 0x41, 0x00, 0x00, /* Track 1, Sector  0 filled con 0x00 */
$0007: 0x41, 0x0B, 0x00, /* Track 1, Sector 11 filled con 0x00 */
$000B: 0x41, 0x01, 0x00, /* Track 1, Sector  1 filled con 0x00 */
$0007: 0x01, 0x0C,       /* Track 1, Sector 12 uncompressed Data */
... 256 Byte Data ...
$0109: 0x81, 0x02,       /* Track 1 ,Sector 2 RLE Encoded */
       0x12, 0xEA,       /* 0x12(18) Byte, RepeatChar: 0xEA */
       0x45, 0x22, 0x34, 0x08,/* Plain Data */
       0xEA, 0xD0, 0x77,      /* 0x77 repeated 0xD0 times */
       0x12, 0xFF, 0x00, 0x00, 0x32, 0x11 /* Plain Data */
       0xEA, 0x24, 0x55,      /* 0x55 repeated 0x24 times */
       0xEE, 0x98,            /* Plain Data */
$011F: 0x41, 0x0D, 0x11  /* Track 1, Sector 13 filled with 0x11 */
$0122: ...

E.6 Formato Disco Immagine Floppy *.D71

Il formato file *.D71 è una copia 1:1 di tutti settori come appaiono su un disco floppy 1571. Su un disco formattato C1571 (e quindi anche in un *.D71 file) ogni settore consiste di 256 Byte. Per essere capace di trattare con brutti settori il formato *.D71 opzionalmente funzionalità un addizionale errore byte per settore.

Il lettore disco 1571 usa dischi a doppio lato che contengono 35 Tracce per lato (facendo un totale di 70 tracce). Tracce al il fuori del bordo del disco contengono più settori che di quelli al centro dei dischi (Zone Bit Recording). Il numero dei settori su ogni traccia è:

      Tracks  1..17 - 21 Sectors
      Tracks 18..24 - 19 Sectors
      Tracks 25..30 - 18 Sectors
      Tracks 31..35 - 17 Sectors
      Tracks 36..52 - 21 Sectors (corrispondere Tracks  1..17 - secondo lato del disc)
      Tracks 53..59 - 19 Sectors (corrispondere Tracks 18..24 - secondo lato del disc)
      Tracks 60..65 - 18 Sectors (corrispondere Tracks 25..30 - secondo lato del disc)
      Tracks 66..70 - 17 Sectors (corrispondere Tracks 31..35 - secondo lato del disc)

Comparando questo al Layout di un disco immagine *.D64 come descritto in Appendice E.4 è semplice per vedere che un disco immagine *.D71 semplicemente consiste di immagini *.D64 incollate insieme.

La Block Allocation Map (BAM) è immagazzinata in Traccia 18 - Sector 0 e Traccia 53 - Settore 0. La Directory inizia a Traccia 18 - Sector 1.

Per immagazzinamento in un immagine *.D71 i settori sono arrangiati nel seguente modo:

  Track  1 - Sector  0: Offset   0 * 256
  Track  1 - Sector  1: Offset   1 * 256
                .....
  Track  1 - Sector 20: Offset  20 * 256
  Track  2 - Sector  0: Offset  21 * 256
  Track  2 - Sector  1: Offset  22 * 256
                .....
  Track  2 - Sector 20: Offset  41 * 256
  Track  3 - Sector  0: Offset  42 * 256
                .....
  Track 18 - Sector  0: Offset 357 * 256
  Track 18 - Sector  1: Offset 358 * 256
                .....
  Track 35 - Sector  0: Offset 666 * 256
  Track 35 - Sector  1: Offset 667 * 256
                .....
  Track 35 - Sector 16: Offset 682 * 256
                .....
  Track 36 - Sector  0: Offset 683 * 256
  Track 36 - Sector  1: Offset 684 * 256
                .....
  Track 36 - Sector 20: Offset 703 * 256
                .....
  Track 70 - Sector  0: Offset 1349 * 256
  Track 70 - Sector  1: Offset 1350 * 256
                .....
  Track 70 - Sector 16: Offset 1365 * 256

Nota che le tracce sono contate partendo con traccia 1, mentre i numeri settore iniziano con 0.

E.7 Formato Disco Immagine Floppy *.D81

Il formato file *.D81è una copia 1:1 di tutti settori come appaiono su un disco floppy 1581. Su un disco formattato C1581 (e quindi anche in un *.D81) ogni settore consiste di 256 Byte. Per essere capace di trattare con settori cattivi il *.D81 opzionalmente produce un addizionale byte di errore per settore.

Il lettore disco 1581 usa dischi a lato doppio 3.5" che contengono 40 Tracce per lato (facendo un totale di 80 tracce). Tutte le tracce pare sono numerate su 1 lato del disco, tutte le dispare sull'altro. Quindi la traccia 40 è locata à metà del disco. Ogni traccia contiene 40 settori; Quindi una completa immagine disco 1581 contiene 80*40 = 3200 settori.

Il blocco master floppy è locati sulla Traccia 40 - Sector 0. E' seguito dalla Mappa di Allocazione Blocco (BAM) a Traccia 40 - Settori 1 e 2 e la Directory inizia a Traccia 40 - Settore 3.

Sicché tutte le tracce sono la stesso dimensione di offset di un settore in un disco *.D81 può essere computato con un semplice formula:
Offset = (40 * (Track -1) + Sector) * 256

Nota che le tracce sono countate partendo da traccia 1, mentre i settori da 0.

E.8 Formato File *.Lynx

Il formato file Lynx (o LNX o Ultimate Lynx) era sviluppato da Will Corley per uso sul C64(!). E' disegnato intorno a blocchi di 254 Bytes.Questo corrisponde ai 256 Bytes di un settore disco 1541 meno i 2 Bytes che contengono l'informazione sulla prossima traccia/settore e rende semplice copiare files tra dischi 1541 e files Lynx.
Sfortunatamente l'header Lynx è scritto in un formato che è in qualche modo più duro da gestire che un T64 o D64, e quindi il formato ha ricevuto piccola attenzione dagli autori dell'emulatore.

typedef struct
 {
  Byte Directory[DirSectorCnt * 254];
  Byte Dati[DataSectorCnt * 254];
 } LynxFile;

La Directory inizia con un piccolo programma BASIC quale, quando caricato e in esecuzione, visualizza il messaggio "Usa LYNX per disssolvere questo file". Il messaggio attuale e dimensione del programma puo cambiare. Solitamente, i suoi 94 bytes di lunghezza, da $0000 a $005D. Nota che degli emulatori dipendono sul esatta dimensione di 94 Bytes e anche richiedono che il testo 'LYNX' può essere trovato all'offset $003C fino a $003F.

$0000: 0x01, 0x08, 0x5B, 0x08, 0x0A, 0x00, 0x97, 0x35, /* .......5 */
$0008: 0x33, 0x32, 0x38, 0x30, 0x2C, 0x30, 0x3A, 0x97, /* 3280,0:. */
$0010: 0x35, 0x33, 0x32, 0x38, 0x31, 0x2C, 0x30, 0x3A, /* 53281,0: */
$0018: 0x97, 0x36, 0x34, 0x36, 0x2C, 0xC2, 0x28, 0x31, /* .646,.(1 */
$0020: 0x36, 0x32, 0x29, 0x3A, 0x99, 0x22, 0x93, 0x11, /* 62):.".. */
$0028: 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x22, /* ......." */
$0030: 0x3A, 0x99, 0x22, 0x20, 0x20, 0x20, 0x20, 0x20, /* :."      */
$0038: 0x55, 0x53, 0x45, 0x20, 0x4C, 0x59, 0x4E, 0x58, /* USE LYNX */
$0040: 0x20, 0x54, 0x4F, 0x20, 0x44, 0x49, 0x53, 0x53, /*  TO DISS */
$0048: 0x4F, 0x4C, 0x56, 0x45, 0x20, 0x54, 0x48, 0x49, /* OLVE THI */
$0050: 0x53, 0x20, 0x46, 0x49, 0x4C, 0x45, 0x22, 0x3A, /* S FILE": */
$0058: 0x89, 0x31, 0x30, 0x00, 0x00, 0x00,             /* .10...   */

Questo è equivalente al seguente programma BASIC:

   10 POKE53280,0:POKE53281,0:POKE646,PEEK(162):
        PRINT"<CLS><DOWN><DOWN><DOWN><DOWN><DOWN><DOWN><DOWN><DOWN>":
        PRINT"     USE LYNX TO DISSOLVE THIS FILE":
        GOTO10

Il seguente è un <CR> e il numero di blocchi della directory in ASCII con spazi su ambedue i lati. Per una directory con solo 1 blocco che sarebbe:

$005E:  0x0D, 0x20, 0x31, 0x20, 0x20                    /* . 1     */

Dopo questo c'è la "firma" dell' archivio, un testo in minuscolo CBM (per la maggior parte ASCII) finendo per <CR> che descrive l'archivio Lynx. Normalmente questa firma conterrà una stringa 'LYNX'.
Power64 usa:

$0063: 0x2A, 0x4C, 0x59, 0x4E, 0x58, 0x20, 0x41, 0x52, /* *LYNX AR */
$006B: 0x43, 0x48, 0x49, 0x56, 0x45, 0x20, 0x42, 0x59, /* CHIVE BY */
$0073: 0x20, 0x50, 0x4F, 0x57, 0x45, 0x52, 0x36, 0x34  /*  POWER64 */
$007B: 0x0D

Questo è seguito dal numero di files nell' archivio Lynx, come prima questo è dato come un numero ASCII circondata di spazi e delimitati da <CR>.
Per una directory con 3 files che sarebbero:

$007C: 0x20, 0x33, 0x20, 0x0D                          /*  3 .     */

Following questi headers è l'attuale directory. Ogni file è descritto di its nome del file (in PETASCII, spesso padded to 16 caratteri di shifted-spazios), followed di il dimensione di il file (plus 2 bytes per l'indirizzo) in blocchi di 254 bytes, il file type (P, S, R, U), il dimensione in bytes del ultima blocco. Se il file type è Relative, questo entrata è il Record dimensione, e il next entrata è il ultima blocco dimensione. Se il file type non è Relative, il next entrata sarà il next nome del file. Relative files non sono supportata di Power64. Ogni entrata è terminated di un <CR>, numeri sono surrounded di spazios. Per example questo could essere:

File 1: "Block Out", PRG, 2+2519 Byte (2521 = (10-1) * 254 + 235)
$0080: 0x42, 0x4C, 0x4F, 0x43, 0x4B, 0x20, 0x4F, 0x55, /* BLOCK OU */
$0088: 0x54, 0xA0, 0xA0, 0xA0, 0xA0, 0xA0, 0xA0, 0xA0, /* T        */
$0090: 0x0D, 0x20, 0x31, 0x30, 0x20, 0x0D, 0x50, 0x0D, /* . 10 .P. */
$0098: 0x20, 0x32, 0x33, 0x35, 0x20, 0x0D,             /*  235 .   */

File 2: "Serpentine", PRG, 2+8703 Byte (8705 = (35-1) * 254 + 69)
$009E: 0x53, 0x45, 0x42, 0x4C, 0x45, 0x4E, 0x54, 0x49, /* SERPENTI */
$00A6: 0x4E, 0x45, 0xA0, 0xA0, 0xA0, 0xA0, 0xA0, 0xA0, /* NE       */
$00AE: 0x0D, 0x20, 0x33, 0x35, 0x20, 0x0D, 0x50, 0x0D, /* . 35 .P. */
$00B6: 0x20, 0x36, 0x39, 0x20, 0x0D,                   /*  69 .    */

File 3: "Quadromania", PRG, 2+7056 Byte (7058 = (28-1) * 254 + 200)
$00BB: 0x51, 0x55, 0x41, 0x44, 0x52, 0x4F, 0x4D, 0x41, /* QUADROMA */
$00C3: 0x4E, 0x49, 0x41, 0xA0, 0xA0, 0xA0, 0xA0, 0xA0, /* NIA      */
$00CB: 0x0D, 0x20, 0x32, 0x38, 0x20, 0x0D, 0x50, 0x0D, /* . 28 .P. */
$00D3: 0x20, 0x32, 0x30, 0x30, 0x20, 0x0D,             /*  200 .   */

I files attuali seguono la directory. Ogni file consiste un caricamento dell'indirizzo di 2 bytes più i dati attuali.

Nota che la directory e ogni files dimensione è un multiple di 254 bytes. Se l'attuale informazione richiede meno spazio, poi c'è un wasted gap, che è filled con 0x00 in Power64 (altri implementations vary).

In il sopra example la directory consiste di solo 1 blocco, e quindi Block Out inizia at offset 1 * 254. The secondo file (Serpentine) inizia at offset (1+10) * 254 e Quadromania begins at (1+10+35) * 254.

$00FE: 0x01, 0x08, 0x26, 0x08, 0xC1, 0x07, 0x9E, 0x32, /* ..&.i..2 */
$0106: 0x30, 0x38, 0x38, 0x3A, 0x12, 0x42, 0x4C, 0x4F, /* 088:.BLO */
$011E: 0x43, 0x4B, 0xAB, 0x4F, 0x55, 0x54, ...         /* CK-OUT.. */
... /* (1+10) * 254 = $0AEA */
$0AEA: 0x01, 0x08, 0x26, 0x08, 0xC1, 0x07, 0x9E, 0x32, /* ..&.¡..2 */
$0AF2: 0x30, 0x38, 0x38, 0x3A, 0x12, 0x53, 0x45, 0x52, /* 088:.SER */
$0AFA: 0x50, 0x45, 0x4E, 0x54, 0x49, 0x4E, 0x45,...    /* PENTINE  */
...

E.9 Formato Immagine Nastro *.T64

Il formato file *.T64 è un molto bene designato, sviluppato da Miha Peternel per i C64. Come un disco immagine è capace di contener molti files logici; un grande aiuto quando si cercano di tenere parecchi files organizzati. D'alra parte c'è molta piccola organizazione in generale, sia in termini di spazio perduto sul file di sistema host e in termini di tempo di carica per il emulatore. Come un file *.T64 contiene un header magico è inoltre per l' emulatore per prevenire files non validi dall'essere usato.

typedef struct
 {
  TapeHeader Header;          /*  $0000  -  $003F  */
  TapeEntry  Entry[MaxFiles]; /*  $0040  - ($03FF) */
  Byte       Dati[n];         /* ($0400) -   ...   */
 } T64File;

`Header`	- Informazione Generica; contenente una Stringa Magica per identificare un file *.T64, il numero di files sul nastro etc... (vedi sotto per dettagli)
`Entry`	- Directory Nastro; Una lista di tutti i files immagazzinato sul nastro. Il Valore Massimo di Files è definito nell'Header, ma è solitamente 30. (vedi sotto per dettagli)
`Dati`	- I dati attuali per tutti i files.

typedef struct
 {
  Byte TapeDescr[32]; /* $00 - $1F */
  Byte Versione[2];    /* $20 - $21 */
  Byte MaxFiles[2];   /* $22 - $23 */
  Byte CurrFiles[2];  /* $24 - $25 */
  Byte Reserved[2];   /* $26 - $27 */
  Byte UserDescr[24]; /* $28 - $3F */
 } TapeHeader;

`TapeDescr`	- Stringa Magica: "C64 nastro immagine file"; riempito con $00 Nota che questa Stringa Magica ha bisogno di non essere verbatim. Cerca per sottostringhe "C64" e "nastro" per identificare un file *.T64. Attenzione: i files immagine nastro TAP (vedi sotto) usano"C64-TAPE-RAW" per una Stringa Magica. Questo anche contiene "C64" e "nastro"!
`Versione`	- Nastro Versione 1.0 = {$00, $01}
`MaxFiles`	- Number di places nel nastro directory. Ci sono dei dei emulatori che rely su fact che ci sono esattamente 30 places nel directory. Quindi tutti *.T64 files creato di Power64 will supply questo value. = {$1E, $00}
`CurrFiles`	- Number di Files correntemente immagazzinato sul nastro. Questo numero can mai exceed MaxFiles. Nota che dei emulatori can solo read il primo file immagazzinato in un *.T64 immagine.
`Reserved`	- MustDeve essere $00.
`UsedDescr`	- Descrizione del Nastro Utente. (Set carattere CBM)

typedef struct
 {
  Byte EntryUsed;     /* $00 */
  Byte FileType;      /* $01 */
  Byte StartAddr[2];  /* $02 - $03 */
  Byte EndAddr[2];    /* $04 - $05 */
  Byte ReservedA[2];  /* $06 - $07 */
  Byte TapePos[4];    /* $08 - $0B */
  Byte ReservedB[4];  /* $0C - $0F */
  Byte FileName[16];  /* $10 - $1F */
 } TapeEntry;

`EntryUsed`	- E' usata questa entrata nella directory *.T64 ? (0..No, 1..Si)
`FileType`	- C'era una piccola documentazione su questo campo. Power64 adotta la nozione di Star Commander che corrisponde al tipo di file identificatori usati su disco floppy: $82..Relocatable Prg, $81..Data File Versioni precedenti di Power64 implementarono il seguente significato: 0..Relocatable Prg., 1..Force Load Prg., 2..Data File Per prevenire messaggi di errore tutti gli altri valori sono anche trattati come programmi riubicalizzabili.
`StartAddr`	- Inizio del destinazione campo in C64 memoria. (Basso/Alto)
`EndAddr`	- Fine del campo destinazione in C64 memoria. (Low/AltaBasso/Alto
`ReservedA`	- Deve essere $00
`TapePos`	- Offset da la partenza del nastro a files logici
`ReservedB`	- Deve essere $00
`FileName`	- Nome del file (set caratteri CBM)

C'era una piccola ufficiale documentazione sul file *.T64 formato. Quello che si sapeva era lo si imparava esaminando file esistenti *.T64. A volte non era fatto con sufficiente scrutinio. Quindi ci sono molti *.T64 su internet che non seguono il formato descritto. E', per example abbastanza common, che il difference tra EndAddr e StartAddr di un file non è consistent con il file dimensione del *.T64 file. Power64 tenta to automaticamente fix tale inconsistencies.

Come riportato sopra ci sono dei emulatori che si affidano sul fatto che ci sono sempre esattamente 30 entrate directory, mentre allo stesso tempo caricheranno sempre il primo file. Per favore ricordalo quando si fanno files C64 disponibili ad un pubblico generico con un vasto campo di emulatori.

Tutti i valori multi-byte sono immagazzinati nel Formato Little-Endian (Basso/Alto) che è generalmente usato dal C64.

E.10 Formato Immagine Nastro .TAP (.RAW)

The *.TAP (o *.RAW) nastro immagine formato, offre un molto precise immagine di un C64 dati nastro. A causa di il alto livello di precisione e detail most del giochetti che were possibile con C64 lettore nastro può essere emulato. Anche caricatori veloci offer no problema. The drawbacks del *.TAP formato sono il loro grande memoria footprint (almeno 8 volte, solitamente 10-12 volte, at worst su to 45 volte il file dimensione di un T64 immagine contenente il stesso dati) e il long, lento per caricare processo (usando le originali routines ROM C64 riguardo 110 bytes/secondo può essere caricato at peak rate, ma a causa della ridondanza per errore correzione net throughput è solo 50 bytes/secondo; usando speciale caricatori veloci riguardo 200-500 bytes/secondo può essere achieved).

L'informazione su un nastro C64 è codificata in singole pulsazioni. Il ritardo del tempo tra 2 sucessive pulsazioni porta l'attuale informazione. Esattamente questi ritardi sono immagazzinati in un file *.TAP .

typedef struct
 {
  Byte TAPMagic[12];     /* $00 - $0B */
  Byte Versione;         /* $0C */
  Byte Reserved[3];      /* $0D - $0F */
  Byte Dimensione[4];    /* $10 - $13 */
  Byte Dati[Dimensione]; /* $14 - ... */
 } TAPFile;

`TAPMagic`	- Constante Magica "C64-TAPE-RAW" = {$43, $36, $34, $2D, $54, $41, $50, $45, $2D, $52, $41, $57}
`Versione`	- $00 o $01: vedi Dati
`Riservato`	- Sempre $00
`Dimensione`	- Dimensione del file *.TAP in formato Little-Endian , escludendo l' header.
`Dati`	- Il ritardo di tempo tra 2 sucessivi pulsa sul nastro. I Valori $01-$FF direttamente rappresententano il timespan tra 2 pulsazioni, misurate in multipli di 8 cicli CPU. (es: un valore di $2E significa che ci sono 8$2E = $170 Cicli di CPU tra 2 pulsazioni). Il valore $00 ha un speciale significato. In versione TAP $00, un valore di $00 significa qualsiasi tempo più lungo di 8$FF cicli CPU. In Versione $01 i 3 bytes seguenti il $00 danno (in formato Little-Endian) il numero di cicli CPU (senza un multiplyer di 8) che passerà prima che la prossima pulsazione venga insieme.

Le routines originali C64 ROM usano un efficiente algoritmo di correzione errore per codificare dati. Ogni byte di dati utente è scritto usando un bit di partenza, 8 bits utente (primo LSB, ultimo MSB) e una parità di bit (facendo il numero di '1' bit dispari). Il bit di partenza consiste di un intervallo molto lungo seguito da un altro lungo ancora. I bits '0' sono codificati da un breve intervallo seguito da un lungo intervallo e '1' bits sono codificati da un lungo intervallo seguitone da uno breve. Brevi cicli di Intervalli CPU lunghi circa 0x164 (= 0x2C*8) . Gli intervalli lunghi durano circa 0x1FC (= 0x3F*8) cicli, e molti intervali lunghi sono circa 0x2AC (= 0x55*8) cicli. I valori di timing attuali possono significamente e rapidamente variare, sin dal fatto che il lettore nastro era sempre ottimizzato per il suo movimento. Le routines ROM cercano di compensare per questo di correggere permanentemente un parametro di velocità nastro. Ad un intervalllo molto lungo seguito da un breve intervallo indica la fine di un blocco di dati.
Efficienza stimata: Per 1 byte di utente dati il nastro richiede (0x2AC + 0x1FC) + 9*(0x1FC+0x164) = 0x2308 = 8968 cicli CPU, dando una performance di circa 110 byte/secondi. Sicché ogni blocco è immagazzinato due volte per permettere la correzione di errori e ci sono insolite distanze tra le copie solo metà dell'adempimento (riguardo 50 byte/secondo) è disponibile per uso attuale.
D'altra parte immagazzinando un byte utente richiede 2+9*2 = 20 intervalli ogni byte codificato. Per permettere compensazioni di errore tutti dati vengono immagazzinati 2 volte, totalizzando 40 byte di dimensione per ogni byte di informazione utente di un file TAP. In aggiunta a ciò più files TAP contengono generose distanze tra le aree usate, incrementando addirittura di più le dimensioni file.

Vari caricatori veloci immagazzinano i loro dati in differenti, formati proprietari. In generale guadagnano efficienza usando solo un singolo intervallo per ogni bit utente, riducendo la dimensione di ogni intervallo, rilasciando bit di partenza e parità ed immagazzinando dati completi solo una volta. Mentre questo drasticamente riduce la possibilità di rilevazione errore e correzione migliora la velocità di caricamento a 200-500 byte/secondo. Allo stesso tempo la dimensione del TAP è ridotta di circa 8 volte la dimensione dei dati contenuti dell' utente.

Il Centro Informazioni sulle Cassette Commodore 64 è disponibile su http://www.geocities.com/SiliconValley/Platform/8224/c64tape/index.html fornisce informazioni dettagliate sui vari formati cassetta.

Se sei interessato nel trasferimento dati da cassette fisiche al tuo Mac, dovresti leggere le FAQ relative su: http://www.geocities.com/SiliconValley/Platform/8224/c64tape/faq.html. Troverai anche collegamenti (DOS/Windows-, sfortunatamente non per Mac-) su strumenti che convertiranno gli archivi WAV in TAPs od in immagini T64.

E.11 Formato Modulo ROM *.CRT

Il formato cartuccia *.CRT ROM è abbastanza flessibile e rende possibile codificare una vasta varietà di differenti tipi di cartucce efficientemente. Inoltre è semplice da leggere, ha una Stringa Magica facilmente riconoscibile e richiede solo piccole operazioni amministrative.

Di fondo un file CRT consiste di una Cartuccia Header, descrivendo la cartuccia in generale, segueta da 1 o più pacchetti chip ognuna descrivente i contenuti di 1 chip ROM.

Tutti i Valori Multibyte sono immagazzinati in Formato Big-Endian.

typedef struct
 {
  Byte CartrigeMagic[16];  /* $00 - $0F */
  Long HeaderSize;         /* $10 - $13 */
  Word Version;            /* $14 - $15 */
  Word HardwareType;       /* $16 - $17 */
  Byte ExROM_Line          /* $18 */
  Byte Game_Line           /* $19 */
  Byte Not used[6];        /* $1A - $1F */
  Byte CartridgeName[32];  /* $20 - $3F */
 } CartridgeHeader;

`CartridgeMagic`	- Magic Constant `'C64 CARTRIDGE ' = {$43, $36, $34, $20, $43, $41, $52, $54, $52, $49, $44, $47, $45, $20, $20, $20}`
`HeaderSize`	- sizeof(`CartridgeHeader`) = 64 = `{$00, $00, $00, $40}`
`Version`	- CRT Versione 1.0 = `{$01, $00}`
`HardwareType`	- C'è una vasta varietà di differenti cartucce che sono tutti riassunti sotto il formato CRT. Tutte le cartucce contengono delle ROM (come pianificato dai disegnatori C64), ma in aggiunta a ciò delle cartucce contengono anche RAM e/o circuiti logici. Solitamente questi disegni erano usati solo per ogni singolo progetto, così che la fatica per la loro emulazione è difficilmente valsa il problema. Power64 supporta cartuccia tipi 0, 4, 6, 7, 8, 11 e 12 coprendo l'intero campo dei giochi. `0 - Normal Cartridge 1 - Action Replay 2 - KCS Power Cartridge 3 - Final Cartridge III 4 - Simons Basic 5 - Ocean type 1 (256 e 128 KByte) 6 - Expert Cartridge 7 - Fun Play 8 - Super Games 9 - Atomic Power 10 - Epyx Fastload 11 - Westermann 12 - Rex 13 - Final Cartridge I 14 - Magic Formel`
`ExROM_Line`	- Segnale di linea dell' ExROM (per configurazione Memoria)
`Game_Line`	- Segnale di linea del Gioco (per configurazione Memoria)
`CartridgeName`	- Nome leggibile della Cartuccia (Stringa a terminazione Null)

typedef struct {
  Byte ChipMagic[4];  /* 0x00 - 0x03 */
  Long PacketLength;  /* 0x04 - 0x07 */
  Word ChipType;      /* 0x08 - 0x09 */
  Word Bank;          /* 0x0A - 0x0B */
  Word Address;       /* 0x0C - 0x0D */
  Word Length;        /* 0x0E - 0x0F */
  Byte Dati[Length];  /* 0x10 - ...  */
 } ChipPacket;

`ChipMagic`	- Costante Magica 'CHIP' = {$43, $48, $49, $50}
`PacketLength`	- Dimensione del PacchettoChip (= Length + 0x10)
`ChipType`	- 0..ROM, 1..RAM (Nessun Campo Dati), 2..EEPROM
`Bank`	- per Cartucce Multi-Banco (per cartucce a banco singolo : 0)
`Address`	- 'Carico'-Indirizzo del chip ROM (solitamente $8000 o $A000)
`Length`	- Dimensione del chip ROM (solitamente $1000 o $2000 o $4000)
`Dati`	- Contenuti della ROM

Esempio: Cartuccia Basic Simons

$0000: 0x43, 0x36, 0x34, 0x20, 0x43, 0x41, 0x52, 0x54, /* C64 CART */
$0008: 0x52, 0x49, 0x44, 0x47, 0x45, 0x20, 0x20, 0x20, /* RIDGE    */
$0010: 0x00, 0x00, 0x00, 0x40, 0x01, 0x00, 0x00, 0x04, /* ...@.... */
$0018: 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* ........ */
$0020: 0x53, 0x69, 0x6D, 0x6F, 0x6E, 0x27, 0x73, 0x20, /* Simon's  */
$0028: 0x42, 0x61, 0x73, 0x69, 0x63, 0x00, 0x00, 0x04, /* Basic... */
$0030: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* ........ */
$0038: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* ........ */

$0040: 0x43, 0x48, 0x49, 0x50, 0x00, 0x00, 0x20, 0x10, /* CHIP.. . */
$0048: 0x00, 0x00, 0x00, 0x00, 0x80, 0x00, 0x20, 0x00  /* ...... . */
$0050: .... $2000 Byte per Bank 0: $8000 - $9FFF ....

$2050: 0x43, 0x48, 0x49, 0x50, 0x00, 0x00, 0x20, 0x10, /* CHIP.. . */
$2058: 0x00, 0x00, 0x00, 0x00, 0xA0, 0x00, 0x20, 0x00  /* ...... . */
$2060: .... $2000 Byte per Bank 0: $A000 - $BFFF ....

$4060: End of File

E.12 File Istantaneo RAM

Il formato per Istantanee RAM venne adattato con un suggerimento fatto da Jouko Valta per l'Emulatore il Vice su sistemi Unix. L'originale descrizione, che spiega il significato dei campi header individuali in più punti, si trova su http://stekt.oulu.fi:/~jopi/x64/RAM-format

typedef struct
 {
  Byte MagicCode[6];     /* $00 - $05 */
  Byte ReservedA[2];     /* $06 - $07 */
  Byte Version[2];       /* $08 - $09 */
  Byte EmulatorID;       /* $0A */
  Byte SnapType;         /* $0B */
  Byte RAMStart[2];      /* $0C - $0D */
  Byte RAMSizeKB[2];     /* $0E - $0F */
  Byte REUSizeKB[2];     /* $10 - $11 */
  Byte ReservedB[14];    /* $12 - $1F */
  Byte Config[6];        /* $20 - $25 */
  Byte IORAM;            /* $26 */
  Byte CPURestore;       /* $27 */
  Byte PCHigh, PCLow;    /* $28 - $29 */
  Byte RegA, RegX, RegY; /* $2A - 2C */
  Byte RegFlags, RegSP;  /* $2D - $2E */
  Byte IOPort;           /* $2F */
  Byte Z80_CPU[16];      /* $30 - $3F */
  Byte REC[16];          /* $40 - $4F */
  Byte OSVersion;        /* $50 */
  Byte OSPatch;          /* $51 */
  Byte PatchID[2];       /* $52 - $53 */
  Byte ReservedC[44];    /* $54 - $7F */
  Byte Custom[128];      /* $80 - $FF */
  Byte RAM[65536];
  Byte IOArea[4096];
  Byte REU[REUSize];
  FloppyState Floppy1541[FloppyCnt];
 } Snapshot;

Nota: Tutti i valori multi-byte sono immagazzinati in formato Big-Endian (Alto/Basso) piuttosto che nel fromato Little-Endian (Basso/Alto) usato dal C64.

`MagicCode`	- Constante Magica 'CBM'64 = `{$43, $42, $4D, $64, $00, $00}`
`ReservedA`	- Dovrebbero essere`{$00, $00}`
`Versione`	- Numero Versione 1.0 Maggiore e Minore = `{$01, $00}`
`EmulatoreID`	- Power64 usa '/' = $2F
`SnapType`	- Istantanea RAM = $00
`RAMStart`	- Offset all' Immagine RAM nel File. L'header correntemente usa 256 Bytes. Quindi RAMStart = `{$01, $00}`.
`RAMSizeKB`	- Dimensione delll' Immagine RAM in KByte (non Byte!) = `{$00, $40}`
`REUSizeKB`	- Dimensione della Espazione Unità RAM in KByte
`ReservedB`	- Dovrebbero essere tutti $00
`Config`	- Riservato per configurazione bit masks - Al momento tutti $00
`IORAM`	- Bit 2/1: VDC RAM disponibile (00..No, 01..16KB, 10..64KB, 11..32KB) Bit 0: I/O dati disponibile (0..No, 1..Si) Valore usato di Power64: $01
`CPURestore`	- CPU(s) disponibile: (Bit 0: M6502, Bit 1: Z80, Bit 2: REC) = $01
`PCHigh, PCLow`	- Contatore Programma M6502
`RegA, RegX, RegY, RegFlags, RegSP`	- Registri M6502
`IOPort`	- Scatto 6502 CPU I/O
`Z80_CPU`	- Riservato per stato interno di Z80 (non usato)
`REC`	- Riservato per stato interno di REC (non usato)
`OSVersion`	- Byte ID per Kernal C64 (non usato)
`OSPatch`	- ID Patch Kernal per estensioni (caricatori veloci etc.) (non usato)
`PatchID`	- Versione Patch informazione (non usato)
`ReservedC`	- Versione Kernal informazione (non usato)
`Custom`	- Informazone su periferiche, dispositivi esterni etc. (non usato)
`RAM`	- Contenuti della RAM
`IOArea`	- I Contenuti dell'area I/O (VIC, SID, ColorRAM, CIA1/2, REU) Ogni dispositivo è immagazzinato solo una volta, addirittura così parecchie ombre appaiono nello spazio indirizzo C64. Le distanza sono riempite con lo stato interno di Power64 e parecchi di $00.
`REU`	- I Contenuti della REU RAM, se un Espansione RAM è presente. 0, 128, 256 o 512 KByte - come specified di REUSizeKB.
`Floppy1541`	- Il corrente stato di ogni allegato, è completamente emulato dal Floppy 1541. typedef struct { Byte MagicCode[6]; /* $00 - $05 ('CBM',$15, $41, $00) / Byte ReservedA[2]; / $06 - $07 / Byte Version[2]; / $08 - $09 / Byte EmulatorID; / $0A / Byte SnapType; / $0B / Byte RAMStart[2]; / $0C - $0D / Byte RAMSizeKB[2]; / $0E - $0F / Byte REUSizeKB[2]; / $10 - $11 / Byte ReservedB[14]; / $12 - $1F / Byte Config[6]; / $20 - $25 / Byte IORAM; / $26 / Byte CPURestore; / $27 / Byte PCHigh, PCLow; / $28 - $29 / Byte RegA, RegX, RegY; / $2A - 2C / Byte RegFlags, RegSP; / $2D - $2E / Byte ReservedC[81]; / $2F - $7F / Byte Custom[128]; / $80 - $FF */ Byte RAM[2048]; Byte IOArea[512]; } FloppyState;

E.13 File Audio (reSID Sound File)

Il formato C64 Audio era sviluppato da Roland Lieger per Power64 e reSID. E' basato su un idea usata da Richard Bannister per Frodo, ma è stato migliorato in flessibilità e compattezza dei files risultanti.