Prg To Tap

[Fabrizio]

 Ciao ragazzi, avrei bisogno di convertire un file PRG contenente un programmino assembly che ho sviluppato in un file .TAP, che poi vorrei trasferire su cassetta dopo averlo trasformato in wav con l'utility TAPWAV. Ho provato a caricare il PRG e quindi a salvare su TAP da VICE (creo immagine TAP e quindi faccio SAVE "programma") ma non sono riuscito a concludere nulla di buono, forse perchè il programma parte dalla locazione $c000 ??...
A questo punto ho pensato di scrivere un utilitina C che mi permetta di creare un file TAP a partire dal PRG... da quello che ho letto i dati devono essere codificati come "lunghezza di impulso" in secondi, ora mettiamo che ottengo un valore di 0.00076333 per un certo byte del file prg, come va scritto nel file tap? Su quanti byte devo farlo
stare? Poi c'è il problema dei byte $00, non ho capito molto bene come devono essere codificati, voi mi sapreste spiegare o indicare qualche documentazione a riguardo?
Vi ringrazio anticipatamente. Ciao. Fabrizio.
P.S. Se esiste una soluzione più semplice al problema vi prego di comunicarmela (considerate che sono piuttosto nubbio e che quindi non conosco molto su questi argomenti). Grazie ancora. Ciao!  

P.P.S. Spero di non essere OT in questa sezione del forum.

[eregil]

 Effettivamente sì, hai postato in una sezione sbagliata ("Programmazione" è dedicata alla programmazione del C64, la tua è una domanda più da "L'Angolo Tecnico").

Per quanto riguarda la conversione "diretta" da .PRG a .TAP, io non conosco nessun tool che la esegua. Il formato .TAP come saprai è fondamentalmente diverso dal .PRG (o dal .T64) in quanto non contiene i dati come sono contenuti in memoria, bensì proprio nella forma di impulsi presenti sulla cassetta, comprese le particolarità dovute a turbo tape e trucchetti vari. Insomma non si tratterebbe di una vera e propria "conversione" ma della "generazione" di un .TAP sulla base dei dati da memorizzare: l'output non è univoco, ossia un .PRG può generare molti .TAP diversi. Anche il tuo dubbio sulla memorizzazione del byte $00 (sempre che non sia io ad averti capito male ) è mal posto: su un .TAP non si memorizza il byte $00 bensì impulsi tali che possano essere "interpretati" come un byte $00...

Cmq non sentirti troppo male, ammetto apertamente di non conoscere neanch'io il formato .TAP in maniera abbastanza approfondita da tenere un seminario...

Dovendo generare un .TAP e avendo il programma sul VICE, io ti consiglierei di continuare a provare a generare il .TAP direttamente da VICE e non da un .PRG.

Evidentemente però, come dovresti sapere, il comando SAVE effettua salvataggi sempre dall'area BASIC, così come è identificata dai puntatori 43-44 e 45-46.

La procedura corretta per salvare aree di memoria diversa, quindi, è:

1) alterare i puntatori 43-44 e 45-46 rispettivamente all'indirizzo iniziale e all'indirizzo finale più uno (particolare da non sottovalutare) dell'area di memoria che devi registrare

2) eseguire il tuo bel comando SAVE

3) rimettere i puntatori a posto prima di continuare a usare il C64!

Ad esempio per salvare l'area di memoria da 49152 a 49762 (indirizzo che ho preso a caso... tu mettici quello che ti serve):

1) prendi nota dei valori attuali di PEEK(43), PEEK(44), PEEK(45), PEEK(46) facendoli stampare con PRINT e scrivendoteli da una parte. Memorizzarli su variabili del C64 non va bene, perché alterando i puntatori, il C64 si perde anche le variabili!

2) calcoli i valori byte basso/byte alto:
byte alto = INT(locazione/256)
byte basso = locazione - byte alto * 256
49152 = 0 + 192*256
49763 = 99 + 194*256

3) esegui
POKE 43,0:POKE 44,192
POKE 45,99:POKE 46,194

4) fai il tuo bel
SAVE "nome programma"

5) esegui le POKE per rimettere nelle locazioni 43, 44, 45, 46 i valori precedenti

In alternativa, usare una routine in linguaggio macchina o una di quelle espansioni del BASIC che forniscano un comando tipo BSAVE.

Ti ricordo anche che la procedura corretta per caricare zone di memoria da cassetta è LOAD"nome programma",1,1 (eventualmente anche solo LOAD"",1,1) seguito da NEW a caricamento terminato.

Spero che questa dissertazione ti sia utile...

Ma alla fine di tutto, quello che volevo dirti realmente è: perché non usi i dischetti?

[Fabrizio]

 

Effettivamente sì, hai postato in una sezione sbagliata ("Programmazione" è dedicata alla programmazione del C64, la tua è una domanda più da "L'Angolo Tecnico").

Effettivamente avevo questo dubbio... mi scuso.

l'output non è univoco, ossia un .PRG può generare molti .TAP diversi.

Questo non lo avevo capito, in effetti da quello che ho letto, avevo capito che ogni valore doveva essere codificato come: pulse length (in seconds) = (8 * data byte) / (clock cycles), quindi in modo univoco essendo clock cycles un valore costante...
 :huh:

su un .TAP non si memorizza il byte $00 bensì impulsi tali che possano essere "interpretati" come un byte $00...

Ok, non si memorizza $00 ma dovrebbe essere codificato come 8*0/clock che però fa zero, da qui il mio dubbio... però la regola di conversione forse non è questa o forse l'ho capita male.... Dove sbaglio?

La procedura corretta per salvare aree di memoria diversa, quindi, è:

Grazie dell'indicazione e della spiegazione!! Proverò senz'altro in questo modo... Ti farò sapere i risultati!
Un'altra cosa, quando poi carico il programma, questo dove viene messo? Nel buffer basic?

Ma alla fine di tutto, quello che volevo dirti realmente è: perché non usi i dischetti?

Si, forse sarebbe più semplice ma il mio obiettivo è provare il programmino sul mio vero C64 che però ha solo il Datassette...

Grazie. Ciao. Fabrizio.

[Alberto]

 Per chi è interessato,qui c'e' qualcosa sul formato .TAP

TAP1
TAP2

 

[Fabrizio]

 Ho provato il metodo che mi hai suggerito modificando i puntatori della ram basic, però quando lancio il SAVE ottengo un errore di out of memory... Allora ho modificato direttamente l'indirizzo di origine del mio programmino e l'ho inserito proprio nella ram basic, in questo modo sono riuscito a creare il TAP senza problemi... Ti ringrazio per le indicazioni!! Grazie anche ad Alberto per i link sulla documentazione! Ciao. Fabrizio.
 

[eregil]

 

Un'altra cosa, quando poi carico il programma, questo dove viene messo? Nel buffer basic?

Funziona così: se non specifichi il secondo parametro "1" dopo la periferica nel LOAD, cioè esegui uno fra...

Codice: [Seleziona]

LOAD
LOAD "nome programma"
LOAD "nome programma",8

...il programma viene sempre caricato nell'area BASIC (di default da 2049 in poi). Se specifichi il secondo parametro "1":

Codice: [Seleziona]

LOAD "",1,1
LOAD "nome programma",1,1
LOAD "nome programma",8,1

il programma viene caricato nelle stesse locazioni da cui era stato salvato: nel mio esempio da 49152.

Ho provato il metodo che mi hai suggerito modificando i puntatori della ram basic, però quando lancio il SAVE ottengo un errore di out of memory...

Questo non dovrebbe accadere sempre che tu non abbia sbagliato a modificare i puntatori 43-44 e 45-46. Hai calcolato bene i valori? Fai la controprova verificando che la solita formuletta (basso + 256*alto) dia la locazione che ti aspetti. Sei sicuro di non aver invertito byte basso e byte alto? In ogni puntatore, il primo valore è il byte basso, non quello alto. Infatti normalmente 2049 è memorizzato come 1,8 e non come 8,1. Sei sicuro di non aver invertito 43-44 con 45-46? ecc...

Se sposti "brutalmente" il programma nell'area BASIC per salvarlo... poi devi rilocarlo quando lo carichi... non mi sembra molto comodo.

Altrimenti dimmi la tua e-mail in un messaggio privato e ti mando un programmino che serve solo a salvare zone di memoria, così tagli la testa al topo. :D

Sul formato .TAP:

Ok, non si memorizza $00 ma dovrebbe essere codificato come 8*0/clock che però fa zero, da qui il mio dubbio... però la regola di conversione forse non è questa o forse l'ho capita male.... Dove sbaglio?

Nel continuare a credere che quel "data byte" rappresenti un byte come è memorizzato nella memoria del C64 (o nel .PRG)! Non è così!!! Nel .TAP non si memorizzano i byte della memoria del C64, ma le durate degli impulsi così come sarebbero nella cassetta. Ogni byte va modulato in impulsi, e gli impulsi, non i byte, vengono memorizzati nel .TAP. Un impulso evidentemente non ha mai durata zero, altrimenti... non c'è!

Un byte $00 è formato da otto bit "0", ciascuno dei quali è modulato in un impulso di una durata particolare: quelle durate sono memorizzate nel .TAP, non lo zero (o gli zeri).

Per questo non è univoca la corrispondenza tra un .PRG e un .TAP: a parte la possibilità che un .TAP ospiti più programmi in successione, ciascuna sequenza di bit è codificata diversamente nella cassetta a seconda che si utilizzi questo o quel "turbo tape", o nessuno. Leggere "a mano" quei numeri che trovi nel file .TAP assomiglia molto di più ad ascoltare in uno stereo una cassetta registrata dal C64, che a visualizzare il contenuto di un blocco del disco inserito nel 1541.

Ti è più chiaro adesso? Una volta che hai capito questo, puoi leggere i documenti linkati da Alberto (che ringrazio) per capire esattamente come avviene la codifica degli impulsi nel .TAP.

[Fabrizio]

 Grazie per le specificazioni!

Questo non dovrebbe accadere sempre che tu non abbia sbagliato a modificare i puntatori 43-44 e 45-46. Hai calcolato bene i valori?

Credo di sì, il programma va da $c000 (49152) a $c993 (51603), quindi dovrò inserire come valore per il puntatore in 43-44 49152 e 45-46 51603+1, ossia: 0,192 e 148,201... corretto?

Se sposti "brutalmente" il programma nell'area BASIC per salvarlo... poi devi rilocarlo quando lo carichi... non mi sembra molto comodo.

Il programma sta e gira nell'area del basic, non mi serve rilocarlo, è compilato a partire da 2050.

Sul formato .TAP:

Nel .TAP non si memorizzano i byte della memoria del C64, ma le durate degli impulsi così come sarebbero nella cassetta. Ogni byte va modulato in impulsi, e gli impulsi, non i byte, vengono memorizzati nel .TAP.

Ok, questo l'ho capito, ma come si "traducono" in durate di impulso i valori da salvare (e perchè questa traduzione può non essere univoca) questo non mi è chiaro... non va usata quella formuletta?

Vabbè, comunque il problema che avevo è stato risolto, grazie. Ciao! Fabrizio.

[eregil]

 

Credo di sì, il programma va da $c000 (49152) a $c993 (51603), quindi dovrò inserire come valore per il puntatore in 43-44 49152 e 45-46 51603+1, ossia: 0,192 e 148,201... corretto?

Sì.

ma come si "traducono" in durate di impulso i valori da salvare (e perchè questa traduzione può non essere univoca) questo non mi è chiaro... non va usata quella formuletta?

No, lo scopo di quella formuletta è memorizzare gli impulsi in formato leggibile dall'emulatore (e non in file audio, per intenderci), che è già il passo successivo.

Su come esattamente i dati vengano convertiti in impulsi, la risposta è: dipende. Dipende se si usano le routine "normali" del C64 o un turbo tape o qualche altro trucchetto. Se non ti spaventano le spiegazioni tecniche, vai su

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

cerca nella pagina il link "Loader Documentation", e leggiti i file contenuti nello .zip (inizia da quello del loader standard, "C64 ROM Tape.txt").

In soldoni, nel loader standard ogni byte è codificato con 20 impulsi: i primi due segnalano l'inizio di un nuovo byte (ciò è utile per sincronizzare la trasmissione), seguono 16 impulsi di dati (ogni bit è memorizzato come una coppia di impulsi, corto-medio per lo 0 e medio-corto per l'1) e due impulsi di controllo (una specie di checksum). E questo solo per i dati veri e propri.

[Fabrizio]

 Grazie, ci darò senz'altro un'occhiata, l'argomento mi interessa. Ciao. Fabrizio.  :D  

[Alberto]

 Questo è un altro buon punto di partenza per capire come sono fatti e come vengono processati i nastri del C64.

come si "traducono" in durate di impulso i valori da salvare (e perchè questa traduzione può non essere univoca) questo non mi è chiaro... non va usata quella formuletta?

Usando questa formula

byte * 8

si ottiene l'intervallo di tempo intercorso tra la generazione dell'impulso e il precedente,espresso in microsecondi (1 microsecondo = 0.000001 secondi).

Moltiplicando il tutto per 0.985248 si ottiene invece la durata dello stesso intervallo di tempo,espressa però in cicli di clock di un C64 PAL.

Un byte $0 sul TAP è sempre associato a un bit 1 perchè,come riportato nei link rappresenta una "condizione di overflow",cioè una pausa tra due impulsi particolarmente lunga (> 255*8 microsec.).

L'argomento è affascinante ma anche abbastanza complesso:per approfondimenti rimando ai link puntualmente segnalati da Eregil.

Ciao

[fab]

 WAV-PRG (http://wav-prg.sourceforge.net) è in grado di salvare un .PRG in .TAP, usando il Turbo Tape 64 o il vecchio loader senza turbo (sconsigliato, a meno che il .PRG non sia piccolissimo).

[Flimbo]

 Riapro questo topic per sapere se c'è un modo per convertire un PRG in tap usando anche altri tipi di loader oltre al KERNEL e al TURBO TAPE di WAV-PRG.
 

[eregil]

 Regolamento:

4) Non riesumate i thread vecchi aperti mesi o addirittura anni fa. E' consigliabile inaugurare una nuova discussione piuttosto che rispondere a temi già esauriti molto tempo prima;

Se proprio devi fare riferimento a vecchie discussioni, è meglio un link.