Autore Topic: Tapclean + Galadriel Support  (Letto 7875 volte)

iAN CooG

  • Utente
  • **
  • Post: 1774
    • http://iancoog.altervista.org
  • Gioco Preferito: Turbo Assembler, ActionReplay Monitor, DiskDemon
Tapclean + Galadriel Support
« Risposta #30 il: 18 Gennaio 2008, 22:54:05 »
 Finito di confrontare i vari loaders, implementate le necessarie modifiche sia a Galadriel che Easytape, i tap modificati di Blackhawk sono riconosciuti e ripuliti, al 99% nel peggiore dei casi.
Si tratta di 3 principali sottovarianti:
- Galadriel con sync 0x10...0x00 (normale)
- Galadriel con sync 0x0f...0x00 (hack)
- Easytape con sync 0x42/0x42 (hack)
Per di piu, per far capire a tapclean i tap malamente ripuliti da Blackhawk con valori troppo alti (0x1b/0x43, validi per Easytape ma troppo alti per Galadriel e soci che dovrebero essere 0x1b/0x27) ho dovuto innalzare il valore della variante Poke/Rev a 0x39, un compromesso che salva capra e cavoli, valido sia per i normali Poke/rev che per questi tap.
Entro lunedi' sera faro' il rilascio ufficiale, intanto proseguo con i test, finora tutti positivi.
-=[]=--- iAN CooG/HVSC^C64Intros ---=[]=-
- http://hvsc.c64.org - http://intros.c64.org -

iAN CooG

  • Utente
  • **
  • Post: 1774
    • http://iancoog.altervista.org
  • Gioco Preferito: Turbo Assembler, ActionReplay Monitor, DiskDemon
Tapclean + Galadriel Support
« Risposta #31 il: 21 Gennaio 2008, 20:36:24 »
 
  • Tutti i loaders di Blackhawk, perlomento tra quelli da me trovati, sono riconosciuti. Con una riga di comando del genere:

tapclean -o magn7_17a.tap -u -d -p -n -doet -doga -bc -e
il tap esaminato, contenente un primo blocco di Blackhawk+Easytape1, e altri blocchi in normale Easytape, verra' ripulito al 99% ma estratto al 100%.
Rimane solo un CBM block non ripulito perche' mancante del terminatore, una volta patchato manualmente aggiungendo "V0" e rieffettuando un'ottimizzazione del tap senza -e, verra' anche ripulito al 100%
  • scanners\turbotape.c: Aggiunti messaggi stampati quando un loader viene identificato.
  • Aggiunta una variante di Action Replay generata dalla cartuccia Atomic Power, anch'essa hack della AR. Praticamente stesso loader con 3 bytes in meno nell'header.
  • Migliorato il riconoscimento dell'header dell'Action Replay, evitando un falso riconoscimento in TAP Load'n'Run.
  • Migliorati i riconoscimenti degli header di Easytape1 e Smagic, anch'essi potevano essere interpretati malamente.
tapclean-0.20.g14.7z
-=[]=--- iAN CooG/HVSC^C64Intros ---=[]=-
- http://hvsc.c64.org - http://intros.c64.org -

iAN CooG

  • Utente
  • **
  • Post: 1774
    • http://iancoog.altervista.org
  • Gioco Preferito: Turbo Assembler, ActionReplay Monitor, DiskDemon
Tapclean + Galadriel Support
« Risposta #32 il: 22 Gennaio 2008, 20:33:06 »
 Come Murphy insegna, quando pensi di aver finito, ci sara' dell'altro lavoro da fare.
  • Trovato un altro loader di Blackhawk, stavolta il loader secondario e' un hack di Galadriel/Poke ma con i pilot byte = $01 anziche' $02
  • Non so come ma mi e' sfuggito un ennesimo end of file sempre in Galadriel/Poke, pensavo di averli sistemati tutti tempo fa. Contavo giusto 1 byte di troppo per determinarne l'EOF.
  • Invertiti nuovamente Load'n'Run e 7notebit per evitare che il primo venisse interpretato come il 2o, che essendo molto piu' raro (un solo tap a mia disposizione, mai visto altri dump di questa collana) e' piu' improbabile trovarlo in altri tap.
tapclean-0.20.g15.7z
 
-=[]=--- iAN CooG/HVSC^C64Intros ---=[]=-
- http://hvsc.c64.org - http://intros.c64.org -

tce

  • Neo-iscritto
  • *
  • Post: 16
Tapclean + Galadriel Support
« Risposta #33 il: 26 Febbraio 2008, 01:01:47 »
 iAN,

vedo che nei tuoi sorgenti ti porti dietro stralci di vecchi loaders e non segui l'evoluzione dei nuovi loaders ufficiali. Esempi:
- addblockdef() restituisce un valore che va verificato, solo se non negativo e' giusto riprendere la scansione dalla fine del file (i=eof);
- il contatore di read error sul checkbyte, nelle funzioni xxx_describe(), non viene incrementato piu' in nessuno scanner di ultima generazione

Il copia e incolla di vari pezzi di codice o il riuso di uno scanner per farne un altro produce effetti rovinosi: indentazione inconsistente (a volte TAB e altre volte spazi), commenti che si riferiscono ad altri scanners, bug, warning...
A questo si aggiungono frammenti di codice che denotano la mancanza di un quadro chiaro di quali sono gli strumenti che in TC si possono utilizzare per fare qualcosa un po' al di sopra della norma, come illustrato negli ultimi scanners e documentato nel cookbook che ho scritto per TC.

Lo scanner per Action Replay che e' entrato in CVS, integrato da Fabrizio in TC, e' poco leggibile, inutilmente complicato (come ho detto, il mio parere e' che manchi il quadro degli strumenti disponibili in TC) e bacato. Nessuno ha seguito o pensato di validare le tue patch per questo scanner, dopo l'iniziale integrazione.

A mio parere gli strumenti per fare bene dalla prima implementazione ci sono tutti: e' inutile reinventarsi la ruota e produrre codice bacato e poi patcharlo di volta in volta.
Inoltre per le sub-sub-sub-varianti vale il principio di Pareto: meglio scanners robusti che coprono l'80% (nessuna variante) che scanners hackati e rihackati che tentano di coprire il 100% ma non ci riescono bene.

Per il futuro, ti consiglio di consultare la wiki di c64tapes.org, in particolare:

http://c64tapes.org/dokuwiki/doku.php?id=scanner_cookbook

e di leggere le coding guidelines per TC (che sono quelle del Kernel di Linux per volere di Bo, l'admin del progetto).

I criteri elencati nei succitati documenti rendono la vita piu' facile sia a chi scrive che a chi fa il debugging dei sorgenti. Non a caso il primo usa la wiki, ove e' aperto a critiche e integrazioni.

E' un peccato che i tuoi sforzi si dirigano in una direzione che non credo essere giusta.

Un saluto,

Luigi.

tce

  • Neo-iscritto
  • *
  • Post: 16
Tapclean + Galadriel Support
« Risposta #34 il: 26 Febbraio 2008, 02:08:58 »
 Davvero non riesco a capire: anche le cose piu' basilari mi appaiono sbagliate nel tuo codice.

0x7F come pilot byte per Action Replay? pmin = 1? Stiamo dando i numeri?  :dotto:

La conseguenza e' che la prima parte del lead-in (2048 pulses circa) non viene riconosciuta come lead-in, ma restano 2048 UNKNOWN pulses prima di Action Replay.

Il pilot value corretto e' 0x01 il che triggera la lettura del pilot come bit invece che byte in find_pilot():

if ((pv == 0 || pv == 1) && (sv == 0 || sv == 1)) {   /* are the pilot/sync BIT values?... */
...
} else {    /* Pilot/sync are BYTE values... */
...
}

Il minimum pilot size, pmin, percio' non e' 1 ma diventa 1500 (75% circa di 2048).

Se il tuo e' un hack per supportare la variazione di threshold nel blocco dati del "Superturbo", ti assicuro che non e' assolutamente il caso di ricorrere a questi hack. Io stesso ho scritto uno scanner pulito molto tempo fa, senza ricorrere a questi mezzi.

Senza commenti nel codice che facciano pensare diversamente, questi appaiono come sviste dovute, credo, a una conoscenza incompleta del software preesistente (poco leggibile e poco documentato di suo, devo ammetterlo). Io non so come stai conducendo i test degli scanners, ma ti prego, sii vigile.

iAN CooG

  • Utente
  • **
  • Post: 1774
    • http://iancoog.altervista.org
  • Gioco Preferito: Turbo Assembler, ActionReplay Monitor, DiskDemon
Tapclean + Galadriel Support
« Risposta #35 il: 26 Febbraio 2008, 11:53:31 »
Citazione da: "tce"
Stiamo dando i numeri?  :dotto:
 
 :lol:
Cerchero' di fare tesoro dei consigli, ma voglio esporre un "piccolo" sfogo
alle critiche, sicuramente costruttive, che mi hai mosso.

Io non mi sono certo messo a modificare Tapclean per presentare dei sorgenti
"belli" ma per avere un programma che MI aiutasse a ripulire le cassettacce.
Ora il 99% dei tap che ho sono ripuliti e ricompressi con 7zip, mi occupano
un decimo di quanto occupassero prima, alcuni erano non funzionanti ora sono ok,
i prg li posso estrarre facilmente... e IO sono a posto cosi'.
Se serve anche a qualcun altro, meglio cosi'.

Anche a me non piace trovare i sorgenti con i tab impostati diversamente da
4 spazi, odio vedere i LF al posto degli CR+LF che servono A ME perche' uso
editor DOS/Windows, odio i sorgenti con le graffe a destra anziche' sotto,
detesto quando si trovano sorgenti che si compilano solo sotto linuccss
o che necessitano di headers o librerie che si trovano solo in linuccss etcetc
ma li adeguo alle MIE abitudini/necessita', non vado a lamentarmi con nessuno.

Se ogni tanto i tab spariscono dai sorgenti che tocco e' per mio sfizio,
Ctrl+K+X ed espando i tab a 4 spazi, per non avere differenze quando li vedo
in Visual Studio, piuttosto che MingWStudio o Aurora editor o Hiew o con quel
diavolo che mi pare. Ogni editor purtroppo gestisce alla sua maniera ste cose
e non ne uso uno solo.

Lo so benissimo che sono degli hack, non molto belli da vedere e lo dico anche
io, ma a me interessa il risultato prima della forma.
L'unico scanner che potrei eliminare e' il freeze frame che tanto e' un casino
da implementare e non so nemmeno se e quando mi verra' voglia di finirlo, tanto
l'ho trovato solo in un paio di tap. Mi basta per ora che venga individuato e
non rimanga un generico unrecognized.

Delle guidelines non ne sapevo nulla, nei sorgenti non sono nominate.
Non seguendo il forum in questione non potevo saperlo, dato che non se ne
parla altrove. Diciamo che e' una carenza di autodocumentazione da parte mia.
Certo se l'avessi saputo prima non mi sarei dovuto scervellare per cercare
di capire come funzionasse il tutto, ma sono abituato a modificare programmi
senza istruzioni e senza il parere dell'autore, non so se hai presente ;)
Sicuramente gli daro' un occhio se e quando riprendero' a modificare il
programma, ma non e' nei mie progetti a breve termine, avendo raggiunto
un risultato accettabile e, come detto gia' sopra, di tap sporchi non ne ho
quasi piu', quelli che ogni tanto Rob mi passa per analizzarli sono
pressoche' ripulibili al 100% a parte qualche byte qua e la' da sistemare
a colpi di Hiew. Gli scanners che mi interessava avere ora ce li ho.
Ce ne sono diversi altri "one shot", trovati in solo un tap e non mi
stimolano troppo ad implementrli.

Cosi' come e' vero che io non seguo lo svilupppo della 0.21 come dovrei,
perche' ormai non me la sento di rifare il tutto sui nuovi sorgenti,
mi pare che nemmeno voi vediate le modifiche che faccio io.
Ho appena dato un occhio al vostro cvs, e ho visto che il sorgente e' olderrimo,
scanners\actionreplay.c e' cambiato almeno 3 volte da quella prima versione, ha
subito modifiche proprio per ovviare ad una incorretta implementazione,
compreso l'header che prima non veniva riconosciuto. E' una cosa naturale
che ci siano errori di implementazione e successive fix.
Se i settaggi sono cosi' e' perche' non mi andavano in altro modo quando li
ho implementati. Si, sono andato per tentativi finche' non l'ha letto e
decodificato, mea culpa. "ogniuno ci habbiamo i suoi difetti" :D
E siccome NESSUNO ha mai dato uno straccio di feedback o commento a riguardo,
per me la cosa era a posto cosi'.
Quando potro' vedro' di applicare il tuo hint e vedere se riesco a rifare l'AR
nel modo che dici tu.

Concorderai sul fatto che partire da zero come ho fatto io non e' facile, io
per capire cosa fare mi sono dovuto arrangiare, non c'era nessuno a spiegarmi
cosa e come fare per crearmi uno scanner. Prima d'ora non sapevo nemmeno come
fossero fatti i tap. L'ho imparato "su strada" come ho sempre fatto nella vita.

Tu dicevi di aver fatto un biturbo (una delle N varianti), ora anche l'AR...
E dove diavolo erano? Perche' me li sono dovuti rifare io? Come facevo a sapere
che li avevi gia' fatti? Ho fatto prima a farmeli che sperare che apparissero
da soli, visti i tempi di sviluppo del programma. E si, come ho scritto nel
mio README, ci sono un sacco di kludges per far andare le cose, anche se
sono illogici. Non l'ho mai nascosto. Non sapendo come altro fare mi sono
arrangiato, ma anche se ho dovuto prendere il programma a calci nel culo per
fargli fare quello che volevo, ora fa quello che deve fare. IMHO egregiamente.

Le modifiche le faccio se e quando trovo dei bachi, senza dover aspettare
l'approvazione di chichessia, perche' ribadisco se non si fosse capito, che
queste modifiche sono fatte PER ME. Secondo te perche' non mi sono proposto
di entrare a far parte del team di manutenzione? Perche' non mi interessa.
So di non avere un indole per il groupworking, nemmeno al lavoro mi sono mai
abbassato ad adattarmi ai metodi di programmazione altrui, figuriamoci se mi
metto a farlo in ambito hobbistico.

Se volete prendete spunto, ma non chiedetemi di abbellire i sorgenti perche'
non piacciono a voi. Io non sono venuto a chiederveli come piacciono a me.
Io non mi sono messo a chiedere "ma perche' non fai questo , non fai quello,
non mi puoi mettere l'altro, E DAI c***o SBRIGATI CHE E' URGENTE" come fanno
tanti. Avrei potuto. Invece mi sono rimboccato le maniche e mi sono adattato.
Non vi piacciono i miei scanners e le mie modifiche a tapclean? Non posso farci
nulla se non esortarvi a reimplementarveli da voi che sicuramente verranno
meglio di quanto abbia fatto io, nel frattempo ho quello che mi serve e funziona.
So long and thanks for all the fish.

 
-=[]=--- iAN CooG/HVSC^C64Intros ---=[]=-
- http://hvsc.c64.org - http://intros.c64.org -

tce

  • Neo-iscritto
  • *
  • Post: 16
Tapclean + Galadriel Support
« Risposta #36 il: 26 Febbraio 2008, 13:29:13 »
 iAN, non e' di abbellimento di sorgenti che sto parlando, ma di strutturazione del codice alla nascita. Io non ho il tempo di prendere in considerazione i tuoi scanners (ahime' anche quelli che possono essere validi) se sono scritti alla meno peggio. A quanto pare nemmeno Fabrizio ha il tempo e questo spiega perche' due tuoi scanners siano entrati in release e mai aggiornati.
Cio' si traduce in lavoro che potrebbe servire la comunita' dei TAP files intera, ed e' uno spreco che non sia cosi'. Questo e' un mio rammarico personale, non una critica a come e per chi scrivi gli scanners.

Mi rendo conto che non hai una enorme esperienza nella scrittura di scanners, ma io non ho mai ricevuto richieste di aiuto con gli scanners da nessuno. Se non mi chiedete aiuto o suggerimenti su come si potrebbero fare le cose, io non posso darvelo. In questo stesso post scrissi: "sincronizziamoci", evitiamo di duplicare il lavoro. Scrissi anche che ho una decina di scanners pronti ma mai aggiunti a Tap Clean perche' non dispongo di un paniere di tap files sufficiente a testarli. So far, ho testato il mio AR scanner sulle mie stesse cassette e su tap files prodotti con gli emulatori (CCS64 "soffre" del problema della mancanza di eof pulses nei blocchi CBM e percio' mi da noia usare tap files sintetizzati).
Inoltre non ho mai pensato che tali scanners fossero di grande impatto (80% del lavoro per coprire il 20% della produzione).

Il cookbook nasce proprio dal mio sforzo di coinvolgere quante piu' menti possibili, evitando loro di dover fare il reverse engineering dell'intero programma per capire come scrivere scanners o per farsi un'idea del se scriverli seguendo una implementezione piuttosto che l'altra, viste le inconsistenze nel codice "legacy".

I nuovi scanners sono stati scritti tirando le somme e debuggando il codice pre-esistente, lasciando alle spalle le inconsistenze e i bug. Io mi faccio carico di mantenere perfettamente l'allineamento proprio per chi vuole attingere a tali sorgenti senza trovarsi di fronte a inconsistenze. Nuovi sorgenti non conformi ad essi, io non posso aggiornarli affatto, non avrebbe senso.

Ribadisco la mia richiesta: sincronizziamoci. A memoria non ricordo di aver mai lasciato nessuno senza clues su come fare le cose, quando sono stato interpellato.

fab

  • Utente
  • **
  • Post: 493
    • http://wav-prg.sourceforge.net/
  • Gioco Preferito: Tetris, Turrican, Impossible Mission
Tapclean + Galadriel Support
« Risposta #37 il: 26 Febbraio 2008, 23:15:02 »
 CVS non è il modo migliore per tenere sincronizzati due rami di un programma, ma almeno è qualcosa. Sul sito di iAN ci sono patch che si applicano alla 0.20, quando la 0.21 esiste da agosto, e la versione CVS si è evoluta da allora. Per chi mantiene l'ultima versione, non è facile tenere conto di patch che si applicano a versioni vecchie. Per venire incontro ai manutentori, il consiglio è di fornire patch che si applicano all'ultima versione CVS.

Se non mi ricordo male, Luigi, durante la sua visita di una decina di giorni fa, aveva sollevato la questione dei revision control system moderni, che permettono a sviluppatori diversi di mantenere i loro tree, e di integrare facilmente tree paralleli (Luigi, correggimi se sbaglio, forse era qualcun altro). Se solo Sourceforge permettesse di usare git, bzr eccetera... Comunque l'idea di passare almeno a Subversion c'è. In un futuro non ancora stabilito, ma c'è.
Un giapponese sa recitare a memoria tutti i numeri di pi greco fino all'83431º decimale. Sa a memoria anche l'unico numero telefonico che è nella sua agendina - Daniele Luttazzi

tce

  • Neo-iscritto
  • *
  • Post: 16
Tapclean + Galadriel Support
« Risposta #38 il: 27 Febbraio 2008, 22:06:51 »
 TC e' un progetto ambizioso ma non complesso. Secondo me CVS e' sufficiente allo scopo. Certo e' che coordinare gli sforzi viene sempre prima di qualunque sistema di revision control.

Fabrizio, non sono stato io a parlarti dei vari sistemi moderni, il merito va a qualcun altro :lol:

Bene, ho appena fatto il commit di una versione di TC. Questa include lo scanner AR scritto da me. Gli ho dato un'occhiata e fatto qualche verifica con un gioco originale commercializzato usando il superturbo di AR.

Una curiosita', iAN, probabilmente dovuta al fatto che non ci arrivo. Quando AR usa il superturbo, come fa la tua versione di TC a ripulire il TAP file visto che nello stesso blocco AR ci sono 4 differenti pulsewidths (2 per l'header e 2 per il blocco dati)?

Un saluto,

Luigi.

iAN CooG

  • Utente
  • **
  • Post: 1774
    • http://iancoog.altervista.org
  • Gioco Preferito: Turbo Assembler, ActionReplay Monitor, DiskDemon
Tapclean + Galadriel Support
« Risposta #39 il: 27 Febbraio 2008, 22:20:37 »
 Con un bell'hack ad personam in clean.c
Codice: [Seleziona]
       if(t==ACTIONREPLAY)
        {   /*
            note by iAN CooG:
            in case of ACTIONREPLAY_SUPER normal AR header won't be cleaned
            but they're only few bytes: -2048<-p1->+88
            let's clean them anyway:)
            */

            sp = ft[t].sp;
            lp = ft[t].lp;
            tp = ft[t].tp;
            s = blk[i]->p1;

            limit = tol + 2;
            if (boostclean)
                limit += 10;

            for (j = s-2049; j < s + 88; j++) {
                b = tap.tmem[j];
                if (b > tp && b < lp + limit)
                    tap.tmem[j] = lp;
                if (b < tp && b > sp - limit)
                    tap.tmem[j] = sp;
            }

            if(blk[i]->xi == 0x11)
            {
                t=ACTIONREPLAY_SUPER;
                blk[i]->lt=t;
            }
        }

:D  
-=[]=--- iAN CooG/HVSC^C64Intros ---=[]=-
- http://hvsc.c64.org - http://intros.c64.org -

tce

  • Neo-iscritto
  • *
  • Post: 16
Tapclean + Galadriel Support
« Risposta #40 il: 27 Febbraio 2008, 22:27:48 »
 Grazie iAN, l'idea e' buona, cosi' mi piaci.  :D
Non lo chiamerei hack (con cui io personalmente intendo il modo di lavorare in certe aziende e progetti oscuri...), ma soluzione salvatutti (che e' l'idea imprevedibile ed elegante che salva la situazione).

Non mi meraviglia che la release di TC non funzionasse, questo codice non e' stato mai integrato in clean.c...

fab

  • Utente
  • **
  • Post: 493
    • http://wav-prg.sourceforge.net/
  • Gioco Preferito: Tetris, Turrican, Impossible Mission
Tapclean + Galadriel Support
« Risposta #41 il: 28 Febbraio 2008, 16:27:29 »
Citazione da: "tce"
Non mi meraviglia che la release di TC non funzionasse, questo codice non e' stato mai integrato in clean.c...
Whoops...

Comunque, una soluzione che non richiede modifiche a clean.c e' preferibile.
Un giapponese sa recitare a memoria tutti i numeri di pi greco fino all'83431º decimale. Sa a memoria anche l'unico numero telefonico che è nella sua agendina - Daniele Luttazzi

tce

  • Neo-iscritto
  • *
  • Post: 16
Tapclean + Galadriel Support
« Risposta #42 il: 02 Marzo 2008, 00:20:38 »
 Purtroppo io stesso stasera ho dovuto modificare clean.c (clean_files()) e database.c (count_unopt_pulses()) per poter ripulire correttamente il trailer del Superturbo (che usa gli impulsi del normale turbo) e per poter riportare correttamente il numero di impulsi non ottimizzati. Quest'ultima modifica e' necessaria affinche' il tap ripulito passi il test sull'ottimizzazione.

Ahime', l'unica sarebbe aumentare il numero di impulsi da 3 (s, m, l) ad almeno 4, in modo da poter riconoscere e ripulire AR in un sol colpo ed eseguire la condizione sulla purezza senza modifiche ad hoc.

In tutta onesta', trattandosi di un trailer, avrei potuto "forzare" gli impulsi e far quadrare i conti senza cambiare clean.c, ma non ne sarei stato fiero.
Il lato positivo e' che AR da degli spunti di riflessione interessanti.

Ciao,

Luigi.

iAN CooG

  • Utente
  • **
  • Post: 1774
    • http://iancoog.altervista.org
  • Gioco Preferito: Turbo Assembler, ActionReplay Monitor, DiskDemon
Tapclean + Galadriel Support
« Risposta #43 il: 02 Marzo 2008, 00:37:04 »
 
Citazione da: "tce"
Purtroppo io stesso stasera ho dovuto modificare clean.c (clean_files()) e database.c (count_unopt_pulses())
Ma che caso, ho dovuto fare piu' o meno le stesse modifiche quando l'ho implementato :P
-=[]=--- iAN CooG/HVSC^C64Intros ---=[]=-
- http://hvsc.c64.org - http://intros.c64.org -

tce

  • Neo-iscritto
  • *
  • Post: 16
Tapclean + Galadriel Support
« Risposta #44 il: 02 Marzo 2008, 01:26:07 »
 Non e' un caso, dal log del mio ultimo commit si legge:

Citazione
Inserted code to cope with different pulsewidths used in the trailer for Action Replay Superturbo (idea partly from iAN CooG)

Come ho gia' detto, il mio rammarico e' il non coordinarsi seguendo cosi' binari non paralleli e duplicando lo sforzo.