Exomizer E Cadaver's Fastloader

[med]

Sto provando ad usare il fastloader di Cadaver (insomma, uno di quelli che trovate qui) in associazione alla sua funzione di decomprimere "on fly" eventuali file compressi utilizzando exomizer. In particolare uso, come mera prova, questi 2 file prg:

1) il primo file si dovrebbe occupare di caricare un secondo file compresso con exomizer eseguendo la decompressione on fly e quindi a caricamento ultimato saltare direttamente al nuovo programma.

Codice: [Seleziona]

* =$2000

JSR initloader
LDX #<filename
LDY #>filename
JSR loadfile_exomizer
bcc ok
sta $d020
exit jsr getin
tax
beq exit
jmp 64738

ok jmp $4000;si tratta dell'indirizzo di partenza del secondo file

include cfg_exom.s
include loader.s
2) il secondo file è un semplice prg che modifica il colore dello sfondo a ripetizione, insomma un semplice test. il codice è:

Codice: [Seleziona]

* =$4000

inc $d020
inc $d020
inc $d020
inc $d020
inc $d020
inc $d020
inc $d020
inc $d020
inc $d020
inc $d020
inc $d020
inc $d020
inc $d020
inc $d020
inc $d020
inc $d020
jmp $4000
questo ultimo file lo assemblo con dasm e lo comprimo con exomizer usando l'espressione "exomizer level test.prg -otest.prg" perchè da quello che ho letto sul sito di cadaver è necessario che il file da decomprimere on fly sia stato compresso utilizzando il sub command "level" appunto.
Metto i 2 file su un d64, ma non funge nulla... cioè il primo file sembra caricare il secondo ma di fatto non decomprime un bel niente per cui a partire da $4000 non ci sono altro che 00,00,00... ripetuti.

La domanda è, sperando che qualcuno di voi abbia mai provato ad usare questa funzione (spero sinceramente almeno ianCoog), dove sbaglio? Forse devo usare altri comandi di exomizer o l'errore lo devo cercare nel loader di cadaver?
Del resto una domanda mi sorge spontanea... come fa a sapere il loader dove andare a decomprimere un file compresso con exomizer level se in esso non viene inserito alcun header?
Aiuto... :doh: 

[iAN CooG]

A me funziona, ma devo avvertirti: il level decrunch di exomizer nel cadaver's loader, per lo meno fino alla versione 2.2 del loader (che preferisco alla 2.05/2.1 perche' riconosce da solo se sta girando su un 1541+tde o su altri drive), non supporta la compressione di default con "sequenze letterali" quindi se exomizer decide autonomamente che e' il caso di usare questa tecnica perche' il file da comprimere contiene sequenze incomprimibili, la decompressione con il cadaver's loader fallira' a meta' strada, MA non da' alcun tipo di errore =). Usa quindi anche l'opzione:
 -c            compatibility mode, disables the use of literal sequences
exomizer level tuofile.prg -ofilecompresso -c

Poi magari c'e' qualcosa di sbagliato/non settato nel tuo cfg_exom.s, ma inizia con il -c

Per quanto riguarda l'header, in effetti non c'e' alcun segno di riconoscimento, ed hanno una struttura fissa (i primi 2 byte sono l'indirizzo FINALE di destinazione+1, in formato HI-LO, poi c'e' lo stream compresso) quindi non dargli mai in pasto files di cui non sei sicuro siano stati fatti con exomizer level

PS: ma tu il "filename" dove l'hai settato? =)
ti ho allegato un esempio funzionante

[med]

 Contavo i minuti in attesa della tua risposta...
Quando dici:

A me funziona

ti riferisci a tuoi test oppure hai assemblato i file che ho postato?
Ok, proverò ad inserire il comando -c come da te suggerito.

Poi magari c'e' qualcosa di sbagliato/non settato nel tuo cfg_exom.s

Sinceramente non ho proprio rivoluzionato il file cfg_exom, quindi allo stato attuale uso quello inserito da cadaver nel file zip del loader (avevo già scaricato sia la 2.2 ma volevo usare la 2.05 perchè mi consente il 2-bit e quindi caricamente dalla velocità eccezionale).

PS: ma tu il "filename" dove l'hai settato? =)

direttamente all'interno del file cfg.
Spero di non stressarti oltre, altre 2 domande:
1) exomizer userà solamente le locazioni di memoria che gli ho riservato come buffer ed in pagina zero all'interno del file cfg, giusto? non c'è il rischio che comprometta altre locazioni (eccetto quelle destinate al programma in decompressione).
2) mi spieghi la differenza tra FORWARD_DECRUNCHING e BACKWARD_DECRUNCHING? Io ho capito (o più che altro immaginato) che la prima comincia la decompressione dall'indirizzo iniziale e si sposta verso quello finale, la seconda comincia dalla fine e si avvicina all'inizio. Giusto? se così fosse, qual'è il vantaggio della FORWARD_DECRUNCHING.
Come sempre, grazie.

[iAN CooG]

 mi riferisco al mio test ovviamente, il tuo non si compila nemmeno =)
--- Unresolved Symbol List
filename                 0000 ?         (R )
--- 1 Unresolved Symbol

Le locazioni usate sono definite nei sorgenti e nel cfg, se definisci ADDITIONAL_ZEROPAGE verranno anche usate le 4 locazioni a partire da zpbase2, c'e' anche scritto quanto usa per i buffer di caricamento (256) e di decompressione (156)

Per la forward/backward decrunch, non ho idea quali siano gli svantaggi derivanti dall'uso di una rispetto all'altra, a parte una questione "estetica": durante la decompressione all'indietro di una bitmap decompressa direttamente nella pagina bitmap attiva, la vedresti comparire dal basso verso l'alto. Probabilmente il forward decrunch e' necessario solo in caso di streaming diretto, raramente necessario su c64 (decompressione on the fly di un sample digitale ad esempio)

[med]

 Chiarissimo come sempre...

mi riferisco al mio test ovviamente, il tuo non si compila nemmeno =)
--- Unresolved Symbol List
filename 0000 ? (R )
--- 1 Unresolved Symbol

Come ti ho scritto prima, l'ho tralasciato perchè lo avevo aggiunto all'interno del file cfg.

Le locazioni usate sono definite nei sorgenti e nel cfg, se definisci ADDITIONAL_ZEROPAGE verranno anche usate le 4 locazioni a partire da zpbase2, c'e' anche scritto quanto usa per i buffer di caricamento (256) e di decompressione (156)

Lo so, ma temevo che comunque a parte quelle "scelte personalmente" attraverso il file cfg, ne potessero essere interessate anche altre "non modificabili" dall'utente.

Per la forward/backward decrunch, non ho idea quali siano gli svantaggi derivanti dall'uso di una rispetto all'altra, a parte una questione "estetica"

La mia era semplice curiosità... del tipo "se se ne parla, a qualcosa servirà".
Giuro, l'ultima domanda: cos'è l'interleave di cui si parla nelle spiegazioni del loader di cavader, e come lo modifico? Io uso DirMaster per creare/gestire immagini .d64 ma non ho trovato un riferimento a questo interleave.
Per il resto la discussione ormai può considerarsi (quasi) conclusa (sperando possa servire anche ad altri oltre che a me). Quindi ti ringrazio nuovamente.

[iAN CooG]

 L'interleave e' la distanza tra un settore e l'altro su disco, quando scrivi un file su 1541 non vengono scritti sequenzialmente nel settore 0,1,2,3, ma bensi' 0,10,1,11,2,12 etc per motivi di temporizzazione. Un interleave diverso rende la lettura piu' lenta se si usa il normale load da kernal, ma alcuni turbo vengono facilitati da interleave diversi. So che ci sono alcuni file copiers nativi che consentono di modificare l'interleave in copia, anche con star commander puo' variare questo valore, ma sinceramente non me ne sono mai interessato piu' di tanto.

[med]

 Ok, allora, grazie. :lol: