Tap Manager

[Massi cadenti]

 

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)...

[Alberto]

 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  

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

[Massi cadenti]

 

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  

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ì:

Codice: [Seleziona]

- 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ì:

Codice: [Seleziona]

- 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
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.

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").

[eregil]

 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.

[fab]

 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

[fab]

 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.

[Alberto]

 

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.  

[tsm_carmine]

 Mi faccio sentire? Mi faccio sentire!

Orsù, che cosa vuoi chiedermi?

--
TSM

[fab]

 

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...)

[iAN CooG]

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).
 

[Massi cadenti]

 

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à

[Alberto]

 

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).  

[tsm_carmine]

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.    

[Alberto]

 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

[tsm_carmine]

Per ora sono sommerso dagli impegni,appena posso ti mando i sorgenti;io sto sviluppando con MinGW.

Mail per te.

--
TSM