Autore Topic: Tap Manager  (Letto 15622 volte)

tsm_carmine

  • Redazione
  • Utente
  • ****
  • Post: 513
  • Gioco Preferito: Krakout
Tap Manager
« Risposta #15 il: 26 Gennaio 2006, 09:26:04 »
  :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
Riusciremo a costruire un mondo dove più nessuno osi pronunciare le parole... "lettore floppy"?

Alberto

  • Utente
  • **
  • Post: 589
  • Gioco Preferito: Grand Prix Circuit
Tap Manager
« Risposta #16 il: 26 Gennaio 2006, 15:03:05 »
 
Citazione
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 :)

tsm_carmine

  • Redazione
  • Utente
  • ****
  • Post: 513
  • Gioco Preferito: Krakout
Tap Manager
« Risposta #17 il: 26 Gennaio 2006, 15:35:50 »
  ;)  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
Riusciremo a costruire un mondo dove più nessuno osi pronunciare le parole... "lettore floppy"?

iAN CooG

  • Utente
  • **
  • Post: 1774
    • http://iancoog.altervista.org
  • Gioco Preferito: Turbo Assembler, ActionReplay Monitor, DiskDemon
Tap Manager
« Risposta #18 il: 26 Gennaio 2006, 20:59:47 »
 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  
-=[]=--- iAN CooG/HVSC^C64Intros ---=[]=-
- http://hvsc.c64.org - http://intros.c64.org -

Massi cadenti

  • Utente
  • **
  • Post: 237
    • http://massicadenti.altervista.org
  • Gioco Preferito: The Last Ninja
Tap Manager
« Risposta #19 il: 27 Gennaio 2006, 00:58:07 »
Citazione da: "iAN CooG/HF"
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 ;)
Lo so, per tanti è difficile da capire anche se ormai sono 12 anni che lo uso, ma <b>il mio nick ha la "c" <u>minuscola</u></b>...
"Prima volta" nel settembre 1982 (Vic20 di mio cugino)
Utente C16 dal 25 dicembre 1984. Utente C128 dal 24 dicembre 1987
C16(4), C128, Vic20, 1541, 1541-II, 1530(3), 1531(2), X1541, MPS802, CaptainMikyII, Moviola x C64, esp.16KB x C16, ca.1300 cassette, ca.900 floppy, ca.10 joystick, paddles, accessori vari
<a href="http://massicadenti.altervista.org/algasoft.html">La mia pagina sulle Alga Soft, sulle cassette napoletane e su come Napoli ha vissuto a modo tutto suo gli anni d'oro della pirateria</a>
<a href="http://ready64.it/forum/?showtopic=2252#">Massi cadenti non è né un esperto (anche se si millanta tale) né un frequentatore di questo forum</a>
Importante: <a href="http://ready64.massicadenti.com">Ready64 è un sito che <B><U>non</U> è di Massi cadenti</B> ma di Rob Nicoletti</a>

Alberto

  • Utente
  • **
  • Post: 589
  • Gioco Preferito: Grand Prix Circuit
Tap Manager
« Risposta #20 il: 27 Gennaio 2006, 09:18:53 »
 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
 :)  

Alberto

  • Utente
  • **
  • Post: 589
  • Gioco Preferito: Grand Prix Circuit
Tap Manager
« Risposta #21 il: 27 Gennaio 2006, 09:41:13 »
 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.



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  

iAN CooG

  • Utente
  • **
  • Post: 1774
    • http://iancoog.altervista.org
  • Gioco Preferito: Turbo Assembler, ActionReplay Monitor, DiskDemon
Tap Manager
« Risposta #22 il: 27 Gennaio 2006, 15:23:20 »
Citazione da: "Alberto"
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)
-=[]=--- iAN CooG/HVSC^C64Intros ---=[]=-
- http://hvsc.c64.org - http://intros.c64.org -

koseidon72

  • Utente
  • **
  • Post: 177
Tap Manager
« Risposta #23 il: 28 Gennaio 2006, 01:19:39 »
 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:

tsm_carmine

  • Redazione
  • Utente
  • ****
  • Post: 513
  • Gioco Preferito: Krakout
Tap Manager
« Risposta #24 il: 29 Gennaio 2006, 10:22:55 »
 Sorgenti inviati  :mattsid: .

--
TSM
Riusciremo a costruire un mondo dove più nessuno osi pronunciare le parole... "lettore floppy"?

Alberto

  • Utente
  • **
  • Post: 589
  • Gioco Preferito: Grand Prix Circuit
Tap Manager
« Risposta #25 il: 30 Gennaio 2006, 14:26:50 »
 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
 

Alberto

  • Utente
  • **
  • Post: 589
  • Gioco Preferito: Grand Prix Circuit
Tap Manager
« Risposta #26 il: 30 Gennaio 2006, 15:16:32 »
 
Citazione
un flag sul crc.. tipo OK oppure BAD.. (e' complicato?)
Vediamo :)
Citazione
Sorgenti inviati  .
Grazie,appena ho tempo me li guardo.

Massi cadenti

  • Utente
  • **
  • Post: 237
    • http://massicadenti.altervista.org
  • Gioco Preferito: The Last Ninja
Tap Manager
« Risposta #27 il: 31 Gennaio 2006, 02:22:06 »
 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...
Lo so, per tanti è difficile da capire anche se ormai sono 12 anni che lo uso, ma <b>il mio nick ha la "c" <u>minuscola</u></b>...
"Prima volta" nel settembre 1982 (Vic20 di mio cugino)
Utente C16 dal 25 dicembre 1984. Utente C128 dal 24 dicembre 1987
C16(4), C128, Vic20, 1541, 1541-II, 1530(3), 1531(2), X1541, MPS802, CaptainMikyII, Moviola x C64, esp.16KB x C16, ca.1300 cassette, ca.900 floppy, ca.10 joystick, paddles, accessori vari
<a href="http://massicadenti.altervista.org/algasoft.html">La mia pagina sulle Alga Soft, sulle cassette napoletane e su come Napoli ha vissuto a modo tutto suo gli anni d'oro della pirateria</a>
<a href="http://ready64.it/forum/?showtopic=2252#">Massi cadenti non è né un esperto (anche se si millanta tale) né un frequentatore di questo forum</a>
Importante: <a href="http://ready64.massicadenti.com">Ready64 è un sito che <B><U>non</U> è di Massi cadenti</B> ma di Rob Nicoletti</a>

koseidon72

  • Utente
  • **
  • Post: 177
Tap Manager
« Risposta #28 il: 31 Gennaio 2006, 15:51:18 »
 
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:  

eregil

  • Administrator
  • Utente
  • *****
  • Post: 706
  • Gioco Preferito: Impossible Mission
Tap Manager
« Risposta #29 il: 31 Gennaio 2006, 17:55:23 »
 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. :)

Citazione
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. ;)
Non rispondo a richieste private, di qualunque genere esse siano.
Per domande tecniche leggete le FAQ e usate l'apposito forum.
Per questioni amministrative contattate lo staff tramite il form Contatti sul sito.