MSC1 è un compressore progettato specificamente per comprimere schermate testuali e a colori di computer a 8 bit. Ha la caratteristica di poter comprimere in modo efficiente piccole aree di memoria (fino a 1024 byte). Questa specifica è destinata agli sviluppatori che desiderano produrre stream di dati compressi compatibili con MSC1 utilizzando qualsiasi linguaggio di programmazione.

NOTA BENE: questo documento descrive solo il formato del blocco, non come funzionano effettivamente il compressore né il decompressore. La correttezza del decompressore non dovrebbe dipendere dai dettagli di implementazione del compressore e viceversa.

Un flusso di dati compresso con MSC1 è composto da uno o più “blocchi”. Un blocco può essere alternativamente:

• un blocco di dati “letterali”;
• un blocco di duplicazione (“dupes”).

L'ultimo blocco deve essere il blocco di “fine flusso”.

Ogni blocco inizia con un token di controllo (“CTR”). Il token è un valore di un byte e gestito a livello di bit. Il primo bit definisce se il blocco è “letterale” (0) o “duplicazione” (1). Il resto del layout dei bit cambia il significato in base a questo primo bit. La fine del blocco del flusso è speciale poiché ha l'intero token di controllo a zero (00000000). La decodifica di qualsiasi blocco si conclude alla fine del blocco corrente. Il byte successivo sarà l'inizio di un altro blocco.

Se il CTR definisce il blocco come “letterale”, il token contiene anche il conteggio dei caratteri nei 7 bit inferiori. Quindi, a seguire il CTR si trovano i caratteri stessi, da 1 a 127. Sono esattamente tanti quanto ne indica il campo count. Non è possibile avere zero letterali poiché il CTR sarebbe uguale a quello che indica il blocco “END OF STREAM”.

Ad esempio, i seguenti byte definiscono un letterale di 4 lettere (“CIAO”):

   0x04, C, I, A, O

Se il CTR definisce un blocco come “duplicazione”, il token conterrà:

• un campo count, come il campo nei bit 6-2 (5 bit);
• un campo offset (bit alti), come parte bassa del CTR (2 bit).

Il byte successivo conterrà i bit bassi del campo offset (8 bit).

Quando si incontra un BLOCCO “DUPLICAZIONE”, il decoder deve copiare 4 byte dall'indirizzo attuale della memoria di origine meno offset per count volte. Iniziamo a valutare l' offset: questo è un valore a 10 bit (posizione 0 … 1024) e rappresenta la posizione da cui iniziare per copiare. 0 significa “posizione iniziale”. Il valore di offset massimo è 1024.

Ad esempio, i seguenti byte definiscono una ripetizione della stringa “CIAO” per 4 volte:

   0x04, C, I, A, O, 0x90, 0x06, ...
         |<------ 0x06 bytes-----|

Se il CTR definisce una “fine del flusso” (un byte di valore 0x00), non vi sono altri dati.

Esistono regole specifiche per generare blocchi di flusso compresso.

• L'ultimo blocco DEVE essere la FINE DEL FLUSSO. Il flusso di dati termina subito dopo.
• Se l'input è inferiore a 5 byte, vi sarà solo un blocco e conterrà l'intero input come letterali.
• Un input vuoto può essere rappresentato con un singolo END OF STREAM, interpretato come un blocco finale senza letterale aggiuntivo e senza doppioni aggiuntivi.
• Se un BLOCCO DUPLICAZIONE ha un conteggio pari a zero (0) allora è uguale a un conteggio di 32.
• I flussi inferiori a 8 byte non possono essere compressi.

Queste regole sono state aggiunte per garantire che un decodificatore conforme possa essere progettato per la velocità, emettendo istruzioni speculative, senza mai leggere o scrivere oltre i buffer di I/O forniti.

Il formato non presuppone né limita il modo in cui il compressore cerca e seleziona le corrispondenze all'interno del blocco dati sorgente. Possono essere prese in considerazione più tecniche, caratterizzate da distinti compromessi tempo/prestazione. Fintanto che il formato è rispettato, il risultato sarà compatibile e decodificabile da qualsiasi decoder conforme.

Si veda:

• midres_memory_008.c per una implementazione di un decompressore in memoria;
• midres_memory_007.c per una implementazione basata sui file.