[zxspectrum] Re: Perche` non turbo con decompressore Huffman?
- From: "Antonio S." <schianto9001@xxxxxxxxx>
- To: zxspectrum@xxxxxxxxxxxxx
- Date: Thu, 21 Feb 2013 12:02:24 +0100
Non ti seguo. Come fai a usare 4 simboli con la codifica Manchester ?
Il giorno 21/feb/2013 06:29, "Paolo Ferraris" <pieffe8@xxxxxxxxx> ha
scritto:
> On 2/20/2013 12:14 PM, Stefano Donati wrote:
>
>> Ciao Antonio,
>>
>> il WAV di Jet Set Willy X lo trovi alla pagina dedicata
>> http://ronja.twibright.com/**jswx.php<http://ronja.twibright.com/jswx.php>.
>> Il loader implementa "solo" la codifica Manchester inversa che, stando a
>> quanto scritto nei sorgenti, raggiunge i 16000 baud.
>> Il mio prototipo invece non l'ho ancora pubblicato... :(
>>
>
> 16000 bauds sono davvero tanti, ma per questa velocita` hai bisogno di un
> file wav da almeno 64000 campioni/sec. (Il file wav presente sul sito e` a
> 96000 campioni/secondo.)
> Per i CD la velocita` massima probabilmente e` 11025 bauds.
>
> La parte "positiva" della velocita` da CD e` pero` che ci sono piu` di 100
> cicli di CPU persi dall'algoritmo, che sembrano sufficienti per la
> decompressione Huffman. Secondo dei miei calcoli approssimativi, 320 kbit
> (40kbytes) a 16000 bauds richiedono 20 secondi. Con la compressione i 320
> kbit diventano ~200kbit, che a 11025 bauds sono 18 secondi!
>
> (Se poi si riuscisse a usare 4 simboli, anche se due piu` lenti, si
> potrebbero ottenere 12.7 secondi... sogno?)
>
>
>
> By looking at the loader code getting faster than 16000 bauds seems not
> easy: there're very few CPU cycles left in the argorithm. But at the CD
> speed of 11025 bauds there are more than 100 cy
>
>
>
>> Stefano.
>>
>> Il giorno 20/feb/2013, alle ore 14:58, "Antonio S." <
>> schianto9001@xxxxxxxxx <mailto:schianto9001@xxxxxxxxx**>> ha scritto:
>>
>> Il giorno 20 febbraio 2013 09:24, Paolo Ferraris <pieffe8@xxxxxxxxx<mailto:
>>> pieffe8@xxxxxxxxx>> ha scritto:
>>>
>>> On 2/19/2013 10:50 AM, Paolo Ferraris wrote:
>>>
>>> On 2/19/2013 12:20 AM, Stefano Bodrato wrote:
>>>
>>> A questa velocità lo spazio di manovra per fare altro con
>>> la CPU diventa veramente poco (Paolo non me ne voglia se
>>> rimango di questa idea).
>>>
>>>
>>> Non conoscendo l'algoritmo di decompressione dell'ultracargas
>>> non lo so di sicuro. L'algoritmo huffman che ho visto
>>> richiede un centinaio di cicli extra per bit, quindi potrebbe
>>> ancora andare bene.
>>>
>>>
>>> Tra l'altro la risposta l'ha gia` data Stefano Donati: non solo
>>> hanno implementato un turbo che richiede 4 campioni per bit (non
>>> solo per lo 0 ma anche per l'1, grazie al manchester inverse
>>> coding) ma con decompressione huffman al volo. Il file wav che
>>> hanno distribuito in lista per jswx e` circa 26 secondi, circo lo
>>> stesso tempo che l'ultracargas usa per manic miner, tranne che la
>>> quantita` di dati in jswx e` di 40k invece dei 32 di manic miner.
>>>
>>> C'è un tzx o wav da qualche parte per dargli un'occhiata? Sembra molto
>>> interessante.
>>>
>>> L'unico modo che vedo per aumentare ulteriormente la velocita` e`
>>> usare anche segnali piu` lunghi (non solo 4 campioni, ma anche 8
>>> campioni). Si potrebbe ridurre il tempo di caricamento di circa
>>> il 33%.
>>>
>>>
>>> Non so, da verificare numeri e codice alla mano. Il fatto è che il
>>> sampling loop non è precisissimo, specie in presenza di accessi a memoria
>>> contesa. Nell'ultima versione ho dovuto mettere lo stack in memoria alta
>>> perché le temporizzazioni sballavano di brutto. Purtroppo anche la porta
>>> I/O 254 è contesa e quindi il campionamento è intrinsecamente impreciso, il
>>> che non consente di diminuire troppo l'intervallo fra i simboli.
>>>
>>> Intanto ho ritrovato il cavo video e ho fatto un paio di test sul mio +2
>>> (collegato al portatile via un adattatore con finta cassetta).
>>> Inaspettatamente, ottengo risultati migliori con le onde quadre - ma forse
>>> la tua osservazione sulla componente continua giustifica questa cosa. Non
>>> sono riuscito a caricare il Ghost&Goblins super veloce in nessun modo: non
>>> mi prende neanche il loader iniziale.
>>>
>>> Una stranezza: sul +2 riesco a caricare un wave che Fuse non legge, cosa
>>> che non ritenevo possibile. Deve esserci qualche bug nell'emulazione...
>>> Infine ho cambiato leggermente la routine di compressione in maniera da
>>> tenere conto del costo effettivo (in tempo) della trasmissione dei bit, che
>>> appunto varia a secondo del numero di bit a 1 trasmessi; così facendo si
>>> risparmiano altri 2 secondi :-)
>>>
>>> Ciao
>>>
>>> A.
>>> <Manic_o.wav.bz2>
>>>
>>
>
>
Other related posts:
