Ready64 Forum
Commodore 64 => CBM Hardware => Topic aperto da: walter76 - 13 Giugno 2008, 10:59:32
-
Ciao a tutti.
Da pochi giorni ho rispolverato il mio glorioso C64... Che nodo in gola mi è venuto!
Girando in rete ho visto che ci sono molte possibilità di espandere le periferiche con tecnologie di oggi. Mi è venuta l'idea di realizzare una semplice scheda che si collega al posto del datassette e ne emula il funzionamento, sostituendo però il nastro magnetico con un banco di EEPROM seriali.
Sapete dirmi se esiste già una cosa del genere? Dove posso trovare la documentazione relativa a protocollo e segnali scambiati da C64 e datassette?
Grazie mille in anticipo a chi mi risponderà!
Walter
-
una semplice scheda che si collega al posto del datassette e ne emula il funzionamento, sostituendo però il nastro magnetico con un banco di EEPROM seriali.
Sapete dirmi se esiste già una cosa del genere?
Si'. Si chiama DC2N (http://www.luigidifraia.com/c64/dc2n/)
Dove posso trovare la documentazione relativa a protocollo e segnali scambiati da C64 e datassette?
Avevo scritto qualcosa al riguardo qui (http://geocities.com/SiliconValley/Platform/8224/c64tape/tape.html) tempo fa.
-
Fab, grazie delle risposte!
Purtroppo da lavoro non ho accesso al link sul datassette... lo aprirò da casa.
Ma schematici e firmware del DC2N sono disponibili?
Altrimenti vorrei provarci e rendere pubblici i risultati.
-
Ma schematici e firmware del DC2N sono disponibili?
Luigi e' piuttosto cauto al riguardo, non rende disponibili le sorgenti del firmware ne' gli schemi. Ma puoi provare a scrivergli, e' molto disponibile e forse lo convinci.
-
Stasera apro il link che mi hai dato e comincio a studiarci su.
Cmq non credo che sia molto difficile emulare una periferica lenta come il datassette.
Quanti kB sono necessari per caricare il gioco più pesante che conosci?
Personalmente sono per lo shareware, tantopiù se si tratta di C64!
-
Il gioco piu' pesante nel senso di occupazione dischi e' senz'altro Enhanced Newcomer, 15 disksides da 40 tracce per un totale di quasi 3mb. Per un gioco in single load vanno garantiti i 64k, i multilevel possono arrivare a 2mb di dati, espansi, ma di solito si viaggia sulle 2 disksides piene quindi 340k
Personalmente sono per lo shareware
Cioe' far pagare per una versione finale completa e dare gratuitamente solo una versione crippled?
-
Grazie IAN per le info.
Volevo dire freeware, non shareware... sono io che da ignorante ho pensato fossero due cose analoghe! :fagiano:
Comincio a capirci un po' di più sul funzionamento del datassette. Ho anche visto che c'è una profusione di interfacce varie in rete. Cmq, non mi è passata la voglia di smanettarci su!
Alcune domande:
1) Il contenuto dei files .TAP è esattamente ciò che leggerei decodificando i segnali del datassette?
2) Che modifiche a livello di segnali comporta il caricamento del fastloader?
Ciao,
WA
-
1) Il contenuto dei files .TAP è esattamente ciò che leggerei decodificando i segnali del datassette?
Sì. Ogni byte codifica la durata di un impulso, l'unità di misura è 8 cicli di clock (poi ci sono le pause, che richiedono più di 1 byte, e sono codificate diversamente tra TAP v0 e v1).
2) Che modifiche a livello di segnali comporta il caricamento del fastloader?
Nessuna. Al massimo, la durata media degli impulsi è più breve.
Le differenze tra un fast loader e il loader normale sono ad alto livello, il TAP codifica a basso livello.
-
Penso di aver capito...
E' possibile convertire un file .d64 in .TAP?
Con cosa posso visualizzare i bytes di un .TAP per confrontare le letture sul datassette?
-
E' possibile convertire un file .d64 in .TAP?
No. Pero' puoi convertire i singoli .prg in un .d64 in .TAP, purche' siano in caricamento singolo.
Con cosa posso visualizzare i bytes di un .TAP per confrontare le letture sul datassette?
Con un hex editor. Oppure, convertendo il TAP in WAV (con Audiotap, o con Tapclean, o con TapWav) e osservando il WAV con un editor sonoro.
EDIT: dimenticavo TAPMoni, che visualizza un TAP come una sequenza di impulsi piu' o meno corti, e mostra gli impulsi con lo scorrere del tempo.
-
Ho visto che ci sono un mucchio di impulsi brevi sia all'inizio del file TAP che tra i bocchi di dati, equivalenti a diversi secondi.
Suppongo si tratti di pause...
Ci sono tempi minimi per le pause?
Potrei eliminarle quasi completamente?
Vorrei trovare il modo di comprimere i .TAP per salvarli sulle EEPROM.
Esite già uno standard?
-
Ho visto che ci sono un mucchio di impulsi brevi sia all'inizio del file TAP che tra i bocchi di dati, equivalenti a diversi secondi.
Suppongo si tratti di pause...
Se e' un file TAP v0, e' normale avere all'inizio e tra un programma e l'altro sequenze di byte 00.
Ci sono tempi minimi per le pause?
Potrei eliminarle quasi completamente?
Come in una vera cassetta, no. L'unico limite e' dovuto ad eventuali imprecisioni nella fermata del motore.
Vorrei trovare il modo di comprimere i .TAP per salvarli sulle EEPROM.
Esite già uno standard?
No. Ogni tanto vengono fuori delle proposte. Ce n'era una che non trovo piu', forse era sul forum di tapes.c64.no che ha chiuso. E ne avevo fatta una (http://ready64.org/smf/index.php?topic=1251.30) anche io. Ma entrambe rimangono pure teorie.
Luigi Di Fraia (che e' presente su questo forum come tce, ma posta sporadicamente, e che ho avuto la fortuna di conoscere di persona) mi ha detto che, nell'uso real-time, ha dei problemi pure con i TAP v1, e quindi il suo DC2N supporta solo i TAP v0, oppure un formato di sua invenzione che usa 16 bit per impulso. In entrambi i casi, la tendenza e' opposta alla sua proposta, i file occupano piu' spazio di un normale TAP v1.
-
Una domanda sul contenuto dei file .TAP: ho notato che, header a parte, i dati codificano fondamentalmente tre durate degli impulsi nella fase iniziale (suppongo sia il loader) e soltanto due nelle sessioni successive.
Quello che non mi spiego sono dei bytes strani che si incontrano all'inizio o alla fine di alcune sessioni. :huh:
Faccio un esempio, riferito a Rick Dangerous II, side A:
Z00ZZ00ZZ0Z0ZZZ0Z000000ZZZ0000000Z0000000000 àn 0000ZZZZ0000ZZZZ0000ZZZZ0000ZZZZ0000ZZZZ
Cosa sono i bytes diversi da Z e 0?
Qualche CRC?
Come si calcolano?
-
Ho scaricato il TAP da http://tapes.c64.no/main_tapelist.php?group=R&orderby=title (http://tapes.c64.no/main_tapelist.php?group=R&orderby=title) (immagino che anche tu lo abbia preso da li').
Immagino che tu ti riferisca a qualcosa di simile:
0000.àn.0000ZZZZ0000Z
o, in esadecimale,
30 30 30 30 00 e0 6e 1f 30 30 30 5a 5a 5a 5a 30 30 30 30 5a
La risposta e' nelle specifiche del TAP v1 (http://www.computerbrains.com/tapformat.html)
Version=1:
As above but data value of 00 is now followed by three bytes, representing a 24 bit value of C64
cyles (NOT times 8). The order is as follow: 00 .
Dopo il byte 00, seguono 3 byte. Essendo little-endian, rappresentano il numero 0x1f6ee0 (2060000 in decimale). Cioe', un impulso lungo 2060000 cicli di clock, o, in altri termini, una pausa di circa 2 secondi.
-
Ho capito :P
Però ho visto che in hex non c'è 00 come da specifica, bensì 20...
30 30 30 20 20 E2 04 30 30 30 ... 30 30 20 E0 22 02 30 30 ...
come mai?
Il passo successivo è trovare il modo di comprimere molto i .TAP.
Ho dato un occhio alla proposta per il formato .TMG, ma mi sono incasinato. Inoltre non ho capito come faccia a distinguere differenti sessioni nello stesso file :huh:
Ho pensato ad un formato semplificato ma reversibile:
Proposta per comprimere i .TAP v1.0
4 bytes header "CTAP" Compressed TAP
1 byte versione
2 byte numero puntatori a blocchi (N)
N*4 bytes (32-bit per ogni puntatore)
4 bytes per l'indirizzo di fine file
all'indirizzo di ciascun blocco:
1 byte marker che può essere "2"=codifica a 2 livelli oppure "3"=codifica a 3 livelli
3 bytes per definire la durata degli impulsi L,M,S
4 bytes per il valore di pausa iniziale
4 bytes puntatore fine blocco corrente
seguono i dati compressi come segue:
Codifica a 2 livelli: binario (rapporto di compressione 8:1)
Codifica a 3 livelli: coppie di bit per impulso (rapporto di compressione 4:1)
All'indirizzo di fine blocco:
4 bytes CRC32
All'indirizzo di fine file:
4 bytes CRC32 sull'intero contenuto del file, header incluso.
4 bytes "C=64" come tributo al biscottone :P
Cosa ne pensate?
-
Allora quell'E2 e' sicuramente un impulso "sporco", ma bisognaerebbe vedere il tap dopo una bella pulizia con Tapclean. RickDangerous2 usa un Cyberload e non ha simili bytes, non nella versione pulita del tap. L'hai mai provato? B)
Il formato TMG l'ho visto su sourceforge, gran bella idea, ma un tap ripulito con tapclean e compresso con 7zip e' senza dubbio migliore in termini di occupazione, senza contare che quel formato non e' - e imho mai sara' - supportato da alcun programma, mentre e' un attimo aggiungere 7zip tra i formati compressi supportati da vice.
-
Però ho visto che in hex non c'è 00 come da specifica, bensì 20...
30 30 30 20 20 E2 04 30 30 30 ... 30 30 20 E0 22 02 30 30 ...
come mai?
Ho cercato nel TAP e non l'ho trovato. Ho trovato
30 30 30 00 00 e2 04 30 30 30 (offset 35394)
30 30 30 00 e0 22 02 30 30 30 (offset 47575)
x iAN, dove hai torvato le informazioni sul TMG? Su Google, TMG non da' niente collegato col C64.
-
x iAN, dove hai torvato le informazioni sul TMG? Su Google, TMG non da' niente collegato col C64.
http://sourceforge.net/projects/c64tapes/ (http://sourceforge.net/projects/c64tapes/)
progetto di Gremlin, membro sudafricano di c64tapes.org/forum.
Uno dei 2 programmi di questo progetto e' TapTMG, nei files scaricabili sono compresi anche i dox sul formato. Purtroppo e' in ViralBasic.
-
Purtroppo e' in ViralBasic.
Giusto per la cronaca, come esercizio e puro sfizio, oggi ho provato a convertirlo in C. La compressione TAP->TMG e' gia' funzionante, poi cerchero' di convertire anche la parte della decompressione TMG->TAP.
-
Finito. Il programma originale contiene anche degli errori di implementazione, e va spesso in crash su tap sporchi.
Il mio porting contiene diversi fix rispetto alla versione originale, per chi vuole provarlo:
hxxp://iancoog.altervista.org/C/comptap_src_v1.0.rar
inclusi sorgente, readme.txt e exe win32 precompilato.
Grazie a Eregil per averlo compilato e testato sotto *nix. Con mio stupore va anche li' :fagiano:
-
Bug report: nel file readme.txt tutte le date dicono 2007 :)
-
heh, potenza del copia incolla. Corretto e riuppato il tutto.
Fabrizio, ti chiedo una cortesia. Siccome bokvamme non si sveglia ad attivarmi l'account su c64tapes.org/forum potresti girare il file nell'apposito thread?
http://c64tapes.org/forum/viewtopic.php?p=340 (http://c64tapes.org/forum/viewtopic.php?p=340)
grazie anticipate
-
Fatto.