Wav-prg 3.2

[fab]

 Ciao a tutti.

E' uscito WAV-PRG 3.2. La novità principale è la possibilità di creare file .TAP e .WAV per Commodore 16/Plus4 a partire da .PRG, .P00 e .T64. E' supportato il Turbo tape.

WAV-PRG è un programma che permette di:
- estrarre file .PRG,.P00 e .T64 da cassette del Commodore (in formato .TAP o .WAV, o dalla scheda sonora collegata a uno stereo con piastra cassetta). Dato che, per fare ciò, è necessario conoscere il formato della cassetta, sono disponibili vari plug-in, ciascuno estrae un diverso formato (se per il formato di cui avete bisogno non esiste un plug-in... fate un po' di reverse-engineer del loader e scrivete il relativo plug-in   )
- creare file .TAP o .WAV da .PRG, .P00 o .T64, o suonare il file .PRG, .P00 o .T64 sulla scheda sonora

Lo trovate sul sito di WAV-PRG. Grazie a Rob che da tempo ha messo un link alla pagina.

Sullo stesso sito trovate anche Audiotap, un programma per suonare file .TAP (su .WAV o scheda sonora) e registrare file .TAP (da .WAV, altri formati audio, o da scheda sonora). E' un po' un'alternativa a mtap/ptap per chi non ha abilità col saldatore. Anche se la qualità non è eccellente come in mtap/ptap, data la limitata risoluzione delle comuni schede sonore, il risultato non è disprezzabile.

Progetti per il futuro? Troppi . Le cose che sarebbe bello avere sono:
-riconoscimento, dal "loader" iniziale (quello che si carica con LOAD), del formato, e caricamento automatico del plug-in giusto
-possibilità di creare file .TAP puliti, come già fa Final TAP
-e, naturalmente, creazione di plug-in per quei formati che non ce l'hanno ancora
Se e quando verranno realizzati dipenderà dal tempo, dalla voglia e dal contributo degli utenti che sanno anche programmare in C    

[Alberto]

 Ciao fab

Hai pensato alla possibilità di estrarre il codice del programma seguendo il codice macchina del loader?Se si riuscisse a scrivere un piccolo "interprete macchina" che segua passo passo il codice del loader,sarebbe possibile estrarre automaticamente i byte del programma,indipendentemente dal loader utilizzato.Risultato:non sarebbero più necessarie valanghe di plug-in .
Poi,c'e' un altro problema:una volta estratto il codice del programma,bisogna individuare qual'e' la prima istruzione da eseguire.
Infatti,non tutti i programmi (anzi,pochi,per la verità) cominciano con una SYS all'indirizzo d'inizio;in questo difetta anche FINALTAP.
Bye
 

 

[fab]

 

Hai pensato alla possibilità di estrarre il codice del programma seguendo il codice macchina del loader?Se si riuscisse a scrivere un piccolo "interprete macchina" che segua passo passo il codice del loader,sarebbe possibile estrarre automaticamente i byte del programma,indipendentemente dal loader utilizzato.Risultato:non sarebbero più necessarie valanghe di plug-in .

Ciao Alberto.

Temo che scrivere un interprete di linguaggio macchina sia al di sopra delle mie capacità di programmatore.

Inoltre c'è un altro problema: i loader sono scritti per riempire la memoria del C64 e saltare alla prima istruzione del programma, non per creare .PRG.
Ad esempio, occorre sapere qual è l'ultima locazione di memoria in cui vengono memorizzati i byte caricati da cassetta: dopo l'ultimo byte, si può salvare il .PRG. Un interprete si limita a eseguire il codice, incurante del codice che verrà eseguito successivamente (nel caso specifico, se in seguito verranno caricati da cassetta altri byte, o se si eseguirà l'istruzione di salto). Altro problema è capire qual è l'istruzione di salto finale: certi caricatori usano JSR, altri JMP, altri JMP() (salto a vettore), altri riempono lo stack on istruzioni PHA e poi eseguono RTS o RTI, altri riempono il buffer di tastiera con RUN, altri fanno un JMP alla parte dell'interprete Basic che esegue RUN...chi più ne ha più ne metta.

Comunque questo discorso significa che non so risolvere questi problemi, non che questi problemi sono irrisolvibili.

Poi,c'e' un altro problema:una volta estratto il codice del programma,bisogna individuare qual'e' la prima istruzione da eseguire.
Infatti,non tutti i programmi (anzi,pochi,per la verità) cominciano con una SYS all'indirizzo d'inizio;in questo difetta anche FINALTAP.

Anche qui dipende molto dal loader: quasi impossibile trovare un metodo generale. Per alcuni loader è possibile usare metodi specifici: infatti alcuni plug-in scrivono qual è l'entry point (in pratica, il numero da mettere dopo SYS). Sicuramente lo fanno i plug-in Poke e Rack-It

[Alberto]

 

Altro problema è capire qual è l'istruzione di salto finale: certi caricatori usano JSR, altri JMP, altri JMP() (salto a vettore), altri riempono lo stack on istruzioni PHA e poi eseguono RTS o RTI, altri riempono il buffer di tastiera con RUN, altri fanno un JMP alla parte dell'interprete Basic che esegue RUN...chi più ne ha più ne metta.

Credo che questo sia il problema più grosso.Infatti,disassemblando un pò di loader,ne ho viste anch'io di tutti i colori :doh:  

[ice00]

 

-riconoscimento, dal "loader" iniziale (quello che si carica con LOAD), del formato, e caricamento automatico del plug-in giusto

questo in effetti è una cosa molto utile.

Magari il file TAP potrebbe essere spezzato da una routine in pezzi che contengono la parte relativa a un caricatore (forse questo è possibile analizzando il valore medio dei bit 0/1).
Poi ricorsivamente si chiama un plugin e si vede se "riconosce" il pezzo

per riconoscere deve esserci:

-riconoscimento sequenza di sincronizzazione
-riconoscimento sequenza iniziale

-lettura del file sperando che il plugin sia giusto (eventuali controlli di byte letti su byte da leggere se previsti dal plugin)

questa è solo un'idea non so se ci sono soluzioni più raffinate

bye
S.T.