Ready64 Forum
Commodore 64 => Segnalazione News => Topic aperto da: iAN CooG - 31 Luglio 2007, 21:23:42
-
Era da un po' che volevo provarci e dopo 4 giorni di tentativi (ed errori) sono riuscito a sfornare un nuovo scanner per TapClean, erede opensource di FinalTAP.
I TAPs con loader Galadriel aka Connection aka Biturbo aka caricamento chiocciola, e le varianti "Poke" e "BOB85" (variante trovata per ora solo nel tap originale di Dylan dog: Murderers) ora vengono decodificati e ripuliti correttamente, salvo qualche eccezione.
Finora questi formati mi obbligavano a ripulire manualmente i TAP, a colpi di ricerca e sostituisci con un editor binario, e pur non essendo una cosa lunghissima, diventava estremamente tediosa se bisognava ripertere l'operazione su piu' di un TAP.
Un TAP pulito viene compresso dalle 10 alle 20 volte da 7zip, al contrario di un TAP sporco, quindi perche' sprecare spazio?
Per l'estrazione dei prg c'era gia' l'ottimo Wav-Prg, ma riuscire a farlo anche da TapClean mi da' soddisfazione.
Se Fabrizio Gennari, che da quanto so e' anche manutentore di TapClean, lo ritenesse opportuno, sarebbe da mettere al vaglio l'aggiunta dello scanner nella versione ufficiale.
La mia versione di TapClean contiene alcune modifiche dovute al mio gusto personale, come quella di creare i files nella dir corrente e l'aumento del database a 20000 elementi per gestire ENORMI taps etc., ma se quanto ho fatto puo' servire anche nella official version, tanto meglio.
-
Tapclean ha avuto un momento iniziale di entusiasmo, poi tutti i manutentori (anche TCE alias Luigi di Fraia, e Bo Kvamme di http://tapes.c64.no) (http://tapes.c64.no)) si sono stancati allo stesso momento, e il programma è stato trascurato.
Ma questa novità sembra troppo interessante per essere trascurata. Appena ho un po' di tempo (mai) la scarico e la inserisco nel CVS di Tapclean. Poi scrivo a Bo e gli chiedo se è il caso di far uscire una nuova versione.
-
Benone :)
Sto gia' lavorando ad una nuova versione della versione "poke" che ha pero' i bit LSBf e con meno bytes. Entro domani sera posto la nuova versione.
Mi rimane da capire come fare per i Galadriel "normali" a beccare l'header CBM giusta, cosi' com'e' ora va sempre bene solo se c'e' un solo CBM e un solo Galadriel.
-
E chi mi ferma adesso?
- Aggiunta variante Poke/Reversed
- Aggiunti Easytape 1/2 anche conosciuto come Disk2tape Extra e usato nelle algasoft/magnifici7/specialprogram
- corretti calcoli dei checksum
- nel tcreport ora finiscono anche i StartAddress (la sys da dare insomma) per quelle varianti galadriel/poke che non partono necessariamente con un RUN.
- varie ed eventuali
-
- ripristinato parametro -noall e aggiunti parametri -dogaladriel, -doeasytape, -doturbo, da aggungere dopo -noall e attivare quindi solo quegli scanner, risparmiando tempo nell'operazione.
- Corretto un errore nello scanner del Visiload, successo in un caso solamente ma meglio fare in modo che non succeda ancora. Una stringa veniva riempita a dismisura e andava a sovrascrivere altre variabili in memoria, tra cui quella del path corrente, causando la creazione ricorsiva della directory prg\
-
Rileggendo le vecchie mail ho trovato uno scanner Biturbo scritto da tce, e mai finito nel CVS.
Prima di inserire quello di iAN nel CVS, quindi, preferisco aspettare di sentire che cosa ne pensa tce.
-
iAN, forse è chiedere troppo, ma riesci a spezzare la patch in patch più piccole, una per ogni caratteristica aggiunta/bug risolto? Aggiungere un pezzo per volta è più maneggevole, e soprattutto più facile da giustificare agli altri manutentori.
(nell'archivio scaricabile dal sito di iAN, oltre alla sorgente completa, c'è anche una patch con tutte le differenze tra la versione 0.20 e quella di iAN)
-
Mi rimane da capire come fare per i Galadriel "normali" a beccare l'header CBM giusta, cosi' com'e' ora va sempre bene solo se c'e' un solo CBM e un solo Galadriel.
Coordiniamoci, perche' il problema l'ho gia' affrontato e risolto un anno fa...
/*
* biturbo.c (by Luigi Di Fraia, Aug 2006 - armaeth@libero.it)
*
* Part of project "TAPClean". May be used in conjunction with "Final TAP".
*
* Based on cyberload_f4.c, turrican.c, that are part of "Final TAP".
* Final TAP is (C) 2001-2006 Stewart Wilson, Subchrist Software.
*
*
*
* This program is free software; you can redistribute it and/or modify it under
* the terms of the GNU General Public License as published by the Free Software
* Foundation; either version 2 of the License, or (at your option) any later
* version.
*
* This program is distributed in the hope that it will be useful, but WITHOUT ANY
* WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
* PARTICULAR PURPOSE. See the GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along with
* this program; if not, write to the Free Software Foundation, Inc., 51 Franklin
* St, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
/*
* Status: Beta
*
* CBM inspection needed: Yes
* Single on tape: No! -> requires tracking of the right CBM file (done)
* Sync: Sequence (bytes)
* Header: Yes
* Data: Continuos
* Checksum: Yes
* Post-data: No
* Trailer: Yes
* Trailer omogeneous: Yes (bit 0 pulses)
*/
#include "../mydefs.h"
#include "../main.h"
#define THISLOADER BITURBO
#define BITSINABYTE 8 /* a byte is made up of 8 bits here */
#define SYNCSEQSIZE 0x11 /* amount of sync bytes */
#define MAXTRAILER 2040 /* max amount of trailer pulses read in */
#define LOADOFFSETH 0x5D /* load location (MSB) offset inside CBM data */
#define LOADOFFSETL 0x4B /* load location (LSB) offset inside CBM data */
#define ENDOFFSETH 0x52 /* end location (MSB) offset inside CBM data */
#define ENDOFFSETL 0x59 /* end location (LSB) offset inside CBM data */
#define MAXCBMBACKTRACE 0x2A00 /* max amount of pulses between turbo file and the
'FIRST' instance of its CBM data block.
The typical value is less than this one */
void biturbo_search (void)
{
int i, h; /* counters */
int sof, sod, eod, eof, eop; /* file offsets */
int pat[SYNCSEQSIZE]; /* buffer to store a sync train */
int ib; /* condition variable */
int en, tp, sp, lp, sv;
unsigned int s, e; /* block locations referred to C64 memory */
unsigned int x; /* block size */
/* legacy sync pattern */
static int sypat[SYNCSEQSIZE] = {
0x10, 0x0F, 0x0E, 0x0D, 0x0C, 0x0B, 0x0A, 0x09,
0x08, 0x07, 0x06, 0x05, 0x04, 0x03, 0x02, 0x01,
0x00
};
int match; /* condition variable */
int cbm_index; /* Index of the CBM data block to get info from */
int xinfo; /* extra info used in addblockdef() */
en = ft[THISLOADER].en;
tp = ft[THISLOADER].tp;
sp = ft[THISLOADER].sp;
lp = ft[THISLOADER].lp;
sv = ft[THISLOADER].sv;
if (!quiet)
msgout(" Biturbo");
cbm_index = 1;
for (i = 20; i > 0 && i < tap.len - BITSINABYTE; i++) {
eop = find_pilot(i, THISLOADER);
if (eop > 0) {
/* Valid pilot found, mark start of file */
sof = i;
i = eop;
/* Decode a 16 byte sequence (possibly a valid sync train) */
for (h = 0; h < SYNCSEQSIZE; h++)
pat[h] = readttbyte(i + (h * BITSINABYTE), lp, sp, tp, en);
/* Note: no need to check if readttbyte is returning -1, for
the following comparison (DONE ON ALL READ BYTES)
will fail all the same in that case */
/* Check sync train. We may use the find_seq() facility too */
for (match = 1, h = 0; h < SYNCSEQSIZE; h++)
if (pat[h] != sypat[h])
match = 0;
/* Sync train doesn't match */
if (!match)
continue;
/* Valid sync train found, mark start of data */
sod = i + BITSINABYTE * SYNCSEQSIZE;
/* Now we try to retrieve the Biturbo variables from the corresponding CBM
Data block ('FIRST' instance).
We search for the CBM data block whose start offset in the TAP file is not
too much far from where we found the actual Biturbo file */
/* Note: it could be cbm_index += 2 so we skip the "REPEATED" instances of
CBM data blocks, but in case the "FIRST" instance of any CBM
Data blocks is not recognized, that would cause a misalignment, and
the CBM data block of non Biturbo files could be accidentally used */
match = 1;
for (;; cbm_index++) {
ib = find_decode_block(CBM_DATA, cbm_index);
if (ib == -1)
return; /* failed to locate CBM data for this one and any further Biturbo file. */
/* Plausibility checks. Here since we track the CBM part for each
of them, in case of multiple Biturbo files on the same tape:
there may be some programs using Biturbo, some others using another loader,
so that the n-th Biturbo file may not come just after the n-th CBM file. */
if (blk[ib]->p1 < sof - MAXCBMBACKTRACE)
continue; /* Not yet the right CBM data block */
if (blk[ib]->p1 > sof) {
match = 0; /* Too far ahead: failed to locate CBM data for this Biturbo file only. */
cbm_index--; /* Make the last checked CBM data instance available to the following Biturbo files, if any */
break;
}
s = blk[ib]->dd[LOADOFFSETL] + (blk[ib]->dd[LOADOFFSETH] << 8);
e = blk[ib]->dd[ENDOFFSETL] + (blk[ib]->dd[ENDOFFSETH] << 8) - 1;
/* Plausibility check. Maybe a read error in the 'FIRST' instance of CBM data, so it's
worth trying the next CBM data file, which should be the 'REPEATED' instance. */
if (e < s)
continue;
break;
}
/* Failed to find the CBM data block for this Biturbo file (maybe CBM part is unrecognized) */
if (!match)
continue;
/* Compute size */
x = e - s + 1;
/* Point to the first pulse of the checkbyte (that's final) */
eod = sod + x * BITSINABYTE;
/* Initially point to the last pulse of the checkbyte */
eof = eod + BITSINABYTE - 1;
/* Trace 'eof' to end of trailer (also check a different
implementation that uses readttbit()) */
h = 0;
while (eof < tap.len - 1 && h++ < MAXTRAILER &&
tap.tmem[eof + 1] > sp - tol &&
tap.tmem[eof + 1] < sp + tol)
eof++;
/* Store the info read from CBM part as extra-info */
xinfo = s + (e << 16);
if (addblockdef(THISLOADER, sof, sod, eod, eof, xinfo) >= 0)
i = eof; /* Search for further files starting from the end of this one */
} else {
if (eop < 0)
i = (-eop);
}
}
}
int biturbo_describe(int row)
{
int i, s;
int en, tp, sp, lp;
int cb;
int b, rd_err;
en = ft[THISLOADER].en;
tp = ft[THISLOADER].tp;
sp = ft[THISLOADER].sp;
lp = ft[THISLOADER].lp;
/* Retrieve C64 memory location for load/end address from extra-info */
blk[row]->cs = blk[row]->xi & 0xFFFF;
blk[row]->ce = (blk[row]->xi & 0xFFFF0000) >> 16;
blk[row]->cx = (blk[row]->ce - blk[row]->cs) + 1;
/* Compute pilot & trailer lengths */
/* pilot is in bytes... */
blk[row]->pilot_len = (blk[row]->p2 - blk[row]->p1) / BITSINABYTE;
/* ... trailer in pulses */
blk[row]->trail_len = blk[row]->p4 - blk[row]->p3 - (BITSINABYTE - 1);
/* if there IS pilot then disclude the sync sequence */
if (blk[row]->pilot_len > 0)
blk[row]->pilot_len -= SYNCSEQSIZE;
/* Extract data and test checksum... */
rd_err = 0;
cb = 0;
s = blk[row]->p2;
if (blk[row]->dd != NULL)
free(blk[row]->dd);
blk[row]->dd = (unsigned char*)malloc(blk[row]->cx);
for (i = 0; i < blk[row]->cx; i++) {
b = readttbyte(s + (i * BITSINABYTE), lp, sp, tp, en);
cb ^= b;
if (b != -1) {
blk[row]->dd[i] = b;
} else {
blk[row]->dd[i] = 0x69; /* error code */
rd_err++;
/* for experts only */
sprintf(lin, "\n - Read Error on byte @$%X (prg data offset: $%04X)", s + (i * BITSINABYTE), i);
strcat(info, lin);
}
}
b = readttbyte(s + (i * BITSINABYTE), lp, sp, tp, en);
blk[row]->cs_exp = cb & 0xFF;
blk[row]->cs_act = b;
blk[row]->rd_err = rd_err;
return(rd_err);
}
Perdonate la scarsa leggibilita' ma la formattazione viene perduta quando un TAB e' seguito da un ulteriore TAB o spazi nella tag CODE...
Lo scanner non e' ufficialmente in TAPClean perche' a parte qualche italiano appassionato come noi, non pensavo nessuno ne avesse bisogno.
Chiedermi queste cose prima di lavorarci da voi non e' una cattiva idea, e io sono sempre felice di accogliere richieste degli appassionati, a maggior ragione se sono italiani ;)
Per il resto, bel lavoro iAN (soprattutto con i fix, ma anche con il supporto). Tuttavia mi associo a Fabrizio per i bugfix: patch piccole e documentate un po' cosi' possiamo starti dietro visto che hai messo la quinta :D
Ciao,
Luigi.
-
Tapclean ha avuto un momento iniziale di entusiasmo, poi tutti i manutentori (anche TCE alias Luigi di Fraia, e Bo Kvamme di http://tapes.c64.no) (http://tapes.c64.no)) si sono stancati allo stesso momento, e il programma è stato trascurato.
Ma questa novità sembra troppo interessante per essere trascurata. Appena ho un po' di tempo (mai) la scarico e la inserisco nel CVS di Tapclean. Poi scrivo a Bo e gli chiedo se è il caso di far uscire una nuova versione.
Dietro le quinte il lavoro va avanti e ho una decina di scanners pronti ma non in CVS solo perche' non ho avuto tempo di provarli su 10 o + TAP files, o perche' non ho trovato 10 o piu' TAP files che usassero un particolare loader.
Direi che c'e' stata mancanza di comunicazione, Fabrizio, per questo vi invito a unirvi a noi sul canate irc #tapes di IRCNet, dove con Bo e Peepo c'e' un massivo scambio di idee "informali" e idee che finiscono raramente nel file TODO del CVS.
Inoltre sapete che sono venuto in UK da 4 mesi e i primi 2 sono stati davvero duri senza lavoro... Ora ho traslocato e ancora mi sto sistemando prima di poter dire di sentirmi a casa e tornare a ufficializzare il mio lavoro in CVS.
Ciao,
Luigi.
-
Non voleva essere una critica: i progetti open source sono su base volontaria e quindi non ci si può aspettare niente perché niente è dovuto. E in fondo sono stato il meno attivo di tutti. E mi sono accorto soltanto dopo che in realtà c'erano versioni nuove di Tapclean.
-
@TCE: Grazie per la dritta, ho gia' adattato lo scanner per cercare l'header giusta e relativo cbm_data controllandone l'offset, faro' la stessa cosa anche per l'easytape e poi provvedero' a creare i diff per ogni sorgente.
-
E mi sono accorto soltanto dopo che in realtà c'erano versioni nuove di Tapclean.
Giusto. Il supporto per i dump fatti con DC2N ne e' un esempio. Il fatto che ho trovato un bug nel codice di Bo e l'abbia corretto nel giro di pochi giorni dalla realizzazione conferma che l'attenzione non e' calata.
Anche il front end uscira' a breve con nuove opzioni. Non escludo l'inserimento del visualizzatore di bitmap. Probabilmente in futuro ci sara' anche quello per i fonts.
Inoltre potrei citare tcrep2html, uno script Perl che ho realizzato per convertire il file tcreport.txt in un file html con le caratteristiche che c'erano un tempo in Final Tap GUI e in piu' un utile index dei file presenti nel TAP. Esiste una versione beta compilata per Windows, in quanto mi rendo conto che gli utenti Windows non vogliano installarsi Perl per usare lo script:
tcrep2html (http://www.luigidifraia.it/c64/tcrep2html.zip)
Un esempio di cio' che fa lo script lo trovate su:
tcreport (http://www.luigidifraia.it/c64/tcreport.html)
La pubblicazione dello script avverra' unitamente all'aggiunta di una nuovissima (e super segreta ;) ) caratteristica che dara' agli utenti piu' esperti la possibilita' di diagnosticare in modo piu' rapido eventuali problemi nei files TAP.
Come vedi di carne a cuocere ce n'e', e tanta ;)
-
@TCE: Grazie per la dritta, ho gia' adattato lo scanner per cercare l'header giusta e relativo cbm_data controllandone l'offset, faro' la stessa cosa anche per l'easytape e poi provvedero' a creare i diff per ogni sorgente.
Bene. A suo tempo io scrissi lo scanner per Biturbo e lo provai scrupolosamente ma non lo aggiunsi in TC perche' il mio obiettivo era solo quello di creare un paniere di scanner con diverse funzionalita', in modo da poter riusare il codice per altri scanner di diffusione maggiore. Segnalai a Fabrizio il fatto che avevo scritto tale scanner, in modo da coinvolgere lui e Bo affinche' potessero apprezzarne e magari riusarne le potenzialita'.
Ora come ora i nuovi scanners cui ho lavorato offrono la possibilita' di aggiungerne di nuovi, semplicemente facendo copia e incolla di sezioni prese da scanners del paniere, quasi senza rischi.
-
Eccomi =)
I diff sono in una dir diff\ separata.
Ci ho lavorato tutto il giorno da stamattina alle 7, tra prove e debug/correzioni.
Come primo giorno di ferie non c'e' davvero male *g*
Ho testato estenuamente una 50ina (non scherzo) di tap edicolosi, e a botte di -tol, -noc64eof vanno tutte, a parte alcuni casi particolari.
Ad esempio una algasoft che ha un gioco originale in Freeload, e il resto dei giochi in easytape, non c'e' verso di farlo andare, nemmeno con -noid (che metterlo o non metterlo non mi cambia nulla, fa sempre l'estrazione del freeload e basta).
Spezzando il tap con stap invece va.
Un altro tot di tap invece pur essendo fatte con la variante poke, stap non vede praticamente nemmeno le cbm headers, e tapclean invece non trova la sync $09...$01 e quindi non le considera valide. Pazienza.
-
Eccomi =)
http://iancoog.altervista.org/C/tapclean-0.20.g6.7z (http://iancoog.altervista.org/C/tapclean-0.20.g6.7z)
I diff sono in una dir diff\ separata.
Ci ho lavorato tutto il giorno da stamattina alle 7, tra prove e debug/correzioni.
Come primo giorno di ferie non c'e' davvero male *g*
Ho testato estenuamente una 50ina (non scherzo) di tap edicolosi, e a botte di -tol, -noc64eof vanno tutte, a parte alcuni casi particolari.
Ad esempio una algasoft che ha un gioco originale in Freeload, e il resto dei giochi in easytape, non c'e' verso di farlo andare, nemmeno con -noid (che metterlo o non metterlo non mi cambia nulla, fa sempre l'estrazione del freeload e basta).
Spezzando il tap con stap invece va.
Un altro tot di tap invece pur essendo fatte con la variante poke, stap non vede praticamente nemmeno le cbm headers, e tapclean invece non trova la sync $09...$01 e quindi non le considera valide. Pazienza.
TC per alcuni giorni sara' blindato: la compilazione su architettura a 64 bit ha prodotto effetti indesiderati che non sono solo a livello di rappresentazione di numeri...
Mentre ci lavoro vedro' di inserire quelle patch che sembrano piu' importanti e chiare, ovviamente dandoti l'adeguato credito.
Prima di tale lavoro penso che verra'fatta una release ufficiale su sourceforge, probabilmente domani sera, con due o tre nuovi loaders che ho volutamente tenuto fuori dall'anno scorso.
Grazie mille per il tuo lavoro.
-
Un altro tot di tap invece pur essendo fatte con la variante poke, stap non vede praticamente nemmeno le cbm headers, e tapclean invece non trova la sync $09...$01 e quindi non le considera valide.
La notte porta consiglio, ho analizzato il loader e trattasi di una variante del poke/rev. Ora Tapclean le gestisce, resta da capire perche' STAP non ne vede gli headers.
Gia' che ero intento ad analizzare varianti ho aggiunto anche una galadriel che decripta parte del codice caricato prima di eseguirlo. Per gestirlo ho sfruttato i membri della struttura blk_t inutilizzati perche' sia galadriel che galadriel/xor non controllano il checksum finale. Il loader galadriel ne risulta cosi' parecchio variato.
-
Mentre ci lavoro vedro' di inserire quelle patch che sembrano piu' importanti e chiare, ovviamente dandoti l'adeguato credito.
Potresti dare precedenza all'aumento dello spazio per il database, la memoria per l'info raddoppiata e la fix per il visiload.
Per quanto riguarda l'uso della dir corrente anziche' la dir dell'exe, e i comandi remove(), rename() etc anziche' l'uso di system() ribadisco che si tratta di miei gusti personali, puoi anche ometterli se dovessero causare problemi di portabilita' o di uso con il front end.
-
Per quanto riguarda l'uso della dir corrente anziche' la dir dell'exe, e i comandi remove(), rename() etc anziche' l'uso di system() ribadisco che si tratta di miei gusti personali
Io sono d'accordo, l'uso di system() va evitato se si tratta di operazioni normali (cancellare un file...). iAN ha creato l'implementazione Windows e lasciato system() ecc. in Linux, per completare l'opera bisognerebbe creare un'implementazione Linux degli stessi comandi senza system().
-
Potresti dare precedenza all'aumento dello spazio per il database, la memoria per l'info raddoppiata e la fix per il visiload.
Per quanto riguarda l'uso della dir corrente anziche' la dir dell'exe, e i comandi remove(), rename() etc anziche' l'uso di system() ribadisco che si tratta di miei gusti personali, puoi anche ometterli se dovessero causare problemi di portabilita' o di uso con il front end.
iAN,
sono d'accordo. La rimozione dell'uso di system per cose tipo chdir, delete e rename era gia' in programma, ma il tempo e' poco e testare tutto su Win e Linux non e' piu' facile per me come lo era una volta. Per fortuna ho una vm con debian, dunque dovrei potermi mettere all'opera presto.
Grazie,
Luigi.
-
Grazie a te, fai con calma, io mi sono fermato qua.
Piuttosto, ho visto che in CVS (ho fatto il browse su sourceforge, non ho ne cvs ne svn installati) hai gia' messo il biturbo e quell'altro dal nome strambo, che da quanto ho capito trattasi della variante "poke/Golden", dico giusto?
-
Grazie a te, fai con calma, io mi sono fermato qua.
Piuttosto, ho visto che in CVS (ho fatto il browse su sourceforge, non ho ne cvs ne svn installati) hai gia' messo il biturbo e quell'altro dal nome strambo, che da quanto ho capito trattasi della variante "poke/Golden", dico giusto?
Non so se sia la variante poke/Golden o no, fatto sta che quel loader e' usato in buona misura nelle cassette RE&C, dunque per me fa coppia con Biturbo, non l'ho ritenuto una variante di quest'ultimo, anche per via del CRC32 del file dati (da cui prende il nome in TAPClean).
Ho solo di recente fatto il checkin della versione 64-bit safe di TC (a partire dalla release 0.22, l'unico compilatore di riferimento e' gcc e i suoi port), per cui ancora non ho potuto guardare con attenzione le tue patch.
Ho eliminato l'uso di tutte le system() e ti ho citato per il suggerimento nell'HISTORY del programma.
Abbiate ancora pazienza: il lavoro e' tanto e DC2N e l'ispezione dei dump da esso prodotti richiede tempo e attenzione.
-
Ottimo. Ti auguro buon lavoro
-
Ho fatto un paio di aggiunte:
- i parametri -do ora ci sono tutti, non solo quelli per galadriel/easytape/turbotape. Sono indispensabili, assieme a -noall, per elaborare tapes in brevissimo tempo, quando si sa che e' inutile cercare tutti i 50 e passa loaders.
- aggiunto un parametro -easykludge per alcuni TAP come Special Program/Special playgames/I magnifici 7, che sono fatti con Easytape1 ma con un solo blocco di tipo CBM e da 2 a 4 blocchi in Easytape1.
Questo parametro forza i parametri -noall -doeasytape, quindi non e' necessario specificarli a linea di comando. Se il tap esaminato contenesse anche Easytape2 o altri tipi di loaders, meglio spezzare con STAP ed elaborarli separatamente, per poi riunirli con JTAP/MJTAP.- la pulizia di alcuni tap si fermava troppo presto, lasciando gli ultimi 48/56 bytes sporchi, era uno stupido errore di calcolo.
-
Nuova versione, tra i vari fix minori, ho aggiunto lo scanner per Action Replay, 2 varianti (AR mk3 e AR mk4/successive) e con 2 sottovarianti ciascuna, Turbo e SuperTurbo, quest'ultima con impulsi variabili.
Nel file ho incluso anche l'history delle revisioni, che mi sono sempre scordato di includere.
-
Ecco una nuova versione.
- Aggiunti loaders di LOAD'N'RUN (cassette COM64 e Turbo C64) e cartuccia SMAGIC2 (Cassette Viking)
- fixati un paio di bachi in Galadriel e variante XOR, ora il riconoscimento e' al 100%
- aggiunti parametri in versione corta (anziche' -dogaladriel basta -doga, -boostclean diventa -bc, -prgunite diventa -u), dopo un po' diventano anche piu' semplici imho.
- cambiamenti estetici al report, ai nomi dei files e directory generate.
Per ulteriori dettagli c'e' sempre l'history file all'interno.
-
- Trovata una nuova particolare variante Galadriel nelle cassette Edizioni Trinacria. Nonostante abbia 4 headers anziche' 2 header e 2 data blocks e' stato facile aggirarla.
- anticipato il controllo del loader Galadriel, messo prima di quello del TurboTape250 per consentire il riconoscimento della variante POKE in cassette che contenevano entrambi i loader, evitando che vadano in conflitto, perche' la variante poke e' molto simile al TT250.
- applicato un cambiamento per consentire la compilazione sotto *nix (thx Eregil)
- migliorati un pochino i dox, spero.
Da questa release ho incluso tutti i sorgenti, oltre che ai diff, per facilitare la ricompilazione senza dover scaricare la versione 0.20 da sourceforge.
-
- ActionReplay completato, ripulisce al 100% e non lascia bytes non ottimizzati.
- FreezeFrame non completo ma funzionante diciamo al 50%. Ancora inutilizzabile a livello pratico, ma lo sto sviscerando. Per lo meno l'identificazione e l'estrazione parziale dei prg funzionano.
- Parametro -tp per considerare il threshold (valore "di mezzo" tra gli impulsi corti e lunghi) come impulso corto o lungo anziche' considerarlo un read error.
Specificando -tp s verra' considerato corto, -tp l invece lungo. Evita di dover patchare manualmente i tap con un hexeditor quando in un tap con Galadriel ci sono dei valori 0x20 o Easytape con 0x2F (e sono davvero frequenti). Basta provare prima con -tp s, controllare il report e i prg generati, se il CRC fosse ancora sbagliato, riprovare con -tp l.- parametro -removetrail (-r) per rimuovere un eventuale ultimo blocco marchiato come Unrecognized. Spesso si trovano in tap spezzati con vecchie versioni di STAP o dumps effettuati da cassette sovrascritte, con parte della vecchia registrazione, inutilizzata, dopo il programma vero e proprio. Anche questa e' un ulteriore aggiunta "alla bisogna", che evita di troncare il tap manualmente con un hexeditor.
- restyling di un paio di sorgenti, galadriel.c & easytape.c rinominati levando la parte "turbotape_", piu' altre pulizie di codice qua e la'
- aggiornati altri sorgenti prendendoli dal CVS della 0.21, pur adattandoli alla mia:
scanners/c64tape.c?revision=1.11 - seq file support and M/L ambiguity
(& re-added missing #include crc32.h)
scanners/pavloda.c?revision=1.4 - Enhanced to acknowledge a block...etc
scanners/_scanners.h?revision=1.13 - new pav_readbyte() proto
main.c - moved make/save_prgs from analyze() to end of report()[/list]Dato che ci sto lavorando anche in questo momento l'ho denominata beta, ma vale la pena aggiornarla, se vi pare.
tapclean-0.20.g12beta3.rar (http://iancoog.altervista.org/tapclean.htm)
-
- Trovata una ennesima variante Galadriel, veniva confusa con la precedente versione con 4 headers, ora sono differenziate e perfettamente "capite"
- Cambiamento cosmetico: ora il nome dello scanner corrente durante la fase di controllo viene stampato sulla stessa riga evitando che vengano stampati uno di fianco all'altro che imho stava malissimo. Quando un loader di quelli aggiunti da me viene individuato, viene stampato andando a capo, consentendo di vedere a colpo d'occhio quali varianti vengono trovate.
Questa modifica mi ha costretto a toccare tutti i sorgenti in scanners\ ma ne e' valsa la pena.- aggiunti messaggi informativi riguardo ai read errors nei report, per i loader aggiuntivi, per individuare meglio quali bytes vanno patchati manualmente. Ho preso spunto dallo stesso messaggio che appare in accolade.c
Avendolo ritestato a fondo lo faccio uscire dalla fase di beta. Graditi feedback e bugreports, ovviamente :paolone:
tapclean-0.20.g12.7z (http://iancoog.altervista.org/tapclean.htm)
-
- Dopo una attenta analisi incrociata dei loaders ho notato che Load'n'Run/Com64/Next/7notebit usano tutti degli hack del TurboTape250, non e' necessario uno scanner apposito, ma basta usare il TT250 con parametri diversi.
Eliminato quindi loadnrun.c e cambiato turbotape.c per supportare le chiamate generiche. La maggior parte dei TAP summenzionati ora sono riconoscibili al 100%, salvo eventuali sporcizie.
Dovro' adattare anche Easytape per lavorare nello stesso modo, piu' generico e senza per forza esaminare il CBM block.- Sto continuando a studiare un metodo per far riconoscere e ripulire i detestabili tap modificati da Blackhawk/F2cg (dal sito XP64), seppur interessanti dal punto di vista del coding. Ho notato che gli headers e i CBM blocks non terminano correttamente, facendo letteralmente impazzire tapclean, dopo un patch manuale aggiungendo "V0" (e almeno 79 "0" dopo il 2o CBM block) finalmente si riesce a derivare che si tratta di un loader Poke/reversed, che carica un altro loader Galadriel (o a volte Easytape) a $C000 ma subito rilocato a $03xx come quelli normali, ogni volta diverso e customizzato, alcuni con effetti visivi durante il load, altri con schermo spento e alla fine appare la schermata aggiuntiva. E' quindi necessario trovare un ennesimo kludge per far ri-scannare questo loader una volta trovato.
tapclean-0.20.g13.7z (http://iancoog.altervista.org/tapclean.htm)
-
Annuncio solo che 4 dei 7 loaders di Blackhawk/f2cg^Xp64 che ho trovato finora sono caduti e vengono riconosciuti/estratti al 100% :metallica:
Diciamo che senza patch manuale dei terminatori dell'header un tap viene riconosciuto al 99% perche' anche usando -noc64eof (-e) oltre che -n -doga , gli headers non vengono del tutto identificati, ma almeno il loader principale si, e cosi' posso decodificare quello secondario e decidere se rieseguire lo scan da quel punto modificando i parametri.
tapclean-0.20.g14beta1.7z (http://iancoog.altervista.org/tapclean.htm)
-
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.
-
- 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 (http://iancoog.altervista.org/tapclean.htm)
-
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 (http://iancoog.altervista.org/tapclean.htm)
-
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 (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.
-
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.
-
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, 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.
-
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'è.
-
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.
-
Con un bell'hack ad personam in clean.c
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
-
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...
-
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.
-
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.
-
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
-
Non e' un caso, dal log del mio ultimo commit si legge:
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.
-
Approfittando di questo giorno di vacanza e facendo finta che non abbia niente di meglio da fare, ho corretto un paio di bachi nel parser e nella decodifica dei tap Vic20 che in effetti non andava come avrebbe dovuto :stordita:
Queste le modifiche dall'ultima release:- Modificata la readttbit() per correggere automaticamente la lettura di valori "medi" (threshold) quando incontrati e quando si specifica -tp s/l. Necessario in alcuni tap galadriel quando trovava un 0x20 nell'header, ora vengono riconosciuti grazie a questa aggiunta. Vedere l'HISTORY per ulteriori dettagli
- I parametri -20, -16, -ntsc non settavano a FALSE gli altri parametri, quindi risultava sempre attivato lo scan con C64 PAL.
- I valori degli impulsi per Vic20 erano sballati e nessun tap Vic20 veniva ripulito.
Ora sono corretti[/list]A quanto pare i tap C16 non sono ancora supportati, ma finche' nessuno si lamenta, e io non capiro' come sono fatti, rimarranno cosi'.
Chi lo vuole lo piglia QUA (http://iancoog.altervista.org/tapclean.htm) chi non lo vuole lo pigli pure in Q
-
Ciao iAN, per quel che ricordo il C16/Plus4 avevano una frequenza di registrazione del segnale diversa da quella degli altri computer commodore (c64, vic 20, c128, pet)..
ciao
-
Si :) lo so sia io che chi ha implementato tapclean, vedi main.c funzione handle_cps(), cosi' come ho scritto nell'history:
- C16 tapes are still not supported correctly.
Found some with
sp = 0x35
mp = 0x6A
lp = 0xD4
others with
sp = 0x34
mp = 0x64
lp = 0xC9
but nothing happens on cleaning/extraction. Must investigate.
(a volte mi chiedo proprio chi diavolo me lo faccia fare a scrivere la documentazione)
Resta il fatto che anche variando i valori nessun tap viene riconosciuto, e non ho ne' tempo ne voglia di vedere cos'altro c'e' che non va nel riconoscimento di quei tap.