Ready64 Forum
Commodore 64 => Commodore 64 & Ready64 => Topic aperto da: Alberto - 17 Gennaio 2006, 18:38:21
-
Ciao ragazzi
Solo per dire che in questo periodo sto sviluppando un TAP manager che consenta di rimuovere, modificare e spostare entry da un TAP ad un altro (e chissà,forse anche riparare le parti danneggiate).Pensavo a un programma GUI che sfrutti le caratteristiche drag and drop di Windows e che sia veloce,potente e intuitivo.
E' probabile che venga inglobato in una delle prossime release del WAV-PRG (ho sentito fab via e-mail e sembra che non abbia nulla in contrario in proposito,non so se vorrà collaborare anche lui alla realizzazione di questo utility,vedremo).
Il progetto è più o meno al 20%,quindi sono ancora agli inizi.Non so entro quanto tempo potrò terminarlo (anche considerati gli impegni attuali),ma se qualcuno potrà e vorrà darmi una mano,inutile dire che è benvenuto. :-)
Alla prossima
-
Hai contattato Carmine TSM, l'autore di STAP/JTAP/FTAP? La sua mail (quella sul sito) è valida.
Il mio sogno sarebbe qualcosa come Star Commander (o magari integrata in SC stesso) che faccia quello che tu dici (con la GUI e tutto) MA IN PIU' anche quello che fanno MTAP e PTAP di Markus Brenner e i tre programmi che ho citato sopra di Carmine TSM.
E' troppo anacronistico, probabilmente, visto che Markus Brenner (e i sorgenti dei suoi programmi, che NON sono GPL) è irreperibile da mesi (Hiryu ne sa qualcosa :( ), e per quanto riguarda un'integrazione in Star Commander non so sinceramente se i suoi autori ci abbiano mai pensato. Credo però che la collaborazione con Carmine sia possibile, e ti consiglio quindi di contattarlo almeno per farti dare quello che lui ha scoperto. Così come ti aiuta Fabrizio Gennari (che diede a suo tempo anche una mano a Carmine per la parte del riconoscimento dei nomi dei programmi).
Io personalmente più di consigli esterni ed eventuale betatesting (che farei con piacere, sarebbe un onore) non posso fare, però ti (vi) auguro di tutto cuore buon lavoro, sicuro che riuscirete a farlo e che aiuterete non poco la comunità.
Mi raccomando da subito il supporto per il loader Alga Soft ;)
-
Purtroppo alterno momenti (pochi) in cui ho tempo, a lunghi periodi (troppi) in cui non riesco a dedicarmi agli hobby. Perciò, pur essendomi ripromesso di ripulire il codice del rudimentale TAP manager che giace nella partizione Linux del mio HD, e spedirlo ad Alberto, come gli ho scritto per e-mail, ancora non sono riuscito a farlo. Però proprio in questo momento sto compilando Qt per Windows, che è un piccolo passo avanti (l'interfaccia grafica usa Qt proprio per essere cross-platform).
Spero di poter pubblicare qualcosa a breve. Ma considerata la mia inaffidabilità degli ultimi tempi, non prometto niente.
Il sogno sarebbe trasformarlo in una versione open source di Final TAP, che negli ultimi tempi non è mantenuto un granché neanche lui...
-
Mi raccomando da subito il supporto per il loader Alga Soft ;)
Da poco c'è un plug-in WAV-PRG che si chiama Firebird e supporta, tra l'altro, il loader Alga Soft. L'ho testato con pochi TAP, mettilo alla prova
-
Da poco c'è un plug-in WAV-PRG che si chiama Firebird e supporta, tra l'altro, il loader Alga Soft. L'ho testato con pochi TAP, mettilo alla prova
Ecco, adesso che li ho estratti tutti a mano da vice, c'e' il plugin :doh: :doh:
ora guglo per cercarlo
-
Fab: ho scaricato wavprg 3.3 e tutti i plugin (evviva flashget, se no sai che palla a cliccarli tutti :D)
Devo informarti che le prime 2 alga che ho provato, 16 e 17, non vanno con il firebird.dll, non estrae nulla
Dalla 10 in alcuni lati va in altri non del tutto, estrae solo qualche prg ma comunque stecca tutti i nomi, usa il primo per tutti mi sa.
"NEMESIS 1.prg"
"NEMESIS 2.prg"
"NEMESIS 3.prg"
"NEMESIS 4.prg"
"NEMESIS 5.prg"
"NEMESIS 6.prg"
"NEMESIS 7.prg"
"NEMESIS 8.prg"
"NEMESIS 9.prg"
"NEMESIS 10.prg"
"NEMESIS 11.prg"
"NEMESIS 12.prg"
"CABER TOSS [CH1.prg"
"CABER TOSS [CH3.prg"
"CABER TOSS [CH4.prg"
"CABER TOSS [CH5.prg"
"CABER TOSS [CH6.prg"
"CABER TOSS [CH7.prg"
"CABER TOSS [CH8.prg"
"CABER TOSS [CH9.prg"
"CABER TOSS [C10.prg"
"EXPRESS RAIDER 1.prg"
"EXPRESS RAIDER 2.prg"
-
Grandissimo progetto. Finalmente qualcuno che si dedica ad 1 utility cosi' necessaria.
Grazie e in bocca al lupo!
-
Dalla 10 in alcuni lati va in altri non del tutto, estrae solo qualche prg ma comunque stecca tutti i nomi, usa il primo per tutti mi sa.
Devi premere "Advanced options" e ridurre il "number of chunks between seeks". 20 significa che usa il primo nome per i primi 20 giochi che trova.
Il problema è che non c'è un riconoscimento automatico di quando viene trovato uno "header chunk" e quando uno header Alga Soft. Semplicemente, viene cercato uno header chunk e 20 (o meno, se diminuisci il numero) giochi Alga Soft, poi di nuovo uno header chunk (così il nome cambia) ecc.
Se diminuisci troppo il numero, rischi però di perdere le ultime parti dei giochi multiparte. Un gioco multiparte ha uno header chunk seguito da parecchie parti Alga Soft, non inframmezzate da header chunk. Esempio: se metti 1 come numero e carichi 1 gioco in 2 parti:
-trova lo "header chunk" iniziale
-carica la prima parte
-si mette a cercare uno "header chunk", perdendo così la seconda parte.
L'unica soluzione che mi viene è di fare una prima prova con un numero alto, e diminuirlo progressivamente. E' il contrario di user-friendly, mi rendo conto, servirebbe un riconoscimento automatico, oppure usare passate multiple come fa Final TAP.
Mi mandi per e-mail i TAP che non vanno? In particolare quelli che non vanno per niente, in teoria almeno il primo gioco dovrebbe funzionare...
-
QUOTE (iAN CooG/HF @ Jan 18 2006, 12:41 AM)
Dalla 10 in alcuni lati va in altri non del tutto, estrae solo qualche prg ma comunque stecca tutti i nomi, usa il primo per tutti mi sa.
Sì,l'ho notato anch'io;il problema è legato alla struttura dei blocchi dopo l'intestazione,che può variare da loader a loader:cose del genere succedono spesso quando si cerca di scrivere codice generico.
Hai contattato Carmine TSM, l'autore di STAP/JTAP/FTAP? La sua mail (quella sul sito) è valida.
Il mio sogno sarebbe qualcosa come Star Commander (o magari integrata in SC stesso) che faccia quello che tu dici (con la GUI e tutto) MA IN PIU' anche quello che fanno MTAP e PTAP di Markus Brenner e i tre programmi che ho citato sopra di Carmine TSM.
Non conosco i programmi di Carmine ma conosco bene M(P)TAP,avevo scaricato anche il sorgente della versione 0.36 perchè ero curioso di sapere come facesse a ricevere il segnale dalla porta parallela,ma poi non l'ho più guardato.
pur essendomi ripromesso di ripulire il codice del rudimentale TAP manager che giace nella partizione Linux del mio HD, e spedirlo ad Alberto, come gli ho scritto per e-mail, ancora non sono riuscito a farlo.
Vai tranquillo,quando puoi ;)
Comunque anch'io sono molto indietro,per ora il programma legge solamente i nomi dei programmi su TAP e dà alcune info per ogni entry (indirizzo d'inizio e fine,tipo di loader usato),l'altro giorno ho buttato giù lo schizzo per dotare l'utility di una "ricerca intelligente" (te lo invio prima possibile).
Ad ogni modo,appena riesco mailo Carmine (hai detto /TSM?
ma è in un demo group? :P )
Ciao
-
Ad ogni modo,appena riesco mailo Carmine (hai detto /TSM?
ma è in un demo group? :P )
No TSM (senza slash) sta per The Sudden Miracle, che è il suo nick ed è anche il nome del suo sito che contiene le utility in questione, gli schemi di collegamento del registratore e un po' di dump di cassette.
L'URL è http://spazioinwind.libero.it/vic20/ (http://spazioinwind.libero.it/vic20/), qui trovi anche la sua mail (clicca su "TSM" nella prima pagina, frame di destra).
-
hai detto /TSM? ma è in un demo group?
No, erano un Cracking group e Importers USA (The Shaolin Monastery)
-
Ciao a tutti!
Innanzi tutto grazie ad Alberto per avermi coinvolto nel progetto e a Massi per essere da sempre il fan n. 1 delle mie utilities.
Ebbene sono proprio io, "quello di STAP". Questo programmino che, come tanti, all'inizio non fu pensato per essere pubblicato, lo misi su Internet soltanto per allungare un po' il brodo del mio sito, messo in piedi solo per condividere i miei "dump" di cassettine del 64.
Onestamente non ne vado fierissimo (chi vorra` interessarsi di come funziona capira` ben presto il perche`) ma all'epoca si rivelo` molto utile: usavo CCS64 e ogni volta che volevo passare da un gioco al successivo sulla cassetta, il maledetto mi resettava il nastro. Scrissi una mail a Sundell e non ottenendo risposta, decisi di adottare una tipica soluzione "quick & dirty". Poi fu principalmente grazie al mio "tifoso" e "sfruculiatore" Massi che aggiunsi il riconoscimento dei nomi.
Il motivo per cui non esistono in giro soluzioni comode per gestire come si deve i "blocchi" all'interno dei file TAP, secondo me, e` che fuori dall'Italia le "collane" di cassette piene di giochi pseudo-originali non ebbero molta diffusione; e anche qui, col senno di poi, alcuni tendono a liquidarle come roba taroccata di poco interesse. Io comunque ci vado matto, e` piu` forte di me!
Tutta questa premessa per dire che io, nei limiti del possibile, ci sono. Purtroppo non saro` utilissimo come coder perche` non conosco il C++, ma solo C semplice, Java e Vis... ehm, e un'altra cosa che non ricordo!
--
TSM
P.S. Il mio nick, che mi porto dietro dal '92, e` una sigla dal significato leggermente osceno. Quando feci il sito scelsi un titolo con le stesse iniziali per ottenere la stessa sigla!
-
^_____________^
Lo sapevo che non avresti resistito a postare :D :D :D
-
Molto bene,se il buon Rob ce lo consente,direi che d'ora in avanti potremmo usare questo topic per scambiarci idee e impressioni su come impostare il programma,che dite?Io ho già qualche ideuzza (messa su codice da un paio di settimane) ma vorrei sentire voi in proposito.
Ovviamente,la partecipazione è aperta a tutti :)
Ciao
-
Onestamente non ne vado fierissimo (chi vorra` interessarsi di come funziona capira` ben presto il perche`)
L'ho provato ieri sera e ho apprezzato molto la sua rapidità nell'analisi del TAP.
P.S.:tra l'altro ho notato che "sfora" i nomi dei programmi,nel senso che mancano dei caratteri.Puoi spiegarmene il motivo?
Grazie :)
-
:confused: Mancano caratteri nel nome? Non mi era mai capitato... Almeno credo! Potresti inviarmi il TAP (o anche una parte, diciamo 2 - 3 blocchi) zippato in email?
Da come lo programmai mi aspettavo che ci fossero caratteri di troppo, piuttosto che mancanti!
--
TSM
-
Mancano caratteri nel nome? Non mi era mai capitato... Almeno credo! Potresti inviarmi il TAP (o anche una parte, diciamo 2 - 3 blocchi) zippato in email?
Sì certo :)
-
;) Ma è un'Alga Soft, queste cassette sembrano essere leggermente fuori standard. Anche Vice, nonostante le apra correttamente, ha problemi nel creare l'elenco dei file nella finestra di caricamento immagine (a me ha dato "Empty image").
Dovremo lavorare anche su questo!
--
TSM
-
Eh, si vede che non hai aggiornato Vice. Se leggi i thread riguardo al Vice 1.18 e 1.19 sempre su questo forum vedrai che ORA vice supporta anche queste tape images fuori standard
-
Eh, si vede che non hai aggiornato Vice. Se leggi i thread riguardo al Vice 1.18 e 1.19 sempre su questo forum vedrai che ORA vice supporta anche queste tape images fuori standard
Dopo fatiche e insistenze, aggiungo ;)
-
Ti riassumo la situazione:nelle versioni < 1.19,VICE non accettava header più corte di 193 byte (192+1 di checksum),mentre molti programmi delle AlgaSoft presentano un header di 180 byte (179+1 di checksum).
Intanto,volevo chiederti se puoi inviarmi i sorgenti di STAP;vorrei vedere come legge i TAP.Grazie
:)
-
Intanto posto un assaggino del TAP manager che sto programmando;è pensato come una funzionalità aggiuntiva di WAV-PRG,per cui l'aspetto grafico non si discosta molto dal resto del programma.
(http://www.geocities.com/tuttowindows98/immagini/tapmng260106.jpg)
Ovviamente c'e' ancora molto da sistemare (opzioni da aggiungere,ecc...).
Siccome sono sempre convinto che 20 menti pensano meglio di una o due,sono graditi suggerimenti,idee,consigli...
Ciao :P
-
Siccome sono sempre convinto che 20 menti pensano meglio di una o due,sono graditi suggerimenti,idee,consigli...
L'interfaccia sembra essere sufficientemente funzionale, a me piacciono le cose semplici.
Consigli di implementazione da parte mia:
- uso di tasti/hotkeys anziche' solo mouse, per selezionare files, estrazione, e passaggio tra un pannello e l'altro tramite tab.
- possiblita' di scanning per riconoscimento del loader (come finaltap, provando ogni plugin e vedendo cosa ne tira fuori)
-
Intanto complimenti... perche' da questo topic che ho sostenuto dall'inizio e' uscita fuori gente con passione e capacita'!!!!
GRAZIE.
Io sono daccordo sui suggerimenti di Ian sopratutto sulle 2 finestre e copia di blocchi da 1 tap a l'altro e un flag sul crc.. tipo OK oppure BAD.. (e' complicato?)
Avanti cosi'!!! :mavieni:
-
Sorgenti inviati :mattsid: .
--
TSM
-
Ciao ragazzi
Intanto grazie per il sostegno (koseidon72) e per i consigli (iAN CooG,li terrò sicuramente presenti).
Qualche giorno fa ho iniziato a lavorare sul motore di scansione dei file TAP.
Un possibile algoritmo di scansione a cui avevo pensato è questo:
1. Non appena ricevi un impulso lungo,vai in 2.
2. Se hai trovato un'headerchunk originale,vai in 3;
altrimenti incrementa il contatore d'errore e torna in 1.
3. Se non ci sono errori nei byte di headerchunk,vai in 6;altrimenti
- se hai l'ordine di recuperarne la copia,vai in 4.
- altrimenti,vai in 7.
4. Non appena ricevi un impulso lungo,vai in 5.
5. Se hai trovato la copia dell'headerchunk,vai in 6;altrimenti
- se hai l'ordine di abortire la ricerca,termina.
- altrimenti,torna in 4.
6. Non appena ricevi un impulso lungo,vai in 7.
7. Se hai trovato un datachunk originale,vai in 8;altrimenti
- se hai l'ordine di abortire la ricerca,termina.
- altrimenti,torna in 6.
8. Se non ci sono errori nei byte del datachunk,vai in 11;altrimenti
- se hai l'ordine di recuperarne la copia,vai in 9.
- altrimenti,vai in 11.
9. Non appena ricevi un impulso lungo,vai in 10.
10. Se hai trovato la copia del datachunk,vai in 11;altrimenti
- se hai l'ordine di abortire la ricerca,termina.
- altrimenti,torna in 9.
11. FINE :-)
Fondamentalmente,l'algoritmo "intelligente" segnala la presenza di blocchi "spuri" servendosi di un contatore d'errore e può recuperare la copia dell'header e dei dati di ogni entry,nel caso in cui l'originale risulti danneggiato o incompleto (previa scelta dell'utente).
Per ogni entry completa viene allocata una struttura che contiene,tra le altre cose,un flag d'errore (in questo modo l'utente ha modo di sapere che cosa c'e' che non va all'interno dell'entry,ad esempio headerchunk e/o datachunk incongruenti tra loro e/o danneggiati).
Infine,mi permetto di farvi osservare una cosa:la ricerca dell'incipit del blocco (passo 1) causa al massimo una segnalazione d'errore,diversamente dalla ricerca degli altri 3 chunk (passi 5,7,10) che possono interrompere l'intero processo di scansione del TAP.
Questo per il seguente motivo;supponiamo di avere un TAP con questa struttura
- entry 1 -
HO1
HC1
DO1
DC1
- entry 2 -
HO2
HC2
DO2
DC2
- entry 3 -
HO3
HC3
DO3
DC3
dove H sta per headerchunk e D per datachunk,O per originale e C per copia,1 2 3 sono gli indici di entry (prima seconda e terza).
Se mancasse l'incipit della prima entry (cioè HO1) l'algoritmo segnalerebbe questo errore,ma le entry 2 e 3 verrebbero comunque correttamente riconosciute.
Se invece mancasse DO1,senza il meccanismo di blocco,assumendo tutti gli altri chunk corretti l'algoritmo riconoscerebbe (erroneamente) una struttura del genere
- entry 1 -
HO1
HC1
DO2
DC2
- entry 2 -
HO3
HC3
DO3
DC3
i chunk della prima e della seconda entry verrebbero "fusi" insieme perchè il programma cercherebbe sempre il primo DO chunk dopo HO1(o HC1).Il risultato finale è che solo 1 entry su 3 verrebbe riconosciuta correttamente,anche se inizialmente l'entry incompleta era una sola.(Tra l'altro,grazie al meccanismo di blocco l'utente potrebbe individuare facilmente non solo l'entry,ma anche la parte danneggiata all'interno di questa,usando poi l'algoritmo di correzione d'errore per cercare di "riparare" il guasto.Di questo discuteremo più avanti...:-)).
In definitiva il meccanismo di blocco eviterebbe potenziali "disastri" in vista di un'eventuale copiatura/spostamento dell'entry su un altro TAP.
Queste sono solamente delle mie considerazioni iniziali,ma a mio avviso già utili per poter avere uno spunto su cui lavorare.
Al solito attendo opinioni e suggerimenti da chiunque fosse interessato.
P.S.:spero di non aver fatto casino coi numerelli dell'algoritmo!
Alberto
-
un flag sul crc.. tipo OK oppure BAD.. (e' complicato?)
Vediamo :)
Sorgenti inviati .
Grazie,appena ho tempo me li guardo.
-
Adesso sarò provocatorio, MOLTO provocatorio. Astenetevi dal rispondere "Perché non lo fai tu": se ne fossi capace (non lo sono, non so quanto effettivamente si possa fare e ammetto candidamente la mia ignoranza: "Io so di non sapere") l'avrei già fatto, e comunque sono consapevole che quello che dirò sarà in gran parte utopia.
Che mi dici se dico che questa potrebbe diventare la più grande utility per TUTTI i formati del C64 e non solo i .tap?
Allargare il supporto a .t64, .p00, .g64, .d64, .prg e via dicendo, ovviamente con le peculiarità di quel formato, e allo stesso tempo creare un "convertitore interno" che permetta di trasferire i file da un formato all'altro (rimanendo, per i file in più parti, tra disco<->disco e cassetta<->cassetta, se no diventa troppo complicato).
A parte il .g64 che andrebbe scritto da zero, il resto è tutto fatto o in questo progetto o nello Star Commander (il cui team si potrebbe contattare per l'uso delle routine, o al limite proporre noi l'integrazione di queste routine nello SC).
Il riconoscimento dei .tap e la relativa conversione in .prg (trasportabili più facilmente da un formato all'altro) è in gran parte già fatto da Final TAP/WAV-PRG (andrebbero ovviamente aggiunti via via i vari loader che saltassero fuori). Per la conversione da prg *A* tap, oltre a crearli internamente dagli emulatori, si potrebbe sempre prevedere l'eventuale operazione inversa (che tornerebbe utile per chi volesse riportare su una cassetta reale i file per usarli sul vero C64, pur non disponendo di un drive).
Ma dirò di più: propongo infatti la nascita di un nuovo formato.
Infatti, oltre al prg (che è pratico e maneggevole ma perde molte informazioni) si potrebbe pensare a una sorta di prg "ibrido" che in pratica contenga i dati del programma più altre informazioni che consentano di ricreare il tap "pulito". Una specie di d64+errors, o di g64.
Ovviamente quest'ultimo formato (che risulterebbe poi essere il migliore, perché manterrebbe "i caricamenti originali" ma ridurrebbe moltissimo le dimensioni dei file) sarebbe complicato da creare, e soprattutto avrebbe senso se poi venisse implementato dagli emulatori. Il "contenitore" poi sarebbe una specie di t64 che conterrebbe questi "prg allargati con le info sul loader" (.L64, con la L che sta per "Loader"? E' solo un'idea balorda ovviamente).
Però, quantomeno per le cassette da edicola che usano loader standard (tipo le Pubblirome che usano praticamente tutte il Turbo202), non mi pare difficile da implementare.
Questo implicherebbe, ovviamente, che tutti i programmi che facessero uso di questo nuovo formato (emulatori compresi) debbano saper riconoscerlo e comportarsi di conseguenza. Il che significa che dovrà avere tutti i loader integrati e usare di volta in volta quello richiesto. Non sarebbe comunque un gran spreco di spazio visto che parliamo di cose che prendono byte ognuna, anche se i loader sono tanti non sono comunque delle migliaia: al più si arriverebbe a un mega (ma esagero) per contenerli tutti. Se i programmi non hanno i dati per quel loader, caricherebbero comunque il prg come se fosse dentro un .T64, e cioè in maniera "istantanea". Questo ovviamente potrebbe essere settabile anche da menù, una specie di "True drive emulation" che diventerebbe la "True tape emulation" ;)
I pregi di un formato del genere sarebbero innumerevoli: oltre all'ovvio risparmio di spazio (sempre buono per i nostri HD e per i siti) i file verrebbero caricati più velocemente e si potrebbe scegliere tra il caricamento istantaneo (che sarebbe istantaneo e non semplicemente accelerato come succede mettendo il VICE in modalità warp) e il caricamento "emutorially correct". Inoltre, si creerebbe un database dei tanti loader esistenti, che mi sembra sempre un buon motivo di conservazione. Inutile dire che i sorgenti dovrebbero essere aperti a chiunque e fare quindi in modo che tutti possano dare il loro contributo, donando dei TAP con loader ancora non riconosciuti, descrivendo loader o in altro modo.
In fondo, se ci pensiamo, anche il G64 è nato con lo stesso scopo. E in fondo lo stesso formato TAP è relativamente recente. Di un formato come quello di cui parlo si sente effettivamente la mancanza, e se contiamo che un tap di una cassetta da edicola (ma anche i tap dei giochi originali non scherzano) prende mediamente sui 2,5 mega... E' vero che siamo nell'era dei DVD e degli HD da centinaia di giga, ma un file da 2 mega e mezzo per contenere dei giochi che messi insieme non prenderebbero più di 400 KB -e zippati pure meno- (contando che non tutti i giochi prendono tutta la RAM ovviamente) è giusto? ^^
Infine, sarebbe bello anche aumentare la compatibilità agli altri computer, quantomeno a quelli Commodore (ma non sarebbe brutto per una volta togliere le barricate coi "cugini" Spectrum, MSX e via dicendo), visto che soprattutto C16/+4 e Vic20 (ma in parte anche il C128) usano frequenze diverse e, quantomeno nel caso del C16/+4 (nel Vic20 non ho mai visto dei loader diversi da quello standard, anche se SO BENISSIMO che esistevano dei turbotape anche per il Vic20, ma nessuno li usava per ovvi motivi di memoria, almeno nella configurazione base con 3KB) anche loader diversi, forse meno numerosi della controparte per C64 ma comunque ugualmente "curiosi". Se può interessare posso fare un elenco di quelli che conosco (mi riferisco al C16/+4), visto che sono attaccato a queste macchine ancora più di quanto non lo sia al C64.
Tutto quanto ho appena detto è... Utopia? Sogno? O possibile realtà?
Ai poster(i) l'ardua sentenza...
-
Bellissimo topic.. si sta trasformando in uno studio scentifico minuziosissimo sulle implementazioni nuove dei formati di memorizzazione dei vecchi giochi e utility.
Credo che nessun sito anche non italiano sia arrivato a tanto!!!
Complimenti... molte idee interessanti.
Io ti appoggio al 100% pero' sono convinto che prima si debba procedere a passetti. Ad esempio prima si dovra' essere certi che la nuova utility in sviluppo tratti senza errori i tap, poi dopo si potranno estendere le conoscenze a queste altri interessanti aggiunte.
:mavieni:
-
La discussione, evolutasi in qualcosa di più di un semplice annuncio, è ora spostata nel forum "Commodore 64" e promossa a Discussione In Rilievo, poiché sembra che il progetto stia prendendo forma.
Da questo momento siete tutti invitati a postare solo messaggi pertinenti. Inoltre, in particolare, Alberto è invitato a notificare Roberto o un moderatore qualora sopravvengano ragioni per cui questa discussione diventi "obsoleta" e debba essere retrocessa a discussione normale (speriamo di no naturalmente :D).
Io personalmente ho qualcosa da dire sulla proposta di Massi. :)
Questo implicherebbe, ovviamente, che tutti i programmi che facessero uso di questo nuovo formato (emulatori compresi) debbano saper riconoscerlo e comportarsi di conseguenza. Il che significa che dovrà avere tutti i loader integrati e usare di volta in volta quello richiesto.
Allora, a parte che anche a me sembra un po' presto per parlare di un'utilità "multiformato", finché Alberto non è almeno a buon punto con i .tap e non se la sente, all'atto pratico, di sviluppare per altri formati...
Mi pare di capire che l'idea di base per questo ipotetico nuovo formato sia quella di creare un formato con caratteristiche "ibride" tra .tap e .t64, caratteristiche tali da:
1) non costringere a riportare tutte le informazioni relative agli impulsi presenti sulla cassetta; sarebbero invece memorizzati i byte già "processati", come sarebbero inseriti nella memoria del C64
2) e pur tuttavia, riportare informazioni sul loader e quant'altro occorra per ricreare il .tap sulla base del file .L64 (continuiamo a chiamarlo così per il momento) e degli algoritmi e informazioni incluse nelle apposite utilità e negli emulatori.
Un appunto:
Questo non implicherebbe che insieme al "L64 manager" e agli emulatori dovrebbero essere inclusi i binari eseguibili C64 che costituiscono i vari loader? O ho capito male io?
Se così fosse, prima di imbarcarsi in proposte ai team di sviluppo degli emulatori per supportare il nuovo formato, sarebbe il caso di chiedersi se sono disposti a distribuire tali loader insieme agli emulatori. I loader per quanto ne so potrebbero essere coperti da copyright e il problema della ridistribuzione può non essere banale... io considero già un miracolo che con gli emulatori siano distribuite le ROM del C64!
Questo è quanto per ora. A dopo, e spero di sentire presto buone nuove da Alberto. ;)
-
Mi pare di capire che l'idea di base per questo ipotetico nuovo formato sia quella di creare un formato con caratteristiche "ibride" tra .tap e .t64, caratteristiche tali da:
1) non costringere a riportare tutte le informazioni relative agli impulsi presenti sulla cassetta; sarebbero invece memorizzati i byte già "processati", come sarebbero inseriti nella memoria del C64
2) e pur tuttavia, riportare informazioni sul loader e quant'altro occorra per ricreare il .tap sulla base del file .L64 (continuiamo a chiamarlo così per il momento) e degli algoritmi e informazioni incluse nelle apposite utilità e negli emulatori.
Esattamente.
Un appunto:
Questo non implicherebbe che insieme al "L64 manager" e agli emulatori dovrebbero essere inclusi i binari eseguibili C64 che costituiscono i vari loader? O ho capito male io?
In effetti è proprio così, quantomeno per l'emulatore. Per l'utility, più che il codice vero e proprio, servirebbe una sorta di plugin che alla fine comunque conterrebbe il codice, o delle info per riconoscerlo e ricrearlo. In effetti anche per gli emu si potrebbe fare così. Rimarrebbe un "escamotage" analogo a quello che facevano alcuni emulatori Amiga per caricare i giochi senza avere la rom del kickstart.
In alternativa, bisognerebbe che gli emulatori consentano che i loader stiano in file esterni (magari belli ordinati in una cartella) così che questi file siano distribuibili in modo separato dagli emulatori stessi (che comunque a tutt'oggi contengono le rom del kernal e del basic, che sarebbero ancora sotto copyright). Se il file di quel loader è presente, è possibile scegliere se caricare il file "come TAP" o "come T64", in mancanza si caricherà solo come T64.
Sta comunque di fatto che negli emulatori il solo codice dei loader, da solo, non servirebbe a nulla. Il suo uso avrebbe senso quindi solo con i relativi .L64 (che ovviamente si possono usare a patto di avere le cassette originali ;) ).
In ogni caso, al di là dei loader delle cassette originali che in alcuni casi (es. l'Ocean Loader) possono effettivamente essere proprietari, nel caso delle cassette "generiche", ossia quelle da edicola, come pure nel caso di alcune cassette originali (ad es. quelle che usano il nova load) venivano usati loader PD (oggi diremmo freeware). Per quelli, non credo ci sia nessun problema ad includerli insieme agli emulatori, fermo restante che la logica vorrebbe che siano anch'essi in file separati. Una cartella "loader" in cui includerli sarebbe l'ideale.
Considerando i loader come una sorta di "bios" (intendendo "bios" come quelli per il MAME, es. quelli del NeoGeo che servono a far andare i giochi del NeoGeo, che però, a differenza di questo, non è assolutamente indispensabile per l'uso dei relativi .L64 perché si possono usare come normali .T64 senza bisogno di caricare i loader), penso che questa possa essere la soluzione.
I loader "separati" si troverebbero comunque poi nei soliti luoghi dove si trovano i disk/tape images, senza bisogno di andare a procurare grane (comunque molto improbabili) agli autori di emu, a chi gestisce e programma l'utility di cui stiamo trattando, e ai gestori dello spazio web/ftp che li conterrebbero. In ogni caso, penso che questo qui del come implementare il supporto negli emu, e come gestirlo a livello di copyright, sia l'ultimo dei problemi (ma, allo stesso tempo, non il meno importante: last but not least).
Ovvio che quanto ho detto va considerata una cosa a lungo termine, non si può certo implementarla dall'oggi al domani.
EDIT: Tra le altre cose, si risolverebbe una volta per tutte e in maniera definitiva l'annoso problema dei LOAD ERROR, e non mi sembra una cosa da poco.
RE-EDIT: Forse il formato .L64 esiste già per i file compressi con Lynx (non l'omonima console Atari, ma il compressore per C64). Comunque il nome è veramente l'ultimo dei problemi (e stavolta proprio l'ultimo e anche meno importante). Parlandone ora in chat, stanno venendo fuori .cbm, .dt7 (datassette), .c2n (il nome all'estero del datassette)...
-
Ciao ragazzi
Innanzitutto grazie a tutti dell'interesse e dell'entusiasmo
Che mi dici se dico che questa potrebbe diventare la più grande utility per
TUTTI i formati del C64 e non solo i .tap?
Dico che è possibile,ma che ci vorrà moooooooooooolto tempo per avere un programma
così versatile e potente ;)
rimanendo, per i file in più parti, tra disco<->disco e cassetta<->cassetta,
se no diventa troppo complicato
Hai toccato un punto "dolente" (se non IL punto dolente per eccellenza) di tutto il
panorama emulativo C64.
Comprimere i programmi multi-file in .prg funzionanti è,per le problematiche
che comporta (prima su tutte i tempi e i modi in cui allocare in memoria i vari
pezzi del programma),una sfida che mi affascina maledettamente :mattsid:
Infatti, oltre al prg (che è pratico e maneggevole ma perde molte
informazioni) si potrebbe pensare a una sorta di prg "ibrido" che in pratica
contenga i dati del programma più altre informazioni che consentano di ricreare
il tap "pulito".
C'e' da tenere presente che i .prg sono stati concepiti appositamente per portarsi
dietro solo le informazioni indispensabili per l'esecuzione (l'indirizzo iniziale
e i byte di programma).
A mio avviso,meglio sarebbe trovare un modo per comprimere i dati sui .TAP stessi.
Questo potrebbe essere un ottimo spunto per migliorare il formato .TAP (in effetti
un pò ingombrante);prima di distribuire una utility che tratti un simile formato
andrebbero comunque contattati il VICETEAM (per il supporto sull'emulatore) e Per
Hakan Sundell (per il supporto nonchè l'approvazione,visto che il formato è un suo
brevetto).
Non sarebbe comunque un gran spreco di spazio visto che parliamo di cose che
prendono byte ognuna, anche se i loader sono tanti non sono comunque delle migliaia:
al più si arriverebbe a un mega (ma esagero) per contenerli tutti
Anche qui,la questione è piuttosto spinosa,e legata alla flessibilità dei loader
stessi;ciascuno di essi è un vero e proprio protocollo di comunicazione tarato
ad-hoc usato dal computer per caricare un certo programma,e i "trucchi" usati
per arrivare al risultato finale possono essere i più svariati.
Inutile dire che i sorgenti dovrebbero essere aperti a chiunque
Questo è fuori di dubbio,questo software sarà assolutamente OPEN-SOURCE.
Per quanto riguarda gli altri formati,la compatibilità ecc.,sono pienamente d'accordo
con koseidon72 e eregil;mettere troppa carne al fuoco in una sola volta può non portare
a nulla,per cui secondo me è meglio prendere una cosa per volta. ;)
In sostanza,quel che di interessante si può pensare di implementare in tempi (relativamente)
brevi è un manager con queste caratteristiche (il ? indica una caratteristica che potrebbe
richiedere un pò più di tempo rispetto alle altre):
- scansione TAP
- verifica/riparazione kernel headerchunk/datachunk ?e blocchi dati registrati con routine
custom
- manipolazione TAP (copia/spostamento/cancellazione/modifica blocchi standard)
- ?visualizzazione/manipolazione blocchi dati registrati con routine custom
- ?supporto per un formato TAP compresso (previa richiesta agli autori dei due principali
emulatori)
Una volta soffisfatti questi requisiti,si vedrà.
Ovviamente,chiunque si senta libero di aggiungere le proprie osservazioni o i propri consigli
in merito.
Ciao!
P.S.:Carmine,credo che prima di sabato/domenica i tuoi sorgenti non li sfiorerò nemmeno :)
-
rimanendo, per i file in più parti, tra disco<->disco e cassetta<->cassetta,
se no diventa troppo complicato
Hai toccato un punto "dolente" (se non IL punto dolente per eccellenza) di tutto il panorama emulativo C64.
Comprimere i programmi multi-file in .prg funzionanti è,per le problematiche che comporta (prima su tutte i tempi e i modi in cui allocare in memoria i vari pezzi del programma),una sfida che mi affascina maledettamente :mattsid:
Infatti io stesso sono convinto che è impossibile, all'atto pratico, prevedere un passaggio indolore per tutti i giochi. Oltre che molto probabilmente inutile, perché per quanto riguarda il T->D si fa prima a cercare la versione disco, e per quanto riguarda il D->T... se non è stato già fatto, è probabile che non si possa fare per questioni di comodità -indubbia- del formato disco rispetto alla cassetta (penso ai giochi tipo Maniac Mansion o Zak McKracken, sai che casino se fossero stati su cassetta). In fondo è il motivo per cui noi nel 2006 usiamo CD e DVD, e le memorie a nastro sono relegate a backup e basta (e quello, essendo in gran parte sequenziale, lo fanno benissimo).
Infatti, oltre al prg (che è pratico e maneggevole ma perde molte
informazioni) si potrebbe pensare a una sorta di prg "ibrido" che in pratica
contenga i dati del programma più altre informazioni che consentano di ricreare
il tap "pulito".
C'e' da tenere presente che i .prg sono stati concepiti appositamente per portarsi
dietro solo le informazioni indispensabili per l'esecuzione (l'indirizzo iniziale
e i byte di programma).
Infatti più che un prg pensavo a una sorta di "t64 espanso". Il t64, come certamente sai, altri non è se non un "contenitore" di prg (molto più blando di quanto non sia un d64, che è invece molto più complesso). "Espandere" un t64, senza arrivare alle dimensioni del TAP, ma inserendovi informazioni per "simularne uno" in tempo reale, non è secondo me molto difficile. Ovvio che ci sarebbe il problema di implementarlo e di imporlo come standard. Si potrebbe partire dalle cassette da edicola (ad esempio le Pubblirome che usano praticamente tutte il turbo202) e vedere come va. Il problema è che le cassette da edicola, a parte noi italiani (neanche tutti, vero Rob? ^^) non se le fila nessuno, e questo non ci permetterebbe di imporre il nuovo formato come uno standard. Però come "sperimentazione" può essere un buon punto di partenza.
A mio avviso,meglio sarebbe trovare un modo per comprimere i dati sui .TAP stessi.
Bhe, col 7z si risparmia un po', ma siamo comunque decisamente molto sopra il nuovo formato.
In effetti, oltre all'architettura "a plugin" che effettivamente ruberebbe spazio, si potrebbe fare in modo che il formato preveda gli eventuali loader (uno per tipo, senza quindi ripetizioni) in testa al formato stesso con eventuali info semplici tipo byte di inizio e fine. L'unico problema sarebbe, ovviamente, per l'utility gestire questi loader e "spostarli" dai programmi di quel tap fino ad una specie di "directory", un "blocco zero", o un "lead-in" per dirla coi termini di oggi, che starebbe appunto in testa al file.
Per intenderci, una cassetta tipo Game2000 risulterebbe così:
- elenco dei giochi, dei rispettivi turbo associati (in questo caso uno solo)
- informazioni sull'unico turbo presente (turbo202)
- codice binario del turbo202
- gioco n.1
- gioco n.2
- gioco n.3
- gioco n.4
- gioco n.5
- gioco n.6
- gioco n.7
- gioco n.8
Una cassetta homemade sarebbe così:
- elenco dei giochi, dei rispettivi turbo associati (in questo caso tre)
- informazioni sul turbo1 (turbo202)
- codice binario del turbo1 (turbo202)
- informazioni sul turbo2 (connection)
- codice binario del turbo2 (connection)
- informazioni sul turbo3 (algasoft)
- codice binario del turbo3 (algasoft)
- gioco n.1 (turbo202)
- gioco n.2 (connection)
- gioco n.3 (turbo202)
- gioco n.4 (turbo202)
- gioco n.5 (algasoft)
- gioco n.6 (algasoft)
- gioco n.7 (connection)
- gioco n.8 (algasoft)
In alternativa, si potrebbe mettere tutte le info e i codici aggiuntivi "in coda" al file, per mantenere anche un'eventuale compatibilità con il "vecchio" T64.
Questo potrebbe essere un ottimo spunto per migliorare il formato .TAP (in effetti un pò ingombrante);prima di distribuire una utility che tratti un simile formato andrebbero comunque contattati il VICETEAM (per il supporto sull'emulatore) e Per Hakan Sundell (per il supporto nonchè l'approvazione,visto che il formato è un suo brevetto).
Mai negato, prima però andrebbero fatte delle prove "tra di noi", magari avvertendoli solo delle nostre intenzioni ;) (ma non prima di capire che la cosa sia effettivamente fattibile, e questo ahimé non so dirlo, io faccio solo mera teoria)
Anche qui,la questione è piuttosto spinosa,e legata alla flessibilità dei loader stessi;ciascuno di essi è un vero e proprio protocollo di comunicazione tarato ad-hoc usato dal computer per caricare un certo programma,e i "trucchi" usati per arrivare al risultato finale possono essere i più svariati.
Giusto. Per ora forse è meglio rimanere sui loader "standard".
Magari cominciando proprio da quello originale :c64:
Confesso di non aver usato WAV-PRG e simili se non in poche occasioni (come sai io dumpavo con MTAP quindi non me ne curavo), quindi non so come funzioni.
Inutile dire che i sorgenti dovrebbero essere aperti a chiunque
Questo è fuori di dubbio,questo software sarà assolutamente OPEN-SOURCE.
:mavieni:
Per quanto riguarda gli altri formati,la compatibilità ecc.,sono pienamente d'accordo con koseidon72 e eregil;mettere troppa carne al fuoco in una sola volta può non portare a nulla,per cui secondo me è meglio prendere una cosa per volta. ;)
Ovvio che io intendessi qualcosa a lung(hissim)o termine. Però può essere interessante iniziare a fare quello che ci siamo (ehm vi siete ^^) preposti tenendo presente un obiettivo ancora più ampio (e, consentitemelo, più "alto").
-
Massi, dopo la delucidazione che ti avevo chiesto su quale fosse la tua idea di "nuovo formato" (per la quale ti ringrazio) ho iniziato a rifletterci su e in effetti inizio ad avere il sentore che, ammesso e non concesso che la cosa sia realizzabile (a giudicare dovrebbe essere qualcuno abbastanza esperto tanto di tecniche di caricamento da cassetta su c64 quanto di programmazione di emulatori), sarebbe di scarsa utilità pratica. La ragione è che o fai vera emulazione o non la fai, c'è poco da trovare vie di mezzo.
Se fai vera emulazione, il loader deve girare nel c64 emulato. Non si tratta di riversare "dall'esterno" nella RAM emulata il programma così come sarebbe alla fine del caricamento; è necessario emulare tutta la trafila della conversione degli impulsi in byte, che avviene nel c64: perciò hai bisogno delle informazioni presenti nel .tap, così come sono. Nell'ipotesi di avere un file nel nuovo formato, una volta caricato il loader nel C64 (= non devi perdere nessuna informazione sul loader), questo loader deve prendere in input gli impulsi e non i byte, il che significa che l'intera operazione non sarebbe dissimile dal riconvertire il file in .tap esattamente come era all'origine (= non devi perdere nessuna informazione sugli impulsi). La conclusione è che il nuovo formato deve essere lossless nei confronti del .tap.
Se il nuovo formato è lossless nei confronti del .tap, a conti fatti non è dissimile da un .tap compresso con zip o 7-zip, con la sola eventualità che un algoritmo di compressione "ad hoc" possa essere più efficiente in termini di spazio (cosa tutta da dimostrare). Ergo: non è necessario, e non c'è ragione di implementare nuovo codice negli emulatori.
È anche abbastanza cervellotico, se ci pensi, avere un formato che riporta i byte, e un emulatore che riconverte i byte in impulsi (usando algoritmi diversi a seconda dei loader!), per passare i suddetti impulsi alla macchina emulata che, facendo girare il loader, li riconverte in byte...
Se invece non interessa fare vera emulazione, ogni informazione sul loader diventa superflua, così come è superflua (e infatti non riportata) in formati esistenti come il .t64...
Certo, l'intento è quello di poter stabilire "sul momento" se fare o non fare vera emulazione, ma considerato che se non fai vera emulazione ci sono delle limitazioni non superabili, non tutti i file dell'ipotetico nuovo formato potrebbero essere letti senza vera emulazione, quindi almeno in una parte dei casi possibili non ci sarebbe alcun vantaggio evidente ad avere il file del nuovo formato rispetto al .tap.
E per quanto riguarda la parte rimanente... be', verosimilmente il vantaggio non sarebbe di entità tale da giustificare tutto il lavoro necessario per sviluppare i nuovi tool.
Con mille scuse... meglio tornare a concentrarsi sul tap manager. :)
-
In passato qualcuno aveva proposto di estendere il formato TZX (diffuso per gli emulatori Spectrum, e praticamente identico al ".t64 espanso" di cui parla Massi) alle cassette C64. Il progetto è morto sul nascere perché gli sviluppatori di emulatori si sono dimostrati non disposti a supportarlo. Il problema principale è che è il formato TZX deve essere consapevole di tutti i caricatori supportati. Data l'enorme quantità di formati diversi esistenti sul C64, la cosa è impraticabile.
Da qualche tempo mi gira per la testa un'idea di "TAP compresso", generico ma che sprechi meno spazio del TAP. Qualcosa che, per ogni programma salvato, contenga
-4 byte: numero di impulsi in questa parte di cassetta
-1 byte: numero di possibili lunghezze (2 quasi sempre, 3 nel caso del kernal loader e pochi altri)
-4 byte: lunghezza 1 (in microsecondi)
-4 byte: lunghezza 2 (in microsecondi)
-4 byte: lunghezza 3 (in microsecondi) [eventuale]
-impulsi, 1 bit (non 1 byte come nel TAP. 2 bit nel caso di 3 lunghezze) per impulso.
Per le pause
-4 byte:numero di decimi di secondo di durata della pausa
-1 byte: 0
Il problema è generare un tale formato. Bisogna riconoscere quali parti sono in "kernal loader", e quindi richiedono 3 lunghezze di impulso diverse, e quali sono in formati diversi, e quali lunghezze di impulso richiede ciascuna di esse. E, soprattutto, una volta che un file in questo formato è fatto, estendere VICE in modo da supportarlo
-
Miha Peternel, l'inventore del .t64 e del vecchio emulatore C64S (da tempo non mantenuto), aveva previsto un'estensione del .t64 che salvasse gli "header chunk". La sua invenzione si è dimostrata inutile per i motivi spiegati da Eregil: il formato .t64 non è abbastanza generico da salvare le informazioni sui loader speciali.
-
Da qualche tempo mi gira per la testa un'idea di "TAP compresso", generico ma che sprechi meno spazio del TAP. Qualcosa che, per ogni programma salvato, contenga
-4 byte: numero di impulsi in questa parte di cassetta
-1 byte: numero di possibili lunghezze (2 quasi sempre, 3 nel caso del kernal loader e pochi altri)
-4 byte: lunghezza 1 (in microsecondi)
-4 byte: lunghezza 2 (in microsecondi)
-4 byte: lunghezza 3 (in microsecondi) [eventuale]
-impulsi, 1 bit (non 1 byte come nel TAP. 2 bit nel caso di 3 lunghezze) per impulso.
Per le pause
-4 byte:numero di decimi di secondo di durata della pausa
-1 byte: 0
Pensavo che un formato TAP supercompresso potrebbe consentire agli emulatori di dispositivi portatili (che per ovvi motivi non dispongono di grosse risorse di calcolo) di emulare finalmente i caricamenti dei nastri veri,e quindi supportare anche i programmi multi-file.Avrei in mente un possibile algoritmo di compressione,ma finchè il TAP manager non è completo,niet. :D
Mai negato, prima però andrebbero fatte delle prove "tra di noi", magari avvertendoli solo delle nostre intenzioni (ma non prima di capire che la cosa sia effettivamente fattibile, e questo ahimé non so dirlo, io faccio solo mera teoria)
Quello non è un problema,si possono scrivere un encoder e un decoder su misura per testare il formato anche senza emulatore.Difficile sarà più che altro convincere chi scrive emulatori per PDA e cellulari a inserire il supporto per un simile formato.
:)
Tornando al manager,ultime news
@tsm_carmine:
ho trovato un'oretta libera per studiare il sorgente di STAP.Fatti sentire sul forum, ti dovrei parlare.
@fab:
se hai miglioramenti da suggerire all'algoritmo di scansione,fammi sapere ;)
@tutti:
se avete commenti o volete dire qualcosa,non esitate.Nessuna considerazione è sciocca o inutile,tutto può servire. :)
-
Mi faccio sentire? Mi faccio sentire!
Orsù, che cosa vuoi chiedermi?
--
TSM
-
le cassette da edicola che usano loader standard (tipo le Pubblirome che usano praticamente tutte il Turbo202)
Domanda un po' off-topic. Le cassette Pubblirome usano quello che, rozzamente, avevo definito "caricamento chiocciola", perché fa apparire una @ in mezzo allo schermo. Mi pare che Overkiller mi avesse deto che il nome corretto è Connection. Tu però lo chiami Turbo 202.
In Final TAP, il Turbo Tape normale è definito Turbo 250. E in un vecchio articolo di Ready64, veniva definito Turbo220 il caricatore usato da molte cassette da edicola (Poke, Peek, Full games...).
La domanda è: da dove originano questi nomi? Ed è possibile sapere chi ha inventato questi formati? (immagino che la risposta alla seconda sia quasi impossibile da trovare...)
-
La domanda è: da dove originano questi nomi? Ed è possibile sapere chi ha inventato questi formati?
Se vuoi te ne dico altri 2: "Biturbo by SC 85" e "Galadriel"
Sono tutti hack dello stesso turbotape, ne ho un po' in ita, un po' in inglese, e il codice e' praticamente lo stesso (NOP piu' NOP meno).
-
le cassette da edicola che usano loader standard (tipo le Pubblirome che usano praticamente tutte il Turbo202)
Domanda un po' off-topic. Le cassette Pubblirome usano quello che, rozzamente, avevo definito "caricamento chiocciola", perché fa apparire una @ in mezzo allo schermo. Mi pare che Overkiller mi avesse deto che il nome corretto è Connection. Tu però lo chiami Turbo 202.
Abbiamo ragione tutti e tre perché nessuno s'è spiegato appieno con gli altri.
Le Pubblirome usano il caricamento "con le righe colorate di vari colori" (abbastanza strette rispetto ad altri loader).
Quel tipo di loader si chiama Turbo202.
Nella versione standard, e cioè quella usata dalle Pubblirome, è usato l'autorun e la chiocciola a fine caricamento in un punto casuale dello schermo.
Altre versioni possono includere caratteristiche come il doppio READY. oppure nessuna chiocciola oppure nessun autorun, oppure l'autorun fatto con RUN (intero) piuttosto che con r + shif-U, oppure con r + shift-U + duepunti.
Sono tutte varianti leggere del Turbo202.
Varianti molto meno standard e decisamente più macchinose del Turbo202 sono quelle usate dal Disk to Tape+, quelle del loader Algasoft e simili, l'unica cosa che hanno in comune è il tipo di righe "multicolor" (limitato in questi casi alla cornice quando compare la schermata di caricamento) e presumo anche il tipo di frequenze e impulsi usati.
Poi esiste il Connection, che è un'altra cosa. Il Connection (anche chiamato "Turbo Connection", è la stessa cosa) NON presenta assolutamente le "righe colorate", ma presenta SEMPRE la chiocciola in un punto random. E' questo che è (giustamente) chiamato "Caricamento chiocciola", perché così veniva chiamato anche in un'utility dell'epoca prodotta dalla Cooperativa A.P.E. di Gorizia (la stessa dei corsi didattici "Progredisco" pubblicizzati su C.C.C.).
Questo loader era usato spesso nelle cassette della Logica2000, in particolare sono sicuro venisse usato in Computer Set. Era usato anche in "Software Club" della Systems e in tutte le cassette Systems che mi sono capitate sottomano.
Di entrambi i turbo esistono poi versioni modificate e adattate per il C16/+4, ne parlerò un'altra volta, ora devo scappà ;)
-
Mi faccio sentire? Mi faccio sentire!
Orsù, che cosa vuoi chiedermi?
--
TSM
Avresti la disponibilità per aiutarmi nella stesura del codice per la scansione dei TAP?Attualmente è più o meno al 50% (ma nelle ultime 2 settimane ho potuto avanzare di pochissimo). :)
-
Avresti la disponibilità per aiutarmi nella stesura del codice per la scansione dei TAP?Attualmente è più o meno al 50% (ma nelle ultime 2 settimane ho potuto avanzare di pochissimo). :)
Eccomi, mi si è guastato il monitor e ne sto usando uno di fortuna avuto da un amico. Puoi mandarmi una mail con il codice? Che "ambiente di sviluppo" stai usando? Vorrei prepararmi tutto l'ambiente, poi magari possiamo lavorare su parti diverse dell'applicazione e spedirci i sorgenti aggiornati di volta in volta. Aspetto una tua mail. :sonno:
-
Guarda che combinazione,io invece ho avuto problemi col modem ADSL di Telecom e ora sto usando il 56k di riserva...
Per ora sono sommerso dagli impegni,appena posso ti mando i sorgenti;io sto sviluppando con MinGW.
Ciao
-
Per ora sono sommerso dagli impegni,appena posso ti mando i sorgenti;io sto sviluppando con MinGW.
Mail per te.
--
TSM
-
Allora, ho pubblicato ciò che avevo fatto. Lo trovate su http://sourceforge.net/projects/initialtap (http://sourceforge.net/projects/initialtap) .
Che cosa fa? Poco. Riconosce quali programmi ci sono su un TAP, dove un programma è qualsiasi sequenza di impulsi non troppo lunghi, intervallato da pause, che sono sequenze di impulsi lunghi. Si possono aggiungere pause tra programmi, cancellare pause e programmi, trascinare programmi da un punto all'altro del TAP, e, se sono aperte due finestre, trascinare un programma da un TAP a un altro.
Non fa nessun tipo di riconoscimento dei programmi.
Il problema è che il 4 gennaio avevo promesso ad Alberto che gli avrei mandato le sorgenti, e ho mantenuto la promessa oltre un mese dopo. Ho poco tempo per programmare per hobby, e le cose non sembrano destinate a migliorare: la mia vita ha avuto una svolta importante, la seconda in tre mesi, visto che la mia ragazza è venuta a vivere con me. Insomma, forse dovrei avere il coraggio di dire basta e rendermi conto che non ce la farò a mantenerlo. E invece, vi invito a suggerire miglioramenti, critiche ecc.
-
Hai fatto un ottimo lavoro e anzi in bocca al lupo per queste novita' tue personali.
Ora scarico la beta!
:mavieni:
-
Allora.. l'ho provata ma ha subito un fastidioso bug sul display della finestra.
Non si allarga e all'avvio risulta piccolissima, senza la possibilita' di modificarne l'altezza e larghezza. Direi che come dimensione potrebbe essere 2 cm x 1cm su uno schermo 800x600.
Anche provando ad aprire configurazione, appare una finestra nulla con la sola barra di intestazione.
Il problema sembra dipendere dal file:
qt-mt3.dll
Ho provato altre 2 versioni della libreria con risultati diversi ma non buoni.
Il mio sistema operativo e' Windows Me
Posso, se ti serve, spedirti un screen grab via email.
Ti lascio la mia cosi' se vuoi mi contatti.
koseidon72@hotmail.com
Ciao
-
Ciao
Adesso sono bloccato anch'io (almeno fino a sabato),quindi non ti preoccupare se le cose vanno lunghe.
Il problema è che il 4 gennaio avevo promesso ad Alberto che gli avrei mandato le sorgenti, e ho mantenuto la promessa oltre un mese dopo. Ho poco tempo per programmare per hobby, e le cose non sembrano destinate a migliorare: la mia vita ha avuto una svolta importante, la seconda in tre mesi, visto che la mia ragazza è venuta a vivere con me. Insomma, forse dovrei avere il coraggio di dire basta e rendermi conto che non ce la farò a mantenerlo. E invece, vi invito a suggerire miglioramenti, critiche ecc.
Tengo a precisare che non sei costretto a stare nel team di sviluppo se non te la senti,e poi qui ognuno è libero di dare quello che vuole e soprattutto,che può in quel momento:non ci sono vincoli di nessun tipo,insomma,visto che abbiamo tutti più o meno i nostri impegni e programmiamo "a tempo perso". :)
Ad ogni modo,appena ho tempo e modo (adesso sto usando un 56k ma spero di ripristinare l'ADSL al più presto) scarico il programma (p.s.:è comprensivo di sorgenti?)
Quanto a te Carmine,ho ricevuto la tua mail:pazienta almeno un paio di giorni e ti mando tutto il popò di roba che ti avevo detto.
-
Ad ogni modo,appena ho tempo e modo (adesso sto usando un 56k ma spero di ripristinare l'ADSL al più presto) scarico il programma (p.s.:è comprensivo di sorgenti?)
Per ora solo se usi CVS. Stasera spero di riuscire a metterle in un file scaricabile a parte.
Per compilarlo serve Qt versione 3 (per Windows si puo' scaricare su http://qtwin.sf.net (http://qtwin.sf.net))
-
Ho messo anche il file con le sorgenti. (necessario l'ambiente di sviluppo di Qt)
-
Ho messo anche il file con le sorgenti. (necessario l'ambiente di sviluppo di Qt)
Ok,li scarico e me li guardo.
In bocca al lupo anche da parte mia per la tua carriera,ti auguro ogni bene. :P
A presto!
-
Ciao ragazzi
Solo per dire che il progetto non è morto,ma è semplicemente in un punto di stallo.
Nel week-end tornerò a lavorarci.
P.S.:Carmine ti ho mandato una mail,appena puoi dammi le tue coordinate. :)
-
anche se non ho postato e lo faccio solo ora ho sempre seguito la discussione e continuero' a farlo.
Comunque volevo augurarvi buona fortuna e' un bel progetto, utilissimo , perfino per le cassette da edicola che contengono molti giochi.
-
Non so se puo' servire al progetto ma questo Disk2tape mi e' familiare
http://noname.c64.org/csdb/release/?id=28272 (http://noname.c64.org/csdb/release/?id=28272)
Sembra generare un loader pressoche' identico a quello usato in alcune Algasoft.
Qualcuno puo' confermare?
-
Non so se puo' servire al progetto ma questo Disk2tape mi e' familiare
http://noname.c64.org/csdb/release/?id=28272 (http://noname.c64.org/csdb/release/?id=28272)
Sembra generare un loader pressoche' identico a quello usato in alcune Algasoft.
Qualcuno puo' confermare?
Io ne avevo (ne ho) uno molto simile, nel senso che la scritta è identica e cambiano solo i colori di quella schermata; si chiama "Disk to Tape+" e proveniva nientepopodimeno che dallo storico Computer House di viale Tripoli a Rimini (:D).
Se è quello, il loader non è quello Algasoft (quello della bandiera), ma in alcune Algasoft (specie nei primi numeri) è comunque presente per alcuni giochi. La caratteristica di questo loader è:
- viene regolarmente riconosciuto dalle vecchie versioni del VICE (quindi non ha i blocchi in meno)
- la schermata di caricamento si presenta con una scritta così:
(schermata con fondo bianco, righe colorate sulla cornice)
NOME EDITABILE: NOME DEL FILE
READY.
LOADLa prima riga è normalmente rossa, mentre READY. e LOAD sono o ciano o verde (la memoria fa brutti scherzi).
Al posto di "NOME EDITABILE" per le Algasoft compariva la scritta "ALGASOFT NAPOLI", i ":" non erano sempre ":" ma a volte erano "!" o uno spazio. Il nome del file era quello che veniva dato nella schermata dello screenshot, ossia il nome del file come si caricava su disco.
Ricordo che Gerry (*) del Computer House di Rimini mi fece una cassetta con sopra Bubble Bobble e compariva
COMPUTER HOUSE: BUBBLE B*
READY.
LOADchiaro indice che questo disk to tape si limitava a copiare quello che si era digitato (quindi eventualmente anche il semplice asterisco se il gioco è il primo file su disco) e lo usava sia per il FOUND sia per la schermata di caricamento.
C'erano anche, con questo loader, giochi a più caricamenti e in questi casi più sotto del LOAD compariva (alla fine del primo) un READY., sotto ancora un RUN e il caricamento proseguiva subito con le righe colorate (insomma partiva direttamente in turbo) senza dover scomodare il loader standard con il classico FOUND.
Io stesso ho usato molte volte questo software per trasferire da floppy a cassetta diversi giochi, con ottimi risultati, anche perché spesso il programma rimaneva in memoria e permetteva talvolta di copiare anche i livelli successivi di un gioco multiload, a patto di giocarseli.
In pratica, la routine di load veniva modificata in modo che a ogni fine caricamento da floppy, su cassetta venisse scritto quanto si era appena letto.
Tutto questo a patto che il floppy non avesse protezioni o caricamenti in turbodisk o comunque "strani", e che la routine non venisse sovrascritta (non so dove risiedesse in memoria ma da qualche parte doveva pur stare). Nel successivo caricamento da cassetta non si riscontravano problemi. L'unica cosa è che gestiva solo i file caricabili con LOAD, quindi solo i PRG; niente SEQ o simili. Ad esempio io copiai Music Shop su cassetta ma poi era comunque inutilizzabile se si disponeva solo del registratore (a meno di non creare musica "al volo" senza salvarla), visto che andava comunque a caricare e salvare solo file SEQ su disco.
C'era un'altra comodità di questo loader: che con MEGADISK 4.2 si poteva fare benissimo l'operazione inversa (da cassetta a disco), che funzionava perfettamente.
La differenza principale tra questo e il loader "della bandiera", oltre al fatto che ha un numero di byte standard mentre quello invece no, è che quello lì carica due parti: una solo l'area colore con i colori della bandiera e la seconda che comincia dall'area video (da 1024 in poi) per poi prendersi tutto il programma. Questo almeno io ho sempre creduto, anche se non ho mai capito perché, se così fosse, la cella n.2023 non veniva riempita (se fosse "POKEata" non dovrebbe far scattare lo scrolling verso l'alto...).
PS Sia Disk to tape+ sia Megadisk 4.2 sono presenti in "Copy 100%" che è il nome dei floppy B02 (lati A e B ) e B03 (lato A), già pubblicati anni fa sul newsgroup it.binari.emulatori e ora di prossimo ri-rilascio pubblico insieme agli altri miei dump ;)
PPS (EDIT) Ora ricordo che Disk to tape+ contiene tre diversi "creatori di loader" per cassetta. Ma per quel che ricordo nessuno dei tre è analogo a quello della bandiera. Uno ha delle righe molto larghe (circa 10 volte quelle normali) senza schermata di caricamento (quindi le righe prendono tutto il quadro), l'altro è quello che ho descritto, l'altro proprio non me lo ricordo e ho anche dubbi che mi abbia mai funzionato...
(*) Ma Gerry ha ancora il ristorante sulle colline? Se ne parlava periodicamente su ICE/ICSE e qualcuno (Pucci mi pare) se ne uscì che per un periodo vendeva caldarroste vicino al porto canale... Ricordo che nella posta di Zzap! dissero che la Finanza gli aveva sequestrato tutto... (anche se non dissero il nome dei due negozi, dissero che erano di Rimini). Tra l'altro, uno dei floppy che vidi all'epoca (che non comprai perché non avevo ancora il drive) conteneva LEGENDARY WINGS... che non sono mai riuscito a capire se sia mai uscito per C64, se era un demo, o che altro... rimarrà uno dei tanti misteri irrisolti, come una cassetta per C16 comprata in edicola che doveva contenere tra gli altri il gioco dei Puffi per C16 e che invece aveva registrato sopra della musica... Oppure la cassetta di PACLAND per C16 che mio padre era sicurissimo di aver visto alla stazione Termini di Roma e che poi non abbiamo mai più ritrovato per comprarla... Sono quelle classiche leggende metropolitane insomma... Scusate se ho divagato, ma a volte mi faccio trasportare ;) Scusate ancora ^^
-
volevo augurarvi buona fortuna e' un bel progetto, utilissimo , perfino per le cassette da edicola che contengono molti giochi.
Grazie bubusan,il sostegno morale è sempre gradito.
Ultime news per quanto riguarda il progress del TM
Il motore di scansione adesso opera secondo l'algoritmo illustrato èd è più o meno all'80%,restano da velocizzare un pò il codice e da definire alcuni dettagli,credo comunque che non sarà completo prima della prossima settimana.
Tempo residuo stimato per il rilascio del manager: considerando il fatto che ci metto le mani tra le 9.30 e le 10 di sera,facendo una media tra l'ipotesi migliore e quella peggiore non credo prima di aprile-maggio (magari verrà anche rilasciata una versione beta per i members di codesto forume).
Ciao
-
Qualcuno puo' confermare?
Lo shcema di caricamento del loader generato è identico a quello presente in molti giochi delle Algasoft (stessa endianess,stesso byte pilota,stessa soglia di commutazione) eccezion fatta per il secondo byte di sincronizzazione (66 e non 77 come sulle Algasoft).
Se non mi sbaglio questo stesso loader è anche documentato sul sito di ice00.
P.S.:tra l'altro ho scoperto qlc tempo fa che il famigerato loader delle Algasoft passa sotto il nome (non so se originale) di "Easy-Tape System".
-
Alberto, ci sono novita' per una versione funzionante su sistemi windows 98/me del tuo programma?
Grazie
-
P.S.:tra l'altro ho scoperto qlc tempo fa che il famigerato loader delle Algasoft passa sotto il nome (non so se originale) di "Easy-Tape System".
L'Easy-Tape è presente in alcune AlgaSoft in una versione credo non modificata, la schermata di caricamento è l'"ASCII-ART" (chiamiamola così) di un datassette, solo che è tutto bianco su fondo blu.
Quella della bandiera è probabile che derivi da quella, ma è stata modificata per caricare prima i colori della schermata e poi la schermata stessa (che precede il programma contiguo alla schermata, in pratica viene caricato da 1024 alla fine del programma). Rimane il dubbio sull'ultima cella video (la 2023).
Qualche volta ho visto anche le FSN usare un loader uguale a quello AlgaSoft, la differenza è che invece della bandiera veniva disegnata la cella di un carcere.
Infine le AlGaSoft come ho già detto hanno usato un loader comune a quello usato dai tizi della Camera Oscura, perché in una cassetta certamente preparata da loro compariva la stessa bandiera, ma al posto di "ALGASOFT" era scritto "DARK ROOM".
-
Alberto, ci sono novita' per una versione funzionante su sistemi windows 98/me del tuo programma?
Sto sviluppando su Win98:come già detto sopra,da solo non credo di riuscire a implementare il tutto prima di 2-3 mesi.Sono sommerso,tra le altre cose,dagli impegni di studio (sono in odore di laurea,speriamo bene... :mattsid: ) e il programma in sè non è semplicissimo da scrivere per cui se qlc mi vuole/può aiutare ben venga,altrimenti bisognerà attendere un pò prima di vedere anche solo una versione di prova.
Ciao
-
In bocca al lupo per la laurea.. se sapevo programmare ti avrei aiutato al 100%.
Ok attendero' i tuoi risultati piu' avanti
Ciao
-
In bocca al lupo per la laurea..
Crepi! :lol:
se sapevo programmare ti avrei aiutato al 100%.
Non ne dubito :)
Il motore di scansione è pressochè completato.
Adesso è in grado di fare tutto quello che prevede l'algoritmo postato:in caso di blocchi danneggiati (header o dati) recuperarne una copia su richiesta dell'utente, e abortire la sequenza (sempre su richiesta dell'utente) se la sequenza standard non viene rispettata.
La prossima mossa sarà quella di disassemblare il contenuto del blocco di header e dei dati,in modo da dare la possibilità all'utente di visualizzarne il codice macchina e,all'occorrenza,modificarlo.
Ormai lo sapete e non mi dilungo più sulla questione:chiunque voglia collaborare... (non è necessario stendere codice,le idee e i suggerimenti li possono dare tutti ;) )
Alla prossima!
-
Aggiunto il supporto per i file di dati.
-
Rinnovo i complimenti..
E' poco ma questo e' il minimo di supporto che posso dare al tuo lavoro con questo programma.
Ps: spero di poterlo provare a breve con windows Me :)
-
spero di poterlo provare a breve
:headshake: ;)
Tra breve caricherò sul mio spazio web i sorgenti del progetto (ovviamente solo la parte del TAP manager perchè il resto è proprietà intellettuale di fab),in modo da rendere il progetto open-source a tutti gli effetti,anche in fase di sviluppo.
Ciao
-
La gestione dei file di dati si sta rivelando più complessa del previsto.
Il fatto è che questo genere di file (che come sappiamo non vengono caricati
usando la LOAD,bensì con una OPEN) devono risiedere interamente nel buffer
di cassetta (locazioni $33c-$3fb);ergo,i file dati più lunghi di 192 bytes
risultano "spezzati" in chunk (ciascuno lungo 192 bytes) e caricati in più
colpi.
Ora,nel caso si trovi a che fare con un file di dati,per quanto detto un pò
di post addietro il manager potrebbe gestire la situazione in questo modo
1.Se non ci sono errori nei dati del chunk passa al chunk
successivo,altrimenti
- se hai l'ordine di recuperarne la copia,vai in 2
- altrimenti,passa al chunk successivo
2.Non appena ricevi un impulso lungo,vai in 3
3.Se hai trovato una copia del chunk passa al chunk successivo,
altrimenti
- se hai l'ordine di abortire la ricerca,termina
- altrimenti,torna in 3
Questo processo andrebbe iterato fino a che non si incontra l'ultimo
chunk (che contiene un byte $0) o la fine del file (nel qual caso
l'entry viene scartata perchè incompleta).
Le difficoltà maggiori stanno nell'analisi e gestione di ogni
singolo chunk,in quanto per una successiva visualizzazione occorre
compattare tutti i chunk (nel caso siano più d'uno) e distinguere per
ciascuno di essi l'originale dalla copia (nel caso in cui l'utente
abbia spuntato l'opzione corrispondente).
Inoltre,dato che il codice per la gestione dei suddetti file sembra
destinato a "esplodere",a questo punto non so davvero se sia meglio
tenerlo in un'unica funzione (che si occupa di recuperare i chunk di
dati sia per i file programma che per i file di dati) oppure definirne
un'altra prevista appositamente per questo scopo.Boohh... :overkiller:
Ogni consiglio in proposito è ben accetto
Saluti
-
Ho uppato i sorgenti (intestazione e implementazione) del motore di scansione.
La pagina ufficiale del project è questa (http://geocities.com/tuttowindows98/projects/c64/tapmanager.htm).
Abbiate pietà per la veste grafica (col tempo migliorerà,siamo all'inizio).
Ciaooooo
-
Manca un tot di roba per poterlo compilare. ;)
-
Per ora ho uppato solamente i sorgenti del motore di scansione,più che altro per rendere l'idea di come funzioni in pratica.Il resto è la parte della GUI (ancora incompleta) e i sorgenti del WAV-PRG 3.0 standard.
Appena finisco il motore di scansione (completo del disassemblatore) pubblico i sorgenti da aggiungere al WAV-PRG necessari a poterlo ricompilare correttamente.
Ciao
-
Forse può servire sapere che Subchrist ha reso pubblico il codice sorgente di Final TAP (http://www.coder.myby.co.uk). E' la versione solo testo, ma gli analizzatori di loader ci sono tutti.
-
Ok,le ultime sull'avanzamento del progetto. :)
Motore di scansione leggermente modificato (come detto sul sito,è stato necessario rivedere anche l'algoritmo di scansione per un full support dei file dati,aka SEQ).
E' già possibile spostare voci da un TAP a un altro (per ora niente d&d,solo scorciatoie da tastiera) MA le routine per il trasferimento non sono ancora complete,per cui ci dovr(em)ò lavorare ancora un pò.
Ultima cosa:adesso si possono solo visualizzare le info su ogni singolo blocco di ciascun file,questo per avere un check-up completo del TAP (e per altre ragioni che spiegherò nel readme a corredo del programma completo :D ).
Tra breve i sources on-line.
SYS 64738
-
ci dovr(em)ò lavorare ancora un pò.
Forza ragazzi! :metal:
:ciauz:
-
...A 3 settimane dall'ultimo resoconto.
Il motore di scansione è completo (ormai da circa un mese): nel poco tempo a disposizione ultimamente ho lavorato sulla parte di manipolazione dei TAP,ormai a buon punto.Di seguito riporto le caratteristiche implementate e il loro stato di avanzamento:
- scansione TAP (100%)
- copiatura file da un TAP a un altro (100%)
- spostamento file da un TAP a un altro (100%)
- rimozione file (90%)
- spostamento file sul singolo TAP (50%)
- copia file sul singolo TAP (20%)
- drag & drop/supporto mouse (20%)
- visualizzazione dei blocchi di ogni singolo file (50%)
A questo punto,l'obiettivo è terminare di implementare la quinta e la sesta feature
e poi,ripulire il codice e (se tutto va bene) rilasciare una versione di prova,ancora incompleta ma già in grado di gestire efficientemente i file sui vari TAP (che poi era la caratteristica principale).
Intanto,sul sito ho uppato gli screenshot che,man mano,dovrebbero dare un saggio delle possibilità del TM.
A presto :)
-
A che punto è il supporto dei loader fuori standard (leggi Algasoft)?
-
Ciao, complimenti per lo stato di avanzamento.
Volevo sapere.
In cosa concerne la differenza di copia da un tap all'altro che e' implementata al 100% e la copia in un singolo tap che e' implementata al 20%
Anche lo spostamento e' implementato al 50%, come mai?
Non si tratta dello stesso procedimento di una copia?
Grazie.
-
In cosa concerne la differenza di copia da un tap all'altro che e' implementata al 100% e la copia in un singolo tap che e' implementata al 20%
Che nel primo caso prendi un file da un TAP e lo inserisci in un altro TAP,nel secondo lo inserisci in un'altra parte dello stesso TAP.
La seconda situazione dev'essere gestita in maniera leggermente diversa dalla prima,per cui dovrò studiare per bene la situazione. :)
Anche lo spostamento e' implementato al 50%, come mai?
Non si tratta dello stesso procedimento di una copia?
Sì ma quando sposti un file,oltre a copiarlo devi rimuoverlo dalla posizione originaria.L'implementazione dello spostamento TAP->TAP è completa;come sopra, lo spostamento all'interno di un singolo TAP è il caso più "difficile" da
gestire e richiede un pò più di abilità.
Spero di aver risposto alle tue domande.
Ciao
-
A che punto è il supporto dei loader fuori standard (leggi Algasoft)?
E' la prima cosa che ho implementato,circa 3 mesi fa;cmq si tratta di un semplice controllo,niente di più... :D
-
In cosa concerne la differenza di copia da un tap all'altro che e' implementata al 100% e la copia in un singolo tap che e' implementata al 20%
Che nel primo caso prendi un file da un TAP e lo inserisci in un altro TAP,nel secondo lo inserisci in un'altra parte dello stesso TAP.
La seconda situazione dev'essere gestita in maniera leggermente diversa dalla prima
Parlando da profano, vedo differenze solo all'atto pratico, non all'atto teorico.
Si tratta sempre di scrivere un nuovo file con i file in ordine diverso oppure con un file in meno. Presumendo che i tap siano in memoria, la cosa dovrebbe essere quasi istantanea. Altrimenti ci vorrà un pochino (ma rimaniamo pur sempre nell'ordine di secondi).
Ci sono altri modi per fare quello che dici? Quali? :) (non è una domanda retorica, davvero non lo so)
-
Parlando da profano, vedo differenze solo all'atto pratico, non all'atto teorico.
Si tratta sempre di scrivere un nuovo file con i file in ordine diverso oppure con un file in meno. Presumendo che i tap siano in memoria, la cosa dovrebbe essere quasi istantanea. Altrimenti ci vorrà un pochino (ma rimaniamo pur sempre nell'ordine di secondi).
Ci sono altri modi per fare quello che dici? Quali? (non è una domanda retorica, davvero non lo so)
Sì il procedimento è sostanzialmente lo stesso:il mio dilemma era più che altro "stilistico" (come generalizzare la routine senza complicarla troppo),
non certo algoritmico.
-
Grazie ho capito!
Ciao
-
Ciao a tutti
Dopo una pausa forzata di 15 giorni,ho ricominciato solo da oggi a lavorare al TM:in particolare,adesso riporta le dimensioni corrette dei .TAP dopo le modifiche.
Nei prossimi giorni intendo concentrarmi sull'ottimizzazione del codice per la gestione del singolo .TAP,sul miglioramento dell'input da tastiera e su alcuni dettagli importanti,tra i quali la compatibilità col TAP selector di VICE (che nelle versioni >= 1.18 dà problemi con i file che vengono spostati in coda, mannaggialapupazza :)) e la conversione automatica di eventuali impulsi "out-of-range" (caso piuttosto raro,per la verità) nel caso di .TAP di tipo diverso.
Buonanotte
:sonno:
-
Complimenti ancora per i progressi.
Non ci sono beta pubbliche che si potrebbero provare? Anche magari compatibili 98/ME?
Grazie
-
Per ora ti devi ancora accontentare degli screenshots che trovi sul sito,ma se tutto va bene,a breve rilascerò qualcosa. :)
Ciao
-
Risolto il problema dell'inserimento dei file in coda;tra le altre cose,questo permette di inserire i file all'inizio dei .TAP vergini creati da VICE e CCS64.
Quasi completata anche la routine di conversione dei dati tra i due formati di .TAP esistenti.
Ciao
-
Quasi completata anche la routine di conversione dei dati tra i due formati di .TAP esistenti.
:confused: :confused: :confused: :confused:
Scusa l'ignoranza, quali sarebbero? :confused:
-
Tap versione 0 e 1
Cambia poco ma in modo sufficiente per doverli trattare in modo diverso.
http://ist.uwaterloo.ca/~schepers/formats/TAP.TXT (http://ist.uwaterloo.ca/~schepers/formats/TAP.TXT)
-
Ciao a tutti
...completata anche la conversione dei programmi v0<->v1,l'ho testata con qualche TAP e sembra funzionare,ma domani farò test più accurati. :)
Tra l'altro sto stendendo un doc dove espongo e motivo le mie scelte implementative;questo a supporto di chi volesse collaborare per colmare bug,aggiungere nuove funzionalità,ecc...Ho intenzione di zipparlo sotto forma di readme insieme alla 1st version (volevo mettere a punto anche il drag & drop,non so se ce la farò per la scadenza che mi sono prefissato,vedremo).
Ciauz :P
-
Completato il test del codice di conversione,pare proprio tutto ok.
Si può procedere col d&d e con le ultime rifiniture del codice.Riciao
-
:mavieni:
:ciauz:
-
Ottimo, alla grande :c64:
-
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
-
- 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 ;)
-
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. :)
-
- 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.
-
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" :overkiller:
- 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 :P (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).
-
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.
-
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
-
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
-
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/ (http://www.coder.pwp.blueyonder.co.uk/)
-
Probabilmente lo sapevate già tutti, ma sul sito del Final TAP
Si, bastava leggere la pagina 4
-
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
-
Che cosa e' successo al progetto?
Avevo letto che a meta' giugno sarebbe uscita la prima versione...
:huh:
Problemi da risolvere o impegni personali?
-
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 ;) ).
-
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.
-
Ti do 1000 euro virtuali :D
Scherzo, non era per mettere fretta ma per essere aggiornato sugli sviluppi dato che sul sito l'ultima nota risaliva a piu' di un mese fa.
Grazie
-
Salve a Tutti Commodoriani Amici!!! Sono nuovo del foro ma commodoriano esperto ed affezionatissimo! Sono stato attirato maggiormente da questa discussione xkè sto usando tantissimo il programmino STAP del signor Carmine TSM. Devo ringraziarlo. Il suo programma è semplice, veloce e fa benissimo il suo dovere. Una volta diviso il file tap del dump di una cassetta in tante parti quanti sono i programmi che vi sono salvati sopra (stando attento a quelli che hanno doppi caricamenti e nei programmi più vecchi anche più di due...ma x fortuna il programma STAP ha una routine che riconosce la maggior parte dei nomi dei programmi) posso convertire il tap del programma da me desiderato in prg o t64 (se il programma ha più caricamenti) utilizzando Wav-Prg se ho il giusto plugin. Ora però, vi voglio chiedere una cosa, se qualcuno è più esperto di me in questa faccenda. Qualcuno ha il plugin necessario a Wav-Prg x convertire i giochi delle più vecchie cassette da Edicola come Open Game, Poke o Special Program? Parlo dei primi numeri. Xkè gli altri li converto. Ad esempio, Special Program dal numero 15 in poi utilizzo il plugin FreeLoad e le conversioni vengono perfette. X le Poke non funzionano bene i plugin ke ho trovato fatti apposta x loro, almeno x i primi numeri, gli altri non ho provato. Il Plugin Caricamento Chiocciola invece va benissimo x tutte le cassette che avevano il libricino piccolino, ve le ricordate, vero? :) Fatto sta ke sono affezionato tantissimo proprio ai giochi più vecchi...Speranzoso in un vostro aiuto, ringrazio i tanti che si adoperano, come Carmine TSM, x farci rivivere un caro vecchio sogno...
-
Quali numeri esattamente? Ci sono su Edicola64 o qualche altro sito?
-
Tante mio caro amico...x questo vorrei imparare da solo...ma se vuoi provare ad aiutarmi, mi starebbe molto a cuore la poke n8. In particolare il gioco Il Corsaro che presenta due caricamenti. Non sono riuscito in nessun modo ad ottenere un t64 dal tap...cmq, se uno di voi è capace a trovare il plugin giusto x wav-prg, questo potrebbe funzionare x le peek, x le poke, le loadnrun e tutte le cassette vecchie...Grazie x l'interessamento e arrivedereci a presto
-
Tante mio caro amico...x
SimphonyOfSilence: intanto benvenuto sul forum.
Prendi visione del regolamento e prova a scrivere in italiano senza abbreviazioni.
-
Ho scaricato Poke 8 da Edicola64.
Ho usato il plug-in Poke
E' venuto fuori un T64 con 6 programmi dentro
I primi 4 funzionano. Sono: l'introduzione, Super Comets, Super Cristals, Il Combattente. Solo Super Comets funziona con RUN, per gli altri devi scrivere SYS e il numero che WAV-PRG ti restituisce come "entry point" (esempio: SYS 11520 per l'introduzione).
Il Corsaro è in 2 parti, che sono gli ultimi 2 programmi del T64. Non funziona, ma c'è un trucchetto per farlo funzionare (l'ho scoperto col monitor di VICE): devi rinominare l'ultimo programma in assoluto a "ultimate". Per farlo puoi usare Star Commander (http://sta.c64.org/sc.html). Apri il file T64 con Star Commander, muovi il cursore sull'ultimo programma dentro il T64, scegli RenMov, e nella casella di testo scrivi soltanto ultimate (eventualmente cancellando ciò che c'era scritto prima).
White Viper non è presente nel T64. Per quello devi usare il plug-in Caricamento chiocciola.
-
Grazie x l'interessamento. Ma non intendevo così...
Usando Stap a me funzionano tutti, anche White Viper e Il Corsaro, ma sono file tap. Non mi interessa un t64 della Poke n.8 ma uno che comprenda solo i due caricamenti del Corsaro xkè mi serve x il mio Gamebase! Sto cercando di realizzarne uno con tutti i giochi che avevo da bambino! B) Ciao a Tutti
-
MODERAZIONE - Signori, stiamo fuorviando un po' troppo dallo scopo originario di questo thread che è quello di fornire aggiornamenti sul Tap Manager di Alberto ed eventualmente discutere gli sviluppi del progetto.
Finora abbiamo tollerato che la discussione "fuorviasse" un po', restando nell'argomento TAP e perfino parlando di ipotetici nuovi formati, ma arrivati a questo punto, è decisamente il caso di tornare "in carreggiata", anche per rispetto nei confronti di chi ci sta lavorando e, se deve postare aggiornamenti, non deve essere costretto a farlo tra un post off topic e l'altro.
Siete tutti invitati pertanto ad utilizzare questo thread esclusivamente in maniera pertinente al progetto.
In particolare SimphonyOfSilence (a cui dò anche il mio benvenuto personale sul forum), se hai bisogno di ulteriore aiuto sei invitato, piuttosto che postare qui, ad aprire un nuovo thread nella sezione Aiuto: è lì apposta! :) Solo una raccomandazione: come ti è già stato fatto notare, dovresti in futuro avere l'accortezza di evitare il ricorso ad abbreviazioni da SMS, dal momento che riducono la leggibilità dei tuoi messaggi e, in ogni caso, non esiste un limite "stretto" alla lunghezza dei messaggi stessi.
-
Chiedo scusa allora... :mattsid: Sono nuovo! Quello che dici è giustissimo. Confido in questa versione definitiva di un manager per file tap anch'io allora! Alla prossima
-
maybe it is a little off the topic, but where can i find a rims manufacturer??
-
Cosa e' successo a questo progetto?
Sul sito era scritto che verso meta' giugno sarebbe uscita una beta ma poi nessun aggiornamento dopo quasi 3 mesi???
Alberto ci 6?
:huh:
-
Sul sito era scritto che verso meta' giugno sarebbe uscita una beta ma poi nessun aggiornamento dopo quasi 3 mesi???Alberto ci 6?
Ci pensi tu,visto che io non ho più mezza giornata libera da quasi 3 mesi (quasi 3 mesi,scandaloso vero)??
-
Cosa e' successo a questo progetto?
Se ci sono novità queste vengono postate nel thread, se non ci sono vuol dire Alberto non ha avuto tempo di lavorarci e che non ha niente di interessante da aggiungere.
Quindi che senso ha continuare a chiedere "cos'è successo a questo progetto"?
E' già la seconda volta che poni questa domanda, dovresti capire che così ottieni solo l'irritazione chi ci lavora veramente.
Oltre alle note di Moderazione espresse pochi post più sopra da Eregil evitiamo di allungare il brodo con messaggi dozzinali del tipo "sei un mito continua così" e quelle sullo stato di avanzamento del progetto.
In altre parole evitiamo tutto ciò che non è tecnico.
-
Non immaginavo, Alberto, ma te l'ho chiesto solamente perche' mi aspettavo 2 righe sul sito che non e' aggiornato da maggio, cmq anche io purtroppo non da 3 mesi ma da 2 anni e per varie ragioni non ho tempo per me e ti capisco anche :(
Ciao.
-
Ehi,ehi,calma ragazzi :lol:
@Roberto:ti ringrazio dell'appoggio ma la domanda di koseidon è legittima,non avendo più visto upgrades sul sito si è chiesto cosa fosse successo.
@koseidon:non ti preoccupare,la mia non era assolutamente una risposta stizzita,al contrario;mi farebbe sul serio piacere che tu o qualcun altro che è interessato si proponesse.E poi non è mai troppo tardi per imparare a programmare :D
Ripeto,mi spiace che la mia risposta sia suonata come irritata,perchè non lo era assolutamente.
Veniamo al sodo:non mi piace prendere in giro la gente,per cui dico subito che il progetto (come del resto avrete già capito) è momentaneamente sospeso fino a nuovo ordine.
Beninteso che non ho assolutamente intenzione di abbandonarlo e anzi,conto di trovare a breve qualche giornata LIBERA per completare come si deve la prima release.
Detto questo,pero di non aver creato tensioni inutili
Bye
-
@Roberto:ti ringrazio dell'appoggio ma la domanda di koseidon è legittima,non avendo più visto upgrades sul sito si è chiesto cosa fosse successo.
Non penso che tu abbia bisogno del mio appoggio; del resto la mia funzione non è quella di appoggiare un utente a dispetto di un altro ma di fare in modo che il forum ed i thread siano più ordinati possibili e soprattutto costruiti con messaggi utili.
Se tu ritieni lecite questo tipo di domande ti invito a scambiare la mail con gli interessati, a quel punto per quanto mi riguarda te lo possono chiedere anche ogni giorno.
Veniamo al sodo:non mi piace prendere in giro la gente,per cui dico subito che il progetto (come del resto avrete già capito) è momentaneamente sospeso fino a nuovo ordine.
Basta dirlo...
Considerato che il progetto è sospeso e che le note di moderazione di eregil continuano ad essere disattese tanto vale chiudere questo thread.
Se ritieni di essere danneggiato scrivimi privatamente e lo riaprirò.
In caso contrario ti invito a riaprire un nuovo topic alla ripresa del progetto e sarà mia cura metterlo in rilievo.