[zxspectrum] Re: Perche` non turbo con decompressore Huffman?
- From: Paolo Ferraris <pieffe8@xxxxxxxxx>
- To: zxspectrum@xxxxxxxxxxxxx
- Date: Wed, 27 Feb 2013 08:29:13 -0800
On 2/27/2013 3:24 AM, Stefano Bodrato wrote:
>Secondo me invece i nastri lo supportano bene. Quello che credevo e` che
>il loader fosse piu` complicato, ma invece non e` vero: tutto sta nel
>1) captare il fronte d'onda tra le sue semionde,
>2) interpretare il valore del bit a seconda che il fronte sia in salita
>o discesa, e
>3) aspettare, dopo la lettura del fronte d'onda, il tempo di una
>semionda per evitare di leggere il fronte d'onda iniziale invece di
>quello centrale.
Forse ci sono arrivato, ecco le risposte ai 2 dubbi che avevo:
- l'onda risultante grazie allo xor con il clock non dovrebbe soffrire di troppi
problemi di risonanza (ricordi di aver parlato di "frequenza zero" ?).
I problemi sulla semionda che avevo riscontrato con il mio primo turbo
si risolvono leggendo la *posizione* dell'onda invece che misurando la
durata del suo periodo.
La semplifico un po', ma abbiamo una "componente costante" o segnale a
"frequenza 0" di cui parlavo, quando il livello della media del segnale
non e` esattamente alla meta` tra segnale alto e segnale basso. Per
evitare questo, nel caso di onde quadre come per lo Spectrum, il segnale
deve essere alto e basso per la stessa quantita` di tempo. Questo e`
vero sia con l'algoritmo della ROM che con il Manchester, mentre non e`
vero con il sistema della semionda.
- come hai notato anche tu (vedi sopra), un loader può essere molto semplice
perchè basta calibrare il timing del codice e leggere i dati al momento
giusto;
ma in questo modo la velocità motore del registratore diventa molto critica.
Il loader deve tener conto del fronti d'onda per recuperare il sincronismo,
ma non è difficile come sembra, perchè (come detto sopra lo xor del clock
garantisce uno switch.
Se prendiamo il disegnino gentilmente fornito da wikipedia:
http://en.wikipedia.org/wiki/Manchester_code
..il loader per essere stabile anche con le cassette dovrebbe in sequenza:
-- sinconizzarsi con il clock
-- leggere il bit
-- aspettare poco di più più di una semionda del clock
-- loop sulla prossima sync
Ottenere un sync preciso e` impossibile, e nessun algoritmo di
trasmissione si basa su questo, figuriamoci quando abbiamo a che fare
con tecnologia vecchia di 30 anni (portati bene :-). Il tuo algoritmo e`
corretto.
Non sono però sicuro che il sorgente che abbiamo visto si occupi di mantenere
la sincronizzazione: sbaglio ?
Come no? Dalla pagina http://ronja.twibright.com/utils/spectrum/loader.asm
in a,(254) ; 11
ld d,a ; 4
edge: in a,(254) ; 11
xor d ; 4
and e ; 4
jp z,edge ; 10
dove e=64 (il bit del mic).
La parte difficile e` aspettare la semionda, e non molto di piu`. :-)
-p
Other related posts:
