Tapclean + Galadriel Support

[iAN CooG]

 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.

 

[fab]

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

[iAN CooG]

 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.  

[iAN CooG]

 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

[iAN CooG]

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

[fab]

 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.

[fab]

 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)

[tce]

 

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

Codice: [Seleziona]

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

[tce]

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

[fab]

 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.

[iAN CooG]

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

[tce]

 

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

Un esempio di cio' che fa lo script lo trovate su:

tcreport

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]

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

[iAN CooG]

 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.

[tce]

 

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