Tap Manager

[bubusan]

 Ottimo, alla grande    

[Giorgio]

 Salve ha tutti!
Innanzitutto complimenti per il sito e per i progetti sviluppati.
Da un po' di tempo collaboro con EdicolaC64 e ho recuperato parecchie cassette italiane da edicola: l'argomento qui affrontato ha perciò subito catturato la mia attenzione e suscitato il mio interesse. Tanto più che l'idea di un TAP MANAGER mi era venuta anche a me un paio di anni fa. Le mie scarse conoscenze di programmazione e il tempo limiato avevano però impedito al progetto di risolversi in qualcosa di utile.
In base alla mia modesta esperienza mi permetto solo di suggerire - 'buttare lì' forse è termine più corretto - qualche idea:

- Semplificare il più possibile le problematiche del software: ad uno stadio iniziale limitarsi al solo formato TAP (non escludendo lo sviluppo di formati diversi in futuro)
- I plug-ins dei LOADER possono essere scritti a partire da files PRG (ricavabili col Final TAP  o assemblati dall'utente). Il TAPE MANAGER prende un programma PRG lo codifica in turbo, gli antepone l'header e il loader e scrive il file TAP.
- Per la lettura processo inverso: dall'Header vengono ricavate informazioni sul turbo utilizzato. Si fanno delle DLL da usare come plug-ins, come già avviene sull'Audiotap e il WAV-PRG.
- Un nuovo formato potrebbe prevedere la codifica RLE. Per quanto riguarda la struttura, personalmente, preferisco quella più tradizionale che mantiene l'emulazione originale: Header (Loader) --> Loader --> Data
- Prevedere qualche tool integrato nell'interfaccia per l'assemblaggio/disassemblaggio

Per inciso - il loader 'Chiocciola' mi era noto anche come FANTASOFT. Ho visto che sotto la dicitura BITURBO ecc...ecc...ricadono loaders molto diversi (a livello di codice): i più vecchi non avevano effetti di schermo e spesso ti ordinavano FERMA IL REGISTRATORE alla fine della lettura; comunque il recupero dei sorgenti col Final TAP è facilissimo.

Grazie per l'attenzione

[iAN CooG]

 

- I plug-ins dei LOADER possono essere scritti a partire da files PRG (ricavabili col Final TAP  o assemblati dall'utente). Il TAPE MANAGER prende un programma PRG lo codifica in turbo, gli antepone l'header e il loader e scrive il file TAP.

non e' chiaro cosa intendi.

- Per la lettura processo inverso: dall'Header vengono ricavate informazioni sul turbo utilizzato. Si fanno delle DLL da usare come plug-ins, come già avviene sull'Audiotap e il WAV-PRG.

a sapere che era cosi' facile l'avrei fatto anche io.

- Un nuovo formato potrebbe prevedere la codifica RLE.

A questo punto se si vuole comprimere ci sono algoritmi migliori, basta la zlib. Ma a che pro? Tanto sarebbe un formato usato da nessuno e andrebbe riconvertito in tap normale.

- Prevedere qualche tool integrato nell'interfaccia per l'assemblaggio/disassemblaggio

Disassemblare ok, per vedere in immediato il blocco come in final tap, ma addirittura assemblare? e' un idea, non avevo mai pensato a fare crack direttamente sul tap, anche se lo trovo inutile :D

Per inciso - il loader 'Chiocciola' mi era noto anche come FANTASOFT.

anche Galadriel e in altre salse

ricadono loaders molto diversi (a livello di codice): i più vecchi non avevano effetti di schermo e spesso ti ordinavano FERMA IL REGISTRATORE alla fine della lettura

Quello non e' il loader a dirlo, ma il programma stesso dopo l'avvio. In questi crack italiani su cassetta c'e' un piccolo stub accodato al programma - la linea basic punta a questa routine anziche' la vera locazione di partenza - che controlla lo stato del registratore tramite la locazione $01, sta in loop finche' sente il play premuto, dopo di che' lancia la sys normale di avvio.

comunque il recupero dei sorgenti col Final TAP è facilissimo

non sempre, te lo dice uno che spesso ha dovuto usare il metodo tradizionale -usando il monitor degli emulatori piuttosto che quello della action replay - per craccare molti originali; non parlo di cassette da edicola

[Giorgio]

 

Per la lettura processo inverso: dall'Header vengono ricavate informazioni sul turbo utilizzato. Si fanno delle DLL da usare come plug-ins, come già avviene sull'Audiotap e il WAV-PRG.

a sapere che era cosi' facile l'avrei fatto anche io.

Penso di non essermi spiegato bene. Diciamo che 'mi piacerebbe' un software tipo il Final TAP in grado di riconoscere e deassemblare e viceversa assemblare e mettere in turbo un vasto numero di formati via via aggiornabili senza dover riscrivere massicciamente il codice sorgente principale.

Ma a che pro? Tanto sarebbe un formato usato da nessuno e andrebbe riconvertito in tap normale.

Su questo sono abbastanza d'accordo perché non mi riferivo ai TAP; suggerivo questo solo perché ho letto qualche discussione sulla possibilità di fare dei formati ex-novo e nuovi emulatori.

anche Galadriel e in altre salse

Sì ho presente...

ricadono loaders molto diversi (a livello di codice): i più vecchi non avevano effetti di schermo e spesso ti ordinavano FERMA IL REGISTRATORE alla fine della lettura

Quello non e' il loader a dirlo, ma il programma stesso dopo l'avvio. In questi crack italiani su cassetta c'e' un piccolo stub accodato al programma - la linea basic punta a questa routine anziche' la vera locazione di partenza - che controlla lo stato del registratore tramite la locazione $01, sta in loop finche' sente il play premuto, dopo di che' lancia la sys normale di avvio.

Sì, quando ho detto loader stavo pensando a tutto ciò che precede. Però si potrebbe prevedere una funzione del genere, magari con qualche effetto.

Ripeto: sono cose che si potrebbero fare, o meglio che mi piacerebbe - da DILETTANTE del C64 e da MODESTO PROGRAMMATORE - poter fare.
Se sono inutili, impossibili e insensate..."lieto" di venirlo a sapere da persone competenti.


 

[Massi cadenti]

- I plug-ins dei LOADER possono essere scritti a partire da files PRG (ricavabili col Final TAP  o assemblati dall'utente). Il TAPE MANAGER prende un programma PRG lo codifica in turbo, gli antepone l'header e il loader e scrive il file TAP.

non e' chiaro cosa intendi.
 

Credo si riferisse alla mia "idea" di creare un formato analogo al T64 ma contenente anche le info per ricreare a scelta e in tempo reale il caricamento "lento".
L'idea è rimasta tale (appunto solo un'idea) come puoi notare dallo sviluppo del thread, per il momento si è accantonata finché non ci sarà una versione più che stabile del TAP Manager, anche perché ci sarebbe da contattare gli autori di VICE o CCS per "imporre" alla comunità l'ennesimo nuovo formato (che però continuo a credere avrebbe indubbi vantaggi).
Ci sarebbe il problema di fondo del copyright per i loader, risolvibile NON includendoli nell'emulatore (e vietando di includerli, come succede con il MAME e le rom) e permettendo in ogni caso il caricamento istantaneo (come un T64) per i giochi di cui non si hanno i loader relativi.

[Alberto]

 Ciao Giorgio

Innanzitutto grazie anche a te per l'interesse dimostrato,fa veramente piacere.

Semplificare il più possibile le problematiche del software: ad uno stadio iniziale limitarsi al solo formato TAP (non escludendo lo sviluppo di formati diversi in futuro)

Sì,infatti questa è stata una cosa che mi sono imposto fin dall'inizio (vedi primi post di questo thread).Solo quando la parte TAP sarà completa si potrà parlare di altri formati.

Ad ogni modo,un formato interessante sarebbe l'equivalente dei TAP per dispositivi mobili;con lo stesso potere informativo dei TAP,ma meno ingombranti e più idonei alla minore potenza della macchina.

Avevo preso in considerazione fin dalle prime battute anche l'idea del (dis)assemblatore.

Più precisamente,l'idea dell'assemblatore non nasce con l'intenzione di cambiare radicalmente il codice dei programmi;come detto da iAN CooG,a quel punto conviene fare una crack sul programma stesso,perchè lavorare sul TAP sarebbe decisamente scomodo.

L'idea è invece quella di dare la possibilità di "aggiustare" a mano quei piccoli
pezzi di codice dumpati male (nell'intestazione o nelle routine di caricamento successive).

Passiamo ai plug-in.Sono una buona idea,stracollaudata:proprio per questo secondo me riscriverli tutti significa spendere un mucchio di tempo senza introdurre nessuna novità;tanto più che il TM è stato concepito come una funzionalità aggiuntiva del WAV-PRG,per cui riscrivere dei plug-in già esistenti sarebbe anche piuttosto "stupido"

- Per la lettura processo inverso: dall'Header vengono ricavate informazioni sul turbo utilizzato. Si fanno delle DLL da usare come plug-ins, come già avviene sull'Audiotap e il WAV-PRG.

Un programma capace di autoaggiornarsi in base alle esigenze sarebbe interessantissimo,il problema è che dall'header potresti capire solamente se il
programma da caricare è decodificabile con le routine della ROM oppure no.
Anche esaminando il codice del loader,è tutt'altro che semplice estrarre i vari
parametri necessari alla costruzione del plugin:come forse avrai già visto,i loader hanno una struttura molto variabile,non esiste un criterio preciso per dire "ok, questo è il byte di sincronizzazione,questo è l'indirizzo di partenza",ecc...

Senza contare che il loader stesso potrebbe essere stato salvato su più blocchi...

Comunque queste sono solo mie considerazioni,che non vogliono (e non devono) mettere preconcetti sulla possibilità di realizzare qualcosa di interessante.

Chi fose interessato continui a proporre idee   (meglio se corredate da due linee di codice o da un algoritmo,almeno per dare un'idea di quel che si intende).

(Colgo l'occasione per dire che al primo link della homepage del progetto è disponibile la prima parte del "readme" di cui avevo parlato qualche post addietro).

[Giorgio]

 

Avevo preso in considerazione fin dalle prime battute anche l'idea del (dis)assemblatore.

Più precisamente,l'idea dell'assemblatore non nasce con l'intenzione di cambiare radicalmente il codice dei programmi;come detto da iAN CooG,a quel punto conviene fare una crack sul programma stesso,perchè lavorare sul TAP sarebbe decisamente scomodo.

Ne convengo; in effetti l'assemblatore è pleonastico. Il TM deve effettuare solo l'operazione PRG-->TAP su PRG già assemblati.

tanto più che il TM è stato concepito come una funzionalità aggiuntiva del WAV-PRG,per cui riscrivere dei plug-in già esistenti sarebbe anche piuttosto "stupido"

I file sorgenti delle DLL del WAV-PRG erano in Pascal, ricordo bene? Se si volessero scriverne degli altri (e interfacciarli col software già esistente), esiste della documentazione (o qualche discussione di questo Forum) da cui attingere? Preciso anche che sono un programmatore piuttosto scarso in C e che ciò potrebbe esulare notevolemente dalle mie attuali capacità.

i loader hanno una struttura molto variabile,non esiste un criterio preciso per dire "ok, questo è il byte di sincronizzazione,questo è l'indirizzo di partenza",ecc...

Il mio entusiasmo in questo senso era motivato dal fatto che inconsciamente continuavo a pensare ai nastri da edicola. Come giustamente mi fai notare il mondo dei software originali è assai più variegato.  

Infine, complimenti per il lavoro svolto finora, sembra molto promettente.





 

[Alberto]

 

I file sorgenti delle DLL del WAV-PRG erano in Pascal, ricordo bene? Se si volessero scriverne degli altri (e interfacciarli col software già esistente), esiste della documentazione (o qualche discussione di questo Forum) da cui attingere? Preciso anche che sono un programmatore piuttosto scarso in C e che ciò potrebbe esulare notevolemente dalle mie attuali capacità.

Se non erro le DLL delle prime versioni erano scritte con Delphi,mentre le versioni 3.x del programma (e DLL annesse) sono state riscritte in C.

No,non esiste una documentazione su come creare plugin per WAV-PRG,se sei (l'unico) interessato ne possiamo tranquillamente parlare per posta:se conosci un pò di C e come funzionano le routine di caricamento,non c'è niente di complicato

Il mio entusiasmo in questo senso era motivato dal fatto che inconsciamente continuavo a pensare ai nastri da edicola. Come giustamente mi fai notare il mondo dei software originali è assai più variegato. 

Purtroppo (o per fortuna) sì. :D  

Infine, complimenti per il lavoro svolto finora, sembra molto promettente.

Aspetta almeno di vedere la prima release...  :D

[iAN CooG]

 

No,non esiste una documentazione su come creare plugin per WAV-PRG,se sei (l'unico) interessato ne possiamo tranquillamente parlare per posta

A me interesserebbe di piu' una spiegazione qua sul forum :D

[Giorgio]

 Probabilmente lo sapevate già tutti, ma sul sito del Final TAP ho visto che ci sono anche i sorgenti dell'ultima versione, forse potranno servire per implementazioni future.

http://www.coder.pwp.blueyonder.co.uk/

 

[iAN CooG]

Probabilmente lo sapevate già tutti, ma sul sito del Final TAP

Si, bastava leggere la pagina 4

[fab]

 Allora: in WAV-PRG 3.x i plug-in sono scritti solo in C. In quello precedente erano soprattutto in Delphi (qualcuno era in C).

La funzione wav2prg_plugin_init viene chiamata nel momento in cui vengono controllati i plug-in esistenti. Il suo scopo è di effettuare eventuali operazioni iniziali: in particolare, se un plug-in necessita di altri plug-in per funzionare, qui si controlla se questi altri esistono. La funzione restituisce 0 se va tutto bene, un valore diverso da 0 in caso di errori.

Funzioni e variabili che il plug-in deve obbligatoriamente definire:
La funzione wav2prg_get_entry analizza il file di ingresso, e ritorna quando il file di ingresso è finito, o quando un programma ("entry") è stato estratto.

Il puntatore entry va riempito:
- il campo start_addr contiene l'indirizzo iniziale nella memoria del C64
- il campo end_addr contiene l'indirizzo finale, cioè la prima locazione di memoria non occupata dal programma. Esempio, se un programma inizia a $800 ed è grande 1 KB, l'indirizzo finale (end_addr) è $C00. Il programma occuperà esattamente $400 (1024) byte ($c00-$800). Questo significa che $800 è occupata, e $C00 no ($BFF, quella immediatamente precedente, sì).
- il campo data con i byte da mettere nella memoria

Il valore di ritorno è:
OK: il programma è stato caricato con successo (o il formato del loader non contiene metodi per determinare il successo o no)
LOAD_ERROR: il programma contiene errori di caricamento
INCOMPLETE: è stato trovato l'inizio di un programma, ma il file di ingresso è finito prima che se ne trovasse la fine
NOT_FOUND: il file di ingresso è finito senza che sia stato trovato l'inizio di un programma

Il valore dela variabile wav2prg_version (di tipo puntatore a char) è confrontato con quello accettato da WAV-PRG. In pratica, è sempre WAVPRG_VERSION, che è definito 3.0 in 2prg_api.h. Se cambiasse il formato dei plug-in, cambierebbe questo valore (mai successo da quando è uscito WAV-PRG 3.0)

wav2prg_options è un array. Per ogni elemento dell'array, appare un'opzione tra le Advanced Options. L'ultimo (eventualmente l'unico) elemento deve avere valore {0,0,0,0}.

Funzioni e variabili che il plug-in può definire, ma non è necessario:
wav2prg_priv: un puntatore a void, ci si può mettere qualsiasi cosa. E' pensato per il caso in cui due plug-in devono scambiarsi dati: ovviamente chi scrive i due plug-in devono mettersi d'accordo su chi legge il valore e chi lo scrive, e su che cos'è.

wav2prg_exit: chiamata quando il plug-in non si usa più. In pratica, se era stata allocata memoria dinamica, qui la si libera.

Nota su queste due funzioni: in Windows, dopo la dichiarazione, bisogna mettere __attribute__ ((dllexport)) o _declspec((dllexport)), altrimenti la DLL non esporta queste funzioni.

Il plug-in può definire anche altre funzioni o variabili. E' consigliato definirle "static", visto che nessuno al di fuori del plug-in deve usarle.

Funzioni che il plug-in può chiamare:
enum wav2prg_load_plugin_errors wav2prg_load_plugin(char *pathname, wav2prg_plugin *plugin);
Serve se il plug-in ha bisogno di un altro plug-in per funzionare. Per usarlo, si dichiara una variabile plugin, la si passa a questa funzione che la riempe, e poi si possono chiamare le funzioni plugin->get_entry ecc. Tipicamente questa funzione è chiamata da dentro wav2prg_init
void wav2prg_unload_plugin(wav2prg_plugin *plugin);
caricato il plug-in, quando non serve più va deallocato. Tipicamente questa funzione è chiamata da dentro wav2prg_exit
const char *wav2prg_load_plugin_error(enum wav2prg_load_plugin_errors err);
se  wav2prg_load_plugin dà errore, questa funzione specifica quale errore.
unsigned long wav2prg_read_pulse(wav2prg_file *file);
legge dal file di ingresso un impulso. Il valore di ritorno è in cicli di clock. Se il valore di ritorno è 0x1000000 o maggiore, il file di ingresso è finito, e il plug-in deve ritornare immediatamente

void wav2prg_warn(wav2prg_file *file, const char *fmt, ...);
void wav2prg_print(const char *fmt, ...);

Scrive un messaggio sull'output. fmt è una stringa, e ... va sostituito con delle variabili. Le regole con cui l'output viene costruito a partire da fmt e le variabili sono le stesse di "printf". _warn differisce da _print per il fatto che, all'inizio dell'output, viene scritta la posizione attuale del file di ingresso (utile per trovare errori in file TAP o WAV).

void wav2prg_set_status_max(int max);
void wav2prg_show_status(int status);
_set_status_max dice quanto deve essere lunga la barra di indicatore di progresso. _show_status cambia l'indicatore di progresso: 0=barra vuta, max/2=barra a metà, max=barra piena

void wav2prg_set_plugin_dir(const char *name);
const char *wav2prg_get_plugin_dir();
cambia la directory in cui i plug-in vengono cercati

E' sconsigliato che un plug-in chiami funzioni esterne diverse da queste, per motivi di portabilità ed efficienza.

Concludo scusandomi per l'orrendo linguaggio tecnico, che scoraggerà molti, invece di incoraggiarli, col rischio che questo post non sia utile a nessuno

[koseidon72]

 Che cosa e' successo al progetto?
Avevo letto che a meta' giugno sarebbe uscita la prima versione...

 :huh:


Problemi da risolvere o impegni personali?
 

[Alberto]

 Ciao koseidon

Diciamo un pò tutte e due le cose :D
Per la maggior parte del tempo stato fermo causa studio,e nei ritagli di tempo ho avuto qlc problema col d&d.Siccome non mi piace rilasciare cose che so avere dei bug,ho ritenuto fosse meglio rimandare il rilascio.
A quando di preciso,sinceramente non lo so;purtroppo il tempo è sempre tiranno e tra l'altro avevo promesso a Rob le scansioni di CCC (a proposito,il n.66 sarebbe pronto,aspetto il responso del webmaster).

Mi scuso per non avere chiarito prima e conto di rilasciare una prima beta appena avrò risolto TUTTI i problemi che riscontro (quando ciò avverrà -spero presto- faccio un fischio,promesso ).

[iAN CooG]

Mi scuso per non avere chiarito prima e conto di rilasciare una prima beta

Non devi scusarti di niente, non c'e' fretta e lo rilascerai quando e' pronto.
La fretta possiamo averla solo se ci pagano per averla.